PatchBench：漏洞修补 Agent 的安全与语义验证

摘要

PatchBench 检验漏洞修补 Agent 的高通过率究竟来自根因修复、历史补丁记忆，还是只让给定概念验证（Proof of Concept, PoC）不再崩溃。作者先在含 300 个 C/C++ 任务的 SEC-bench 上研究数据污染：Agent 生成的补丁平均有 25% 与历史开发者补丁高度相似；Codex 与 GPT-5.6 Sol 的补丁有 81% 修改崩溃调用栈中的函数，即使历史修复位置不在调用栈中，该比例仍为 64%。

新 benchmark 含 213 个任务、16 类 CWE 和 32 个真实项目。它选择参考修复位于崩溃调用栈之外的漏洞，再把历史漏洞移植到较新的仓库版本并变异修补位置。安全验证使用多个模糊测试生成的崩溃输入，语义验证比较良性输入的 sanitizer、程序级输出状态和项目单元测试。11 个 Agent 的单 PoC 通过率平均虚高 1.83 倍；前三名在单 PoC 上均超过 97%，多 PoC 安全验证后降至 75%–82%，加入语义验证后约只解决一半任务。

方法的独特价值

研究同时控制两类常被混淆的效度威胁。DiffBLEU 面向多 hunk 代码差异，先规范化注释、字符串等表层变化，再比较 Agent 补丁与历史开发者补丁，以发现“文本略改但位置、控制流和返回值近似”的记忆迹象。漏洞移植与代码变异则把旧漏洞放进新上下文，降低逐字复现历史修复的机会。

第二项价值是把“PoC 不再触发”拆成安全正确性与语义正确性。只有目标漏洞不再被多个崩溃输入触发、良性行为与参考修补版本一致、且项目既有测试继续通过，才计为解决。主要产物是 benchmark、判定规则和对照实验，因此归入安全 Benchmark、指标与评测完整性，而不是把 Agent 生成的任一错误补丁视为新的产品漏洞。

适用范围

PatchBench 面向仓库级 C/C++ 漏洞修补，任务来自真实开源项目并依赖 sanitizer、模糊测试输入和可运行单元测试。它不直接覆盖 Java、脚本语言、配置漏洞、并发缺陷、逻辑授权错误或无法稳定重放的生产事件。补丁相似度只能提示训练数据记忆，不能证明某段训练数据确实出现过。

方法与实施流程

在 SEC-bench 的 300 个任务上比较局部上下文 LLM 与 Codex、Claude Code、OpenHands 等仓库级 Agent 生成的补丁。
用面向差异的规范化分词和多 hunk 匹配计算 DiffBLEU，并以历史开发者补丁为参照测量高度相似结果。
选择参考修复不在崩溃调用栈函数内的漏洞，人工核对根因；删除没有真正修复根因的候选，剥离提交中的无关改动。
将漏洞移植到仓库较新版本，并在修补位置做保持漏洞语义的代码变异，减少旧补丁直接套用。
用多个模糊测试生成的崩溃输入验证安全性，不向 Agent 暴露验证集。
用良性输入检查 sanitizer 错误，将程序级输出状态与参考修补版本比较，并运行参考版本可通过的项目单元测试。
分别报告单 PoC、安全验证、安全与语义联合验证下的解决率，并比较不同 Agent 与预算。

质量控制

语义有效要求三个条件同时成立：Agent 修补版本处理良性输入时没有 sanitizer 错误；程序级输出状态与参考修补版本一致；参考修补版本上可工作的项目单元测试也全部通过。安全验证则要求多个独立崩溃输入均不能再触发目标缺陷。该设计能识别删除功能、在崩溃点提前返回或只过滤公开 PoC 等表面修补。

以下去武器化验收伪代码只描述判定逻辑，不含真实漏洞输入、漏洞位置或可用于攻击的触发数据：

text

for task in ISOLATED_FIXTURE_SET:
    candidate = agent.patch(task.repository_copy)
    security_ok = all(no_target_fault(candidate, test) for test in HELD_OUT_CRASH_FIXTURES)
    semantic_ok = no_sanitizer_error(candidate, BENIGN_FIXTURES)
    semantic_ok &= outputs_match(candidate, REFERENCE_PATCH, BENIGN_FIXTURES)
    semantic_ok &= passes_reference_working_tests(candidate)
    solved = security_ok and semantic_ok

所有执行都应限制在隔离容器和本地测试夹具中，不连接生产服务，不公开可直接触发真实项目漏洞的输入。

关键结果与实际影响

SEC-bench 含 300 个 C/C++ 漏洞任务；每任务最高 5 美元预算时，Codex 与 GPT-5.6 Sol 按原验证可通过 97.3%。
Agent 补丁平均有 25% 与历史开发者补丁高度相似；作者将其解释为“可能记忆”的证据，而非训练集成员证明。
Codex 与 GPT-5.6 Sol 的补丁有 81% 修改崩溃调用栈函数；参考修复不在调用栈时仍有 64% 如此。
PatchBench 含 213 个任务，覆盖 16 类 CWE 和 32 个项目；评测对象为 11 个 Agent，其中包括 AIxCC 前三名和 8 个通用 Agent。
前三名的单 PoC 通过率均超过 97%，多 PoC 安全验证后为 75%–82%，再加入语义验证后约为一半。
11 个 Agent 上，单 PoC 验证把解决率平均放大 1.83 倍；另有 67 个任务没有任何 Agent 解决。
性能在达到 5 倍预算上限前已经趋于平台期，说明仅增加推理预算不能自动弥补定位和语义验证缺口。
论文引用的先前研究发现，即使 Team Atlanta 与 Claude Code 通过全部自动检查，仍有 16%–38% 的补丁语义不正确；该数字来自不同评测，不能与 PatchBench 结果直接合并。

局限与待验证问题

证据等级为 moderate：作者公开论文、代码与 benchmark，但结果尚无独立复现。213 个任务集中在 C/C++、32 个开源项目和 16 类 CWE；对历史修补提交的人工整理、漏洞移植和变异可能改变任务难度。参考补丁本身也不是形式化规格，输出状态和单元测试仍可能漏掉未覆盖语义。

DiffBLEU 的高相似度可能来自补丁空间狭窄或唯一自然修法，不能单独证明记忆；低相似度也不能排除语义层面的记忆。安全验证依赖已发现的多个崩溃输入，不能证明不存在其他触发路径。商业 Agent、模型版本与默认脚手架会持续变化，排行只适用于论文冻结的版本、预算和运行条件。

PatchBench：漏洞修补 Agent 的安全与语义验证 ​

摘要 ​

方法的独特价值 ​

适用范围 ​

方法与实施流程 ​

质量控制 ​

关键结果与实际影响 ​

局限与待验证问题 ​

参考链接 ​