security-audit-skill は、Cloudflareが公開した コーディングエージェントを「セキュリティ監査人」に変える オープンソースのスキル（MIT）だ。Claude Codeのようにツール使用とサブエージェントの並列実行に対応したエージェントに読み込ませると、コードベースを6フェーズで監査し、実際に信頼境界を破る脆弱性だけを独立検証つきで残す。本記事は2026年6月の初版を、2026年9月10日と14日の全面改訂（コミット 158eb44・c1c8a8c）後の姿に合わせて書き直したもので、公式リポジトリ（★4.6k・fork 293・コミット14件）を2026-09-15にクローンし、同梱バリデータのテストを手元で実行した結果を含む。
- ・Cloudflare製のOSSスキル（MIT）。社内の脆弱性発見ハーネス（ブログ「Build your own vulnerability harness」）の単一リポジトリ版が出発点
- ・6フェーズは9月改訂で「偵察→台帳主導ハント→候補検証→構造化出力→独立再検証→中立レポート」に組み直され、
coverage-ledger.jsonが軸になった - ・判定は confirmed／needs_validation／rejected の3種。needs_validation には重大度を付けない
- ・guidance モード（質問・部分レビュー）と full audit モード（全フェーズ＋成果物）の2つを明示。読み込んだだけでは監査もファイル生成も始まらない
- ・同梱バリデータ2本のテスト 65件（34＋31）を手元で実行し全通過。Node.js だけで動く
このスキルが扱う「依存・CI・リリース・署名」の攻撃面は、サプライチェーン攻撃の防御と地続きだ。全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。スキルそのものの仕組み（SKILL.md とフォルダ構成）はClaude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説を参照してほしい。
1. security-audit-skillとは——監査の「型」をスキルにする
リポジトリの説明文は「A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings（独立検証済みで機械可読な発見を出す、多段階セキュリティ監査のためのコーディングエージェント用スキル）」。READMEは冒頭で、このスキルがCloudflareの脆弱性発見ハーネスの種であり、ハーネスは多段・全社規模のシステムに育ったが、本スキルはその出発点となった単一リポジトリ版だと位置づけている。
中身は skills/security-audit/ 配下の Markdown 15本と JSON スキーマ1本、Node.js のバリデータ2本（＋テスト2本）で、実行コードは検証系だけだ。監査の知能はすべてエージェントに委ね、スキルは手順・判定基準・出力の契約を固定する。
| 種別 | ファイル | 役割 |
|---|---|---|
| 中核 | SKILL.md（約22KB） |
動作モード・用語・実行安全性・セットアップ・原則・6フェーズの概要・アンチパターン |
| フェーズ手順 | RECONNAISSANCE.md／HUNTING.md／VALIDATION-AND-REPORTING.md |
Phase 1／Phase 2／Phase 3〜6 のプロンプトと統合手順 |
| 攻撃クラス | ATTACK-CLASSES.md ＋ 領域別コンパニオン10本 |
汎用の攻撃プロンプトと、AI/LLM・メモリ安全性・クラウド等の領域別ハント項目 |
| 契約 | report-schema.json |
findings.json の3判定すべてを定義する JSON Schema |
| 検証 | validate-findings.cjs／validate-coverage-ledger.cjs（各 .test.cjs 付き） |
依存ゼロの Node.js バリデータ |
読者の3つの問いへの答え
① 何ができる：手元のコードベースを、隔離された複数エージェントで偵察・ハント・反証・再検証し、根拠つきの発見を JSON と Markdown で出す
② 何を解決する：「理論上は危ないかも」の羅列（誤検知）と、監査のたびに手順が変わる再現性の無さ
③ 何を代替する：単発のプロンプトによる場当たり的なレビュー。SAST の代替ではなく、その後段の「悪用可能性の確認」を担う
2. 6フェーズのパイプライン——9月改訂で何が変わったか
初版（2026年6月）の6フェーズは「Recon → Hunt → Validate → Report → Structured output → Independent verification」で、レポート生成が構造化出力より先だった。9月改訂ではこの順序と中身が組み直されている。
| # | 初版（6月） | 改訂版（9月） | 変更の要点 |
|---|---|---|---|
| 1 | Recon：並列の調査エージェントが構造・信頼境界・入力面を architecture.md に |
Reconnaissance：加えて過去の証拠と決定論的なカバレッジを coverage-ledger.json に記録 |
台帳が新設された |
| 2 | Hunt：注入・アクセス制御・ビジネスロジック・暗号・機能悪用・連鎖・ワイルドカードの各観点で並列攻撃 | Coverage-led hunting：台帳の単位ごとに隔離ハンターを割り当て、検査内容を記録し、coverage critic が抜けを探す | 観点別から台帳主導へ |
| 3 | Validate：別エージェントが反証 | Candidate validation：ユニークな候補すべてを新しい検証役に渡して反証 | 実質同じ。候補の重複排除（fingerprint）が明文化 |
| 4 | Report：REPORT.md と FINDINGS-DETAIL.md |
Structured output：confirmed／needs_validation／rejected を findings.json に書き、スキーマ検証 |
JSON が先、レポートは後 |
| 5 | Structured output：findings.json |
Independent record verification：新しいエージェントが最終記録のソース主張を検証。大きな差し替えは再度別の検証役へ | 検証が2段に |
| 6 | Independent verification | Target-neutral reporting：検証済み記録と台帳から REPORT.md・FINDINGS-DETAIL.md・NEEDS-VALIDATION.md を導出 |
レポートは「記録から導出」に限定。ライブプローブの指示は書かない |
親エージェント（parent）は台帳を作った直後と更新のたびに validate-coverage-ledger.cjs を、Phase 4 と Phase 5 の差し替えごとに validate-findings.cjs を実行する。終了状態は2つに限定され、「Phase 6 の成果物がすべて書かれ両バリデータが通る」か、「run_status: "incomplete" を理由つきで記録し、レポートで空白を開示する」かのどちらかでしか止まれない。
architecture.md＋coverage-ledger.json"] --> B["Phase 2 台帳主導ハント
隔離ハンター＋critic の波"] B --> C["Phase 3 候補検証
fingerprint 単位で新しい検証役が反証"] C --> D["Phase 4 構造化出力
findings.json をスキーマ検証"] D --> E["Phase 5 独立再検証
最終記録のソース主張を照合"] E --> F["Phase 6 中立レポート
REPORT / FINDINGS-DETAIL / NEEDS-VALIDATION"] B -. "台帳の更新ごとに" .-> V1["validate-coverage-ledger.cjs"] D -. "書くたびに" .-> V2["validate-findings.cjs"] E -. "差し替えごとに" .-> V2
改訂版にはプロファイルと予算の概念も入った。quick（台帳の単位を粗くし、ハンター1波＋critic 1回、検証役は候補ごとに1人）、standard（手順どおり）、deep（サブシステムごとに単位を分割し、critic が「抜けなし」になるまで波を繰り返す）の3種で、いずれも「証拠の水準は下げない」と明記されている。予算は run-metadata.json にエージェント起動回数の上限として記録し、偵察4回分・critic・検証役の予約分を先に確保してからハンターに配る。予算が偵察と予約すら賄えない場合はエージェントを1つも起動せず、より大きな予算か狭い範囲を求める。
3. 3つの判定と findings.json——「悪用できるものだけ」の実装
初版の原則「Only report what you can exploit」は、改訂版で3種の判定として実装されている。
・confirmed：完全なソーストレースと、範囲を限定した観測結果（bounded observed result）がそろった発見。重大度は「尤度×影響」で付け、チェックリストからの逸脱では付けない
・needs_validation：ソースに根拠はあるが、決定的な事実がソースやサンドボックスの外にある候補。未解決の事実を1点だけ正確に書き、重大度は付けない
・rejected：反証された候補。理由を残して記録し、次回の実行で同じ主張が変わらなければ抑制に使う
report-schema.json は items.oneOf でこの3分岐を定義しており、手元で読むと confirmed は verdict・fingerprint・title・description・root_cause・intended_behavior・trace・evidence を、needs_validation は claimed_root_cause と blockers を、rejected は claimed_root_cause と reason を要求している。
バリデータは依存ゼロの Node.js スクリプトで、テストも同梱されている。当サイトで実行したところ、validate-findings.test.cjs は34件、validate-coverage-ledger.test.cjs は31件がすべて通過した（所要は各1.3秒・0.8秒）。
# 同梱バリデータのテストを手元で実行（Node.js のみ・依存インストール不要）
git clone --depth 1 https://github.com/cloudflare/security-audit-skill
cd security-audit-skill/skills/security-audit
node validate-findings.test.cjs # tests 34 / pass 34
node validate-coverage-ledger.test.cjs # tests 31 / pass 31
validate-coverage-ledger.cjs は入力5MB・単位10,000件・ネスト64段などの上限を JSON.parse の前後で二重に適用し、coverage_id・canonical_refs・surface・boundary・subsystem・attack_class・starting_paths を必須フィールドにしている。エージェントの出力を「信じる」のではなく、機械が形式を強制する設計だ。
4. 2つの動作モードと実行安全性——読み込んだだけでは動かない
9月改訂で最も実務に効くのは、SKILL.md 冒頭の「Operating modes」だ。このスキルは既定では guidance（助言）であり、読み込んだだけでは全フェーズの実行もファイル生成も認可しないと明記された。
| モード | 発動条件 | 振る舞い |
|---|---|---|
| Guidance | セキュリティの質問、部分的なレビュー、手法の相談、特定の発見の調査 | スキルの関係する部分だけを使う。6フェーズを自動では回さず、出力ディレクトリも成果物も作らない。必要なら焦点を絞ったエージェントを起動し、結果を現在のタスクに返す |
| Full audit | 「コードベースを監査／ペンテストして」「完全な／包括的な／エンドツーエンドのレビュー」「レポート成果物が欲しい」と明示された場合 | 6フェーズをすべて実行し、定義された成果物を書く |
どちらとも取れる依頼では、ファイルを作る前に1つだけ質問して確かめる。初版では「トリガーに合えば自動で起動」と書かれていたため、「脆弱性について質問したら監査が始まった」型の事故を防ぐ変更と読める。
実行安全性の規則は両モードに共通で、対象コードのビルド・テスト・プロセス・ブラウザ・エミュレータ・ファザー等を動かすのはOS強制のサンドボックス内に限る。要件は次の4点で、1つでも満たせなければ対象コードを実行せず、needs_validation のブロッカーとして報告する。
・外部ネットワーク無し（ローカルのクライアント／サーバ通信が要るときだけ隔離ループバック）
・空の環境変数から明示的な許可リストで安全な値だけを投入し、HOME・一時ディレクトリ・キャッシュはスクラッチ内に置く
・対象とツールチェーンは読み取り専用。対象が制御するプロセスは割り当てられた scratch/ にしか書けない
・CPU・メモリ・プロセス数・ファイルサイズ・ディスク・実行時間の上限を明示する
加えて、ダミーの主体・フィクスチャ・秘密を使うこと、デプロイ済みエンドポイント・外部サービス・共有インフラ・本番の身元・他人のデータ・稼働中の制御プレーンへプローブしないこと、依存をインストールしたりビルドに取得させたりしないこと、有料 API のクォータを消費しないことが列挙されている。full audit モードでは書き込み分離も規定され、親だけが run-metadata.json・architecture.md・coverage-ledger.json などの共有ファイルを書き、対象コードが触れる領域は scratch/ に限定される。
5. 導入と使い方
導入は初版から変わらず Skills CLI で行う。ユーザー単位に入れるなら --global を付ける。
# 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
導入後は、監査したいコードベースでコーディングエージェントを起動し、自然言語で依頼する。README の例は次の3つだ。
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
full audit モードの出力先は、指定しなければ ~/security-audit-skill/<リポジトリ名>/run-<N>（<N> は未使用の整数）になる。対象リポジトリの中に書くのは、ユーザーが明示的にディレクトリを選び、親がそれをバージョン管理の無視対象だと確認した場合だけだ。同じリポジトリへの複数回実行は加算的で、過去の台帳と findings.json を読んで空白を狙い、ソースが変わった箇所を再検証し、変わっていない証拠は持ち越す。READMEは「テスト実行では、1回の実行で見つかるのは繰り返し実行で見つかる総数のおよそ半分だった」としており、1回で網羅したとは主張しない設計になっている。
要件はREADMEの3点。ツール使用と並列サブエージェントに対応したモデルを持つコーディングエージェント、バリデータ用の Node.js、そして対象コードを動かすための OS強制のサンドボックスだ。3点目は9月改訂で追加されたもので、無ければ実行系の検証は needs_validation に留まる。
用語もプラットフォーム非依存に書き換えられた。実行を統括する parent、委譲の仕組みである Task tool、ソース探索と事実確認に特化した research エージェント、広い調査と範囲を限定したローカル実行を担う general エージェントの4つで、Claude Code 固有の名称は使わない。同じ「Claude Code 上でのセキュリティ作業」でも、攻撃側の35のサブエージェントを束ねたpentest-ai-agents｜Claude Code向け35の攻撃セキュリティ専門サブエージェント解剖とは、役割を固定して検証を必須化する点で対照的だ。
6. 領域別コンパニオン10本——ハントの守備範囲
初版の攻撃観点は ATTACK-CLASSES.md 1本だったが、改訂版では領域別のコンパニオンが10本に増えた。偵察の段階で対象に合うコンパニオンを選び、ハンターのプロンプトに組み込む。
| コンパニオン | 対象 |
|---|---|
AI-AND-LLM.md |
プロンプトインジェクション、エージェント／ツール、出力の取り扱い |
MEMORY-SAFETY-AND-BINARY.md |
メモリ安全性、バイナリ、カーネル（ネイティブ対象） |
WEB-PROTOCOL-AND-AUTH.md |
HTTP のリクエスト境界、キャッシュ、認証プロトコル |
CLIENT-SIDE.md |
DOM 注入、メッセージングの信頼、UI リドレス、プロトタイプ汚染 |
SUPPLY-CHAIN-AND-RELEASE.md |
依存、CI、リリース、署名、更新、プラグイン、拡張 |
CLOUD-AND-DEPLOYMENT.md |
IAM、IaC、コンテナ、サーバーレス、イングレス、実行時設定 |
PROTOCOLS-RPC-AND-MESSAGING.md |
RPC、シリアライズ、キュー、ブローカー、Webhook、ストリーミング |
RESOURCE-EXHAUSTION-AND-AVAILABILITY.md |
共有リソース、クォータ、キュー、ワーカー、運用者の支出 |
DATA-ISOLATION-AND-LIFECYCLE.md |
テナント分離、キャッシュ、検索、エクスポート、バックアップ、移行、削除、復元 |
DESKTOP-MOBILE-AND-LOCAL-IPC.md |
ネイティブアプリ、ディープリンク、WebView、公開コンポーネント、ヘルパー、デーモン、ローカル IPC |
AI-AND-LLM.md が含まれる点は、エージェント自身の攻撃面を扱う当サイトの他記事と重なる。Claude Code のサンドボックスがどこまで守るかはClaude Code セキュリティ｜サンドボックスの守備範囲と公開アドバイザリで見る攻撃面・確認コマンドで扱っており、本スキルの「OS強制サンドボックス」要件を満たすかどうかの判断材料になる。
7. 改訂の時系列と、注意点・限界
リポジトリの履歴は14コミットと少なく、改訂のタイムラインは次のとおり追える。
| 日付 | 内容 |
|---|---|
| 2026-06-18 | 初期コミット |
| 2026-06-24 | npx skills add 互換のためスキルファイルを skills/security-audit/ に移動 |
| 2026-06-26〜07-06 | メモリ安全性・バイナリ・カーネルのクラス追加。AI/LLM・HTTP プロトコル／認証・クライアントサイドのコンパニオン追加。文体の統一 |
| 2026-07-02 | トレースの手順順序を検証する修正 |
| 2026-09-10 | 監査ワークフロー・発見の契約・バリデータを端から端まで作り直し（PR #12） |
| 2026-09-14 | guidance モードと full audit モードの説明を明確化 |
注意点は SKILL.md のアンチパターン10項目がそのまま使える。代表的なものを挙げる。
・チェックリストからの逸脱を脆弱性として提示すること。到達可能な境界違反の無い多層防御の助言も同様
・範囲を限定したローカルの証拠で足りない場面での、稼働環境・共有環境でのテスト
・ソースに無いプロバイダ・プロキシ・ブラウザ・身元・デプロイの挙動を推測すること
・同一主体の意図された権限や自己への影響を、境界を越えた結果として扱うこと
・needs_validation に重大度を付けること。独立検証の前にレポートを書くこと。散文と JSON が食い違うこと
限界としては、SAST や依存スキャナの代替ではないこと（既知 CVE の網羅は npm audit や OSV-Scanner の仕事で、本スキルは「悪用可能か」の確認に特化する）、サンドボックスが無ければ実行系の検証は全て needs_validation に留まること、1回の実行で網羅はできないこと（README 自身が「およそ半分」と書く）の3点を押さえておきたい。対策としては、CI で quick プロファイルを定期実行して台帳を積み、リリース前に standard か deep を人手で回す運用が、改訂版のプロファイル設計に沿う。
まとめ
security-audit-skill は「エージェントに脆弱性を探させる」道具ではなく、探す・疑う・再検証する役割を分け、出力の形式を機械で強制する道具になった。9月改訂で加わったカバレッジ台帳・3種の判定・2つの動作モード・サンドボックス要件は、いずれも「言ったことを証明できるか」を問う方向の変更で、初版の原則をより厳密に実装している。
findings.json を正とし、REPORT.md はそこから導出されたものとして読む。needs_validation の項目は「未検証」であって「安全」ではない。
参照ソース
・cloudflare/security-audit-skill（公式GitHubリポジトリ） — README・skills/security-audit/SKILL.md・report-schema.json・バリデータとテスト（2026-09-15 時点、コミット c1c8a8c）
・Build your own vulnerability harness（Cloudflareブログ・由来） — README がスキルの出自として参照
・Agent Skills（Anthropic・スキルの仕組み）
・Skills CLI — skills.sh — npx skills add の配布元
