security-audit：コーディングエージェントに六段階のセキュリティ監査をさせる

誰向けか

今のコーディングエージェントにセキュリティ監査員として働かせ、六つの段階——偵察、狩猟、検証、報告、構造化出力、独立確認——を完走させて、実影響があり利用可能な脆弱性を見つけたいときに security-audit を使う。複数の並列サブエージェントを編成するのであり、指名されていないスキャン製品を手でクリックさせるものではない。

前提：コーディングエージェントが使うモデルはツール呼び出しと並列サブエージェントに対応していること。第五段階の schema 検証には Node.js も必要で、validate-findings.cjs に対応する。資料はエージェント製品の一覧ではなく能力要件を出しているので、特定ソフトの独占だと捉えてはいけない。公式ガイドページは

https://github.com/cloudflare/security-audit-skill

3 分で最初の試行を終える

公式のインストールコマンドは抜粋にある：

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

このコマンドは skill を書き込むので副作用がある。今の環境が監査に使うコーディングエージェントだと確認してから実行する。インストール後、まずこのマシンに Node.js があるか確認する。第五段階で validate-findings.cjs を走らせるためである。

未知のリポジトリに対してすぐ「pen-test the code」と言わない。security audit、find vulnerabilities、pen-test the code などのトリガー句に合う依頼は自動で起動する。出力ディレクトリを指定しなければ尋ねられ、既定では ~/security-audit-skill/<repo-name>/run-<N> に書く。ホームディレクトリ配下にファイルができる。

低リスクな最初の試行：インストール成功後、まず空で自分が所有する出力ディレクトリを指定し、「今監査したら出力はどこに書かれるか」だけ尋ねる。コード変更や外向き送信を始める権限は与えない。成功の合図：skill が入り、エージェントが既定の出力パス規則を復唱でき、ディレクトリ確認前に六段階を始めていないこと。本当に完全な監査を走らせるときは、先に対象リポジトリと出力パスを確認してからトリガー句を使う。

利用例

例 1：自分が所有するコードリポジトリで監査を始める。公式インストールを終え、Node.js が使えることを確認し、明確な出力ディレクトリを出し、資料のトリガー句の一つを使う。完了基準はエージェントが六段階に入り、指定ディレクトリに今回の run の出力を残すこと。既定パスで残したくない旧結果を上書きしない。抜粋は各段階の内部コマンドを書いていないので、偵察や狩猟の具体スクリプトを作らない。

例 2：利用できる発見だけを残す。資料の要求：利用できる問題だけを報告し、各発見には具体的な攻撃シナリオが必要であり、「攻撃者は理論上……」ではない。第五段階は validate-findings.cjs で schema 検証をする。これは出力への拘束である。先に検証を走らせ、どの項目を残すかを決める。概要は対抗検証を発見者とは別のエージェントが行うとも述べるが、抜粋はエージェント切替コマンドを書いていない。この例の完了基準は「項目が具体シナリオを持ち schema を通る」ことであり、検証エージェントが自動で切り替わったことではない。

利用上の境界

六つの段階は偵察、狩猟、検証、報告、構造化出力、独立確認である。既定出力は ~/security-audit-skill/<repo-name>/run-<N>。Node.js がなければ第五段階の検証を終えられない。ツール呼び出しと並列サブエージェントがなければ、資料が書いた実行要件に届かない。

利用できない理論上の問題を報告しない。未許可の対象に pen-test トリガー句を使わない。資料はクライアント一覧も、Node.js 欠如時に検証を飛ばす方法も書いていない。ここに書いたインストール、トリガー、出力ディレクトリ、報告基準を超える範囲は、この説明の対象外である。