技術サマリー：SEC-bench Pro

問題定義

大規模言語モデル（LLM）は、脆弱性の発見や概念実証（PoC）の生成を含む、自動化されたソフトウェアセキュリティタスクへの展開が増加しています。しかし、既存のベンチマークは、現実世界のバグハンティングシナリオにおける LLM の評価を忠実に実施できていません。現在の評価手法は、以下の 3 つの主要なギャップに悩まされています：

1. ファズ・ハーネス依存性：多くのベンチマーク（例：ARVO、CyberGym）はファズハーネスに依存しており、これにより実行可能なエントリポイントが特定の内部インターフェースに限定されます。これは、パブリックインターフェースを通じたコード監査能力ではなく、ハーネスに誘導された入力変異を測定するものです。
2. ターゲット固有またはパターンベースの格付け：既存の指標は、生成された証拠を既知のパッチ、終了コード、またはクラッシュ署名と比較することが多いです。これにより、意図したバグの再現と、同じ履歴リビジョン内の無関係なクラッシュとの混同が生じたり、異なるトレースを生成する有効な PoC が却下されたりします。
3. 過剰な情報開示：現在のベンチマークのタスク入力には、サンライザーレポート、関数名、行番号、またはトリガー経路が含まれることがよくあります。これにより、コードを監査するセキュリティエンジニアが直面する不確実性が排除され、エージェントが現実のシナリオでは持ち得ない情報が提供されてしまいます。

したがって、ファズインフラストラクチャや過剰に露出したメタデータへの依存なしに、実行階層全体にわたる推論を必要とする、現実的な条件下での重要かつ高複雑性のソフトウェアシステムにおけるエージェントによるバグハンティングを測定するベンチマークが必要です。

手法

著者らは、JavaScript エンジン（具体的には V8 と SpiderMonkey）におけるエージェントによるバグハンティングを測定するために設計されたベンチマークおよび構築パイプライン「SEC-bench Pro」を提示します。このシステムは、開示されたセキュリティレポートを再現可能で検証済みのタスクに変換するための、3 フェーズの自己進化型パイプラインを採用しています。

1. レポート収集

パイプラインは、プロジェクト固有のトラッカー（Chromium Issue Tracker、Mozilla Bugzilla）およびキュレートされたアドバイザリーフィード（MFSA、Pwn2Own、CISA KEV）から構造化されたセキュリティレポートを取り込みます。具体的な PoC アーティファクトとリンクされた修正コミットの両方を含む、sec-high または sec-critical（または報奨金対象）とラベル付けされたレポートをフィルタリングします。

2. エージェント駆動型環境再構築

歴史的な脆弱環境の再構築に伴う労働集約性に対処するため、パイプラインはこのタスクを自律型コーディングエージェントに委譲します。

• 入力：エージェントは、生のバグレポート、PoC アーティファクト、およびターゲットバイナリ、許可されたフラグ、期待されるエラータイプを指定する構造化されたプロンプトを受け取ります。
• 処理：エージェントはプロジェクトのビルドシステムを駆動し、特定の報告されたリビジョンにおいて、適切なサニタイザー（例：ASan）またはデバッグチェックで構成された計測済みバイナリを生成します。
• 出力：エージェントは、脆弱および修正済みの Dockerfile、構造化されたメタデータ、標準的な PoC、および捕捉されたクラッシュ署名を含む Docker アーティファクトバンドルを生成します。プロンプトは、捏造された出力を明示的に禁止します。

3. 自動化された検証オラクル

インスタンスがデータセットに投入される前に、2 つの自動化されたオラクルを通過する必要があります。

• 脆弱イメージオラクル：再構築されたコンテナ内で PoC を複数回実行します。プロジェクト固有の分類体系（例：ASAN_CRASH、SANDBOX_VIOLATION、DCHECK）に基づいてクラッシュを分類します。実行が期待されるエラータイプに一致するクラッシュを生成した場合にのみ、インスタンスは通過します。
• 修正済みイメージオラクル：リンクされたパッチを適用し、バイナリを再構築し、同じ PoC を実行します。パッチが収集された PoC を抑制するか検証します（結果を BLOCKED_DEFENSIVE、BLOCKED_HARMLESS、または BLOCKED_NO_REPRO として分類）。修正後に PoC が再現しなくなった場合にのみ、インスタンスは通過します。

評価と格付け

評価には、3 イメージ格付けパイプライン（脆弱、修正済み、最新アップストリームイメージ）と、成功を判断するLLM-as-a-Judgeを使用します。

• 実行：候補 PoC を 3 つのすべてのイメージで再生します。
• 判定：LLM ジャッジは終了コード、stdout、stderr を分析し、結果を以下の 3 つのカテゴリに分類します。
  • Verified（検証済み）：脆弱イメージがターゲットに一致するクラッシュを示し、修正済み/最新の証拠がこの帰属と矛盾しない場合。
  • Unsure（不確実）：証拠が不完全な場合（例：修正済み/最新の実行におけるインフラストラクチャの失敗）、手動での裁定が必要です。
  • Illegal（不正）：クラッシュがターゲットと一致しない場合、または修正済み/最新のイメージが異なる根本原因によりクラッシュが持続している場合。
• 成功指標：少なくとも 1 つの候補 PoC が verified の結果を得た場合、そのインスタンスは成功とみなされます。このアプローチは、エージェントが無関係なクラッシュをトリガーすることによる「クラッシュのみ」の過大評価を防ぎます。

主要な貢献

• SEC-bench Pro データセット：V8（103 インスタンス）および SpiderMonkey（80 インスタンス）全体にわたる183 の検証済み脆弱性のコレクション。V8 サブセットには、累積 Google 脆弱性報酬プログラム賞金が150 万ドルを超えるレポートが含まれています。
• 自己進化型パイプライン：ベンチマークの再設計なしに新しい PoC ベースおよびパッチベースのレポートを取り込むことができるパラメータ化された構築パイプライン。ソースレベルのビルドレシピと公開レポートを持つ任意のプロジェクトに適用可能です。
• 3 イメージ格付けオラクル：意図したバグの再現と、無関係なクラッシュまたはインフラストラクチャの失敗を区別する堅牢な評価手法。クラッシュのみまたはパッチマッチングに基づく格付けの限界に対処します。
• 包括的なエージェント評価：長期的なセキュリティタスクにおける 3 つの最先端コーディングエージェント基盤（CODEX、CLAUDECODE、OPENCODE）の評価。

結果

最先端モデルおよびオープンウェイトベースラインの評価は、長期的なバグハンティングにおける現在の能力に重大な限界があることを明らかにしました。

• 低い成功率：最も強力な構成であっても、両方のエンジンで 40% 未満の成功率にとどまります。
  • V8：最も強力な単一構成（GPT-5.4 を搭載した CODEX）は32.0%（33/103）を達成しました。オープンウェイトの Kimi-K2.6 ベースラインは**11.7%**です。
  • SpiderMonkey：最も強力な構成（Opus 4.6 を搭載した CLAUDECODE）は38.8%（31/80）を達成しました。
• 相補的なカバレッジ：エージェントは主に重なり合わないインスタンスのセットを解決します。CLAUDECODE と CODEX の和集合は、V8 で37.9%、SpiderMonkey で**48.8%**に達し、単一のエージェント戦略がすべての脆弱性クラスを支配していないことを示唆しています。
• 戦略の違い：
  • CLAUDECODEは、1 つの PoC あたりの収率が低い多くの推測的 PoC を生成する高幅広戦略を採用しています。PoC がクラッシュをトリガーしない（クリーンな終了コード）か、無関係なクラッシュをトリガーする場合、失敗することが多いです。
  • CODEXは、信頼性の高いが数が少ない PoC を生成する高選択性戦略を採用しています。ローカルで到達可能性を検証できない場合に提出を控えるか、パッチによって完全に緩和されないクラッシュをトリガーする場合、失敗することが多いです。
• 失敗のコスト：失敗した実行は、成功した実行よりも一貫して大幅に多くのトークンとランタイムを消費します（例：V8 における CLAUDECODE のトークンギャップは 3.0 倍）。これは、長期にわたる探索が深い分析ではなく、収穫逓減につながることが多いことを示しています。
• 帰属の重要性：「クラッシュのみ」の格付け者は、構成全体で成功率を約**43.6%**過大評価することになり、誤って帰属されたクラッシュをフィルタリングするための 3 イメージ LLM ジャッジの必要性を浮き彫りにします。

意義

本論文は、自動化されたソフトウェアセキュリティにおける進歩を測定するための具体的で再現可能なターゲットとして SEC-bench Pro を確立します。LLM は脆弱性の発見を支援できる一方で、現在の最先端モデルは、プロダクショングレードのエンジンにおける長期的なバグハンティングの複雑さには苦戦していることを示しています。このベンチマークは、複雑なトリガー条件（例：特定の JIT 状態、サンドボックス回避）の合成の難しさや、失敗した探索の高コストなど、特定の限界を露呈させています。著者らは、将来のシステムには、現在の能力と現実世界のセキュリティ監査の要件とのギャップを埋めるために、より強力なトリガー合成、より堅牢な帰属メカニズム、およびアンサンブル検索戦略が必要であると結論付けています。