技術的概要：PoC-GYM：より信頼性の高い LLM 支援型 Proof-of-Concept 脆弱性エクスプロイト生成に向けた取り組み

問題定義

Proof-of-Concept（PoC）エクスプロイトの生成は、脆弱性の検証、パッチ開発の支援、回帰テストとしての機能において極めて重要である。しかし、公開された脆弱性の相当な割合には、利用可能な PoC が存在しない。大規模言語モデル（LLM）は、脆弱性検出とエクスプロイト生成の自動化にますます適用されているが、既存のアプローチはしばしば信頼性の問題に悩まされている。

現在の LLM 支援型手法は、通常、脆弱性の記述に基づいて PoC を生成し、印刷されたマーカー、生成されたファイル、またはランタイムの副作用などの浅いシグナルを用いて検証する。著者が特定した核心的な問題は、これらのシグナルが、実際には根本的な脆弱性を引き起こさない「偽陽性」のコードパスによって満たされ得る点である。その結果、PoC は自動化されたランタイムチェックの下では成功したように見えるが、実際の脆弱なコード位置（グランドトゥルース）には到達できていない可能性がある。表面的な成功と真のエクスプロイトを区別する、より信頼性の高い生成パイプラインが必要とされている。

手法：PoC-Gym フレームワーク

著者は、静的アプリケーションセキュリティテスト（SAST）のデータフロー追跡と LLM の推論を組み合わせることで、Java PoC エクスプロイトを生成するように設計されたハイブリッドパイプライン「PoC-Gym」を提案する。このフレームワークは、3 つの反復ステージを通じて動作する。

1. プロンプト構築:

   • 脆弱性固有のコンテキスト: システムは LLM を用いて「CVE 固有のガイダンス」を生成し、CVE と Common Weakness Enumeration（CWE）の記述に基づいて、具体的なエクスプロイト目標とプログラム的な検証チェックを定義する。
   • 追跡コンテキスト: 具体的なプログラムパスを提供するために、PoC-Gym は CodeQL と IRIS フレームワークを用いて抽出された静的なソース・ツー・シンクのデータフロー追跡を統合する。これらの追跡は、LLM トリアージ・アシスタントによってランク付けされ、最も関連性の高いパスが選択された後、フォーマットされてプロンプトに挿入される。
   • リポジトリ制約: プロンプトには、脆弱なリポジトリに関するメタデータ（URL、コミット、ビルドスクリプト）と、生成されたコードが実行可能であることを保証するための API 使用に関する厳格な制約（例：リフレクションの回避、依存関係の制限）が含まれる。

2. PoC 生成:

   • LLM エージェント（例：Claude Sonnet 4、GPT-5）は構造化されたプロンプトを受け取り、単一の Java ソースファイル（PoCTest.java）を生成する。
   • エージェントは、脆弱性をトリガーし、特定の成功マーカー（[VULN]）を出力する main メソッドを持つ公開クラスを作成することに制約される。

3. PoC 検証:

   • ランタイム検証: 候補となる PoC は、AspectJ インストルメンテーションを用いて脆弱なプロジェクト上でコンパイルされ、実行される。候補が「ランタイム有効」と見なされるのは、以下の条件を満たす場合に限られる。
     1. 正常に終了する（終了コード 0）。
     2. [VULN] マーカーを出力する。
     3. 静的追跡で定義された特定のシンク位置に到達する（シンク到達性）。
   • 反復的フィードバック: 検証に失敗した場合、出力と追跡カバレッジを含む失敗サマリーが、次の反復のためのプロンプトに付加される。
   • 事後検証: 重要なのは、著者が CWE-Bench-Java ベンチマークによって提供された「グランドトゥルース」の脆弱な位置に対する別個の検証ステップを導入している点である。このステップは、実行がパッチで特定された特定のファイルと行の範囲に実際に到達したかどうかを検証し、真のエクスプロイトとシミュレーションを区別する。

主要な貢献

• ハイブリッドパイプライン: エクスプロイト生成を導くために、静的分析由来のデータフロー追跡と LLM 生成、および動的シンク到達性チェックを統合する。
• 二重検証メカニズム: 「ランタイム有効」（生成ループの基準を満たす）と「事後有効」（グランドトゥルースの脆弱な位置に到達する）の区別を行い、既存手法における成功の過大評価を浮き彫りにする。
• 包括的な失敗分析: ランタイム検証を通過したが事後チェックに失敗した PoC について、詳細な手動分析を行い、「無関係なエラー」（誤った追跡/記述）、「ハードコーディング」、「シミュレーション」（脆弱性ロジックを呼び出す代わりに再実装する）、「不適切な検証」（信頼性の低い成功シグナル）などの失敗モードを分類する。

実験結果

著者は、CWE-Bench-Java から 20 の実世界の Java CVE を用い、3 つの異なる LLM 構成で PoC-Gym を評価した。

• ランタイム対事後有効性: 338 回の実行全体を通じて、PoC-Gym は 116 のランタイム有効な候補（34.3%）を生成した。しかし、グランドトゥルースの位置に対する事後検証の後、有効と確認されたのは 65 候補（19.2%）のみであった。これは、ランタイムチェック下で成功したように見える候補の 44% が、実際の脆弱性シンクに到達しなかった偽陽性であったことを示している。
• 追跡ガイダンスの影響: 追跡情報なしの実験では、初期ランタイム成功率は高かった（86.7%）が、事後有効性は著しく低かった（36.7%）。これに対し、マルチ追跡設定では初期成功率は低かった（23.0%）が、事後有効性の低下は小さかった（15.5%）。これは、追跡ガイダンスが実際の脆弱なパスに対応しない無効なソリューションをフィルタリングするのに役立つことを示唆している。
• FaultLine との比較: FaultLine システムと重複する 14 の CVE において、最強の PoC-Gym 構成（追跡付きの Claude Sonnet 4）は、8/14 の事後有効結果を達成し、FaultLine の元の評価基準における 5/14 と比較して上回った。

意義と主張

この論文は、LLM がエクスプロイト戦略の生成において有望であることを示しつつも、決定論的なテスト生成技術の完全な代替とはなり得ないと主張している。著者は以下のように論じている。

1. 信頼性にはグランドトゥルース検証が必要である: ランタイムシグナルのみではエクスプロイトの正確性を過大評価する傾向が強く、真の有効性を評価するには既知の脆弱な位置に対する事後検証が必要である。
2. 追跡コンテキストは偽陽性を減少させる: 静的追跡はすべての失敗を排除するわけではないが、浅い成功シグナルを満たす無効なソリューションの割合を大幅に減少させる。
3. 失敗パターンは体系的である: 多くの失敗は、LLM が脆弱性をトリガーするのではなくシミュレーションする、または無関係な追跡を使用するなど、特定の反復的なパターンから生じる。これらのパターンを理解することは、将来のシステム設計を改善するために不可欠である。

著者は、LLM 支援型 PoC 生成における将来の進展は、生成品質の向上だけでなく、より強力な検証メカニズムの開発と、失敗分析を用いて LLM の創造性と仕様駆動型チェックの組み合わせを導くことにかかっていると結論づけている。