AI エージェント軍団が脆弱性を自動ハント！Cloudflare の脆弱性ハーネスの作り方
こんにちは、しぃちゃんだよ！ 今日はちょっとワクワクする発表を見つけちゃった！ セキュリティのバグを AI エージェントの軍団が自動で探し回る「脆弱性ハーネス」の作り方が、まるっと公開されたんだよ！
Cloudflare Blog
blog.cloudflare.com
なにが発表されたの？
Cloudflare の Blog で「Build your own vulnerability harness（自分だけの脆弱性ハーネスを作ろう）」という記事が公開されたよ。これは製品の告知じゃなくて、Cloudflare が社内で動かしている脆弱性発見システムの技術アーキテクチャを、まるっと解説してくれる Engineering 寄りの深掘り記事なんだ。
システムは大きく 2 つに分かれているよ。
- Vulnerability Discovery Harness（VDH）: バグをどんどん探し出す発見エンジン
- Vulnerability Validation System（VVS）: 見つかった候補を別のモデルで厳しく検証するトリアージ担当
大事なのは「モデルは交換可能な部品」として扱う設計。フロンティアモデルが進化しても、そのとき一番得意なモデルに差し替えられるようにしてあるんだって。
なぜ重要なの？
AI にコードを渡して「バグを探して！」ってお願いするだけだと、それっぽいけど中身のない指摘（誤検知）が山ほど出てきちゃう。しかも 1 つのエージェントに全部やらせると、コンテキストウィンドウがすぐパンパンになって、モデルが自分の記憶を食いつぶしちゃう……なんてことも起きるの。
この記事がすごいのは、そういう「大規模にやると必ずぶつかる壁」をどう乗り越えたかを、具体的に見せてくれるところ。実際に 128 のリポジトリ、Rust・Go・C・Lua・TypeScript・Python みたいな色んな言語をまたいで動かした実績つきなんだよ！
これで何が変わるの？
一番うれしいのは、この考え方が誰でも試せる形で公開されたこと。Cloudflare はこの仕組みのベースになった security-audit-skill を GitHub で公開したんだ。
これはコーディングエージェント向けのスキルで、複数のエージェントを並列に走らせて recon → hunt → validate …… と多段でセキュリティ監査してくれるの。記事いわく、1 回のランで見つかるバグは複数回まわしたときの約半分。だから「何度もまわすほどカバレッジが上がる」という設計思想になっているんだって。
深く潜ってみよう
ここからは仕組みの中身を見ていくよ！
8 段のパイプライン（VDH）
VDH は Recon → Hunt → Validate → Gapfill → Dedup → Trace → Feedback → Report の 8 ステージでできているよ。
- Recon: 3 つの並列エージェントが構造と攻撃経路を地図化して
architecture.mdを作る - Hunt: 攻撃クラスごとのエージェントが、サンドボックスで実際にコード片を動かして攻める
- Validate: まず決定的なスキーマチェック、その後で別のエージェントが「この指摘を否定してやる」と反証を試みる
- Gapfill / Trace / Feedback: 手薄な領域に新しいタスクを生やしたり、依存グラフをたどって別リポジトリへ広げたり、失敗から次のプロンプトを書き換えたり
- Report: これはモデル不要のスクリプトで人間向けに整形
検証担当の VVS は Dedup → Judgment → Fixing の 3 ステージ。Judgment では MCP サーバーや Jira、git 設定なんかも参照して「本番で本当に到達できる経路なのか」まで見るんだって。
状態は全部そとに出す
賢いなと思ったのが、LLM を「状態を持たない計算エンジン」として扱う設計。各ステージの結果は (run_id, repo, stage) をキーに、ぜんぶ 1 つの SQLite に書き出しちゃうの。だからクラッシュしても失うのは実行中の 1 タスクだけ。途中から再開もできるんだよ。
そして各エージェントの担当範囲をうんと狭くして、コンテキスト使用量を常に全体の 25% 未満にキープ。最初は約 450 行の 1 枚岩スキルだったんだけど、1 時間くらいで限界に達したので、フェーズごとのエージェントに分割したんだって。
誤検知をどう潰す？
指摘 1 つひとつに、攻撃者の定義と脅威モデルの明記が必須。しかも動く PoC（概念実証）を、改変していない元のソースに対して実行して通すことが条件なの。「コードをこっそり書き換えて無理やり攻撃を成立させる」のを防ぐためだね。検証役のエージェントは自分では指摘を登録できなくて、ハンター役の説を全力で否定するのが唯一の仕事。しかも VVS は別のモデルを使うから、まったく違う「論理の重み」で二重チェックされるってわけ。
足りないものは wishlist で頼む
エージェントが必要なツールを持っていないとき、中央の wishlist に外部リソースを要求できる仕組みもあるよ。これ、128 リポジトリ全体で 25,472 回も使われたんだって。あと、範囲外の気になるコードを見つけたら、脇道にそれずに「sibling（兄弟）エージェント」を fork して任せる。この分岐はモデルによって 0〜20%、全体だとだいたい 9% くらいのタスクを占めるみたい。
面白いのが、静的解析ツールの Semgrep も組み込んでみたのに、1 か月で呼ばれた回数はゼロ。エージェントたちは自分でコードを読んで動かす方を選んだんだって！
数字で見る効き目
フリート全体だと、VDH が出した生の候補 20,799 件のうち、独立検証を生き延びたのは 12,057 件（約 58%）。Recon を改善したら、検証での却下率が 40% から 11% に下がって、高品質な指摘の割合は 35% から 58% に上がったそう。VVS まで通すと、ほかの情報源も合わせた 13,841 件から、重複 5,442 件と別リポジトリ・低リスク 1,154 件をふるい落として、最終的にエンジニアに渡す実用的な指摘は 7,245 件になったよ。
Cloudflare が約 30k 行の 1 リポジトリで走らせたときは、生の候補 100 件 → 圧縮後 80 件、発見に 3〜4 時間、自動 Fixer は 1 バグあたり約 5 分、発見から PR 生成まで通しておよそ 14 時間だったそう。ただし修正を勝手にマージすることは絶対になくて、人間のレビューが必須。ここは譲れない安全弁なんだって。
まとめ
- Cloudflare が社内の脆弱性発見システム（VDH と VVS）のアーキテクチャを丸ごと解説してくれたよ
- LLM は状態を持たない部品として扱い、状態は SQLite に外出し。コンテキストは常に 25% 未満にキープ
- 発見役と検証役でモデルを変えて、PoC 必須・元コード改変禁止で誤検知を撲滅
- フリート全体で 20,799 件の候補を 7,245 件の実用的な指摘まで絞り込み
- ベースになった
security-audit-skillは GitHub で公開ずみだから、自分のエージェントで試せる - セキュリティの自動化や AI エージェントの設計に興味があるエンジニアに、グッと刺さる内容だよ！
