Cloudflareが自社監査ツールをOSS化、核は「反論」の仕組み

Cloudflareは今週、コーディングエージェントをセキュリティ監査人に変えるスキルを公開し、GitHubの週間ランキングで最も伸びたリポジトリになりました。7日間で約16,400スター、累計51,000。同社の説明は驚くほど控えめです。これは社内の脆弱性発見ハーネスが進化してきた単一リポジトリの出発点であり、他のチームが自分たちの環境を築けるように公開したものだ、と。

読む価値があるのは攻撃クラスのカタログではありません。もちろんそれも網羅的ですが、面白いのは「検出結果がどうやって論破されるか」という部分です。

6つのフェーズ、うち1つはただの記録作業

ワークフローは会話的ではなく構造化されています。これが「Claudeにバグを探させる」との最初の違いです。

第1フェーズは偵察です。アーキテクチャ、信頼境界、入力面を洗い出し、ここが珍しいのですが、それをarchitecture.mdとcoverage-ledger.jsonに書き出します。第2フェーズは台帳のユニットに隔離されたハンターを割り当て、各員が何を確認したかを記録し、そのあとカバレッジ・クリティックを走らせて誰も見ていない箇所を探します。第3フェーズは個々の候補を新しい検証者に渡します。その職務は反証することです。第4フェーズはconfirmed、needs_validation、rejectedの記録をfindings.jsonに書き、JSONスキーマで検証します。第5フェーズでは新しいエージェントが最終的なソース上の主張を検証し、実質的な差し替えにはさらに独立した検証者が付きます。第6フェーズは検証済みの記録からレポートを導出します。

2つのバリデータは依存関係のない素のNodeスクリプトです。validate-coverage-ledger.cjsは台帳の作成後と更新のたびに、validate-findings.cjsは第4フェーズと、第5フェーズでの差し替えのたびに実行されます。リポジトリで最も退屈なファイルであり、残り全体を成立させている理由でもあります。スキーマに適合するfindingを出せないエージェントは、発見したと主張できません。

3つの判定こそが設計の本体

エージェント型のセキュリティツールの多くは、出力が2種類しかありません。バグの一覧か、何もなしです。これは3種類あり、中間のカテゴリにこそ思想があります。

confirmedは完全なソースの追跡と、範囲の定まった観測結果を意味します。needs_validationは未解決の事実が1つ正確に特定されていて、深刻度は割り当てない状態。rejectedは積極的に反証された候補で、削除せず記録します。

3つ目は珍しく、そして正しいと思います。反証された候補はコードベースについての証拠です。次の実行にそこへ時間を割くなと伝え、レビュー担当者には何が検討されたかを伝えます。多くのツールはそれを捨ててしまいます。

根底にある設計原則はREADMEにぶっきらぼうに書かれています。確定した境界の破綻だけをconfirmedとし、ソースに根拠のある手掛かりが止まった場合は、findingへ格上げせず、未解決の事実を正確に添えてneeds_validationのままにすること。関連する規則もあります。多層防御の欠落は脆弱性ではない、というものです。A層が攻撃を止めているなら、B層の不在はハードニングのメモにすぎません。

機械生成の脆弱性レポートを読んだことがある人なら、これらの規則の理由はすぐ分かります。LLMによるセキュリティレビューの失敗モードはバグの見落としではありません。「自信に満ちたノイズ」です。脆弱性に見えるパターンが高危険度として報告され、トリアージ班の一週間を潰してしまう。

敵対的検証を、文字通りに

最も重要な一行はこれです。findingを検査するエージェントは、決してそれを見つけたエージェントではありません。

これはプロンプトの指示ではなく、オーケストレーションの制約です。そしてこの種のツールが信頼できる何かを生み出す唯一の方法です。自分の出力について「このfindingは正しいか」と問われたLLMは、自分に同意します。新しいコンテキストと別のエージェント・インスタンス、そして反証という明示的な任務を与えて初めて、コードレビューに近いものが得られます。

第5フェーズはこれをさらに延長します。新しいエージェントが最終的なソース上の主張を検証し、主張が実質的に差し替えられた場合は、別の独立した検証者がその差し替えを確認します。ハンターと生き残る記録の間には、2段階の分離があります。

正直な数字

設計原則の中にこう埋め込まれています。Cloudflareのテスト実行では、1回の実行で見つかる脆弱性は、繰り返し実行して合計で見つかる数のおよそ半分だった、と。

これを公開するのは選択です。ツールが神託ではなくカバレッジの機械であることを示し、ワークフローの意味を変えます。リリース前に一度走らせるのではなく、繰り返し走らせて台帳を積み上げる。リポジトリはこれを明示的に支えています。同じリポジトリへの複数回の実行は加算的で、以前の台帳とfindingsを使ってギャップを狙い、変更されたソースを再検証し、古い作業をカバー済みと扱わずに現在のソースの証拠を引き継ぎます。

半分というのは、人間の監査人が最初のパスで到達する水準としても妥当な見積もりです。それが心強いか絶望的かは、この職業をどう見るかによります。

ほとんどの人を止める要件

READMEには、多くのユーザーが読み飛ばしたあとにぶつかる厳格な要件が並んでいます。ビルド、テスト、プロセス、ブラウザ、エミュレータ、ファザー、フィクスチャのためのOS強制サンドボックス、外部ネットワークの無効化、無害化された許可リスト環境、強制リソース上限、書き込みはスクラッチパスに限定。

これらの制御がない場合、ワークフローは対象コードを実行せず、手掛かりをneeds_validationに留めます。これは正しい判断です。何しろ言語モデルの提案をコードベースに対して走らせているのですから。ただし同時に、コンテナ基盤を持たない人にとっては、静的解析と推論の練習に劣化することを意味します。

また、npxのインストール行があるにもかかわらず、これはラップトップのツールではないということでもあります。インストールは1コマンドです。

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

使い方はただ尋ねるだけです。

security audit this codebase

奇妙な対比です。呼び出しは一文、前提条件はサンドボックス政策。その二つの間の落差が、デプロイ作業の大半を占めることになります。

出力は実際どんな形か

3つの成果物は、書かれるのではなく導出されます。REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md、そして土台となるfindings.jsonとカバレッジ台帳です。

この分割は聞こえ以上に有用です。単一の脆弱性レポートは、すべての検出を同じ語域に押し込みます。だから重大なSQLインジェクションとCSPヘッダの欠落が隣り合って並ぶことになる。確定した検出、未解決の問い、導出された要約を分ければ、NEEDS-VALIDATION.mdを読む人は、自分が見ているのが結果ではなく進行中の作業だと分かります。

既定の出力先は~/security-audit-skill/<repo-name>/run-<N>で、gitignoreされたディレクトリを明示的に指定した場合にだけ、ワークフローは対象リポジトリの内部に書き込みます。小さな詳細ですが、直感は正しい。リポジトリ内の監査成果物は誤ってコミットされ、未修正の脆弱性リストがコミットされること自体が一つのインシデントになります。

うまくいったかどうかを見分ける方法

2回走らせることです。READMEが明言せずに示唆しているテストです。実行は加算的で、1回ではおよそ半分しか見つからないのですから、同じcommitに対する2回目の実行は、そのコードベースにおけるツールのカバレッジの直接測定になります。2回目に新しいものが出てこなければ、あなたのコードがきれいか、狩りのクラスがスタックと合っていないかのどちらかです。

次にrejectedのログを見ます。5件を確認し40件の候補を棄却した実行は、仕事をしています。40件を確認して1件も棄却しなかった実行は、検証を止めています。その40件は、信じる前に自分の目で読むべきです。

このカテゴリについて何を示しているか

3点、手短に。

エージェント・スキルは配布形態になりつつあります。importするライブラリではなく、markdownのフォルダと2つの検証スクリプトで、モデルが実行時に読みます。リポジトリは20数個の指示ファイルと、対象種別ごとに分かれた攻撃クラスのカタログです。メモリ安全とバイナリ、LLMとエージェント面、Webプロトコルと認証、クライアント側、サプライチェーン、クラウドとデプロイ、RPCとメッセージング、リソース枯渇、データ分離、デスクトップとローカルIPC。この構造自体が製品です。

検証が差別化要因になりつつあります。今やどのベンダーも、それらしいfindingを生成できます。しかし、どれが敵対的パスを生き残り、スキーマに書き込まれ、棄却されたものも保存されているかを教えられるベンダーはほとんどありません。

そして「正直な数字」の習慣が広がっています。「半分しか見つからなかった」と公表するベンダーの次の主張は、より信じられます。

リポジトリはMITライセンスです。つまり面白い問いは、動くかどうかではなく、チームがきちんと動かすのに必要なサンドボックスを用意できるかどうかです。