要旨 近年の大規模言語モデル（LLM）を使った自動プログラム修復は、脆弱性を検出してパッチを生成する研究・実用の両面で注目を集めています。しかし「パッチが与えられた証拠（静的アラートや再現入力）をブロックすること」と「同種の脆弱性に関する全ての攻撃経路を塞ぐこと」は異なり得ます。本稿で紹介する研究（arXiv:2610.20245v1）は、そのギャップを埋める試みとして「P2Patch」という攻撃駆動（exploit-guided）な修復プロトコルを提案・評価しています。著者らは、パッチ適用後を新たな攻撃対象とみなし、攻撃側エージェントが繰り返し別の再現可能な攻撃（PoV：proof of vulnerability）を生成できるかを確認するループを導入しました。成功した攻撃は以後の修復要求に恒久的に追加され、最終パッチはその蓄積された全てのPoVをブロックしなければ受け入れられません。

背景と動機（オラクル再利用の問題） 従来の自動修復は、しばしば同じ証拠を「パッチ生成の根拠」と「パッチ検証のオラクル」として二度使います。たとえばクラッシュ入力や静的解析の指摘を用いてパッチを作り、同じ入力でパッチがクラッシュを防いだことをもって成功とみなす――この手法では、その一例に特化した「部分的なパッチ」で見かけ上成功してしまう危険があります。著者らはこれを「オラクル再利用」による過剰適合（overfitting）問題として指摘します。

代表的な事例（zip-slipのすり抜け） 本文では具体例として、Javaのライブラリでのアーカイブ展開に関する“zip-slip”脆弱性を挙げています。初期の修正は展開先パスのプレフィックス比較（String.startsWith）に基づいていましたが、末尾の区切り文字（File.separator）を加えていなかったため、同名の“兄弟ディレクトリ”に対するパスが比較をすり抜けるケースが残っていました。最終的に（9年後の）修正で正規化と区切り文字の検査が加えられて解消されますが、この例は「与えられた再現入力を遮断しただけでは境界の不備を見落とす」ことを示します。

P2Patchの設計（概念と運用） P2Patchは次のような反復プロトコルを採ります。まず攻撃者役のエージェントが正規化された脆弱性所見から再現可能なPoV（ハーネス＋入力）を作る（ブートストラップ）。それが実行で再現されると、修復者役がそのPoVをブロックするようパッチを提案します。提案されたパッチが当該PoVを遮断すると、攻撃者役はパッチ済みプログラムに対して別種の同種脆弱性の再現PoVを探します。新たに実行で再現されたPoVは恒久的な修復要件に追加され、以後のパッチはそれらすべてをブロックしなければなりません。オーケストレータ（実行審判）は各PoVの実行結果を「再現（reproduced）」「遮断（blocked）」「不確定（inconclusive）」の三値で判断し、不確定な実行は安全側に働くように評価しません。

独立検証オラクル（held-out suites） 重要な点として、P2Patchは「構築時に用いたPoV」と「最終パッチの評価に使うPoV」を厳密に分離します。評価用に著者らが手作業で用意した二種類の保持外オラクルを用います： - fix-closed：脆弱な版では再現し、公式修正で遮断されるPoV（公式修正が閉じた攻撃経路）。 - residual：脆弱な版でも公式修正後でも再現するPoV（公式修正で残る挙動）。 これらを最終パッチに対して実行し、遮断できたPoVの割合を評価指標とします（不確定な実行結果は分母から除外）。この分離により「手元で使った証拠で自己検証してしまう」問題を避けています。

評価概要と主な結果 著者らはVULNREPAIRBENCHというベンチマーク（101件：60件のJava、41件のC/C++、合計61リポジトリ）を整備し、P2Patchの評価を行いました。主な結果は次の通りです（慎重に読み取るべき数値的結論）： - パッチが自身の構築時PoVを阻止した後でも、別の再現可能な同種脆弱性PoVによって突破されることがある割合は41%（101件中41件の実行で、最初にブロックしたPoVをパッチが防いだあとの攻撃で別のPoVが確認された）。 - 同じ出発情報からの「ワンパス修復（single-pass）」と比べると、P2Patchは保持外のfix-closedマクロ平均カバレッジを78.1%→84.7%に、residual（公式修正で残るパス）を42.1%→62.5%に引き上げたと報告しています。統計的検定においても有意性を示したとしています。 - ただし、P2Patchは反復探索と検証が追加で必要なため、計算・API利用のコストは上がります（検証実験で平均コスト増を報告）。