脆弱性や CVE を探索する際、最大の課題は「探索空間」の広さです。アタックサーフェスは事実上無限に近く、そのためバグバウンティハンターにとっては、ターゲット選定こそが最も重要なスキルだと考えられることがよくあります。
本記事では、私が探索空間をどのように絞り込んでいったか、そのプロセスを振り返ります。数百万行のコードから、問題のあるわずか 3 行を特定するまで。その過程では、最新の LLM エージェントはもちろん、アプリケーションセキュリティにおける長年の経験も大きな助けとなりました。この経験があったからこそ、 報酬ハッキング寄りに調整されたエージェントで頻発しがちな誤検知を回避できました。
探索空間
2025 年 10 月、Wiz は Google Cloud、AWS、Microsoft という 3 大クラウドプロバイダーと提携し、「Zeroday Cloud」と名付けられた新しいハッキングコンテストを発表しました。Pwn2Own のようなハッキング大会に着想を得た Zeroday Cloud では、クラウドプロバイダーがクラウドサービスの構築・運用に広く利用している、20 のオープンソースソフトウェア(ライブラリ、アプリケーション、ツールキット)が対象として選定されました。このコンテストの目標は、シンプルではあるものの非常にハードルの高いものでした。すなわち、対象に対する 未認証のリモートコード実行(RCE) を実証することです。
境界条件の設定
膨大な探索空間の中で、最初のターゲットは 20 のリポジトリに限定されました。認証バイパスの可能性はいったん脇に置き、さらにコードパスを未認証ユーザーがアクセス可能な部分のみに絞り込みます。加えて、ほとんどのターゲットルールでは、エクスプロイトはネットワーク経由、通常はローカルの HTTP API サーバーを通じて実行されることが指定されています。
出発点
最初の糸口を得るために、選択肢は 2 つあります。従来であれば、ソースコードやアプリケーションロジックを手作業で確認し、怪しい機能を探します。ファイルアップロード、スクリプトエンジン、ドキュメントレンダラーなどは、任意コード実行につながりやすい領域です。
私は、依然として広い探索空間と限られた時間を考慮し、別のアプローチを選びました。ターゲットは公開されているコードリポジトリであるため、静的コード解析ツールをコードベースに適用し、調査の手がかりを生成したのです。
以下のスクリーンショットにあるように、各ターゲットごとに数十、場合によっては数百のコード検出結果が生成されました。これらが、LLM 支援による脆弱性ハンティングの出発点となりました。
Claude を使ったテイントトレーシング
すべてのコード検出結果が同じように興味深いわけではありません。コンテストの目的であるリモートコード実行につながる可能性があるものだけを調査対象としました。具体的には、次のような問題です。
- “Eval detected”
- “Shell=True in Subprocess call”
- “Pickles deserialization in Pytorch”
- “Non-static Command in Exec”
- “User input in path.join”
- “Dangerous Write Command”
プロンプトは、コード行やフラグ付けされた問題に応じて変えていましたが、共通するテーマはありました。
例示プロンプト：
私は静的解析ツールを使ってコード内の脆弱性を特定しています。このコード行は、コードインジェクションおよび実行の可能性があるポイントとして検出されました。あなたのタスクは、この行で実行される入力の起点をさかのぼり、どこかの時点でユーザー制御、または影響を受け得るかどうかを確認することです。入力がどのように処理され、最終的にこの行に到達したのかを、詳細な分析として回答してください。
競合する大規模言語モデル
Gemini 2.5 と Claude Sonnet 4.5 は、どちらも疑わしいコード行における入力の起点を追跡する点では、十分に良い結果を示しました。インジェクションポイントから入力をさかのぼり、その過程で行われる変換や加工を、体系的に説明してくれます。
両者の違いが明確に表れたのは、「悪用可能性」の分析でした。一方は懐疑的かつ保守的な姿勢を取り、もう一方は潜在的なリスクを積極的に見つけ、周辺的な脆弱性まで探ろうとします。ここでは、静的解析結果の初期トリアージにおいて、両者がどのように振る舞ったかを見ていきます。
保守的なアーキテクチャ vs 意欲的なインターン
Gemini のペルソナは、白髪交じりで懐疑的なアーキテクトと表現できるでしょう。任意コード実行の可能性を評価するよう求められると、その回答は保守的で、悪用経路についても想像力に乏しいものになります。過度に前向きになることもなく、「型破り」な発想をすることもありません。
ここでは、Gemini 2.5 が、特定のコード行について「問題はない」と私を説得しようとしています(図 A：Gemini の保守的トリアージ)。実行されるコードが設定ファイル由来であるという理由から、悪用は不可能だと強く信じており、さらなる調査につながる思考の扉を閉ざそうとします。
一方で Claude は、非常に意欲的なインターンのようです。優秀ではあるものの、落ち着きがありません。視野の広さに欠ける部分を、「あらゆる塹壕を確認したい」という強い意欲で補っています。同じプロンプトに対する回答でも、テイント解析による任意コードインジェクションの検出という本来の目的から大きく逸れ、他の潜在的なセキュリティリスクについて楽観的な主張を展開します。
ここでは、Claude が次のステップを積極的に提案する様子が見られます(図 B：Claude の前のめりな姿勢)。私の経験上、Claude Sonnet が「何らかの脆弱性の可能性」を示唆せずに回答したことはありません。以下に示すように、緩和策を説明する場合でさえ、それらは「正しく実装されなければリスクになり得る」という形で提示されます。
あなたがブラックボード・アーキテクチャである
このワークフローでは、自然と「人間であるあなた」がループ内の必須エキスパートとして登場します。私は、保守的なアーキテクトの閉じた思考に対して異議を唱える役割を担い、同時に、意欲的なインターンの提案に対しては冷静な立場を取るようになりました。一方のモデルともう一方のモデルをぶつけ、より良い提案を選び取る。この実践こそが、ブラックボード・アーキテクチャです。
ブラックボード・アーキテクチャとは、複数の専門化された大規模言語モデル(LLM)エージェントが協調して、複雑で整理されていない問題を解決するためのデザインパターンです。中央の共有ワークスペース、すなわち「ブラックボード」を通じてエージェント同士が情報をやり取りし、厳密に定義されたワークフローに縛られることなく、段階的に解決策を構築できる点が特徴です。
この概念は、チームでの協働に例えると分かりやすいでしょう。各メンバーが独自のスキルを持ち、直接会話はできないものの、共有されたブラックボードやホワイトボードに書き込むことで意思疎通を図り、解決策を組み上げていきます。
高度なマルチエージェントシステムには、最適な解を選択する「オーバーロード」やエージェントマネージャーが存在します。私の即席ワークフローでは、結果的に私自身がブラックボードであり、エージェントマネージャーであり、強い個性同士を調停する役割を果たしていました。
成功のより広い定義
では、このワークフローは成果をもたらしたのでしょうか。結論から言えば、当初期待していた形ではありませんでした。オープンソースコードの潜在的な脆弱性を数週間にわたってトリアージしましたが、未認証のリモートコード実行という厳格な目標を達成することはできませんでした。
しかし、Claude の好奇心と、私自身が積極的に寄り道を許容したことで、これまで特定されていなかった興味深い問題をコードベースの中に見つけることができました。
AI を使ってバグを探す多くの脆弱性研究者は、「効率の最適化」を目指しているのだと思います。最小限の試行回数で、スコープ内かつ CVSS 10.0 級の脆弱性を見つけること。しかしその結果、人間の直感が脆弱性発見において果たす余地が、依然として残されています。少なくとも現時点では、私たちは依然として不可欠な「人間の専門家」としてループの中に存在しているのです。
90 日後に予定している続編では、AI 支援バグハンティングについてさらに掘り下げ、複数の AI エージェントの支援によって私が発見した脆弱性の具体的な内容を紹介する予定です。ぜひご期待ください。
