Cloudflareは、セキュリティーレビューを再現可能で証拠に基づく作業手順に整理するための、オープンソースのコーディングエージェント用スキルを公開した。「Security Audit Skill」と呼ばれるこのプロジェクトは、同社がより広範な脆弱性発見用の実行基盤を開発する出発点となった、単一リポジトリー向けの仕組みとして提示されている。

このスキルは監査を6段階に分ける。事前調査、調査範囲を基準とした検討、候補の検証、構造化された報告、独立した記録確認、中立的な結果提示である。モデルが最初に抱いた疑いをそのまま脆弱性として扱わず、調べたコードを記録し、発見事項を確認済みとする前に後続の検証を要求する。

設計の中心となるのは機械可読の成果物だ。親エージェントは調査範囲台帳の作成後に検証ツールを実行し、その後の作業で台帳が変更されるたびに再び実行する。別の発見事項検証ツールは第4段階で実行され、第5段階で記録を置き換えた後にも実行される。こうした反復確認は、複数のエージェントがコードベースの異なる部分を調査する際、監査記録の内部整合性を保つことを目的とする。

報告モデルは3種類の結果を区別する。確認済みの発見事項には、関連するソースまでの完全な追跡経路と、範囲を限定した観測結果が必要だ。「検証が必要」の記録は、未解決の事実を正確に特定しなければならず、重大度を付けることはできない。「棄却」の記録は、調査で否定された候補を残す。棄却された作業や未解決の作業を見える状態に保つことで、作業の重複を減らし、証拠と推論の境界を明確にできる。

監査は実行を重ねるごとに蓄積される。このスキルは以前の調査範囲台帳や発見事項を読み、未調査部分を探し、変更されたソースを再確認できる。また、現在も有効なコードに結びついた証拠を引き継ぐことができる一方、古くなった作業や未解決の作業を十分に調査済みだとは見なさない。この方式は、使い捨ての単発スキャンではなく、繰り返しのレビューを支えることを目指す。

プロジェクトには二つの動作モードがある。コードベースの監査や侵入テストを直接求める依頼では全工程が実行される。一方、限定的なセキュリティー上の質問や対象を絞った脆弱性調査では、ユーザーが報告成果物を求めない限り、ガイダンスモードを使う。全工程の監査で出力先が選択されていない場合、成果物は対象リポジトリーの外の番号付きディレクトリーに保存される。リポジトリー内に監査資料を書き込むには、バージョン管理で無視されるディレクトリーを明示的に選ぶ必要がある。

Cloudflareはこの公開物を、エージェント支援型レビューの基礎であって、コードベースが安全であることの自動的な保証ではないと説明する。安全策は追跡可能性に重点を置く。エージェントは仮説を生み出せるが、検証ツール、ソースに結びついた記録、明確な判定状態が、最終報告に何を含めるかを管理する。根拠のない高重大度のラベルが、欠陥の見落としと同じくらい誤解を招き得るセキュリティーの仕事では、この分離が特に重要になる。