Build your own vulnerability harness｜独自の脆弱性ハーンを構築する | AIニュース最前線

数週間前、私たちはプロジェクト・グラスウィングの初期調査結果を発表しました。これは、最先端のセキュリティモデルをエンタープライズコードベースに適用した場合に何が起こるかを分析したものです。また、最先端 AI がもたらす脅威からインフラと顧客を守るために、私たちの防御構造がどのように適応するかについても探求しました。それ以来、AI エコシステムは急速に変化し続けています。単一のモデルの周りに緊密に構築された開発者たちは、そのモデルが使えなくなった場合や、より能力の高いモデルに置き換えられた場合に何が起こるかをすでに経験しています。これらの市場の変化は、私たちの核心的な仮説をさらに裏付けています。つまり、どの基盤モデルがその日のトップを走っているかに関わらず、エージェント型ワークフローの未来は、スタンドアロンのモデルやプロンプト、単一のエージェントセッションには見出せないのです。 ローカライズされたセキュリティ「スキル」から、継続的でフラット全体のスキャンパイプラインへ移行するには、モデルを交換可能なコンポーネントとして扱うアーキテクチャが必要です。単一のモデルに依存することは本質的に防御のカバレッジを制限します。なぜなら、同じシステムはコードパスを全く同じレンズを通して見てしまう傾向があるからです。これに対抗するため、モデルは頻繁に交換し、相互テストを行うべきです。パイプライン全体でモデルを変化させること（例えば、初期発見には一つのモデルを使用し、検証には全く異なるモデルを使用するなど）により、脆弱性が論理の異なるセットによってクロスチェックされることを保証できます。さらに、真のエントプライズスケールのハーンネスは、孤立したリポジトリを超えて、クロスリポジトリ依存関係にわたる脆弱性を追跡し、最終的に数千もの生のカンドゥデートを信頼できるトリアージ済みキューのアクション可能な修正へと絞り込む必要があります。 本記事では、状態制御の管理方法、偽陽性の排除方法、そして大規模なエンドツーエンドのトリアージ調整方法を焦点に当て、このモデル非依存レイヤーをどのように構築するかを実践的な視点から解説します。 二つの異議、冒頭で 最初の投稿では、汎用的なコーディングエージェントがこのタスクを遂行できない理由について論じました。主な問題は、エージェントが一度に一つの仮説しか保持できず、実際のリポジトリのごく一部をカバーした後にコンテキストウィンドウを満たし、その後コンテキスト圧縮の過程で情報を失ってしまう点にあります。詳細は当該投稿をご覧ください。 進む前に、おそらく二つの質問にお答えしたいと思います。 "なぜハーンではなくサブエージェントを使うのですか？" サブエージェントは有用であり、良い出発点です。しかし、セキュリティ分析には、実行を跨いで存続し、コンテキストウィンドウを共有せず、後でスコープを再定義したり相互参照したりできる数百の別々の調査が必要です。そこには永続性、重複排除、再開可能性、そして最終的には組織全体にわたる依存関係追跡が必要となります。これはオーケストレーションの問題であり、プロンプトだけではそのレベルには達できません。 "このブログ記事はフロンティアモデルのための広告ではありませんか？" いいえ。私たちのアプローチの中心はハーンにあり、モデルにはありません。脆弱性発見に関しては、私たちが求めていることに現在最も適しているフロンティアモデルを何でも使用して実行します。異なるモデルを同じターゲットに向けると、それぞれがバグの異なる割合を発見します。残る部分はハーンです。もし独自のシステムを構築するなら、初日からモデル非依存となるように設計してください。これにより、制約なく任意の選択したモデルを使用する自由が得られます。 すべてはスキルから始まる 私たちは、単一のリポジトリで実行し、実際のバグを表面化させるまでプロンプトを調整した、約 450 行のセキュリティ監査スキル（security-audit skill）から始めました。その後、システム全体の配管となったオーケストレーションを追加しました。真の価値はプロンプト自体にあり、私たちのプロンプトは依然として初期スキルの攻撃者シナリオ、バグクラス、およびアンチパターン検出をほぼ変更せずに引き継いでいます。 このスキルは、1 つのセッションで 7 フェーズの監査を実行するように記述されました： 3 つの並列する研究エージェントが情報収集を行い、architecture.md を作成します。 各攻撃クラスごとに 1 つの Hunter エージェントが実行され、コードをレビューするのではなく、それを破ろうと試みます。 敵対的なバリデータは、それぞれの発見を否定しようと試みます。 生き残ったものは、人間が読みやすい脆弱性レポートとして記述されます。 また、それらは findings.json としてスキーマに対して出力され、機械的なチェックによってそのファイルが検証されます。 最後に、新しいエージェントが独立してソースコードに対してすべての発見を再検証します。 生存し、再検証された発見は ingest API に提出されます。 この最初のスキルは、後のハネスとほぼ直接対応しています： スキルフェーズ ハネスステージ 情報収集エージェントが architecture.md を作成 情報収集 ハンターが各攻撃クラスごとに実行 探索 バリデータが発見を否定 検証 生存した発見がレポートとなる レポート findings.json がスキーマ適合性について機械的にチェックされる（正しさについてはチェックされない） findings 内の行番号と関数の機械的検証 新しいエージェントが発見を再検証 独立検証 このスキルは機能しましたが、すぐにその限界が明らかになりました。カバレッジ指標を見ると、単一のランでは、複数回実行して検出できるバグの約半分しか見つかりません。私たちの経験則では、発見されたものは単純で微妙さの少ないものへと偏っていました。プロセスが基本的に「10 回実行して手動で差分を取る」状態であれば、本格的なハネスを検討し始める必要があるでしょう。 スキルを実行・微調整している間、私たちは 3 つの壁に直面しました： コンテキストの枯渇：1 時間経過するとコンテキストウィンドウがいっぱいになり、モデルは自身のメモリを共食いしてしまい、朝から追跡していたバグを即座に忘却します。このボトルネックを打破するために、状態を完全に外部化し、LLM をステートレスな計算エンジンとして扱いました。 永続性：実行中にクラッシュすると最初からやり直しになります。AI のレート制限エラーや接続の不安定さによって数時間の作業が失われることは、より良いアーキテクチャが必要だと気づくための非常に高価な方法です。 跨リポジトリ推論：単一のリポジトリセッションでは、それを利用するアプリケーション間の関係を完全に把握できず、コンポーネント間のインターフェースを検査した際に表面化するバグの数は、予想以上に多い可能性があります。 助言：真に必要最小限のハーン（harness）とは、Recon、Hunt、Validate の各ステージをデータベースに保持し、独自の発見事項を提出できない別個の Validator を用意するものです。意味のあるリポジトリが 1 つを超えるまで、跨リポジトリの追跡は完全にスキップしてください。ノイズで溺れていると実感するまで、専用の重複排除（Deduplication）エージェントもスキップしてください。まずは開発環境内でスキルを習得し、プロンプトがうまく機能するようにしてから、それが特定のボトルネックとなっている場合にのみ次のアーキテクチャステージを構築してください。 スキルをパイプラインとしてコード化する この分野におけるほとんどの AI セキュリティに関する記事は、単一のリポジトリや厳選されたベンチマークについてのものであり、クロス・リポジトリ追跡を伴うこのような大規模なフリート全体を実行する方法が他で書かれているのを見たことはありません。私たちのコードベースは、Rust、Go、C、Lua、TypeScript、Python といった多様な言語に加え、さまざまな構成管理システム、静的設定ファイル、そしてあらゆる種類の追加コンテキストにまたがる巨大な混合体です。そのため、私たちにとって機能する新しい何かを考え出す必要がありました。最初のスラッシュコマンド実行から、128 の異なるリポジトリをカバーし、関連する依存関係を自動的に発見・調査できるフリートスキャナーへと移行するには約 6 週間かかりました。コード化は主に機械的な作業でした：スキルの各フェーズを独立したエージェントに昇格させ、その背後にデータベースを配置し、前面にオーケストレーターを設置しました。マッピングはほぼ 1 対 1 でした。 フリート全体は、言語ごとの調整を行わない単一の統一されたハーンネス上で実行され、リポジトリ間の依存関係を追跡します。構文解析をモデルに任せることでシステムが言語非依存となりますが、決定的な違いはリポジトリ間の依存関係を追跡できる能力にあります。ハーンネス自体は、C のポインタを見ているのか TypeScript ファイルを見ているのかには関心を持ちません。セキュリティオーケストレーションのより高レベルなロジックに焦点を当てています。これにより、カスタムの言語パーサーを書くことなく、数百もの異なるコードベースにスケールすることが可能になります。 二段階の脆弱性調査ワークフロー 私たちの脆弱性調査ワークフロー全体は、脆弱性発見ハーン (VDH) と脆弱性検証システム (VVS) という 2 つの段階からなる運用フレームワークの上に構築されています。 VDH は発見エンジンとして機能し、コードベースを能動的にスキャンして潜在的なセキュリティ課題を浮き彫りにします。バグが VVS に流入すると、複数のハーンからデータを受け取るこのシステム内で、重複排除 (Deduplication)、判定 (Judgment)、そして最終的な修正 (Fixing) の各段階を経て処理されます。これらについては後ほど詳しく説明します。 VDH には 1 つのモデルを使用しますが、VVS には全く異なる別のモデルを採用しています。つまり、両方のモデルが互いに二重チェックを行う仕組みです。これには明白なセキュリティ上の利点があります。モデル B (VVS) にモデル A (VDH) の出力を判定させることで、発見された事象が、論理的な重み付けとトレーニングデータが完全に異なるセットによって評価されることを保証できます。これは、モデル A の仮定を容赦なくストレステストする唯一の役割を持つ、偏りのない敵対的な第三者として機能します。運用面では、モデルプロバイダーを相互交換可能な商品のように扱うことで恩恵を受けます。モデルプロバイダーは、時間経過とともに温度設定やキャッシュ、推論処理のリソース予算を変更できるためです。モデルが時間を通じて予測可能に動作することに依存するシステムを構築するのではなく、私たちのハーンは下流の振動を検知しても破綻しないように設計されています。 ステージ 1: 脆弱性発見ハーン (VDH) 最初の投稿では、各エージェント/ステージの役割について解説しましたので、今回はそれ以外の部分、つまりステージ間の接着剤や、システムが機能するかどうかを決定するいくつかの詳細についてお話しします。 エージェント/ステージ 主な役割 サブエージェント/ツール Recon（偵察） ターゲットアーキテクチャのマッピングと潜在的な脅威ベクトルの特定 3 つの並列実行される Recon サブエージェントが architecture.md を作成 Hunt（狩猟） クラス別攻撃の実行、断片の統合、バイナリのプロービング 兄弟プロセスを起動します（これらはモデルに応じて fleet 全体のタスクの 9% から 20% を処理します）。また、Wishlist ツールにアクセスして書き込みを行います。 Validate（検証） 発見事項を機械的にチェックし、その後敵対的な手法でその妥当性を否定する 2 つのパスで実行されます。最初のスキーマ/パスチェックは通常のコードが担当し、報告前に発見事項の否定を試みる単一の孤立したエージェントが後続します。 Gapfill（ギャップ補充） 未カバー領域に対する新たな狩猟タスクを生成 まだ薄くテストされている可能性のある (エリア × 攻撃クラス) のセルに対して、新鮮な狩猟タスクをキューに追加 Dedup（重複排除） 重複する発見事項の特定と統合 決定論的なコードとエージェントを組み合わせて、根本原因に基づいて発見事項をクラスタリングし、リアルタイムで統合します。 Trace（追跡） 依存関係グラフの探索とコンシューマーリポジトリタスクの起動 グラフをたどり、特定されたすべてのコンシューマーリポジトリ内に狩猟タスクを追加し、リポジトリ間バグが検出されるようにします。 Feedback（フィードバック） 既存レポートから学習し、今後の実行を最適化 検証の失敗、浅い実行、および繰り返されるミスを取得し、キューされたプロンプトを即座に書き換えて、将来のタスクをより鋭くします。 レポート 人間が読みやすい形式でレポートを生成します。 単なるスクリプトであり、モデルは不要です。 表 1: 脆弱性発見ハーンネス (VDH) ステージ 4 から 8 は、継続的なプロデューサー・コンシューマーループとして実行されます。初期の探索が進行するにつれ、Gapfill（ギャップフィリング）、Feedback（フィードバック）、Trace（トレース）エージェントが新しいタスクを生成し、Dedup（重複排除）は重複した発見結果を統合し、残りのループ部分はキューを引き続き消費します。これにより、サイクルの遅い段階で発見された脆弱性であっても、同じ実行内で検証され、報告され、他のコードと比較されて同一のバグが含まれていないことが確認されます。 パイプラインをこのように分割することで、厳格なコンテキスト制御が保証されます。コンテキストウィンドウがいっぱいになると、モデルは幻覚（ハルシネーション）を起こし始めます。各エージェントの役割を極めて焦点を絞ったものに保つことで、コンテキストの使用量を総ウィンドウの 25% 未満に抑えています。「すべてのファイルを読み取る」という単純なアプローチでは、毎回この制限を超えてしまいます。 私たちが陥った一つの落とし穴は、並列処理を実装する前に永続化（パージステンス）を考慮する必要があるという点です。予期せぬエラーのために 5 時間にわたる実行をすべて捨ててしまうようなことは避けなければなりません。各ステージは、(run_id, repo, stage) をキーとして SQLite データベースに書き込みます。どのステージでも再開や再試行が可能であり、後続の実行に引き継ぐこともでき、作業のやり直しは不要です。発見結果は発生した瞬間にストリーミングされ保存されるため、クラッシュが起きた場合でも影響するのは実行中のタスクのみで、それ以外のデータには被害が及びません。 アドバイス：一時的な API エラーは、コード例外をスローする代わりに、(200 OK) 応答ストリーム内のテキストとして返されることがあります。オーケストレーターにとっては、これは完全に正常に終了したタスクと全く同じように見えます。例外タイプだけを信頼するのではなく、応答テキストを明示的に分類する必要があります。そうしないと、空の実行が成功として記録されてしまいます。 動的脅威モデリング Recon（偵察）ステージでは、エージェントは脅威モデルを受け取るのではなく、自ら作成します。注入、メモリ破壊、プロトコル解析、タイミングサイドチャネルなど、多くの形態を含む約 10 の組み込み攻撃クラスを超えて、Recon エージェントはその場でリポジトリ固有のクラスを即座に発明できます。それぞれが独自のメソドロジーを持ちます。これはそのコードベースに特化したカスタム分類体系を作成し、Hunter エージェントの範囲をより厳密に限定するために使用されます。 ソースコードを読むだけでは、ストレス下での動作を理解するには不十分です。特に C や他の低レベル言語における微妙な未定義動作バグについてはなおさらです。Hunter エージェントはコードの読み取りを超え、アクティブな実行へと移行します。断片をコンパイルし、小型版を構築して攻撃を行います。品質における最大の飛躍は、バイナリをクラッシュさせるためのサンドボックス（unshare をベースに構築）を Hunter に与えたことによってもたらされました。 アドバイス：ハルネス自体が Docker 内で実行される場合、そのサンドボックスには seccomp=unconfined および apparmor=unconfined を設定する必要があります。これらを指定しないと、起動時に静かに失敗してしまいます。ネスト型コンテナ化の専門家でない限り（私たちもそうでしたが）、これを 1 行で修正するだけで、頭を抱えて過ごす 1 日分の時間を節約できます。 マイクロフォークとウィッシュリスト コアパイプラインのステージ以外に、ハント担当者が分析を中断させることなく焦点を適応させたり外部リソースを要求したりするための自律性を大幅に付与する 2 つの専門メカニズムを追加しました。 兄弟フォーク：これは、ハント担当エージェントが現在のスコープ外の興味深いコードパスに遭遇した際に、軌道から逸脱しないようにするために役立ちます。この機能は、正確な構造的シードを持つ兄弟エージェントをフォークするためのツール呼び出しを使用します。フリート全体ではタスクの約 9% を占めますが、その割合はモデル依存度が非常に高く、どのモデルがハントを行っているかによってほぼゼロから約 5 分の 1 の範囲で変動します。 ウィッシュリスト：エージェントが持っていないツールを必要とする際、特に Proof of Concept (PoC) を確認するバリデーターや、特定のビルド環境、仮想マシン（VM）、あるいは本番構成ファイルなどを構築したいハンターは、中央のウィッシュリストに書き込みます。これにより、人間が依存関係を満たした時点でシステムがその正確なタスクを自動的に再実行するための十分な文脈が提供されます。これらの一部は部分的に自己修復機能を持ちます：コンテナに変更を加えて再ビルドする必要がある場合、汎用的なコーディングハーンスがログを監視することで、実行後に自律的にこの処理が行われます。 ウィッシュリストは追加されて以来、128 のリポジトリ全体で 25,472 回書き込まれており、これがエージェントが私たちに報告する主要な手段となっています。執筆中に着信した一例に「この PoC をエンドツーエンドで確認するために FreeBSD VM が必要だ」というものがあります。 フリート全体のクロスリポジトリ追跡 初期のクリーンアップ後、トレーサーエージェントは異なるソフトウェアコンポーネントがどのように接続されているかを確認します。特定のパスを探索します：潜在的な攻撃者が外部から有害な入力をシステムの脆弱な部分に送信できるかどうかです。答えがイエスであれば、トレーサーエージェントは自動的に消費者リポジトリ内で新しいハンティングタスクを起動します。これを機能させるには、統一されたクロスリポジトリシンボルインデックスと正確な依存関係グラフが必要です。これにより、標準的な単一リポジトリスキャンでは見逃される可能性のある深層的で体系的な欠陥を発見することができます。 フルセットのレポジトリ群に対してハーンネスを実行した結果、大規模実施时才に浮き彫りになった2 つの教訓が得られました。 まず、重複排除はそれ自体が独立した大きな問題であり、専用のエージェントを必要とします。数個のレポジトリをスキャンする程度であれば、手作業で重複するバグを目視確認できます。単純な文字列マッチングやファイルパスチェックではここでの課題は解決できません。2 つの複雑なロジック欠陥が実際に全く同じ根本的なバグであるかどうかを判断するのは一見簡単そうに思えますが、実際にはそうではありません。そこには多大な認知的推論が必要となるため、ノイズを除去するために専用の重複排除エージェント（Dedup agents）を配備し、独自のヒューリスティックと作業削減手法を持たせる必要がありました。 2 つ目は、静的解析ツールを早期に組み込まないことです。Semgrep をフルスタックで導入しましたが、ハントラーたちは1 か月の実行期間中一度もそれを呼び出しませんでした。彼らはコードを読んで実行することを好みます。一方、ウィッシュリストはシステム内で最も頻繁に使用されたツールでした。エージェントが実際に何に手を伸ばすかに注目することが、あなたが彼らが必要とするだろうと考えることよりも重要です。 信頼できる発見結果を作成する エージェントは、自身のエクスプロイトが機能するようにソースコードを編集し、作成したばかりのバグを堂々と報告します。あるいは、「exec() は何かを実行するものであるため、重要な脆弱性である」といった全く同語反的なものを証明するテストを書いたり、脅威モデル自体が無意味なために何も証明できないが動作はするエクスプロイトを作成したりします。もしあなたのハーンネスがこの傾向に積極的に対抗しないなら、あなたが構築したのは単にゴミをより速く生産するための手段に過ぎません。 ハンターは、何かを提出することを許可される前に、必ず脅威モデルを明示しなければなりません。攻撃者が誰であるかを正確に定義し、その脆弱性がどの境界を越えるのか、あるいはどの前提を破るのかを明確にする必要があります。出力スキーマの順序付けがこの要件を強制します。この要求により、「ユーザーがデータベース書き込み権限を持っていれば、データベースに書き込める」といった空虚な発見や、「データベースへの書き込み権限を持つユーザーはデータベースに書き込める」といった類の報告を排除できます。 技術用語: エクスプロイト (exploit)、ハーンネス (harness)、脅威モデル (threat model)、出力スキーマ (output schema) すべての確認された発見には、オリジナルの未変更コードベースに対して実行されるテストとして記述された PoC が付属します。これにより、エージェントがソースファイルを編集してエクスプロイトを成立させることが防止されます。動作する PoC がない場合、その発見は偽物として扱われます。実際には、ハンターが三十行程度の解析ループをコンパイルし、メモリ保護を有効にして実行し、誤った読み取りストライドが期待されるメッセージ本体ではなくスタックアドレスから発生していることを実証します。これを自分自身で再実行することも可能です。さらに、すべての確認された発見には提案されたパッチも付属する必要があります。実際にレビューキューに到達するのは、検証済みのバグ、動作するテスト、そして機能的な git diff であり、単なる問題の漠然としたテキスト記述ではありません。 エクスプロイト経路が生き残る前には、決定論的コード（別のモデルではなく通常のコードで記述されたもの）が機械的に、引用されたファイルとパスが実際に存在することを確認し、パッチとテストの両方が正しく構文解析されることを確認します。このバリデータは独自の発見をログに記録することはできません；その唯一の仕事は、ハンターの理論を積極的に反証することです。もしハンターに自分の宿題を採点する許可を与えれば、出力したすべてのものを自信を持って検証してしまうでしょう。 当システムについて、偽陰性率を主張するものではありません。コードベース内のすべての実際のバグにラベル付けされたセットが存在しないため、いかなるリコール数値の主張も完全に推測に基づくものです。私たちが監視できるのは、再実行で新たなバグが継続して発見されるか（実際そうであり）、また各実行を通じてカバレッジがまだ拡大しているかどうかです。これはあくまで代理指標に過ぎません。なぜなら、単一のコードベース内に実際に存在するバグの数を確実に知ることはできないからです。しかし、効果性を測定するための十分に良い方法ではあります。 ステージ 2: 脆弱性検証システム (VVS) ハーネスから得られた発見は、トリアージプロセスの始まりに過ぎません。すべての発見物は、現在 145 のリポジトリ全体で合計 13,841 の発見物を保持している単一の共有 VVS に集約されます。この量のトリアージを行うことは、それ自体が巨大なエンジニアリング課題であり、ハンティングと同様に重要です。そのトリアージエンジンは、ハーネスとは異なるモデルに基づいており、3 つの明確に区別されたジョブに分解されています。 エージェント/ステージ 主たる役割 スパーン/サブエージェント/ツール 重複排除 (Dedup) 脆弱性がシステム内に既に存在するか、あるいは内部 Jira チケットとして既に提出されているかを特定する 決定論的：単純なコードビルドによりファイルに対して逆インデックスを構築し、f

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

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト