独自の脆弱性ハーネスを構築する

独自の脆弱性ハーネスを構築する 数週間前、Project Glasswingの初期調査結果を発表し、最先端のセキュリティモデルをエンタープライズコードベースに向けた場合に何が起こるかを調査しました。また、私たちの防御構造が、最先端AIがもたらす脅威からインフラストラクチャと顧客を保護するためにどのように適応するかを探りました。それ以来、AIエコシステムは急速に変化し続けています。単一のモデルを中心に構築してきた開発者は、そのモデルが利用できなくなったり、より高性能なモデルに取って代わられたりした場合に何が起こるかをすでに経験しています。これらの市場の変化は、私たちの中心的な主張をさらに強化します。どの基盤モデルがその日リードしていても、エージェント型ワークフローの未来は、スタンドアロンモデル、プロンプト、または単一エージェントセッションには見出されないでしょう。 ローカライズされたセキュリティ「スキル」から、継続的なフリート規模のスキャンパイプラインへの移行には、モデルを交換可能なコンポーネントとして扱うアーキテクチャが必要です。単一のモデルに依存することは、本質的に防御範囲を制限します。なぜなら、同じシステムはコードパスを全く同じレンズを通して見がちだからです。これを克服するためには、モデルを頻繁に交換し、クロスチェックする必要があります。パイプライン全体でモデルを変更すること（例えば、初期発見に1つのモデルを使用し、検証に全く異なるモデルを使用するなど）により、脆弱性が異なるロジックセットによってクロスチェックされることを保証できます。さらに、真のエンタープライズ規模のハーネスは、孤立したリポジトリを超えて、クロスリポジトリの依存関係にわたる脆弱性を追跡し、最終的に数千の生の候補を、実行可能な修正の信頼できるトリアージキューに絞り込む必要があります。この投稿は、状態制御をどのように管理し、偽陽性を排除し、エンドツーエンドのトリアージを大規模に調整することに焦点を当て、そのモデルに依存しないレイヤーを構築する方法についての実践的な考察を提供します。 まず、2つの反論に対処します。 最初の投稿では、汎用コーディングエージェントがこの仕事を行えない理由を論じました。主な問題は、エージェントは一度に1つの仮説しか保持できず、実際のレポのわずかな部分をカバーするとコンテキストウィンドウが満杯になり、コンテキストの圧縮中に情報が失われることです。詳細については、その投稿をお読みください。 先に進む前に、2つの可能性の高い質問にお答えしたいと思います。 「なぜハーネスの代わりにサブエージェントを使わないのですか？」 サブエージェントは有用であり、良い出発点です。しかし、セキュリティ分析には、実行をまたいで存続し、コンテキストウィンドウを共有せず、後でスコープを変更したりクロスリファレンスしたりできる数百の個別の調査が必要です。これには、永続性、重複排除、再開可能性、そして最終的にはフリート規模の依存関係トレースが必要です。これはオーケストレーションの問題であり、プロンプトでは到達できません。 「このブログ投稿は単なる最先端モデルの広告ですか？」 いいえ。私たちの方法は、モデルではなくハーネスを中心に据えています。脆弱性発見に関しては、現在私たちが求めていることに最も長けている最先端モデルでそれを実行します。同じターゲットに異なるモデルを向けた場合、それぞれが異なる割合のバグを見つけます。ハーネスは持続する部分です。独自のシステムを構築する場合は、最初からモデルに依存しないように設計してください。これにより、制約なしに任意のモデルを選択して使用する自由が得られます。 すべてはスキルから始まります。 私たちは、単一のリポジトリで実行される約450行のセキュリティ監査スキルから始め、プロンプトを調整して実際のバグを検出しました。その後、システム全体の配管となったオーケストレーションを追加しました。真の価値はプロンプト自体にあり、私たちのプロンプトは、初期スキルの攻撃シナリオ、バグクラス、およびアンチパターンの検出をほぼ変更せずに引き継いでいます。 スキルは、1回のセッションで7段階の監査を実行するように書かれていました。 1. 3つの並列リサーチエージェントが偵察を行い、architecture.md を記述します。 2. ハンターエージェントが各攻撃クラスごとに実行され、コードをレビューするのではなく、コードを破壊しようとします。 3. 敵対的バリデーターが各発見を反証しようとします。 4. 生き残ったものは、人間が読める脆弱性レポートとして記述されます。 5. findings.json としてスキーマに対して発行され、機械的なチェックでそのファイルが検証されます。 6. 最後に、新しいエージェントが独立して、すべての発見をソースに対して再検証します。 7. 生き残った、再検証された発見がインジェストAPIに送信されます。 その最初のスキルは、後のハーネスにほぼ直接対応します。 スキルフェーズ | ハーネスステージ ---|--- 偵察エージェントが architecture.md を記述 | 偵察 Huntersが攻撃クラスごとに実行 | ハンティング バリデーターが発見を反証 | 検証 生き残った発見がレポートになる | レポート findings.json がスキーマ準拠のために機械的にチェックされる（正確さではなく） | 行番号と関数を検証する機械的検証 新しいエージェントが発見を再検証 | 独立した検証 スキルは機能しましたが、すぐにその限界が明らかになりました。カバレッジメトリクスを見ると、単一の実行では、複数回の実行で検出できるバグの約半分しか見つけられません。私たちの経験では、見つかったバグは、より単純で微妙でないものに偏っていました。プロセスが基本的に「10回実行して手動で差分を取る」ようになったら、本格的なハーネスを検討し始める必要があるでしょう。 スキルを実行し、ファインチューニングしている間に、私たちは3つの壁にぶつかりました。 コンテキストの枯渇：1時間後、コンテキストウィンドウが満杯になり、モデルは自身のメモリを食い潰し、午前中に追跡していたバグを即座に忘れてしまいます。状態を完全に外部化し、LLMをステートレスなコンピューティングエンジンとして扱うことで、このボトルネックを解消しました。 永続性：実行中のクラッシュは、最初からやり直しを意味します。AIのレートリミットエラーや接続の不安定さのために数時間の作業を失うことは、より良いアーキテクチャが必要だと気づくための非常に高価な方法です。 クロスリポジトリ推論：単一リポジトリのセッションは、それを消費するアプリケーション間の関係や、コンポーネント間のインターフェースを検査したときに現れるバグの数（予想以上に多いかもしれません）を完全に無視します。 アドバイス：真実で最小限のハーネスは、偵察、ハンティング、検証の各ステージをデータベースに格納し、独自の発見を記録できない別のバリデーターを別に持つだけで構成されます。重要なリポジトリが1つ以上になるまで、クロスリポジトリトレースは完全にスキップしてください。実際にノイズに溺れている状態になるまで、専用の重複排除エージェントをスキップしてください。開発環境でスキルから始め、プロンプトをうまく機能させ、それがないことが具体的に遅延の原因となっている場合にのみ、次のアーキテクチャステージを構築してください。 スキルをパイプラインにコード化する。 この分野のAIセキュリティに関するほとんどの解説は、単一のリポジトリまたはキュレーションされたベンチマークに関するものです。フリート全体をこのように実行し、クロスリポジトリトレースを行うことは、他に書かれたものを見たことがありません。私たちのコードベースは、Rust、Go、C、Lua、TypeScript、Pythonなど、さまざまな言語と、さまざまな設定管理システム、静的設定、およびあらゆる種類の追加コンテキストが混在しています。そのため、私たちにとって機能する新しいものを考案する必要がありました。 最初のスラッシュコマンド実行から、128個の異なるリポジトリをカバーし、関連する依存関係を自動的に発見・調査できるフリートスキャナーへの移行には、約6週間かかりました。コード化はほとんど機械的なものでした。スキルの各フェーズを独自の剤に持ち込み、その背後にデータベースを配置し、その前にオーケストレーターを配置しました。マッピングはほぼ1対1でした。 フリート全体は、言語ごとのチューニングなしで、単一の統合ハーネス上で実行され、リポジトリ間の依存関係をトレースします。構文をモデルにオフロードすることでシステムは言語に依存しなくなりますが、差別化要因はリポジトリ間の依存関係をトレースする能力です。ハーネス自体は、Cポインタを見ているのかTypeScriptファイルを見ているのかを気にしません。セキュリティオーケストレーションのより高次のロジックに焦点を当てます。これにより、カスタム言語解析を記述することなく、数百の異なるコードベースにわたってスケーリングできます。 2段階の脆弱性リサーチワークフロー。 私たちの脆弱性リサーチワークフロー全体は、2段階の運用フレームワークに基づいています。脆弱性発見ハーネス（VDH）と脆弱性検証システム（VVS）です。 VDHは、私たちの発見エンジンとして機能します。