cloudflare/security-audit-skill

コーディング支援AI（エージェント）に読み込ませるスキルで、README はこれを「エージェントをセキュリティ監査担当に変えるもの」と説明している。中身のほとんどは手順書で、SKILL.md に全体の進め方と原則、そのほかのファイルに攻撃の種類ごとの調べ方が書かれている。メモリ安全性、プロンプトインジェクション、HTTP まわり、供給網、クラウド設定、テナント分離など、対象の性格に応じて読むファイルが分かれている。言語は JavaScript、ライセンスは MIT。

進め方は6段階に決まっている。まず全体の見取り図（構造・信頼の境界・入力の入り口）を作り、coverage-ledger.json にどこを見たかの台帳を作る。次にその台帳の単位ごとに別々のエージェントを割り当てて探させる。見つかった候補は、見つけたのとは別の新しいエージェントに渡され、その担当は「それは成り立たない」と崩しにかかる。結果は confirmed（裏付けがそろったもの）、needs_validation（確かめきれない事実がはっきり残っているもの）、rejected（崩されたもの）の3つに分けて findings.json に書かれ、同梱のスクリプトが形式を検査する。検査スクリプトは Node.js で動き、外部の依存が無い。

もとは Cloudflare が社内で使っている脆弱性発見の仕組みの出発点にあたるもので、そちらは多段・全社規模に育ったが、これはリポジトリ1つぶんの版だと README は書いている。同じリポジトリに対して繰り返し走らせることが前提で、前回の台帳と結果を読んで、見ていないところを狙う作りになっている。README は自社の試験運用について「1回の実行で見つかるのは、繰り返し実行して見つかった総数のおよそ半分だった」と書いている。

AIの「脆弱性を見つけました」を、そのまま信じたくないとき

エージェントに調べさせると、それらしい指摘がいくらでも出てくる。このスキルは、見つけた担当とは別の担当に反証を試みさせ、崩せたものは rejected として記録に残す。確定・保留・却下のどれなのかが、最初から分かれて出てくる。

自分のコードのどこを見ていないかを知りたいとき

台帳（coverage-ledger.json）に「どの単位を、どう調べたか」が残る。調べた結果だけでなく、調べた範囲そのものが成果物になる。

サンドボックスが無いと、確かめきれないまま残る。 README は、対象のコードを実際に動かす作業（ビルド・テスト・ブラウザ・ファジング）には OS が強制する隔離環境を要求している。外部通信を切り、環境変数を絞り、資源の上限を決め、書き込みを割り当てた場所だけに限る、という条件が並ぶ。これが無い場合、その手がかりは実行されずに needs_validation のまま置かれる。

1回で終わる想定ではない。 設計方針にも「複数回実行するほどカバー範囲が広がる」と書かれていて、根拠として社内の試験運用で1回あたりおよそ半分という数字が挙がっている。1回のなかで何体ものエージェントを動かす作りなので、外部のモデルを使う場合は費用の出方を先に見ておきたい。

深層防御の穴は、脆弱性として報告されない。 「A の層で攻撃が防げているなら、B の層が無いことは脆弱性ではなく改善点」という方針が明記されている。多層で固めたい立場からすると、出てくる指摘は想像より少なく見えるかもしれない。

動かす側の条件もある。 ツール利用と並列のサブエージェントに対応したモデルが要り、検査スクリプトを動かすのに Node.js が要る。ライセンスは MIT。