LLMを絶対に信用しない。Cloudflareが公開した「AI脆弱性発見ハーネス」の設計思想が凄すぎる
セキュリティで何使ってるの？と海外コミュニティで色んな人に聞いたら結構入れていたのでご共有ですー。わたしも入れてますっ
根拠は簡単。
セキュリティで安定してそうな会社が出しているから、です。
PR コメント
転職サイトGreen様の掲載にご協力させて頂いています。
IT/Web業界の求人・中途採用情報に強い転職サイトGreen(グリーン)
GreenはIT業界最大級の転職サービス。エンジニア・デザイナー等のIT職から営業・管理部門まで幅広い職種を掲載。
IT・Web系を中心に、フルリモート可能な求人も掲載されております。
覗きに行くだけでも、ぜひ。
近年、AIコーディングエージェントにコードレビューやセキュリティ診断を任せる試みが増えています。
しかし、実際にやらせてみると「ベストプラクティス違反を脆弱性だと大騒ぎする」「ハルシネーションのPoCを作る」「多層防御の欠如を過剰報告する」といったノイズに悩まされた経験はないでしょうか。
そんな中、GitHubで4万スター超えの熱狂的な支持を集めているのが、Cloudflareが公開した`cloudflare/security-audit-skill`。
このリポジトリの根底にあるのは、びっくりするくらい徹底的な哲学。
「LLMは信頼対象ではない。交換可能な部品にすぎない」
「モデルは飾りであり、手続き（厳密なプロセスと機械検証）こそが本番である」
AIを「賢いレビュアー」として崇めるのをやめ、コードとプロセスでAIを雁字搦めにして正しい報告しか出せない「ハーネス」へと仕立て上げる。
その圧倒的な設計思想と仕組みを紐解きたいという内容ですー。
1. AIセキュリティ診断が破綻する「10のアンチパターン」
Cloudflareは、エージェントがセキュリティ監査で犯しがちな過ちを「アンチパターン」として厳しく定義しています。
チェックリストからの逸脱を「脆弱性」として報告する
到達可能な境界違反がないのに「多層防御」のアドバイスをする
ローカルの証拠で十分なのに、勝手に外部環境や本番環境をテストする
ソースコードにないプロキシやクラウド環境の挙動を勝手に推測する
単一権限のスコープ内での出来事を「境界越え」と誤認する
実際に観察された結果以上のランタイム影響を大げさに報告する
検証不能なプレーンテキストだけで調査結果を返す
前回の監査結果に引っ張られて同じ結論をなぞる
事実が未確定な調査項目に深刻度を勝手に付ける
独立検証を通す前に勝手にレポートを書き上げる
「あ、これAIにやらせたときに見たことある……」と思った方も多いのではないでしょうか。このスキルは、これらをプロンプトの工夫ではなく「システムの構造」で物理的に防ぎます。
わたしは良くOpusくんで2,3,4を見かけますね。
Geminiくんは8,9,10が多いイメージ。
2. 妥協なき「6フェーズ」の監査ワークフロー
フル監査モードにおいて、エージェントは必ず以下の6段階を順番通りに実行させられます。途中で「見つかりました！」とショートカットすることは許されません。
[Phase 1] 偵察 (Recon)
│ 4体の並行リサーチエージェントが測量、決定論的な「カバレッジ台帳」を作成
▼
[Phase 2] カバレッジ主導の探索 (Hunt)
│ ユニットごとに分離されたHunterを投入。波（Wave）ごとに「批評家」が穴を塞ぐ
▼
[Phase 3] 候補検証 (Validate)
│ 発見者とは「別のエージェント（Verifier）」が全力で論破しに行く
▼
[Phase 4] 構造化出力 (Output)
│ findings.json を出力。依存ゼロのNode.jsスクリプトが機械検証
▼
[Phase 5] 独立レコード検証 (Re-verify)
│ さらに別の新規エージェントが最終検証
▼
[Phase 6] 中立的レポート (Report)
│ 検証済みデータのみからレポートを導出監査の終了条件は極めて厳格で、「Phase 6の全成果物が機械バリデータを通る」か、「予算枯渇などの理由で `run_status: "incomplete"` と明記して終了する」かの2通りしかありません。
3. 核となる3つの設計アーキテクチャ
①「発見者」と「検証者」を絶対に同じにしない（対抗的検証）
人間でも、自分が苦労して見つけたバグを「これはバグじゃないかも」と自己否定するのは難しいもの。
LLMなら尚更、自身の出力にバイアスがかかっちゃいます。
そのため、このシステムでは候補を見つけたエージェント＝Hunterとは別の新規エージェント＝Verifierを立ち上げ、「その候補を論破（反証）してね」という真逆のタスクを与えます。
検証者は自ら新しい脆弱性を報告することはできず、ただHunterの主張を崩すためだけに動きます。
② 親エージェントだけが書ける「決定論的カバレッジ台帳」
エージェントが「ざっくり認証まわり見ました」と報告しても、何を見たのか誰にも分かりません。
このスキルでは、Phase 1でコードベースを以下の4元組で分解し、`coverage-ledger.json` という台帳を作ります。
入力面（Surface） × 信頼境界（Boundary） × サブシステム（Subsystem） × 攻撃クラス（Attack Class）
このユニット単位でタスクが割り当てられ、状態マシン（`planned` → `in_progress` → `covered` / `candidate` / `blocked`）に従って厳密に更新されます。エージェントが勝手にファイルを書き換えることはできず、親（Parent）エージェントのみが台帳の書き込み権限を持ちます。
③ 厳格なサンドボックスとエージェント分離
エージェントごとに独立した作業ディレクトリ（`scratch/`）が与えられ、共有領域やターゲットコードへの直接書き込みは禁止。
成果物の取り込みには11ステップに及ぶシンボリックリンク追跡防止（no-follow）手順が踏まれます。
また、PoCコードを実行する際は「外部ネットワーク完全遮断」「環境変数空」「読み取り専用ツールチェーン」「リソース低上限」のOSサンドボックスが必須要件となっています。
4. 機械検証を通す「3つの判定（Verdicts）」
監査結果（`findings.json`）は、独自に作られた依存関係ゼロのNode.jsスクリプト（`validate-findings.cjs`）によって、スキーマレベルで容赦なく弾かれます。
判定 (Verdict) | 定義と要求される証拠
✅ confirmed（実証済み） | 完全なソーストレース（入口 → 伝播 → シンク）が存在し、ダミーデータによるローカル再現（観察結果）が取れているもの。ここで初めて重要度（Severity）が付与される。
⚠️ needs_validation（要検証） | ソースコード上の根拠はあるが、デプロイ環境や実機に依存する「未解決の事実（blocker）」があるもの。推測でのSeverity付与は禁止。所有者が安全に確認するための検証プランが必須。
❌ rejected（棄却） | 検証プロセスで論破された主張。「なぜダメだったのか」の理由とトレースを記録し、次回以降の無駄な再調査を防ぐ。
重要度の評価も「明示的なセキュリティ制御を完全に突破できたか、それとも弱めただけか」というインパクト基準で決定され、「なんとなく危なそう」なものはMedium以上には上がれません。
5. Cloudflare社内での圧倒的実績データ
このオープンソース化されたスキルは、Cloudflare社内で運用されている大規模脆弱性発見システム（VDH: Vulnerability Discovery Harness）のコア部分を抽出したもの。
公式ブログで明かされた数字が、このアプローチの正しさを証明しているのかもですねー。
調査対象：社内128リポジトリ（C, Go, Rust, TypeScript, Pythonなど多言語を横断、言語個別チューニングなし）
生の候補数：20,799件
最初の検証通過：12,057件（ここで約4割が脱落）
重複排除や低リスク除外後：7,245件が開発チームへ手渡される
精度の劇的向上：
初期の棄却率は 40% → 11% に低下
チームが「対応すべき」と認めた高整合な発見の割合は 35% → 58% に跳ね上がった
特に面白いのは、エージェントが静的解析ツール（Semgrepなど）を自発的に呼び出した回数が1ヶ月で「0回」だったという点。エージェントは静的ルールスキャンよりも、「コードを読み、仮説を立て、ローカルでサンドボックス実行して確かめる」プロセスを求めたといいます。
6. すぐに試せる導入手順
このスキルは、Skills CLI経由で簡単にお手元のコーディングエージェントへ導入できます。
# プロジェクト単位で追加する場合
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
# グローバルに追加する場合
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --global導入後は、チャット上で以下のように指示するだけでトリガーされます。
"security audit this codebase"
"find security vulnerabilities in ./src"
"do a security review, output to ~/audits/my-project"
※「この関数って安全？」といった局所的な質問の場合は、全6フェーズを走らせずにピンポイントで答える「ガイダンスモード」で動いてくれる親切設計になっています。
まとめ：AIエージェント活用の本質は「プロンプト」ではなく「拘束具」にある
Cloudflareの `security-audit-skill` から学べる最大の教訓は、「LLMを賢くしようとするな、LLMを縛る手続き（プロセス）を賢くしろ」ということ。
うーん、耳が痛い。
モデルに頼りすぎず、ハーネスでちゃんと管理してるのか？って聞かれているようなもんですからね。
役割を分割し、互いに対立させる（発見 vs 論破）
状態を台帳で管理し、進捗の誤魔化しを許さない
出力を決定論的なスクリプトで機械検証する
AIエージェントに実用的な仕事を任せたいとき、私たちが作るべきなのは「気の利いたシステムプロンプト」ではなく、「嘘をついたら即座にエラーで弾かれる頑丈なハーネス」なのだと痛感させられる名リポジトリ。
こういう安心を貰えるスキルは大好きです。
セキュリティに携わるエンジニアはもちろん、エージェントシステムを開発しているすべての人に一読をおすすめしますー。
参照元：github.com/cloudflare/security-audit-skill / Cloudflare Blog: "Build your own vulnerability harness"
ごめんなさい。リサーチャー使ってないんで報告書無いんです。
外部に何かを飛ばすの恐怖症です、今。
