この記事について（広告・アフィリエイトリンクはありません）
security-audit-skill は無料（MIT）です。AI の利用料は、ふだん使っている Claude の契約の範囲で、追加の料金はかかっていません。
security-audit-skill は、Cloudflare が公開した、AI エージェントをセキュリティ監査役にするスキルです。わざと穴を5つ入れた ComfyUI のカスタムノードで試すと、スキルあり・なしのどちらも5つすべてを見つけました。違いは「どこまで本当に危ないか」の切り分けで、スキルありは ComfyUI 本体の守り（よそのサイトからの要求を止める仕組み）まで読み、条件しだいのものを「要確認」に分けました。
今回はスキルの「ガイダンスモード」（1人のエージェントで、ファイルを書かずに見る）で試しました。6段階の本格的な監査（full audit）は試していません。所要時間は30分ほど、難しさは中級です。
先に結論（今回のテスト条件で）
| スキルなし（ふつうに頼む） | スキルあり（ガイダンスモード） | |
|---|---|---|
| わざと入れた5つの穴 | 5つとも発見 | 5つとも発見 |
| 安全な部分（おとり2つ） | 1つを「中」の問題として報告 | 2つとも安全と判定（1つは却下と明記） |
| 報告の数 | 8件（全部に重大度） | 確定2件・要確認3件・却下1件 |
| ComfyUI 本体の確認 | 「よそのサイトから呼べるかもしれない（未確認）」 | server.py を読み、初期設定ではよそのサイトからの要求は403で止まると確認 |
| 時間・使った量 | 約30秒・約7.6万トークン | 約82秒・約9万トークン |
security-audit-skill とは？
cloudflare/security-audit-skill は、Cloudflare の脆弱性探しの仕組みのもとになったスキルです（MIT ライセンス）。偵察、網羅的な探索、候補の検証、構造化した出力、独立した再確認、報告の6段階で監査を進めます。
特徴は、見つけた候補を「confirmed（確定）」「needs_validation（要確認）」「rejected（却下）」に分けることです。要確認は、ソースだけでは決められない事実（どこから接続できるか、など）が残っているもので、重大度は付けません。
スキルには2つの使い方があります。「この部分を見て」のような頼み方ではガイダンスモードになり、必要な考え方だけを使います。「このコードベースを監査して」と頼むと full audit モードになり、6段階すべてを実行して報告ファイルを書き出します。
試験用のカスタムノード
正解がわかるように、ComfyUI のカスタムノードの形で、わざと穴を入れたコード（113行）を書きました。インストールはしていません。
| 場所 | わざと入れたもの |
|---|---|
| GET /kobo_demo/preset | ファイル名をそのままつなぐ（パストラバーサル） |
| POST /kobo_demo/import_state | 送られたデータを pickle.loads（任意のコードが動く） |
| GET /kobo_demo/thumbnail | 指定した URL をサーバーが取りに行く（SSRF） |
| KoboDemoMath ノード | 入力の文字を eval（任意のコードが動く） |
| KoboDemoExport ノード | 入力の文字を shell=True のコマンドに入れる（コマンド注入） |
| POST /kobo_demo/preset（おとり） | basename で絞っているので安全 |
| KoboDemoSafeLoad（おとり） | realpath と commonpath で絞っているので安全 |
class KoboDemoMath:
def run(self, expression):
return (float(eval(expression)),) # わざと入れた穴スキルなしの結果
「このコードのセキュリティ上の問題を探して」とだけ頼むと、5つの穴をすべて見つけ、ほかに3件を加えた8件を返しました。追加の3件は、おとりの保存ルート（上書きやディスクの使いすぎ）、認証や CSRF 対策がないこと、読み込み時にフォルダーを作ること、です。
どれにも重大度が付き、pickle・eval・コマンド注入は「critical」でした。ComfyUI がよそのサイトからの要求を止めるかどうかは「確認できなかった」と書かれていました。
スキルありの結果
スキルの SKILL.md などを読ませてから同じコードを見せると、6件に分けて返しました。
| 候補 | 判定 | 理由 |
|---|---|---|
| eval（KoboDemoMath） | 確定・高 | 共有されたワークフローを開いて実行するだけで、作った人のコードが動く。ワークフローは「データ」のはずなのに、コードとして動いてしまう |
| コマンド注入（KoboDemoExport） | 確定・高 | 同じく、共有ワークフローの文字で OS のコマンドが動く |
| pickle（import_state） | 要確認 | –listen などで、ほかの人がポートに届くかしだい。届けば認証なしで任意のコードが動く（critical） |
| パストラバーサル（preset） | 要確認 | 同じく、届くかしだい |
| SSRF（thumbnail） | 要確認 | 外に公開していて、届く先に大事なものがあるかしだい |
| 保存ルート（おとり） | 却下 | basename と .json の固定で、フォルダーの外には書けない |
違いが出たのは、ComfyUI 本体の server.py まで読んだ点です。初期設定（127.0.0.1 で待ち受け、CORS の設定なし）では、よそのサイトからの要求（Sec-Fetch-Site: cross-site）は403で止まります。当サイトでもこの部分を確かめました。そのため、HTTP のルートの穴は「誰がポートに届くか」が決め手になり、要確認に分けられました。
一方で、ワークフローの中の文字で動く eval とコマンド注入は、ネットワークの条件に関係なく危ないので、確定になりました。共有されたワークフローを開くだけで被害が出る、という ComfyUI の使い方に合った判断です。
ComfyUI のカスタムノードを入れる前に
今回の結果から、カスタムノードのコードを AI に見てもらうときは、次の点を頼むとよさそうです。
- ワークフローの入力の文字が、eval・exec・subprocess・pickle に届いていないか（共有ワークフローで被害が出る）
- 独自の HTTP ルート（PromptServer.instance.routes）が、ファイルの読み書きや外への通信をしていないか
- –listen で外に公開している場合は、HTTP のルートの穴も「確定」と同じくらい危ない
ComfyUI を外に公開する危険は、–listen と CVE の記事でも説明しています。
導入
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-auditClaude Code などで「このコードベースのセキュリティ監査をして」と頼むと、スキルが働きます。full audit モードでは、サブエージェントの並列実行、Node.js（検証用のスクリプト）、外部ネットワークを切ったサンドボックスが必要と書かれています。サンドボックスがなければ、対象のコードは実行せず、要確認として残す決まりです。
今回は、スキルのフォルダーを直接読ませる形で試し、PC には入れていません。
よくある質問（FAQ）
Q. security-audit-skill とは？
Cloudflare が公開した、AI エージェントをセキュリティ監査役にするスキルです。候補を確定・要確認・却下に分け、確定だけに重大度を付けます。
Q. スキルなしで頼むのと何が違う？
今回の試験では、どちらもわざと入れた穴を5つとも見つけました。スキルありは ComfyUI 本体の守りまで確かめ、条件しだいの穴を要確認に分け、安全な部分を却下しました。
Q. ComfyUI のカスタムノードで特に危ないのは？
ワークフローの入力の文字が eval やコマンドに渡る作りです。共有ワークフローを実行するだけで、作った人のコードが動きます。
まとめ
security-audit-skill は、穴を見つける力そのものより、「どの条件で本当に危ないか」を根拠つきで分ける力に違いが出ました。カスタムノードを入れる前の確認や、人に報告を渡すときに役立ちます。
見つけるだけならふつうに頼む。危なさを切り分けるならスキルを使う。
検証メモ
- やり方：同じ試験用のコードを、別々の新しいエージェント2つに見せました。一方は「スキルの SKILL.md などを読み、ガイダンスモードで、確定・要確認・却下に分けて」、もう一方は「セキュリティの問題を探して」とだけ頼みました。どちらにも、穴の場所は伝えていません。両方とも、コードの実行・ファイルの書き込み・ネットワークは禁止しました。
- 確認：スキルありが根拠にした server.py の origin_only_middleware（cross-site を403にする）は、当サイトでもソースを読んで確かめました。
- 試していないこと：full audit モード（6段階、カバレッジ台帳、検証スクリプト、報告ファイル）、実在のカスタムノードへの適用、何回か繰り返したときのばらつき、ほかのエージェント。1回ずつの結果です。
