コードとドキュメントの活用
要約
ブラックボックステストは盲目的です。ホワイトボックステストは正確です。リポジトリを接続してシステムに完全な可視性を与え、そのうえでコンテキスト欄とファイルアップロードを使って不足部分を補ってください。
リポジトリ
ホワイトボックステストを有効化
ソースコードがなければ、システムのスキャンは盲目的になります。リポジトリを接続することで、テストは外側からの推測から内部検証へと進化します。
リポジトリを接続することは、あなたが取れる中で最も影響の大きい単一のステップです。外側からエンドポイントをただ試すのではなく、システムは実際のソースコードを解析してアプリケーションがデータをどのように処理するかを理解します。
〜に定型指示をコミットする AGENTS.md エージェントがあなたのアーキテクチャと許容済みのリスクに従えるように、リポジトリのルートに。参照 リポジトリファイルでエージェントをガイドする.
- 重要な理由: 外部スキャンでは到底見えない、深いロジック上の脆弱性を見つけます。
- 選択する内容: スコープに含まれるすべてのリポジトリ（フロントエンド、バックエンド、IaC）を含めてください。
- 1回のペンテストで接続できるリポジトリ数には上限があります。これにより、ペンテストを1つのアプリケーションに絞ることができます。無関係なサービスでスコープを過剰に広げると、分析の深さが損なわれる可能性があります。
- もっと必要ですか？ アプリケーションに必要なリポジトリ数が上限を超える場合は、サポートチームまでご連絡ください。お客様の具体的なユースケースに応じて上限を引き上げることができます。
- 結果: システムはソースからルートとロジックを直接マッピングします。API構造を推測する必要はなく、読み取るだけです。
リポジトリ内のパスを除外する
モノレポの場合は、次をクリック 除外するパス 選択したリポジトリの横で特定のディレクトリを除外し、ペンテストをスコープ内のサービスに集中させます。除外されたパスは、 適正化された クレジット見積もりにも反映されるため、推奨量はテスト対象のコードのみを反映します。
攻撃対象領域に実質的に影響するファイルのみが見積もりの対象になります。画像、ドキュメント、README、その他の非コード資産を除外してもクレジット見積もりは下がらず、推奨もしません。Aikido はこれらをコンテキストとして使用し、アプリケーションの理解を深めることで、ペンテストの品質を向上させます。代わりに、無関係なサービスやアプリケーションを除外してください。
パスのマッチングの仕組み
リポジトリのルートからの「 先頭一致 」ルールで照合されます。ディレクトリパスを入力すると、そのディレクトリとその下のすべて（すべてのファイルとフォルダを含む）が除外されます。
ワイルドカードはサポートされていません。 次のような文字は * パス内では文字通りの文字として扱われ、パターンとしては扱われません。たとえば、 /path/* という名前のファイルまたはフォルダを文字通り除外します *、/path 配下のすべてのファイルではありません /path。ディレクトリ全体を除外するには、ディレクトリのパス自体を入力してください（例: /path).
| 入力したパス | 除外される対象 |
|---|---|
/services/legacy | 次の services/legacy ディレクトリと、その下にあるすべてのファイルおよびフォルダ |
/apps/admin | 次の apps/admin ディレクトリと、その中にネストされたすべてのもの |
/README.md | 対象となるのはファイル README.md リポジトリのルートにある |
データのアップロード
ファイルは、コードだけではわからない構造的要素を補います。
- OpenAPI スペック（JSON / YAML）: API サーフェス全体の完全なマップをシステムに提供します。これにより、クロールできるエンドポイントだけでなく、すべてのエンドポイントとやり取りし、攻撃できるようになります。
- オフラインドキュメント（README.md / スペック）: 対象とその脅威モデルについてシステムに深いコンテキストを与え、意図された設計と実際の脆弱性を見分ける助けになります。
- ユーザーロールの定義: サポートされるロール（例: Admin と Viewer）と、それぞれの制約の一覧です。システムはこれを使って、特定のユーザーが すべきではない アクセスが可能かどうかを厳密にテストします。
- ワークフローと全体構造: 「Checkout」や「Onboarding」のような複雑なフローの説明と、アプリ全体の一般的な構造。
- 過去のペンテストレポート（PDF）: システムに過去のデータを与えます。これを使って、以前の修正を検証（回帰テスト）し、コードの別の箇所にある同種のバグの変種を探します。
データの永続化
私たちは、実用上の2つの理由から、あなたのデータを暗号化して保持します:
1. 継続的なペンテストと再現性 セキュリティは一度きりではありません。再スキャンや継続テストを実行するとき、テストの一貫性を確保するためにこれらの攻撃リソースを使用します。スキャンがトリガーされるたびにスコープを再設定したくはないはずです。
2. 監査と法的防御 SOC2 や ISO 27001 では、 どのように テストしたかを証明する必要があります。私たちは、このデータを保持して、反論可能な監査証跡を作成します。これにより、何がスコープに含まれていたのかを正確に説明でき、表面的なスキャンではなく、完全なホワイトボックス可視性をもってテストが実施されたことを証明できます。
追加メモ
コードは構文を示しますが、意図までは常に示すとは限りません。リポジトリやドキュメントで明示されていない、価値のあるものがあればこのテキストボックスに入力してください。
- ビジネスロジック: バグのように見えても実際にはそうではないルールを説明してください（例:「管理者はすべてのユーザーデータを閲覧できる」）。
- アーキテクチャ上の癖: 「OAuth のカスタム実装を使っている」または「このサービスではデータベースは読み取り専用です。」
- 既知のギャップ: 「リポジトリ内の API ドキュメントは、支払いサービスについては少し古くなっています。」
ドキュメントリンクを追加
ドキュメントがオンラインで公開されている場合は、URL を直接追加できます。
