コードとドキュメントの活用

TL;DR

ブラックボックステストは盲目的です。ホワイトボックステストは正確です。リポジトリを接続してシステムに完全な可視性を与え、その後コンテキスト欄とファイルアップロードで不足分を補ってください。

リポジトリ

ホワイトボックステストを有効化 ソースコードがなければ、システムは盲目的にスキャンします。リポジトリを接続すると、テストは外部からの推測ではなく内部検証へと格上げされます。

リポジトリを接続することは、あなたが取れる最も効果の高い一手です。外側からエンドポイントをただ試すのではなく、システムは実際のソースコードを解析して、アプリケーションがデータをどのように処理しているかを理解します。

重要な理由： 外部スキャンではどうしても見えない、深いロジックの脆弱性を見つけます。
選択する項目： スコープに含まれるすべてのリポジトリ（フロントエンド、バックエンド、IaC）を含めてください。
- 1回のペンテストにつき接続できるリポジトリは最大6件です。この上限により、ペンテストが1つのアプリケーション向けに最適に構成されます。無関係なサービスでスコープを過剰にすると、分析の深さが薄まる可能性があります。
- さらに必要ですか？ アプリケーションが6件を超えるリポジトリに依存している場合は、サポートチームまでご連絡ください。個別のユースケースに合わせて上限を引き上げることができます。
結果： システムはソースからルートとロジックを直接把握します。API構造を推測する必要はなく、読み取るのです。

リポジトリからパスを除外する

モノレポの場合は、 パスを除外 選択したリポジトリの横にあるをクリックし、特定のディレクトリを除外して、ペンテストをスコープ内のサービスに集中させてください。除外されたパスはまた、 適正化された クレジット見積もりからも除外されるため、推奨量はテスト対象のコードのみを反映します。

攻撃面に実質的な影響を与えるファイルのみが見積もりにカウントされます。画像、ドキュメント、README、その他の非コード資産を除外してもクレジット見積もりは下がらず、推奨しません。Aikido はこれらをコンテキストとして使い、アプリケーションをよりよく理解することで、ペンテストの品質を向上させます。代わりに無関係なサービスやアプリケーションを除外してください。

Exclude Paths button next to a selected repository

パス照合の仕組み

パスは、 先頭一致 というルールでリポジトリのルートから照合されます。ディレクトリパスを入力すると、そのディレクトリとその配下のすべて（すべてのファイルとフォルダを含む）が除外されます。

ワイルドカードはサポートされていません。 のような文字は * パス内ではパターンではなくリテラル文字として扱われます。たとえば、 /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 では、 どのように テストしたかを証明する必要があります。私たちは、反証可能な監査証跡を作成するためにこのデータを保持しています。これにより、何がスコープに含まれていたかを正確に正当化し、表面的なスキャンではなく完全なホワイトボックス可視性のもとでテストが行われたことを証明できます。