脆弱性修正の評価にコンパイル成功率だけでは足りない
Metrics Failure in LLM-Based Code Vulnerability Repair: An Empirical Study and a Change-Aware Screen
この論文をやさしく読む
ひとことで言うと
プログラムがコンパイルできても脆弱性を直したとは限らず、指標を上げるために処理を削除するような出力も生じることを実験で調べています。
何に役立つ？
コード修正モデルの評価で、コンパイルや原文との類似度だけを成功条件にしないための材料になります。編集部分を見るdiff_F1は、実行検証の前の簡単な選別候補です。
この研究の面白いところ
無変更の脆弱なコードが全モデルより高いCodeBLEUを得る例や、同じパッチでも規格フラグだけで成功率が変わる例を示します。モデルの進歩と評価環境の影響を切り分けています。
どこまで分かった？
評価は203関数、三つのモデル、三つのプロンプト方式に基づきます。diff_F1も一部の不適切な削除を見逃し、著者自身が修正品質の指標ではないと明記しています。
v1のアブストラクトに基づくAI解説。日本語訳とは別に、用途の解釈を含みます。
アブストラクトの日本語訳
大規模言語モデル（LLM）はC/C++のセキュリティ脆弱性の自動修正に使われるようになり、生成したパッチがコンパイルできる割合が、進歩を測る代替指標としてよく報告される。本研究では、単一関数の脆弱性修正においてコンパイル成功率は科学的に信頼できない指標だと論じる。Big-Vulの脆弱な203関数、3億5000万から67億パラメータの三つのオープンソースコードLLM、三つのプロンプト方式を対象とした、五つの統制実験でこれを裏付ける。 コンパイル成功率には次の問題がある。第一に、生成コードを大幅に改善する介入にほとんど反応しない。第二に、モデル品質より評価基盤とデータセットに由来する要因に左右され、コンパイル失敗の約64％はモデルに帰責できず、この割合はモデル間でほぼ一定である。第三に、同じパッチでもコンパイラの言語規格フラグ一つで成功率が1.8～2.7倍変わり、後退例はゼロである。第四に、三つのモデルの順位が参照修正との類似度指標と逆になる。第五に、最適化目標として使うと修正になっていない出力を評価してしまう。コンパイラのフィードバックを繰り返すと成功率は上がるが、人間の修正との類似度は下がり、新たにコンパイルできるようになった出力を手作業で調べると、削除や仮置きによる非修正が見つかった。 自然な代替候補である関数全体のCodeBLEUも機能しない。脆弱な入力を変更せず複製したものが、すべてのモデルより高得点になる。本研究では、編集部分だけを採点する、変更を考慮した選別指標diff_F1も調べる。この指標は無変更には正確にゼロ点を与え、観察された削除による指標操作の一部には、すべてではないものの、ほぼゼロ点を与える一方、実質的な部分編集は評価する。このため、実行に基づく深い解析の前に行う低費用な選別に使える可能性がある。ただし、修正品質の指標ではなく、その不十分な点も報告する。結果は、LLMによる脆弱性修正には、変更を考慮し、実行に根差した評価が必要であることを示す。
v1の要旨から自動生成。本文の精読・人による確認は未実施。
- 初稿
- 2026-09-22（UTC）
- 最新改訂
- 2026-09-22 · v1
- 査読・掲載
- 査読状況未確認
更新履歴
- v1 2026-09-22 この版を読む
取得できた版を表示。版の更新は査読済みを意味しません。過去版の本文差分は未解析です。
原文の要旨
Large language models (LLMs) are increasingly applied to the automated repair of C/C++ security vulnerabilities, and compile rate is a commonly reported proxy for progress: whether the generated patch compiles. We argue that compile rate is a scientifically unreliable metric for single-function vulnerability repair, and we support this with five controlled experiments over 203 vulnerable functions from Big-Vul, three open-source code LLMs (350M to 6.7B parameters), and three prompting strategies. Compile rate (i) barely responds to an intervention that substantially improves the generated code; (ii) is dominated by evaluation-harness and dataset artifacts rather than model quality, with about 64% of compile failures not attributable to the model, a share that is nearly invariant across models; (iii) shifts by 1.8 to 2.7 times on identical patches under a single compiler-standard flag, with zero regressions; (iv) ranks the three models in the opposite order to reference-similarity metrics; and (v) rewards non-repairs when used as an optimization target, since a compiler-feedback loop raises compile rate while similarity to the human fix falls, with manual inspection finding deletion- and placeholder-style non-repairs among the newly compiling outputs. The natural fallback, whole-function CodeBLEU, also fails: an unchanged copy of the vulnerable input outscores every model. We also examine diff_F1, a change-aware screen that scores only the edited region. It gives exactly zero credit to a no-op and near-zero credit to some, though not all, of the deletion-based gaming patches we observed, while still crediting genuine partial edits, so it may serve as a cheap screen before deeper, execution-based analysis. It is not a repair-quality metric, and we report where it falls short. Our findings argue for change-aware, execution-grounded evaluation of LLM-based vulnerability repair.
著者のコメント
23 pages, 4 figures, 11 tables. Code and data: https://github.com/OmNepal/llm-vulnrepair-metrics
arXiv ID: 2609.26749 ／ 要約の誤りについて