orchestrating-vulnerability-research

脆弱性調査のオーケストレーション

1人のエージェントが1つの対象を調査すると、都合のよい解釈をしがちです。「おそらく悪用可能な」経路を見つけ、自信たっぷりの説明を書き、その説明を自ら発見事項と評価します。しかし、その説明はバグではありません。このスキルは、それを防ぐためのハーネスです。調査が言い逃れできない基準を設け、対象を分割して並行作業させ、候補を作ったエージェントには、それが本物かどうかを判断させません。

これは一度きりの作業ではなく、ループです。発見事項が立証されるか、対象を本当に調べ尽くすまで実行します。もっともらしい報告が最初に出た時点で終わりにはしません。

使用する場合

• 多数のエージェントを動かせる状況で、コードベース全体、バイナリ、または名前の指定された稼働中の対象について、未知の脆弱性を見つけるよう指示された場合
• 深さと新規性が一度きりの網羅性レポートより重要な、バグバウンティや調査キャンペーンを実施する場合
• 1回の監査やテストで進展が止まった、または未立証の「可能性あり」という発見事項しか得られず、独立した批評者にそれを崩すか裏付けてもらいたい場合
• 並列展開と反復に使える予算があり、全体の取り組みを通じて、作成者と批評者の分離、およびトリガー実証の基準を徹底したい場合

使用しない場合

• 網羅性を重視したソースツリーの集中的なレビュー（クライアント監査、1回限りの作業、網羅性をまとめた表の提出物）— auditing-code-for-vulnerabilities を直接使用してください。このスキルはそれをディスパッチするものであり、置き換えるものではありません
• 単一のバイナリのリバースエンジニアリングやトリアージ — analyzing-binaries を使用してください
• 1つのWebアプリやAPIを系統的にブラックボックステストする場合 — testing-web-applications または testing-apis を使用してください
• 立証済みの発見事項を報告書にまとめる場合 — reporting-security-findings を使用してください
• キャンペーンの証拠、出所情報、行き止まりを追跡する場合 — maintaining-engagement-state を使用してください。このスキルはその記録を作成しますが、形式を定めるものではありません
• 誰かがすでに仕込んだWebシェルやバックドアを探す場合（潜在的な脆弱性ではありません）— hunting-web-backdoors を使用してください
• 状態を保持しない単発の確認 — 「この関数1つにインジェクションの脆弱性があるか？」という問いには、ビルダーを1回呼び出せば十分で、キャンペーンは不要です。ハーネスのオーバーヘッドに見合うのは、大規模な調査の場合だけです。

ループ

5つの役割を、対象の各スライスに対するループとして実行します。リードは調査も評価もせず、分解、ディスパッチ、調整を担当します。

decompose → build → critique → iterate → smooth
   lead      hunter   critic     hunter    lead

1. 分解 — 独立して調査できる最小のスライスに分割する

リードは対象を、それぞれ単独で調査・評価でき、相互に影響しない単位に分割します。適切なスライスは、入口となるサーフェスが1つで、到達可能な範囲が限定されています。各部分が独立する軸に沿ってスライスします。

対象	スライスの軸
コードベース	エントリーポイント（ルート／ハンドラー／コンシューマー）、またはバグクラス × コンポーネント
バイナリ	エクスポート済みまたは到達可能な関数群、パーサー、IPC／RPC サーフェス
名前の指定された稼働中の対象	ホスト／サービス、次にエンドポイントまたはプロトコル

ディスパッチする前に、スライスの一覧を書き出します。各スライスには、対象範囲、到達可能なシンクの集合、およびそのスライスで発見事項が満たすべき基準（以下を参照）を記載します。状態を共有するスライスは要注意です。統合しないと、批評者が異なる部分しか見ておらず、意見が食い違うことになります。

2. 作成 — スライスごとにハンターを割り当て、方法ではなく目標を伝える

スライスごとに新しいコンテキストのビルダーエージェントを1つディスパッチし、その対象に適したドメインスキル（auditing-code-for-vulnerabilities、analyzing-binaries、testing-web-applications）を指定します。スライス、保護すべき資産、基準を伝えます。手順を列挙したスクリプトは渡しません。方法を指示すれば、手順をこなして成功したと報告するだけです。目標と基準を伝えれば、実際にそこへ到達しなければなりません。各ハンターは候補（(location, bug class, the trigger it claims, the evidence it has)）を返します。

スライスは、設計上互いに独立しているため、並行して実行します。スライス全体に浅く広く目を通すより、各スライスを深く調べるほうが重要です。トリガーまで完全に実証されたバグ1件には、「怪しい」というメモ20件分の価値があります。

3. 批評 — 独立した批評役が新しいコンテキストで反証を試みる

このスキル全体が徹底させるルールは、ビルダーは自分の成果を決して評価しないということです。各候補は、新しいコンテキストを持ち、反証を任務とする別のエージェントに渡されます。そのエージェントが調べるのは実際の成果物です。実行中のバイナリ、実際の HTTP レスポンス、実行したテスト、読み直したソースであり、ハンターがまとめた内容ではありません。

基準となるのはトリガーが実証されていることであり、批評役はそれが満たされたかどうかだけを問います。

• コードベース：攻撃者の制御が保たれたまま、経路上のすべてのバリデーターを通過してシンクに到達する具体的な入力はありますか？「到達できそう」では不十分です。
• バイナリ：制御された入力でクラッシュまたは状態破損が発生し、その原因も理解できていますか？「この memcpy は長さの制限がないように見える」では不十分です。
• 稼働中のターゲット：リクエストによって、弱点を証明する異常なレスポンスが再現性をもって返されましたか？「エラーからインジェクションが疑われる」では不十分です。

基準を満たしていない場合、批評役は候補と実証済みのバグとの間にある最大のギャップを一つ挙げます。欠けている到達性の確認、ハンターが考慮していなかったバリデーター、実際には実行していない入力などです。そのギャップが次のラウンドの作業指示になります。「証明されていない」とだけ述べる批評役は失格です。何を示せば証明できるのか、または否定できるのかを明確にしなければなりません。

批評役が反証を試みるように促してください。真剣に崩そうとするエージェントの検証を通過した候補は、ビルダーが悪用可能だと断言した候補の10倍の価値があります。影響の大きい候補については、同じ視点の批評役を3人そろえるのではなく、異なる視点（到達性、緩和策、実際に実行されるか）を持つ批評役を複数人起用してください。

4. 反復 — ギャップをフィードバックし、スライス単位でループする

ビルダーは批評役が指摘したギャップを埋めます。到達性を確認し、実際にトリガーする入力を作成し、バリデーターを考慮します。その後、候補を再び批評役に渡します。次の3つの終了条件のいずれかに達するまで繰り返します。

• 実証済み — 基準を満たし、批評役も反証できませんでした。検出事項として確定し、reporting-security-findings に渡します。
• 棄却 — 批評役が安全性を担保する制御を見つけた場合、または繰り返し試みてもトリガーを実証できなかった場合です。理由とともに、検証済みで問題なしの候補としてエンゲージメントの状態に記録します。棄却した候補もカバレッジの一部であり、同じ経路を再度調査するのを防ぎます。
• 予算 — 収束しないままスライスの割り当て分を使い切った場合です。「疑わしいが未実証」と記録したリードに格下げして先へ進みます。費やした労力を無駄にしないために検出事項へ昇格させてはいけません。

スライスのループを際限なく続けてはいけません。ループで失敗するのは、早く打ち切りすぎることではありません。ビルダーと甘い批評役が未実証の候補をやり取りし続け、証明されたように聞こえるまで続けることです。

5. 統合 — リードがスライス間の結果を突き合わせる

スライスごとのハンティングは互いの結果を知らない状態で行われます。すべての結果を把握するのはリードだけです。スライスごとのループが一段落したら、次の作業を行います。

• 重複を排除する。 同じ根本原因が複数のスライスで見つかった場合、たとえば5つのルートで認証レイヤーのチェックが1つ欠けていた場合、検出事項は5件ではなく、5つの事例を含む1件です。
• 連鎖させる。 あるスライスにある弱いプリミティブと、別のスライスにある到達可能なシンクの組み合わせが、実際にはより深刻なバグであることがよくあります。複数の要素の組み合わせは、単独のハンターには見えません。ここでリードの価値が発揮されます。
• 確認済みのバグについて類似パターンを調査する。 実証済みの検出事項はすべてテンプレートです。調査を終える前に、他のスライスでも同じ間違いがないか調べます。
• カバレッジを突き合わせる。 基準まで調査したスライス、時間制限を設けたスライス、未着手のスライスを明記します。誠実なカバレッジは成果物の根幹です。reporting-security-findings を参照してください。

基準の設定

基準とは、批評者が照らし合わせる参照標準、つまりエージェントが異議を唱えられないものです。調査を始める前に、対象範囲ごとに設定し、説明ではなく実証にします。

• コードベース — 具体的なトリガー入力を伴う、ソースからシンクまでの経路、またはその経路を実行する作成済みの PoC です。「攻撃者が id を制御でき、クエリにテナントのスコープ指定がなく、このリクエストで別のテナントの行が返されます。」
• バイナリ — 障害分析を伴う再現可能な入力です。クラッシュ、破損した状態、そして制御が及ぶかどうかを示します。サニタイザーのレポート（ASan/UBSan）またはファザーで最小化したケースなら基準を満たしますが、曖昧な説明では満たしません。
• 稼働中のターゲット — 異常な挙動を観測して再現し、リクエストとレスポンスを記録します。ブラインド信号や時間ベースの信号は、再現され、環境要因が制御されている場合に限り有効です。

対象範囲を具体的な基準で表現できない場合、まだ十分に分解されていません。批評者が合否を実証的に確認できるよう、各部分に分割してください。

実践での実行方法

エージェント型ハーネス（サブエージェントを使う Claude Code）では、このループは次のように対応します。

• リードはメインコンテキストです。対象範囲のリストと作業の状態を保持し、タスクを割り当てます。
• 各ビルダーと各批評者は、それぞれ独自の新しいコンテキストを持つサブエージェントです。ビルダーのコンテキストを共有する批評者は、その盲点や楽観的な見方も引き継いでしまいます。分離こそが要点です。
• 対象範囲のリスト、候補の作業リスト、各候補の判定を、作業記録（maintaining-engagement-state）に保存します。このループは長期間実行される場合があり、クリア済みの経路を再調査することなく、再起動後も継続できなければなりません。
• 割り当てられた予算に合わせて並列実行数を調整し、調査できなかったものを記録します。 40 件中 10 件を黙ってサンプリングして問題なしと報告するキャンペーンは、10 件を調査してそのことを明記するキャンペーンよりも悪質です。

自動検出ツールは対象範囲内のビルダーであり、このループの代替ではありません。ファザー（AFL++、libFuzzer）、テイントエンジン（CodeQL）、スキャナーはいずれも候補を生成しますが、候補は独立した批評者による確認と同じ基準を満たす必要があります。未検証のツール出力をそのまま発見事項として扱うことこそ、このハーネスが防ごうとしている失敗です。

対象範囲と承認

検出キャンペーンは、対象を広げて繰り返し実行するため、単独のテストより危険です。

• 承認では、ターゲット全体と実施強度を対象にする必要があります。 「X をテストしてよい」は、「クラッシュするまで X の本番パーサーをファジングしてよい」という意味ではありません。ファジング、インジェクションの一括テスト、デシリアライズのプローブといった検出手法は、障害を引き起こしたりデータを破損させたりする可能性があります。並列実行を始める前に、ターゲット、環境（本番環境以外を推奨）、許可される実施強度を書面で確認してください。
• 名前を指定されたターゲットには、第三者の資産も含まれることがあります。 ログインが ID プロバイダーと連携している、アセットが CDN の背後にある、「サブドメイン」が許可されていない SaaS テナントである、といった場合があります。調査前に所有者を洗い出し、各ビルダーを承認済みの境界内に留めてください。並列実行では、気付かないうちに対象範囲を逸脱しやすくなります。
• 所有していないソフトウェアの未知のバグには、開示義務が伴います。 未知の脆弱性は、手柄ではなく協調的な開示の義務です。reporting-security-findings を通じて報告してください。
• 基準を超えて悪用してはなりません。 基準とは、トリガーを実証することです。シンクを制御できると証明することが目標であり、稼働中の第三者システムに対する完全な動作可能なエクスプロイトの作成には、おそらく得ていない別個の承認が必要です。

却下すべき合理化

• 「ハンターが悪用可能だと言ったのだから、指摘事項です。」 それを判断してはならないエージェントがいるとすれば、それはハンターです。独立した批評者による確認、または実際の成果物がなければ、仮説にすぎません。
• 「到達可能に見える／そのバッファーには上限がなさそうだ／エラーからインジェクションが示唆される。」 これらはすべて候補であり、バグではありません。基準となるのは、もっともらしい読み取りではなく、トリガーの実証です。
• 「トークンを節約するために、批評者とビルダーでコンテキストを共有できます。」 そうすると、批評者はビルダーの見落としを引き継ぎ、その楽観的な見方を評価することになります。分離こそが手法であり、それをなくせば価値も失われます。
• 「十分に検証を重ねました。労力を無駄にしないため、昇格させましょう。」 未証明の指摘事項は、小さな成果ではありません。実際の指摘事項の信頼性を損なう誤検知です。文書化した手がかりに格下げし、指摘事項として取り繕わないでください。
• 「あるエージェントが何も見つけなかったのだから、この範囲には問題がありません。」 1 人のハンターが何も見つけなかったのは、1 つの探索戦略で何も見つからなかったというだけです。問題がないと言えるのは、基準を満たすまで調査し、批評者の確認を得た場合であり、「最初の調査で何も出なかった」場合ではありません。
• 「該当しなかった候補を記録する価値はありません。」 確認して問題なしと判断した経路とその理由を記録すれば、網羅性を示せます。これを省くと、次のラウンドで同じ調査が繰り返されるか、さらに悪いことに、未検証のまま報告される可能性があります。
• 「分割は余計な手間です。リポジトリにエージェントを 1 つだけ割り当てればよいのです。」 そうすると、エージェントは自分自身を評価し、もっともらしい段落を最初に見つけた時点で調査をやめてしまいます。分割することで、独立した判断と並行処理が可能になります。

参考資料

• auditing-code-for-vulnerabilities — ソースコードの各範囲を担当するハンター
• analyzing-binaries — コンパイル済みターゲットの各範囲を担当するハンター
• testing-web-applications、testing-apis — ブラックボックス調査の各範囲を担当するハンター
• reporting-security-findings — 実証済みの指摘事項の報告先
• maintaining-engagement-state — 範囲リスト、作業リスト、判定の保存先
• ハンターが探す対象の分類には CWE と OWASP ASVS を使用します