独自の脆弱性ハーネスを構築する
多段階の脆弱性発見ハーネスと自動トリアージループの背後にある技術アーキテクチャを解説します。状態管理の方法、敵対的レビューによる誤検出の排除、LLMのコンテキスト制限を回避する方法を学びます。
数週間前、私たちはProject Glasswingの初期調査結果を公開し、最先端のセキュリティモデルをエンタープライズコードベースに向けた場合の影響を調査しました。また、防御構造がどのように適応してインフラストラクチャと顧客を最先端AIの脅威から保護するかも探求しました。それ以来、AIエコシステムは急速に変化し続けており、単一モデルに密接に依存して構築した開発者は、そのモデルが利用できなくなったり、より能力の高いモデルに取って代わられたりした場合の影響をすでに経験しています。これらの市場の変化は、私たちの中心的なテーゼを強化するものです。つまり、どの基礎モデルがその日リードしていようと、エージェンティックワークフローの未来はスタンドアロンモデル、プロンプト、またはシングルエージェントセッションにはありません。
ローカライズされたセキュリティ「スキル」から継続的なフリート全体のスキャンパイプラインへの移行には、モデルを交換可能なコンポーネントとして扱うアーキテクチャが必要です。単一モデルに依存すると、防御範囲が本質的に制限され、同じシステムが同じレンズを通してコードパスを見る傾向があります。これに対抗するには、モデルを頻繁に交換し、相互テストする必要があります。パイプライン全体でモデルを変化させることで（例えば、初期発見に1つのモデル、検証にまったく異なるモデルを使用する）、脆弱性が異なるロジックセットによってクロスチェックされることを保証できます。さらに、真のエンタープライズスケールのハーネスは、孤立したリポジトリを超えて、クロスリポジトリの依存関係を横断して脆弱性を追跡し、最終的に数千の生の候補を信頼できるトリアージ済みの修正可能なキューにフィルタリングする必要があります。
この記事は、そのモデル非依存のレイヤーを構築するための実践的なガイドであり、ステートコントロールの管理、誤検出の排除、大規模なエンドツーエンドトリアージの調整方法に焦点を当てています。
最初に、考えられる2つの反対意見に対処します。まず、「なぜハーネスではなくサブエージェントを使用しないのか？」という質問です。サブエージェントは有用で、良い出発点です。しかし、セキュリティ分析には、実行間で存続し、コンテキストウィンドウを共有せず、後で再スコープや相互参照が可能な、何百もの独立した調査が必要です。それには永続性、重複排除、再開可能性、そして最終的にはフリート全体の依存関係追跡が必要です。これはオーケストレーションの問題であり、プロンプトでは解決できません。次に、「このブログ投稿は単にフロンティアモデルの宣伝なのか？」という質問です。いいえ。私たちのアプローチはモデルではなくハーネスを中心にしています。脆弱性発見に関しては、現在必要な能力に最も適したフロンティアモデルを使用します。異なるモデルを同じターゲットに向けると、それぞれ異なる割合のバグを発見します。ハーネスは永続的な部分です。独自のシステムを構築する場合は、初日からモデル非依存になるように設計してください。これにより、制約なく任意のモデルを自由に使用できるようになります。
すべてはスキルから始まります。私たちは約450行のセキュリティ監査スキルから始め、単一のリポジトリで実行し、実際のバグを発見するまでプロンプトを調整しました。その後、システム全体の配管となるオーケストレーションを追加しました。真の価値はプロンプト自体にあり、私たちのプロンプトは初期スキルの攻撃シナリオ、バグクラス、アンチパターン検出をほとんど変更せずに保持しています。
そのスキルは1セッションで7フェーズの監査を実行するように書かれていました：3つの並列リサーチエージェントが偵察を行い、architecture.mdを書きます。1つのハンターエージェントが攻撃クラスごとに実行され、コードをレビューするのではなく壊そうとします。敵対的バリデーターが各発見を反証しようとします。生き残った発見は人間が読める脆弱性レポートとして作成されます。また、スキーマに従ってfindings.jsonとして出力され、機械的チェックがそのファイルを検証します。最後に、新しいエージェントがすべての発見をソースに対して独立して再検証します。
この最初のスキルは後のハーネスにほぼ直接マッピングされました。しかし、すぐに限界が明らかになりました：単一実行では全バグの約半分しか発見できず、しかも発見されたものはより単純で微妙でないものに偏っていました。私たちは3つの壁に直面しました：コンテキスト枯渇、永続性、クロスリポジトリ推論です。コンテキスト枯渇は状態を完全に外部化し、LLMをステートレスな計算エンジンとして扱うことで打破しました。永続性は各ステージをSQLiteデータベースに書き込むことで解決し、どのステージも再開、再試行、または後続の実行に組み込むことができます。クロスリポジトリ推論は依存関係グラフをウォークし、消費者リポジトリ内にハントタスクを追加することで対処しました。
スキルをパイプラインに体系化する：最初のスラッシュコマンド実行から128の独立したリポジトリをカバーするフリートスキャナーへの移行には約6週間かかりました。体系化は主に機械的で、各フェーズを独自のエージェントに引き上げ、背後にデータベースを置き、前にオーケストレーターを置きました。マッピングはほぼ1対1でした。フリート全体は単一の統一ハーネス上で動作し、言語固有のチューニングは不要で、リポジトリ間の依存関係を追跡します。
脆弱性研究ワークフローは2段階の運用フレームワークに基づいています：脆弱性発見ハーネス（VDH）と脆弱性検証システム（VVS）です。VDHは発見エンジンとして機能し、コードベースをプロアクティブにスキャンして潜在的なセキュリティ問題を表面化します。バグがVVSに入ると、重複排除、判断、そして最終的に修正の段階を経ます。VDHとVVSでは異なるモデルを使用し、モデルが互いに二重チェックを行うようにしています。VDHにはレコン、ハント、バリデート、ギャップフィル、重複排除、トレース、フィードバック、レポートの各ステージが含まれます。ステージ4から8は継続的なプロデューサー-コンシューマーループとして実行され、ギャップフィル、フィードバック、トレースエージェントが新しいタスクを生成し、重複排除が重複する発見を折り畳みます。この分割により、厳格なコンテキスト制御が保証されます：各エージェントのジョブは超焦点化され、コンテキスト使用量をウィンドウ全体の25%未満に抑えます。永続性は並列化の前に考慮する必要があり、各ステージは(run_id, repo, stage)をキーとするSQLiteデータベースに書き込みます。どのステージも再開、再試行、または後続の実行に組み込むことができ、発見はリアルタイムでストリーミング保存されるため、クラッシュしても進行中のタスクのみが失われます。