Cloudflare security-audit-skill とは

security-audit-skill は、Cloudflareが公開したオープンソース（MITライセンス）のエージェントスキルで、Claude Codeなどのコーディングエージェントを「偵察→探索→検証→出力→独立検証→レポート」の6フェーズで動く脆弱性監査役に変える。探す役と反証する役を別のエージェントに分け、機械可読な findings.json に根拠つきで結果を残すのが特徴で、自分が管理するコードを一次スクリーニングする道具としては有力だが、結果は必ず人が確認する前提で使うべきものである。

2026年6月18日に公開され、2026年10月時点でリポジトリのスター数は約4.7万（GitHubの表示）に達している。公開元のCloudflareは、社内の脆弱性発見ハーネスの出発点としてこのスキルを切り出したと説明している。本稿では、一次情報であるGitHubのREADMEとCloudflare公式ブログ、解説記事をもとに、導入方法と使い方、既存ツールとの違い、注意点を整理する。なお、公式が明記していない事項（対応エージェントの保証、誤検知率、実行コストなど）は未公表として扱う。

コーディングエージェント向けの「スキル」（SKILL.md と補助ファイルの束）で、リポジトリを渡して「このコードベースをセキュリティ監査して」と頼むと、複数のサブエージェントを隔離した状態で順に動かし、攻撃シナリオの成立条件まで追った脆弱性候補だけを残す。Cloudflareの公式ブログ「Build your own vulnerability harness」によれば、約450行のこのスキルを1つのリポジトリで動かすところから始め、約6週間で128リポジトリを回す社内の脆弱性発見ハーネスへ育てたという。公開されているのはその出発点にあたる単一リポジトリ版で、フリート全体を回すハーネス本体は未公開（公式は後日の公開を示唆するが日付は未公表）である。

- 1. 偵察：アーキテクチャ、信頼境界、入力面、過去の証拠を整理し、architecture.md と coverage-ledger.json（調査単位の台帳）を作る
- 2. 網羅主導の探索：隔離されたハンターが台帳の単位ごとに調べ、別の「カバレッジ批評役」が調べ漏れを指摘する
- 3. 候補の検証：新しい検証役が、見つかった候補ごとに反証を試みる
- 4. 構造化出力：結果を confirmed / needs_validation / rejected の3区分で findings.json に書き出し、report-schema.json でスキーマ検証する
- 5. 独立検証：さらに別の新しいエージェントが最終的なソース上の主張を確認する
- 6. レポート：REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md を生成する

判定の区分は厳密である。confirmed は「ソースを最初から最後までたどれ、観測できた結果に上限が付いている」もの、needs_validation は「まだ確かめられていない事実が1点残っている」もので重大度は付けず、rejected は反証された候補を指す。防御の層が足りないだけのものは脆弱性ではなく「ハードニングの注意点」に分類される。また、実行はプロファイル（quick / standard / deep）で調整でき、解説記事（SmartScope）によれば quick は小さな対象や再実行向け、deep は大規模・高リスクな対象向けで二周目まで独立に回す。2回目以降の実行は前回の台帳と findings を読み込んで穴を埋めるため、READMEとブログは、Cloudflareの試験では1回の実行で見つかる脆弱性は繰り返した場合の総数の約半分だったと述べている。1回で終わらせず、複数回回す前提で設計されている点に注意したい。

Skills CLI（npx skills）が、導入先のエージェントを選ばせてくれる。スキル自体に料金はなく、費用は使っているコーディングエージェントのモデル利用料としてかかる。複数のサブエージェントを並列に走らせる設計のため、規模の大きなリポジトリではトークン消費が増えやすいが、公式は目安の数値を出していない。また、ビルドやテストなど対象コードの実行が絡む検証は、外部ネットワークを切り、環境変数を許可リスト化し、リソース制限と書き込み先の限定を備えたOS強制のサンドボックス内でしか行わない決まりになっている。そうした環境がなければ、スキルは実行せずに needs_validation として残す。

- 1. 権限を確認する：監査してよいのは自分が管理する、または明示的に許可を得たコードだけである。他人のサービスやOSSに無断で動的な検証をかけない
- 2. スキルを導入する：上記の npx skills add を実行し、使うエージェントを選ぶ
- 3. エージェントを起動して依頼する：対象リポジトリでエージェントを開き、下記のように頼むとフルの監査モードで始まる
- 4. 出力先を決める：未指定なら ~/security-audit-skill/<リポジトリ名>/run-<N> に出る。リポジトリ内に書くのは、バージョン管理の対象外にしたディレクトリを明示したときだけである
- 5. REPORT.md と NEEDS-VALIDATION.md を読む：confirmed でも根拠のコード位置を自分で追って再現性を確認する
- 6. 必要なら再実行する：二回目は前回の台帳を読んで穴を埋める。Cloudflareの試験では回数を重ねるほど見つかる数が増えた

選び分けの目安は次のとおりである。毎回のCIで同じ結果を出したいならSemgrepやCodeQLのような決定的な静的解析、差分のレビューを素早く済ませたいなら /security-review、CIに検証と修正案までつなぎたいならCodex Securityが向く。security-audit-skill は、それらが拾いにくい、複数ファイルにまたがる論理的な欠陥や認可の抜けを、エージェントの探索力で広く洗い出したいときの補完役という位置づけである。Cloudflareのブログによれば、同社のハーネスでもSemgrepを組み込んだがハンターからは使われなかったとされ、静的解析とエージェント探索は役割が違うと見るのが妥当だろう。SkillSpectorは対象が「スキル」であり、監査対象のコードを調べる本ツールとは目的が異なる。

- 権限のないコードには使わない：監査してよいのは自分が管理するか、書面などで許可を得たコードだけである。第三者のシステムへの動的な検証は不正アクセスになりうる
- 結果は人が必ず確認する：誤検知率や見逃し率は公式にも未公表で、Cloudflareのブログも「偽陰性率は主張できない」と述べている。ハンターはあえて多めに報告する調整のため、フィルタリングは前提になる
- 専門家による診断の代わりにはならない：本番サービスの正式な脆弱性診断や、監査・取引先への提出を目的とした評価は、有資格の専門家による診断が必要である
- 実行環境に依存する：スキルを入れただけで完全な監査が走る保証はなく、使うエージェントとモデル、並列サブエージェントの対応状況で結果が変わる。利用者の報告にはWindowsやZIP導入、一部エージェントでの並列実行の停止などの不具合も上がっている
- サンドボックスなしでは動的検証をしない：OS強制のサンドボックスがない環境では、対象コードを実行せず needs_validation で止まる
- コードを外部に送る点を確認する：リポジトリの内容は利用するモデルの提供元に送られる。機密性の高いコードでは契約と設定を事前に確認する
- 修正はしない：このスキルは問題の特定と報告が役割で、修正の適用は利用者側の作業である

関連する記事として、スキル自体の安全性を事前に確かめるNVIDIA SkillSpector、CIにも組み込めるOSSのCLICodex Security CLI、まず何から手を付けるべきかを整理した中小企業のセキュリティ対策の第一歩がある。正式な脆弱性診断の費用感は脆弱性診断の費用にまとめている。