Cloudflare がオープンソース化した security-audit-skill：プログラミング Agent に検証可能な安全監査フローを載せる

公開日 2026年9月23日 著者 Remy
タグ: #security #agent-harness #developer-tools #agent-loop

プログラミング Agent はますますコードを変えられるようになった。一方で安全チームは、次の問いに答えにくくなっている——「今回の変更は、悪用可能な境界破壊を持ち込んでいないか？」 安全方法論の全文を一文の system prompt に押し込むやり方は、短期は見栄えがよいが、長期には通常三事で崩れる——カバーが説明できない、結論が再検証できない、走り始めたら対象コードを実行したくなる。Cloudflare がオープンソース化した security-audit-skill は別の道を晒す：まず監査フローをインストール可能な Agent Skill にし、構造化産物と独立検証で「発見」と「確認」を分ける；それは Cloudflare 内部の脆弱性発見 harness の単一倉庫起点でもあり、公式はブログ Build your own vulnerability harness で、Skill からフリート級パイプラインへ育つ過程を書いている。

2026-09-24 時点で、当該倉庫には約 20,703 star、約 1,176 fork、ライセンスは MIT。下文のスターとフロー記述は公開 README / SKILL.md / Cloudflare ブログに準拠する；公開材料に現れない内部命中率・ドルコスト等の数字は、一切創作しない。

当サイトで対照して読める：Agent Skills 入門、AI 符号化代理と実脆弱性研究、Open Code Review 決定性パイプライン、Claude Code Agent Harness、および Jev × Claude Code における「判断と生成を分ける」境界の議論。

なぜ Skill なのか、また一つの安全 Bot ではないのか

Skill が解くのは配布と起動だ：「いつ有効化するか、どの段階で走るか、何のファイルを出すか、何をもって確認とするか」を、プログラミング Agent が読み込める手順書として書くこと——GitHub 上にだけコメントできるロボットをもう一つ吊るすことではない。当サイトの Agent Skills 入門 は、Skills を配布可能な能力包として論じた；security-audit-skill は安全垂直場面での高強度サンプルだ——ファイルが多く、段階が硬く、検証スクリプトが揃っている。

README は率直に書く：これは Cloudflare 脆弱性発見 harness の種であり；harness はその後、多段階・倉庫横断のフリートシステムへ育ち、この Skill はそれが進化する以前の単一倉庫起点だ。企業読者にとって、この一文はスター数より重要だ：あなたが真似るのは「インストール可能な監査ワークフロー」であり、「すでに全フリートをスキャンし終わった SaaS」ではない。

Open Code Review との対照も有用だ。OCR はコードレビューで間違えてはいけないステップ（ファイル選別、梱包、位置決め）を決定性工学にする；security-audit-skill は安全監査で混じてはいけないステップ（偵察台帳、隔離狩猟、敵対的検証、構造化結論）を Skill ワークフローにする。一方は PR ゲート寄り、他方は脆弱性狩猟と報告寄り；二者とも同種の問いに答えている——モデルに選手と審判を同時にさせない。

六段階は何をするか（そして三態結論がなぜ重要か）

Skill は一回の完全監査を六段階に分ける（倉庫 README 準拠）：

  1. Reconnaissance（偵察） — アーキテクチャ、信頼境界、入力面、既存証拠を整理し、決定性のカバレッジ台帳へ書き込む：architecture.md と coverage-ledger.json。
  2. Coverage-led hunting（カバレッジ主導の狩猟） — 台帳ユニットに従い隔離された hunter を割り当て、検査項目を記録し、coverage critic でギャップを探す。
  3. Candidate validation（候補検証） — 各々の一意候補を新しい verifier に渡し、任務はできるだけ反証すること。
  4. Structured output（構造化出力） — confirmed、needs_validation、rejected を findings.json に書き、report-schema.json で検証する。
  5. Independent record verification（独立記録再検証） — さらに新しい agent で最終のソース主張を照合する；実質的な置換が起きたら、もう一回独立 verifier を通す。
  6. Target-neutral reporting（対象中立の報告） — 検証済み記録とカバレッジ台帳から REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md を派生する。

親 agent は台帳作成後および各更新後に validate-coverage-ledger.cjs を走らせ；第 4 段階および第 5 段階の各置換後に validate-findings.cjs を走らせる。これは飾りではない：JSON schema + ゼロ依存の検証スクリプトは、「報告がどう見えるべきか」をモデルの自由作文から、回帰可能な契約へ引き戻す。

三態結論は分けて理解せねばならない：

結論意味（README 準拠）やってはいけないこと
confirmed完全なソース追跡があり、境界がはっきりした観察結果がある「危険そう」をそのまま confirmed へ昇格させない
needs_validation精確な未決事実があり、重大度を付けないHigh/Critical を付けて業務側を嚇さない
rejected候補がすでに反証された記録を消して「誤報などなかった」装いにしない；反証軌跡を残すほうが価値がある

この状態機械は、安全 Agent が最もよく転ぶ失敗を直接狙う：「チェックリスト偏差」「多層防御のギャップ」「まだ欠けているデプロイ側の事実」を、確認済み脆弱性として書いてしまうこと。README の設計原則は明記する：多層防御のギャップは脆弱性ではない——A 層がすでに攻撃を止めているなら、B 層の欠如は強化提案として記し、脆弱性の項目にしてはいけない；重大度には影響が要る——可能性 × 影響であり、チェックリストからの乖離の度合いではない。

段階産物と検証スクリプト：契約をファイルシステムへ書く

「六段階」の四字だけ覚えても、着地時にはなお漂う。runbook に写す価値が大きいのは、README が列挙するファイル級の契約だ：

段階主要産物機械検証
偵察architecture.md、coverage-ledger.json台帳作成後に validate-coverage-ledger.cjs；以降台帳を改めるたび再実行
カバレッジ主導の狩猟台帳ユニット上の検査記録、critic が指すギャップ台帳更新後に再び coverage 検証
候補検証findings.json へ書く前の候補（まず反証）—
構造化出力findings.json（confirmed / needs_validation / rejected）report-schema.json に照合し、validate-findings.cjs を実行
独立再検証置換されうる findings 記録実質的な置換のたび validate-findings.cjs を再実行
対象中立の報告REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md報告は検証済み記録から派生し、別途自由作文を始めない

倉庫はさらに validate-findings.test.cjs と validate-coverage-ledger.test.cjs を提供し、検証器そのものがテスト可能であることを示す——「スクリプトが置いてあるだけ」ではない。企業が類似フローを自作するときの最低基準はこうだ：人が報告を読む前に、機械が schema 不合の JSON を拒む。 さもなければ三態結論は、最初のモデル逸脱で崩れる。

SKILL.md、RECONNAISSANCE.md、HUNTING.md、VALIDATION-AND-REPORTING.md および複数の攻撃類ドキュメントは、段階プロンプトと方法論だ；report-schema.json と二つの validate-*.cjs は、段階間の硬ゲートだ。前者は対象種別に応じて絞り込んで読み込める；後者は任意項目として切ってはいけない。

インストールと起動：まず「指導モード」と「完全監査」を分ける

インストールは Skills CLI 経由：

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

ユーザー級インストールは --global を付ける：

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

導入後、対象コード庫でプログラミング Agent を開き、自然文で起動する。例えば：

security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project

SKILL.md は見落とされやすいスイッチを強調する：既定は指導モード（guidance）。Skill を読み込んだだけでは、完全六段階や報告ディレクトリの自動書き込みは許可されない。完全監査モードが有効になるのは、ユーザーが明示的にコード庫の監査 / ペネトレーションテストを求めたとき、エンドツーエンドの安全レビューを求めたとき、または報告産物を明示的に求めたときだけだ。要求が両義的なら、走る前に一文問い返す——これは「口頭で安全の質問をしたら、Agent が倉庫をスキャンしてファイルの山を出す」ことを防ぐためだ。

完全監査で出力ディレクトリを指定しなければ、既定は ~/security-audit-skill/<repo-name>/run-<N> に落ちる。明示的にバージョン管理から無視されたディレクトリを選んだときだけ、ワークフローは対象倉庫内部へ書き込む。企業にとってこれは基本衛生だ：監査産物は既定で外置きし、秘密と半信頼の報告が誤ってコミットされるのを避ける。

実行要件も具体的だ：

  • ツール呼び出しと並行子 agent を支えるプログラミング Agent；
  • Node.js でゼロ依存の findings / coverage-ledger 検証器を走らせる；
  • OS 強制サンドボックス：対象が制御するビルド、テスト、プロセス、ブラウザ、エミュレータ、fuzz、fixture 処理に効く——外部ネットワークを禁じ、環境変数を浄化してホワイトリスト化し、資源を制限し、割り当てた scratch への書き込みだけを許す。これらの制御ができなければ、ワークフローは手がかりを needs_validation に留め、対象コードを実行してはいけない。

最後の一条が、標題の fail-open / 安全境界だ：確認を減らすほうが、サンドボックスなしで動的検証できたと偽るよりましだ。

敵対的検証と書き込み隔離：信頼できる根拠はここにある

README 原則はこう書く：検査発見する agent は、決してそれを発見した agent ではない。 Cloudflare ブログは同じ思想をフリート級 harness へ拡げる：発見と検証に異なるモデル・異なる段階を使い、状態を外置きして、コンテキスト窓が朝見つけた穴を「忘れる」のを避ける。Skill 版は単一倉庫の縮図だ——隔離 hunter、新鮮な verifier、独立記録再検証、さらに schema 検証。

SKILL.md は書き込み隔離をより細く書く：親 agent が共有ファイルを独占する（例：run-metadata.json、architecture.md、coverage-ledger.json、findings.json と報告ファイル）；各 hunter / verifier は独立ディレクトリを持ち、scratch と artifacts を分離する；産物を昇格するときは path 検証、no-follow、通常ファイルとリンク数検査、バイト上限等を行う。第一週に記述子級の強化を全部再現する必要はないが、規律は写すべきだ：

  1. 発見者は自分の穴を最終審判できない；
  2. 対象プロセスは scratch にしか書けない；
  3. 保留領域へ入るファイルは、信頼できる親フロー経由で昇格せねばならない；
  4. サンドボックスが欠けたら needs_validation で止まる。

これは当サイトが Agent 失敗モードを論じたときの注意と一致する：信頼できない対象とオーケストレーション層を絡めるのは、事故の高発区だ（Agents of Chaos のような「Agent が制御を失う」議論を参照）。安全監査 Skill は「対象コードは敵対しうる」を既定前提にし、事後のパッチにしない。

カバレッジ台帳：一回で終わらないのは特性でありバグではない

README は明記する：同一倉庫への複数回実行は重ねられる。Skill は既存の ledger と findings を使い、ギャップを打ち、変化したソースを再検証し、ソースがなお成立するとき証拠を継承する——期限切れや未決の作業を「すでにカバー済み」として扱わない。設計原則はさらに照合可能な口径を与える：彼らのテスト実行では、単回実行が見つけるのは、複数回実行の合計脆弱性のおよそ半分前後だ。

この文は失望ではなく、運用戦略として書くべきだ：

  • 第 1 回：アーキテクチャ図とカバレッジ台帳を立て、最初の一群の高信頼 confirmed を収める；
  • 第 2–N 回：critic が指すギャップと needs_validation を専ら打つ；
  • ソース変更後：関連ユニットを再検証し、倉庫全体を盲目スキャンして「まったく新しい」を装わない。

企業が「Skill を一回走らせた」ことを年度監査のクローズドループとみなせば、残存リスクを系統的に過小評価する。より合理的な KPI は：カバレッジ台帳ユニットの埋め速度、needs_validation の消化周期、confirmed が人手受理される比率——単回報告のページ数ではない。

攻撃面ファイル：対象種別で読み込み、恐れを一度に全部押し込めない

倉庫は SKILL.md / RECONNAISSANCE.md / HUNTING.md / VALIDATION-AND-REPORTING.md のほか、対象種別ごとに複数の狩猟類ドキュメントを分ける。例えば：

  • メモリ安全とバイナリ / カーネル；
  • AI / LLM（プロンプト注入、agent/ツール、出力処理）；
  • Web プロトコルと認証；
  • クライアント / ブラウザ；
  • サプライチェーンとリリース；
  • クラウドとデプロイ；
  • RPC / メッセージ；
  • 資源枯渇と可用性；
  • データ隔離とライフサイクル；
  • デスクトップ / モバイル / ローカル IPC。

これは毎回の監査ですべてのドキュメントをコンテキストへ流し込む指示ではない。正しい用法は：偵察段階でまず製品種別を判断し、関連する攻撃類だけを読み込む。LLM 応用なら AI/LLM とデータ隔離を優先；ネイティブパーサならメモリ安全を優先；純業務 API なら認証とテナント隔離を優先。コンテキスト窓が有限なとき、「全開」は「すべてがぼやける」に等しい。

企業の既存安全フローとどう繋ぐか

Skill は「研究員助手の標準作業手順」として考え、SAST/DAST/人手レッドチームの置換ではない：

  1. PR 級：重すぎる。PR ゲートには OCR のような高信号レビュー（Open Code Review 参照）に通常の SAST を足すほうが適する。
  2. 版リリース前 / 重大リファクタ後：完全監査モードが適する。出力は外置きディレクトリ；安全同僚は confirmed と優先度付けした needs_validation だけを見る。
  3. テーマ狩猟：例えば「今四半期はテナント隔離だけを見る」——指導モード + 関連攻撃類ドキュメントで、六段階全開を避ける。
  4. 実脆弱性研究ワークフローとの接続：Skill が解くのは反復可能なソース優先監査；協調開示、CVE、メンテナ確認はなお人間フローだ。当サイトの Anthropic × Mozilla 脆弱性研究 が示すように：信頼度は検証可能なワークフローから来、モデルの自己採点から来ない。

着地時は三役割を固定することを勧める：

  • プラットフォーム工学：Skills インストール、サンドボックスイメージ、出力ディレクトリ方針を保守する；
  • 安全工学：攻撃類の優先度を保守し、confirmed を受理し、誤報を閉じる；
  • 業務倉庫 Owner：パッチと回帰を処理し、Agent 報告をそのまま変更票にしない。

OCR・レッドチーム・通常スキャンとの分業（対照表）

三本の線を一枚の表に書くと、会議を多く減らせる：

次元Open Code Reviewsecurity-audit-skill人手レッドチーム / テーマ研究
主問い今回の diff に高信号欠陥はあるか？この倉庫に確認可能な境界破壊はあるか？実制約下で業務影響を出せるか？
典型トリガPR / ローカル ocr review明示の「完全監査」またはテーマ狩猟リリース前、コンプライアンス、高リスク変更
証拠形態行級コメント、ルール IDfindings.json 三態 + 報告利用チェーン、報告、開示材料
モデルとの関係決定性のファイル選別 / 位置決め + Agent 推論カバレッジ台帳 + 敵対的多 agent人主導、Agent は補助可
失敗時の既定より高い適合、より低い再現（公式ベンチ叙述準拠）サンドボックスなしなら needs_validation範囲外はしない、権限外はしない

当サイトの Open Code Review は日常ゲートに適する；本 Skill は版級またはテーマ級のソース監査に適する；AI 符号化代理と実脆弱性研究 一文は念押しする：真に CVE / メンテナ確認へ入るものは、なお検証可能なワークフローと人間の責任に依存する。三者は重ねて用いるのであり、相互置換ではない。

また Agent Harness と対照する：Skill が配布可能な SOP を提供し、Harness がループと状態外置きを提供する；Cloudflare ブログが記述するフリート harness は、まさに Skill 方法論の永続オーケストレーション上の延長線だ。急いで「フリートへ上げ」ても、人が confirmed をまだ信じられなければ、通常はノイズを増幅するだけだ。

安全上の注意：fail-open、範囲と「本番をスキャンするな」

公開材料で最も赤線として書く価値があるのは次だ：

  1. OS サンドボックスがなければ対象コードを実行しない — 手がかりは needs_validation に留め、欠けている制御が何かを明記する。
  2. すでにデプロイされたエンドポイント、外部ネットワークサービス、共有基盤、本番アイデンティティ、他人のデータ、ライブ制御面を探ってはいけない — SKILL.md はソース優先とローカル fixture の境界を極めて硬く書く。
  3. 実キーと実テナントを使わない — 仮想主体と fixture を使う。
  4. 指導モードを勝手に全量監査へ昇格させない — 「一文の質問」が「一ディレクトリの報告」になるのを防ぐ。
  5. needs_validation に重大度を付けない — 未決事実がチケットシステムで偽の CVSS になるのを避ける。
  6. 多層防御のギャップ ≠ 脆弱性 — 報告が強化提案で埋まり、真の穴が薄まるのを防ぐ。
  7. 複数回実行してようやく「彼らのテスト中の合計発見」に近づく — 単回報告で窮尽を主張してはいけない。

プログラミング Agent が開発者ノート上で走り、かつ隔離がないなら、実務的な戦略はこうだ：偵察と純静的狩猟だけを走らせ、動的検証はすべて人手に渡す；あるいは完全監査を専用 CI サンドボックス機へ投げる。「Skill が走れる」を「対象を攻撃する権限を得た」と読むのはよくある誤読だ——Skill はフローであり、権限書ではない。

サンドボックスと fail-open：制御が欠けたときどこで止まるか

README のサンドボックス要求は、検査可能なチェックリストへ分解できる——「安全に注意」の一句ではない：

  1. 外部ネットワーク禁止 — 対象が制御するビルド / テスト / ブラウザ / fuzz が、監査過程を借りてパブリック網やイントラネットの隣へ打ってはいけない。
  2. 環境変数を浄化しホワイトリスト化 — 開発者ノート上のクラウド鍵、npm token、Kube クレデンシャルが対象プロセスへ漏れないようにする。
  3. 資源上限 — CPU、メモリ、プロセス数、ファイルサイズ、ディスク、壁時計時間に明示制限を置き、「監査がマイニングや fork 爆弾になる」リスクを下げる。
  4. 割り当てた scratch にしか書かない — 対象プロセスは倉庫ソースを改められず、共有出力ディレクトリにも書けない；保留産物は信頼できる親フローだけが昇格する。

SKILL.md は昇格過程を硬く書く：相対パスの検証、シンボリックリンク成分の拒否、no-follow で開く、通常ファイルかつリンク数 1 の確認、バイト上限でコピー、目標側でもディレクトリトラバーサル防護。第一週に記述子級の細部を全部再現する必要はないが、四条の規律は残さねばならない：発見者は自分の穴を最終審判できない；対象は scratch にしか書けない；保留領域は親フロー経由でのみ書き込む；サンドボックス欠如なら needs_validation で止まる。

これが fail-open の工学的意味だ：「エラーでもマージを通す」ではない；「動的証拠が取れないとき、未決に留めるほうが、確認済みを偽るよりまし」だ。安全チケットシステムでは、対応規則はこうなる：needs_validation は調査キューに入れてよいが、自動で CVSS 付きの脆弱性票にしてはいけない。

Harness・Jev・OCR を同一の能力図に置く

簡化した能力図：

能力代表解くこと
配布可能な知識包Agent Skillsどう起動し、どう分段し、何を出すか
ループと状態Agent Harnessコンテキスト、回復、ツール境界
構造化判断Jev のような意思決定層速く、較正可能な分岐判断
PR 高信号レビューOpen Code Reviewファイル選別 / 位置決め / 低ノイズコメント
安全監査 SOPsecurity-audit-skillカバレッジ台帳、敵対的検証、三態結論

Cloudflare ブログの核心論点の一つは：harness は単回のモデルセッションより長く続く；モデルは換えられるが、オーケストレーションと状態外置きこそ資産だ。Skill は harness の配布可能なフロントエンドだ——まず単一倉庫で方法論を通してから、必要に応じてデータベース外置き、倉庫横断の追跡、重複排除と修復パイプラインへ進む。企業が真似る順序の提案は：

  1. まず正しくインストールし、指導 / 完全モードを区別できる；
  2. まずサンドボックス内で六段階を一回通せる；
  3. まず安全同僚が三態結論を信じられる；
  4. それから倉庫横断とフリート級オーケストレーションを語る。

前の三ステップを飛ばして直接「フリートへ上げ」ると、通常はより速いノイズ機械を得るだけだ。

誤用事例：勤勉に見えて穴を掘るやり方

以下は公開設計原則の反面教材化だ——倉庫がある会社を名指し批判するのではなく、README / SKILL.md がすでに書いた境界を「こうするな」へ翻訳する：

  1. Skill を PR ロボットとして毎回必ず走らせる — 六段階 + 多 agent は各小 PR に重すぎ、needs_validation をレビューノイズへ刷り込みやすい。PR には OCR + SAST がより適する。
  2. サンドボックスなしでなお Agent に「走らせて見る」 — 「制御欠如なら対象コードを実行しない」に直接違反する。ノート上のクラウド鍵とイントラネット到達性だけで、一回の監査を一回の事故に変えうる。
  3. needs_validation に Critical を入れる — 未決事実に重大度はない；Jira に入った瞬間、偽のリスク帳簿になり、安全と業務の双方が三態への信頼を失う。
  4. 多層防御のギャップを脆弱性一覧に書く — README 明記：A 層がすでに止めているなら、B 層欠如は強化提案だ。さもなければ報告はスケジュール不能の「提案の海」になる。
  5. 一回走らせて「全カバー済み」を主張する — 公開テスト叙述は：単回は複数回合計のおよそ半分前後しか見つけない。正しい言い方は「本ラウンドの台帳進捗と confirmed 集合」であり、「倉庫にもう穴はない」ではない。
  6. 指導モードの質問が黙って全量監査へ昇格する — SKILL.md は両義的なら先に問えと要求する；黙って報告ディレクトリを書くと、開発者の Agent への基本信頼を壊す。
  7. 出力を倉庫へ書き、かつ無視されていない — 既定は ~/security-audit-skill/... へ外置き；明示的に ignore されたディレクトリを選んだときだけ対象庫へ書く。さもなければ秘密と半信頼報告が誤コミットされやすい。
  8. 発見者自身が確認を付ける — 敵対的検証が信頼の源だ；独立 verifier を「節約のため」切るのは、system prompt が自分を審く状態へ戻ることだ。

Skill を使いながら Agents of Chaos が書いた制御喪失モード——ツール境界が曖昧、状態が監査不能、失敗が再演不能——に繰り返し当たるなら、より長いプロンプトを足す前に、カバレッジ台帳・三態結論・サンドボックスチェックリストへ戻れ。

十四日の試用計画

第 1–2 日：Skills CLI でサンドボックス付きの代理環境へインストールする；非本番・捨てられるサンプル倉庫を一つ選ぶ；まず指導モードで二つの具体的な質問をし、勝手に全量報告を書かないことを確認する。

第 3–5 日：同一サンプル倉庫で完全監査を一回走らせる；人手抜き取り：confirmed に本当にソース鎖と境界結果があるか；needs_validation の各条に「精確な未決事実」があるか；rejected が反証理由を残しているか。

第 6–8 日：コードを変えずにもう一回走らせ、台帳が単純な重複ではなくギャップへ向かうかを見る；README「単回およそ半分」の予期に照合し、第二ラウンドになお増分があるかを検査する。

第 9–11 日：実内部サービス倉庫を一つ選ぶ（読み取り専用ミラー）；合致する攻撃類ドキュメントだけを有効化；出力ディレクトリは外置き；安全エンジニアが受理の演習を行う。

第 12–14 日：組織の赤線を書く：サンドボックスなしでは動的検証禁止、本番スキャン禁止、needs_validation は脆弱性 KPI に入れない、完全監査には明示指令が要る。より広いパイロットへ進むかを決める。

退出基準：安全エンジニアが confirmed を受理したがらなければ、先に面を拡げない——まず攻撃類範囲・検証厳密度・報告テンプレートを直し、それから普及を語る。

結び

security-audit-skill を安全とプラットフォームチームの合同レーダーに書く価値は、スター数が高いからではなく、しばしばスローガンに留まる三文をインストール可能なアーティファクトにしたからだ：発見と検証を分離する；未決事実を確認済みと偽らない；サンドボックスがなければ fail-open して needs_validation へ落ちる。 Skill 配布は「プログラミング Agent に同一 SOP で働かせる方法」を解く；六段階とカバレッジ台帳は「何を調べたかをどう証明するか」を解く；三態結論と敵対的検証は「人がどう信じられるか」を解く。

それは PR 上の自動コメントロボットではなく、レッドチームのワンクリック置換でもない。単一倉庫監査の標準作業手順として扱い、あなたのサンドボックス・受理・開示フローに繋げて初めて、スター項目から組織能力になる。レビューゲートも同時に見ているなら、本稿を Open Code Review と対照せよ：一条の線は PR ノイズを下げ、一条の線は脆弱性証拠の質を上げる——両者とも決定性構造を要し、より長いプロンプトを要しない。

参考ソース

  1. cloudflare/security-audit-skill（README、スター、MIT；2026-09-24 参照）
  2. 倉庫内 skills/security-audit/SKILL.md（指導モード / 完全監査、サンドボックスと書き込み隔離）
  3. Build your own vulnerability harness（Cloudflare ブログ、Skill からフリート harness への文脈）
  4. Skills CLI / skills.sh（インストール入口）
  5. 当サイト関連：Agent Skills 入門、AI 符号化代理と実脆弱性研究、Open Code Review