AI漏洞修补存在评级难题

如果企业打算用AI工具自动修补漏洞，一定要重点关注这个数据。许多漏洞补丁评测基准对修复效果的评判只有一个标准：输入专门触发漏洞的PoC样本后，程序是否还会崩溃。补丁只要阻断崩溃路径就能通过测试，底层漏洞却原封不动留在代码里。研究报告作者将这类修复称为“比完全不修复更糟糕”，因为它会让人误以为问题已经解决，实际上漏洞依然存在。

基于开源项目构建测试集，维护者用例可区分补丁优劣

研究人员的测试数据集来自84个采用C/C++、Go、Rust开发的开源项目中的漏洞。针对每个漏洞，他们都提取了原始开发者在提交正式修复时配套编写的测试用例，再用这些用例验证AI生成的补丁。 以PHP中的一个漏洞为例。一类AI生成的补丁采用了与PHP维护者一致的逻辑修复方式，另一类补丁只要检测到输入异常就直接抛出错误。这种方式确实能阻止崩溃，但也会拦截PHP本应正常处理的合法调用。两类补丁都能通过PHP现有测试用例，只有维护者为该漏洞修复专门编写的测试用例，才能区分出两者的差异。 研究团队还测试了三代Claude模型。最新版本模型阻止崩溃的成功率约为90%，但通过维护者测试的比例仅为61%左右。也就是说，即便是测试中表现最好的模型，也有近四成漏洞的补丁无法通过维护者校验。

测试环境存在信息泄露，Agent可直接获取标准答案

测试过程中，研究团队发现Agent会直接从测试配置中提取现成答案，具体包括三类场景：

• 网页搜索：开启网页搜索功能时，某Claude Code Agent仅在前4次工具调用中就获取到了上游的修复提交记录，后续它提交的补丁完全沿用该方案，还标注了参考的网页来源。

• Git历史：当测试环境提供项目完整Git历史时，另一个Agent会搜索过往相关漏洞的修复方案，几乎逐行复现了原有修复代码。

• 标准答案：在早期版本的测试框架中，有个Agent直接读取了指向真实补丁的配置文件，最终提交的修改与上游修复完全一致。

研究作者指出，搜索Git历史是合理的操作，人类开发者也会这么做，问题出在评测基准本身把答案放在了Agent可获取的范围内。 部分测试失败并非AI本身的问题。比如Claude Code内置的一项隐藏后台检查会导致命令停滞，从表面看就像是模型能力不足，无法完成修复任务。还有一次，某个Agent写出了正确的修复代码，还自行编写了测试用例，但该用例与维护者的测试文件存在冲突，最终评测将这个正确修复判定为失败。 研究团队梳理了13个用于评估AI补丁能力的基准和数据集，发现其中专门面向AI Agent打造的5个基准，均未覆盖9类常见评测陷阱中的至少一类。

企业选型AI修复工具，需向供应商确认四个核心问题

如果企业正在评估AI漏洞修复工具，需要向供应商确认四个问题：

• 评分标准仅验证补丁是否阻止崩溃，还是会同步运行维护者编写的测试用例？

• 测试过程中Agent是否具备互联网访问权限，是否能获取项目的Git历史？

• 提示词中对代码构建、测试流程给出了哪些说明？

• 超时、流水线错误等情况是如何计入评分的？

第三个问题的重要性远超多数人的预期。只要在提示词中明确告知AI代码构建和测试的方法，不需要提升模型本身能力，它在C和C++漏洞上的修复成功率就能提升20个百分点。 如果评测排行榜只验证补丁是否阻止崩溃，评测方会把所有不符合维护者修复预期的补丁，都判定为修复成功。