Cloudflareのモデル非依存AIセキュリティスキャニング設計図

CloudflareのProject Glasswingは、AIを活用したセキュリティツールを構築するエンジニアリングチームに実践的な知見を提供し続けている。最新の投稿では、初日からモデル非依存となるように設計された脆弱性ハーネスのアーキテクチャを解説している。核となるテーゼは、どんなに高性能なモデルであっても、セキュリティパイプラインの基盤とすべきではないということだ。モデルはコモディティであり、オーケストレーション層こそが永続する。

なぜエージェントではなくハーネスなのか

この投稿は、よくある2つの反論に直接答えている。第一に、なぜサブエージェントを使わないのか。サブエージェントは孤立したタスクには適しているが、セキュリティ分析には、実行をまたいで存続し、コンテキストウィンドウを共有せず、後で相互参照できる何百もの持続的な調査が必要となる。これはプロンプトの問題ではなく、オーケストレーションの問題である。第二に、これはフロンティアモデルの宣伝ではない。Cloudflareは、その時々のタスクに最適なモデルでハーネスを実行しており、異なるモデルが異なるバグを発見する。ハーネスこそが耐久性のある資産である。

スキルからパイプラインへ

Cloudflareは、450行のsecurity-auditスキルから始めた。このスキルは、1回のセッションで7フェーズの監査（偵察、ハント、検証、報告、機械的検証、独立した再検証、提出）を実行した。このスキルは機能したが、3つの壁にぶつかった。コンテキストの枯渇（モデルが1時間後にバグを忘れる）、永続性の欠如（クラッシュすると最初からやり直し）、リポジトリ間の依存関係への盲目性である。解決策は、状態を外部化し、LLMをステートレスな計算エンジンとして扱い、各フェーズを独自のエージェントにコード化し、背後にデータベース、前面にオーケストレーターを配置することだった。スキルからパイプラインへのマッピングはほぼ一対一だった。

2段階のワークフロー

Cloudflareの脆弱性研究ワークフローは、脆弱性発見ハーネス（VDH）と脆弱性検証システム（VVS）の2段階に分かれている。VDHはコードベースをスキャンして潜在的な問題を表面化する。VVSは重複排除、判断、修正を担当する。重要なのは、VDHが1つのモデルを使用するのに対し、VVSはまったく異なるモデルを使用することだ。これにより、検証モデルが敵対的な第三者として機能し、まったく異なる論理的重みとトレーニングデータで発見モデルの前提をストレステストする。運用上も、温度変化、キャッシュの変動、推論予算の調整など、単一のモデルプロバイダーの変動からシステムを切り離し、パイプラインを壊さないようにする。

ビルダーへの実践的アドバイス

この投稿は率直なガイダンスを提供している。データベースでバックアップされた偵察、ハント、検証の各段階からなる最小限のハーネスから始めよ。重要なリポジトリが複数になるまでは、リポジトリ間のトレースをスキップせよ。ノイズに溺れるまでは、専用の重複排除エージェントをスキップせよ。まず開発環境でプロンプトをうまく機能させ、その後、それがなければ具体的に遅延が生じる場合にのみ、次のアーキテクチャ段階を構築せよ。

Cloudflareの128のリポジトリからなるフリートは、言語ごとのチューニングなしに1つの統一ハーネスで動作する。ハーネスはCのポインタを見ているのかTypeScriptを見ているのかを気にしない。セキュリティオーケストレーションに集中し、構文はモデルに任せる。これこそが、どのLLMリリースサイクルよりも長持ちする、実用的でモデル非依存の設計である。