> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/docs/docs-ja/penetorshontesuto/configure-a-pentest/leveraging-code-and-documentation.md).
# コードとドキュメントの活用
## 要するに
ブラックボックステストは盲目的です。ホワイトボックステストは正確です。リポジトリを接続してシステムに完全な可視性を与え、あとはコンテキストボックスとファイルのアップロードで不足分を補ってください。
## リポジトリ
{% hint style="warning" %}
**ホワイトボックステストを有効にする**\
ソースコードがなければ、システムは盲目的にスキャンします。リポジトリを接続すると、テストは外部からの推測から内部検証へと進化します。
{% endhint %}
リポジトリを接続することが、あなたができる最も影響の大きい単一の手順です。外側からエンドポイントをつつくだけでなく、システムは実際のソースコードを解析して、アプリケーションがデータをどのように処理するかを理解します。
* **なぜ重要か:** 外部スキャンでは単純に見えない深いロジックの脆弱性を見つけます。
* **何を選ぶか:** 対象範囲に含まれるすべてのリポジトリ（フロントエンド、バックエンド、IaC）を含めてください。
* ペンテストごとに接続できるリポジトリは最大6件です。この制限により、単一アプリケーション向けにペンテストが最適に構成されます。対象範囲に無関係なサービスを詰め込みすぎると、分析の深さが薄まる可能性があります。
* **もっと必要ですか?** アプリケーションが6件を超えるリポジトリに依存している場合は、サポートチームにご連絡ください。お使いのケースに合わせて上限を引き上げられます。
* **結果:** システムはソースから直接ルートとロジックをマッピングします。API構造を推測する必要はなく、読み取ります。
### リポジトリからパスを除外
モノレポの場合、リポジトリごとに特定のパスを除外して、対象サービスに絞ったペンテストにできます。除外されたパスは、 **適正化された** クレジット見積もりに反映されるため、推奨数量はテスト対象のコードのみを反映します。
{% hint style="info" %}
攻撃対象領域に実質的に影響するファイルだけが見積もりにカウントされます。ドキュメント、README、その他の非コード資産を除外する必要はありません。むしろ、除外しないことをおすすめします。Aikidoはこれらを文脈として使ってアプリケーションをよりよく理解し、それがペンテストの品質向上につながります。
{% endhint %}
## データをアップロード
ファイルは、コードだけでは見えない構造的要素を補います。
* **OpenAPI仕様（JSON / YAML）:** システムにAPI表面の完全なマップを与えます。これにより、クロールできるエンドポイントだけでなく、すべてのエンドポイントとやり取りし、攻撃するようになります。
* **オフラインドキュメント（README.md / 仕様）:** 対象とその脅威モデルに関する深い文脈をシステムに提供し、意図された設計と実際の脆弱性を見分けやすくします。
* **ユーザーロール定義:** サポートされるロールの一覧（例: 管理者対閲覧者）と、それぞれの具体的な制約。システムはこれを使って、特定のユーザーが何にアクセスできるべきでないかを厳密にテストします *べきではない* アクセスできるようにする。
* **ワークフローと全体構成:** 「チェックアウト」や「オンボーディング」のような複雑なフローの説明や、アプリ全体の一般的な構造。
* **過去のペンテストレポート（PDF）:** システムに過去のデータを与えます。これを使って過去の修正を検証し（回帰テスト）、コードの他の場所にある同種のバグの変種を探します。
{% hint style="info" %}
**データの永続化**
私たちは、以下の2つの実用的な理由から、あなたのデータを暗号化して保存します:
1\. 継続的ペンテストと再現性 セキュリティは一度きりのものではありません。再スキャンや継続テストを実行するとき、私たちはこれらの攻撃リソースを使ってテストの一貫性を確保します。スキャンがトリガーされるたびに対象範囲を再設定したくはないはずです。
2\. 監査と法的防御 SOC2やISO 27001では、 *どのように* テストしたかを証明する必要があります。私たちは、監査に耐えうる証跡を作成するためにこのデータを保持します。これにより、何が対象範囲に含まれていたのかを正確に説明でき、テストが単なる表面的なスキャンではなく、完全なホワイトボックス可視性のもとで実施されたことを証明できます。
{% endhint %}
## 追加メモ
コードは構文を示しますが、意図までは常に示してくれるわけではありません。リポジトリやドキュメントに明示されていない、価値のある情報があればこのテキストボックスに記入してください。
* **ビジネスロジック:** バグのように見えても実際にはバグではないルールを説明してください（例:「管理者はすべてのユーザーデータを閲覧できます」）。
* **アーキテクチャ上の癖:** 「OAuthの独自実装を使っています」や「このサービスではデータベースは読み取り専用です」。
* **既知のギャップ:** 「リポジトリ内のAPIドキュメントは、支払いサービスについてやや古くなっています。」
## ドキュメントリンクを追加
ドキュメントがオンラインで公開されている場合は、URLを直接追加できます。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.aikido.dev/docs/docs-ja/penetorshontesuto/configure-a-pentest/leveraging-code-and-documentation.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.