《Journal of Cybersecurity and Privacy》：Fixing, Breaking, or Faking It? An Execution-Calibrated Evaluation of LLM Vulnerability Patching in JavaScript, Python, Go, and Java, and the Limits of LLM-as-Judge
编辑推荐：
大型语言模型（LLM）日益承担软件漏洞修复任务，但多数评估仅评判其输出与开发者修复的相似度或弱点是否被消除，二者均无法揭示原本可用的代码是否被破坏。研究在922个JavaScript漏洞补丁上评估了八款商业及开源LLM，从漏洞中和与功能保留两个维度进行评分。由
大型语言模型（LLM）日益承担软件漏洞修复任务，但多数评估仅评判其输出与开发者修复的相似度或弱点是否被消除，二者均无法揭示原本可用的代码是否被破坏。研究在922个JavaScript漏洞补丁上评估了八款商业及开源LLM，从漏洞中和与功能保留两个维度进行评分。由于缺乏测试，研究以基于参考的LLM评判器进行规模化评分，并在包含144个补丁的基准测试集及254个Java CVE补丁上，辅以跨族系评判器，以执行结果进行校准。最佳模型修复了23%的漏洞（基于评判器），而成本效率则颠覆了准确率排名。核心发现聚焦于评判工具本身：两类评判器所标记的过度修复案例均远超执行确认的结果（精确率5–10%），然而在功能维度上，评判器之间的相互一致性（??=0.75）远高于其与执行结果的一致性（??≤0.26），故评判器间的一致性衡量的是可靠性，而非有效性。在真实Java代码上，过度报告现象持续存在，同时评判器的正确性估计出现分歧，使得任何单一评判器均不可信赖。过度修复确实存在，但在执行验证下并不常见：仅占移除漏洞补丁的几个百分点，或排除一个易受伪影影响的情景后低于2%，两者均为下限。唯有经过充分测试的执行验证才能衡量功能保留率，因此安全补丁评估必须运行代码，评判器仅可用于模型排名，并需权衡成本。研究公开了评估工具集与可执行的基准测试集。
论文解读
**研究背景与问题**
软件漏洞的披露速度远快于其修复速度。能够阅读代码并提出修改建议的大型语言模型（Large Language Models, LLMs）被视为弥合这一差距的重要工具。然而，现有研究对LLM修复能力的评估存在根本性缺陷：多数评估仅衡量模型生成的补丁与开发者提交的参考修复在文本上的相似度，或仅检查弱点类别（Common Weakness Enumeration, CWE）是否被移除，而未能验证补丁是否破坏了软件原有功能。这种“修复率”指标掩盖了两个关键问题：补丁是否真正消除了漏洞，以及补丁是否保留了程序的预期行为。一个补丁可能在关闭脆弱路径的同时破坏合法功能，形成安全领域的“过度修复”（over-fixing），这类似于自动程序修复（Automated Program Repair, APR）中的经典过拟合问题。更隐蔽的风险在于，由于多数真实漏洞语料库不附带测试用例，研究者日益依赖第二个LLM作为评判器来评估补丁正确性。若该评判器在区分修复与过度修复的关键维度上本身就不可靠，那么研究报告中的“过度修复率”或“修复率”数字可能仅是测量工具造成的伪影，而非补丁的真实属性。因此，本研究将测量工具本身作为研究对象，旨在通过执行验证来校准和评估LLM评判器的可靠性，并准确量化LLM漏洞修复的真实成功率与过度修复的发生率。
**研究开展内容与结论**
研究人员开展了一项系统性的实证研究，评估了八款商业和开源LLM在922个真实JavaScript漏洞函数上的修复能力，并构建了可执行的基准测试集，将LLM评判器的判断与代码执行结果进行比对校准。研究还进一步将评估扩展到254个真实Java CVE补丁，使用完整的Maven构建与测试套件作为执行标准。研究发现：即使是最佳模型，其正确修复率也仅为23%左右；商业模型的表现约为开源模型的两倍，但成本效率分析显示，高精度模型的单次正确修复成本远高于性价比更高的模型。核心发现是，LLM评判器无法可靠衡量功能保留性：评判器报告的过度修复率是执行结果确认的2.5至3.75倍，精确率仅为5%至10%。更关键的是，两个来自不同家族的评判器之间的相互一致性（κ=0.75）远高于其各自与执行结果的一致性（κ≤0.26），这表明评判器间的共识只能证明可靠性，而非有效性。在真实Java代码上，评判器的过度报告现象持续存在，但其正确性估计出现方向性分歧，一个过度信任而另一个过度怀疑。研究最终证实，过度修复在适当测试下是真实存在但不常见的失败模式，仅占移除漏洞补丁的个位数百分比。该研究发表于《Journal of Cybersecurity and Privacy》。
**关键技术方法**
研究人员为校准LLM评判器并验证其可靠性，构建了一个包含18个可运行漏洞（10个JavaScript、8个Python）、覆盖11种弱点类别（CWE）的执行基准测试集。每个案例包含一个安全性测试和一个功能性测试，以代码实际运行结果作为评估金标准。研究采用基于参考的LLM评判器（Claude Haiku 4.5）进行大规模评分，并用跨族系的GPT-5.2评判器作为第二意见。此外，研究在包含33个真实Java CVE的Vul4J语料库上复现了实验，使用完整项目的Maven回归测试套件进行执行验证。所有补丁均来自提示词固定的单轮生成，温度为0或接近0。
**研究结果**
* **RQ1: 正确性偏低，排名存在重叠**：基于LLM评判器，最佳模型Claude Opus的正确修复率为23.5%，最差的Qwen仅为4.3%。商业模型整体正确率（18.5%）高于开源模型（9.2%），差异具有统计学意义。但相邻模型的置信区间存在重叠，表明排名是指示性的而非严格区分。
* **RQ2: 过度修复不常见，但评判器会过度报告**：在144个可执行补丁上，执行验证发现过度修复仅占移除漏洞补丁的7.1%。然而，两个LLM评判器分别标记了20个和30个过度修复补丁，是执行确认数的2.5至3.75倍。评判器对过度修复标记的精确率仅为5%和10%。过度修复现象在基准测试中集中于单个CSRF场景，这被识别为评估伪影。
* **RQ3: 相似度与LLM评判器均无法衡量功能保留**：两个评判器在功能轴上的Cohen's κ系数仅为0.20和0.14，与执行结果一致性极低。相反，两个评判器之间在功能轴上的κ系数高达0.75，远超其各自与执行的一致性。文本相似度指标（如BLEU-4、精确匹配）与正确性基本无相关性。这表明评判器间的可靠性共识不能替代执行验证的有效性。
* **RQ4: 成本效率反转准确率排名**：每次调用的成本跨度约120倍。按正确修复补丁归一化后，DeepSeek-V3.2的成本效率最高，而最准确的模型Claude Opus每正确修复一个补丁的成本约为其52倍。这种成本效率反转在更换评判器后依然成立。
* **真实Java CVEs复现**：在254个真实Java补丁上，执行验证的正确修复率为9.4%，商业与开源模型的差距仍然存在。执行验证仅发现1个过度修复补丁，而两个评判器分别标记了28个和43个。评判器的错误模式在此发生了变化：多数过度标记落在根本无法编译的补丁上，显示出“中和盲目性”而非“幻影回归”。两个评判器的正确性估计方向性分歧，使其在困难代码上连可靠性都无法保证。
**讨论总结与研究结论翻译**
研究结论部分翻译：大型语言模型仅能正确修复少数孤立的JavaScript函数漏洞，且模型的选择在准确性与成本间构成权衡。这一低修复率在254个真实Java CVE补丁上依然存在，并保持相同的商业模型优于开源模型的差距。然而，论文的核心教训在于评估方法：LLM评判器无法可靠地衡量功能保留性。Claude与GPT两个跨族系评判器的过度修复报告量远超执行确认（28和43对比1个）。在Java上，多数此类标签落在无法编译的补丁上，表明评判器既未能识别无效补丁，也虚构了正常代码的回归。在困难代码上，其正确性估计方向性分歧，一个过度信任另一个过度怀疑，评判器间的共识破裂，而简单代码上的高度共识则会造成虚假的信心。过度修复本身，即通过破坏功能来消除漏洞，在执行裁决下被证明并不常见：在各基准中仅占移除漏洞补丁的个位数百分比，在仓库规模下仅为254个中的1个，且全程为下限估计。文本相似度与LLM评判器均无法可靠衡量其发生率。唯有具备充分功能测试的执行验证才能实现测量；评判器可用于模型排名，而非量化比率。因此，安全补丁评估应运行代码以测量比率，报告不确定性而非点估计，并权衡每个正确补丁的成本。研究人员发布了评估工具集、评判器提示词、可执行基准测试集及可恢复的真实Java（Vul4J）执行运行器，以使此类评估成为常规操作。
