テクニカル・サマリー: SRE-Bench

問題提起

AIエージェントは、ソースコードを伴うサイバーセキュリティのタスクにおいて急速に進化しているが、バイナリのみとして配布されたソフトウェアを分析する能力には、決定的なギャップが残っている。これは、高価値の防御対象（独自のエンタープライズ・ソフトウェア、ファームウェア）や、攻撃的な脅威（難読化されたマルウェア）において現実となっている。これらのバイナリを分析するには、リバースエンジニアリング（RE）、すなわち、不透明なバイト表現から高レベルのプログラム意味論を復元する技術が必要となる。

現在のエージェント型REベンチマークには、現実世界の能力を正確に測定することを妨げる、2つの根本的な欠陥がある。

1. データの汚染（Data Contamination）: 多くのベンチマークは、公開されているソースコードやCTFチャレンジに依存している。モデルが事前学習データの中でそのターゲットを認識していた場合、プログラムの目的を識別することで実際の分析を回避できてしまい、パフォーマンス指標が不当に高くなる。REにおいては、ターゲットの意図に関する粗い知識であっても、復元プロセスをショートカットさせるトップダウンのガイダンスを提供してしまうため、有害となる。
2. 現実的な規模と保護の欠如: 既存のベンチマークは、多くの場合「トイ（玩具）」プログラムやCTFスタイルのチャレンジを使用しており、現実世界のソフトウェア（数千行のコード）や、野生環境で見られる高度な解析妨害技術（難読化、パッキング、アンチデバッグ）のような複雑さを欠いている。

その結果、強力なソースコード・セキュリティ能力がバイナリ解析に転移するかどうかを判断するための、厳格なテストベッドが存在しない。

メソドロジー: SRE-Benchの構築

これらのギャップに対処するため、著者らは、初の現実的かつ汚染のないREベンチマークであるSRE-Benchを導入する。構築手法は、利便性よりも「クリーンルーム」開発と現実的な複雑さを優先している。

1. クリーンルーム開発

• ゼロ汚染: 19個の全ターゲットプログラム、評価インフラ、およびプロテクション・スイートは、平均6年の経験を持つREエキスパートによってゼロから開発された。公開プロジェクトから派生したコードは一切存在しない。
• プライベートな仕様: 各プログラムは、決して公開されないプライベートな設計仕様に基づいて実装されている。
• 敵対的監査: 著者らは、エージェントを進行中のインスタンスと対決させ、真のREなしにクレジットを得ることを可能にするショートカット（例：隠された挙動を明らかにする読み取り可能な文字列など）を特定し、修正するための反復的な「報酬ハッキング（reward-hacking）」監査を採用した。

2. 現実世界の規模とドメイン

• 規模: 本ベンチマークは、平均16,915.8行（LoC）、合計32万行を超えるコードを持つ19個のプログラムで構成されている。これは、従来のREベンチマークよりも30〜470倍大きい。
• ドメイン: プログラムは、業界の議論から特定された5つの代表的なREドメインにわたっている：
  • ネットワークプロトコル: 状態マシンの再構築を必要とする、独自の暗号化クライアント・サーバースタック。
  • ゲーム: 特定のロジックによってトリガーされる隠された「イースターエッグ」の挙動を持つ、20階層のターミナル・ローグライク。
  • ファイルフォーマット: アーカイブをデコードするために、エージェントに多段階のパイプラインのリバースエンジニアリングを要求する、カスタムファイル圧縮・エンコーダ。
  • マルウェア: 6つのマルウェアファミリー（例：ランサムウェア、C2）をシミュレートした合成の安全なLinuxインプラント。タスクは防御的なクリーンアップである。
  • ファームウェア: JTAGスタイルのエミュレータによる制御を必要とする、架空のマイクロコントローラのベアメタル・ファームウェア。

3. 解析妨害プロテクション・スイート

現実世界の防御を模倣するため、著者らは9つのファミリーにわたる44の異なるプリミティブを備えたカスタム・プロテクション・スイート（27K LoC）を構築した。特筆すべきは、これらのプリミティブの半分以上が公開実装を持たないことである。主な機能は以下の通り：

• ページごとの認証暗号化: ページは実行コンテキストから派生したキーで暗号化されており、メモリダンプを防止する。
• オンデマンド復号: コードは実行時にのみページ単位で復号され、プレーンテキストの滞留を最小限に抑える。
• 計測キーによるアンチデバッグ: デバッグ信号（例：ptrace、ブレークポイント）が検出されると、復号キーが破損する。
• ローダーの仮想化: 重要なローディング・ロジックは、難読化されたオペコードを持つカスタムVM内で実行される。
• アンチ・リホスティング: 攻撃者が復号ルーチンを抽出して別のプロセスで実行することを防ぐ。

4. 評価パイプライン

• インスタンス: 19個のプログラムは、最適化、シンボル削除、リンキング、およびプロテクション・プリセットの違いによる262個のバイナリ・インスタンスにコンパイルされた。
• タスク: 各インスタンスは、6つの決定論的に採点されるタスク（例：プロトコルのハンドシェイクの復元、隠されたゲーム挙動のトリガー）を定義しており、合計1,572個のタスクが存在する。
• モデル: 5つの最先端LLM（GPT-5.6-sol, Claude-Opus-5, GPT-5.5, Grok-4.5, GLM-5.2）が、bashのみのツールセットと標準的なREツール（Ghidra, radare2など）を用いた標準化されたハーネスを使用して評価された。総評価コストは31.4Kドルであった。

主な結果

評価により、最も高度なモデルであっても、エージェントによるREは依然としてほとんど未解決であることが明らかになった。

• パフォーマンスの天井: 最も強力なモデルであるGPT-5.6-solは、平均スコア3.69/6（最大可能スコアの61.4%）を達成し、完全に解決できたのはわずか**31.5%のインスタンスであった。最も弱いモデル（GLM-5.2）は、インスタンスを完全に解決できたものは0%**であった。
• 保護の影響: 自社製のプロテクション・スイートが主要なボトルネックとなった。これはGPT-5.6-solのパフォーマンスを半分（4.69から2.50へ）に低下させ、他のすべてのモデルをゼロに近いパフォーマンスへと追い込んだ。
• 人間によるアナリストとの乖離:
  • 最適化とリンキング: コンパイラの最適化や静的リンキングに苦戦する人間のアナリストとは異なり、現在のエージェントはこれらの要因に対して比較的鈍感である。
  • シンボル削除: エージェントはレキシカルなアンカー（関数名や変数名）に大きく依存している。シンボルの削除は大幅なパフォーマンス低下（例：GPT-5.6-solは0.48ポイント低下）を引き起こしており、これはエージェントが命令レベルの推論よりも命名を優先していることを示唆している。
• 汚染 vs 規模: アブレーション研究により、両方の要因が不可欠であることが確認された。
  • クリーンルームで作られたトイ・プログラムは、すべてのモデルによって容易に解決された。
  • 公開されたプログラム（修正を加えたものであっても）は、すべてのモデルによって容易に解決された。
  • プライベートな由来（provenance）と現実世界の規模の組み合わせのみが、モデルを分断する難易度のギャップを生み出した。

意義と主張

本論文は、SRE-Benchが以下のことを証明することで、エージェント型サイバーセキュリティの評価における新しい基準を確立したと主張している：

1. ソースコードの能力はバイナリ解析には転移しない: 強力なソースコード・ベンチマークでの高いパフォーマンスは、バイナリのリバースエンジニアリングにおける能力を保証しない。
2. 汚染管理は譲れない条件である: ベンチマークは、モデルがターゲットを認識することを厳格に防がなければならない。さもなければ、指標は分析ではなく、メモリからの想起を反映したものになってしまう。
3. 規模が重要である: 現実世界の複雑さ（数千行のコード）は、意味のある評価のための前提条件である。トイ・プログラムは、実際のターゲットに対するパフォーマンスを予測できない。
4. 現在のエージェントは脆弱である: エージェントは構造的な分析は扱えるものの、現実的な解析妨害技術に直面すると著しく失敗し、高度に難読化されたバイナリに必要な堅牢な命令レベルの推論が不足している。

SRE-Benchは、この重要なフロンティアにおける進歩を測定するための、厳格で汚染のないテストベッドとして機能し、ソースコードの理解とバイナリ解析の間のギャップが、この分野における重大な課題として残っていることを浮き彫りにしている。