PatchHolmes、リスト全体を比較するエージェントで脆弱性修正コミットを特定

導入

脆弱性情報を実際の修正コミットと結び付けられれば、パッチの確認、影響バージョンの追跡、深刻度の分析、ソフトウェアサプライチェーンの検査が容易になる。しかし、GitHub Advisory DatabaseとNational Vulnerability Databaseでは、約60～63％のCVEに修正パッチへのリンクがない。PatchHolmesは、既知の脆弱性を修正したコミットを見つける「パッチ検索」に取り組むシステムだ。

検索が難しい理由

第一に、候補の数が多い。リポジトリには最大で約140万件のコミットが存在し、脆弱性の約49％は5000件を超えるコミットを持つリポジトリに関係している。第二に、コミット差分が長い。対象コーパスの平均差分は約1万5000トークンで、短い入力を前提とするエンコーダーでは重要な変更を読み落とす可能性がある。第三に、脆弱性報告とコミットメッセージの語彙が一致しない。報告書が「バッファオーバーフロー」と表現していても、修正コミットでは「範囲外読み出し」と記述されることがある。

PatchHolmesの構成

PatchHolmesは2段階で処理する。

• 候補検索： ハイブリッド検索器がローカルのGitリポジトリから候補を集め、上位100件を作る。
• エージェントによる選択： 第2段階のエージェントは候補を1件ずつ別々に評価するのではなく、100件のリスト全体を確認する。そのうえで、4種類の予算管理されたツールを使い、3～10件程度のコミットを選択的に開いて、最終的に1件だけを回答する。

この違いは、同じコード経路を変更するコミットが複数ある場合に重要になる。点ごとの分類では、複数候補に同じような「該当する」という判定を与え、最終的にリストの先頭を選んでしまうことがある。候補全体を見せれば、変更の目的、コード差分、周辺情報を相互に比較できる。

実験結果

GitHubADでは、PatchHolmesのRecall@1は59.95％だった。点ごとの分類器Faviaは34.61％、検索後に推論するIRCoTは28.55％である。候補集合を同一に固定した比較でも、検索器の先頭候補をそのまま採用する場合より、エージェントの導入で27.32ポイント向上した。別ベンチマークのPatchFinder_top10候補集合へ変更なしで移した場合も、PatchFinder本来のトップ1結果24.28％を39.86％まで引き上げた。

Qwen系モデルを入れ替えてもRecall@1の変化は1ポイント未満で、別系統のgpt-ossでもエージェントなしの基準を大きく上回った。したがって、改善の主因は特定のモデルではなく、リスト全体を見て比較するループにあると考えられる。システムは脆弱性1件あたり約9万6000入力トークン、8回のツール呼び出し、約5件のコミット確認を使う。微調整や外部検索APIは利用せず、固定したオープンウェイトモデルとローカルGitクローンで動作する。

意義と課題

PatchHolmesは、大量の候補を単に並べる検索から、限られた調査予算で候補を比較するエージェント型ワークフローへの転換を示している。パッチリンクが欠落した脆弱性情報の補完や、手作業によるトリアージの削減に役立つ可能性がある。

一方、トップ1精度はまだ完全ではない。候補検索の質、長い差分の理解、脆弱性報告と実際のコード変更の語彙差は、今後も検証すべき課題だ。多様なリポジトリ、言語、実運用のセキュリティ業務での評価が求められる。

出典：Hugging Face Daily Papers