PatchBench：马里兰大学团队发布 C/C++ 漏洞修补评测基准

漏洞自动修复评测中存在补丁记忆与单PoC表面抑制两大致命效度缺陷。

• 研究背景与问题重要性：软件漏洞修复成本高昂且耗时漫长，AI 智能体虽在自动化漏洞修复中展现出潜力，但作者指出，对 AI 辅助修复能力的严格评测仍面临挑战。
• 现有评测方法的不足：现有评测通常仅检验程序在单个 PoC 输入下是否不再崩溃，这导致两类效度风险：模型可能仅仅复现训练集中记忆的已知补丁，或者仅在崩溃栈附近生成抑制报错的表面修补，未真正定位并修复根因。
• 论文的核心观察：在真实漏洞基准 SEC-BENCH 上的实验显示，Codex + GPT-5.6 Sol 能通过 97.3% 的任务，但作者发现其补丁平均有 25% 与历史开发者补丁高度相似；即使开发者补丁不在崩溃调用栈上，智能体仍有 64% 的补丁修改了崩溃栈函数。
• 论文提出的解决方案：作者提出了包含 213 个 C/C++ 任务的基准 PATCHBENCH，通过筛选离栈漏洞、跨版本移植与代码变异消除记忆捷径，并建立包含多 PoC 安全验证与良性输入语义验证的评估流程。

论文在相关工作中主要回顾了以下三个领域的研究：

漏洞修复基准（Vulnerability Patching Benchmarks）

• Defects4J（Just 等，2014）与 GitBug-Java（Silva 等，2024）：用于通用程序自动修复，但后续多项研究指出其存在数据污染与补丁记忆现象。
• EXTRACTFIX（Gao 等，2021）、SAN2VULN（Kim 等，2025）、PATCHAGENT（Yu 等，2025）与 SEC-BENCH（Lee 等，2026）：提供仓库级可执行环境，但作者指出它们仅依赖单个 PoC 验证补丁，且均未提供防记忆机制（Table 1）。
• AUTOPATCHBENCH（Meta，2025）与 AIxCC AFC（Zhang 等，2026）：AUTOPATCHBENCH 采用单次无向模糊测试蒸馏输入并进行函数级状态差分测试，作者认为其难以生成针对目标漏洞的新 PoC 且易误拒等价状态补丁；AIxCC 依靠专家手工编写 40 个合成 C 漏洞，作者指出人工编写成本高昂且难以规模化扩展。

基于大模型的漏洞修复智能体（Vulnerability Patching Agents）

• 通用软件工程智能体：SWE-Search（Antoniades 等，2025）、SWE-agent（Yang 等，2024）与 OpenHands（Wang 等，2025）等，允许大模型在结构化环境中自主探索代码仓库、编辑文件与运行终端命令。
• 专用安全漏洞修复智能体：APPATCH（Nong 等，2025）以及 AIxCC 决赛系统 Atlantis（Team Atlanta，2025）、Buttercup（Trail of Bits，2025）与 RoboDuck（Team Theori，2025），将大模型与系统安全工具结合或采用多智能体协同架构。

补丁验证方法（Patch Validation Methods）

• 程序分析与差分验证：Gallagher 等（2014）、Kim 等（2023）利用静态或动态分析验证补丁；SPIDER（Machiry 等，2020）与 VeriBin（Wu 等，2025）提出了安全补丁条件，作者指出其规则对漏洞补丁而言过于严苛。
• 大模型补丁评估实践：先前研究结合单元测试、LLM 评审（Team Atlanta，2025）、修复后模糊测试与人工审计，但近期多项综合评述（Hu 等，2025；Li 等，2025；Zhang 等，2026）均指出现有安全补丁验证仍不充分。

基线方法与基准

• 论文对比了 3 个商业与开源通用智能体框架（Codex、Claude Code、OpenHands）及 3 个 AIxCC 决赛系统（Atlantis、Buttercup、RoboDuck）；对比基准为 SEC-BENCH，数据源基于 ARVO。

论文与相关工作的区别定位

• 作者表示，与以往基准相比，PATCHBENCH 同时实现了对补丁记忆效应的有效抑制（通过版本移植与代码变异），并建立了覆盖崩溃集消除与良性输入程序级输出状态一致性的全面验证流程。

整体上，论文提出了上下文感知补丁相似度指标 DiffBLEU，构建了缓解记忆效应的基准 PATCHBENCH，并设计了涵盖安全与语义维度的两阶段补丁验证流程。

补丁记忆度量与 DiffBLEU

• 度量指标设计：DiffBLEU 在 CodeBLEU 基础上扩展，结合差异感知分词器与程序切片，计算候选补丁与开发者补丁的相似度： DiffBLEU = α BLEU(Δ_r, Δ_c) + β BLEU_w(Δ_r, Δ_c) + γ Match_ast(C_r, C_c) + δ Match_df(C_r, C_c) 公式前两项度量补丁块差异的词法表面相似度，后两项度量补丁代码上下文在控制流 AST 与数据流切片上的结构相似度。
• 分词与切片细节：分词器将新增行与删除行映射到独立空间，匿名化字面量并去除注释；AST 匹配针对包含补丁的控制流切片，数据流匹配针对补丁变量的依赖切片。参数设置为 alpha=0.3、beta=0.3、gamma=0.2、delta=0.2，判定记忆的阈值设为 0.75。

基准构建流程

基准基于 ARVO 数据集构建，包含 213 个任务（涉及 32 个项目、16 种 CWE），分为 7 个步骤：

1. 定位开发者补丁点：将开发者补丁修改的代码实体映射到具体函数集合。
2. 度量距崩溃栈距离：收集 PoC 执行首次到达补丁点的调用栈与崩溃时的调用栈，计算二者函数集合的 Jaccard 相似度（重叠度得分 rho）。
3. 筛选离栈任务：仅保留补丁点不在崩溃栈上的漏洞，并进一步要求重叠度 rho <= 0.5，确保崩溃仅为下游表象。
4. 跨版本移植漏洞：将开发者补丁反转为致病差分，通过二分搜索定位可成功应用该差分并能复现崩溃的最新 Git 提交。
5. 补丁位置代码变异：先对每个补丁块应用 NATGEN 的 5 种语义保持变换（变量重命名、循环变换、语句块交换、操作数交换、插入混淆代码），再用 CODEMORPH 随机应用一次上下文重构（如提取条件至新函数），使原开发者补丁无法直接应用。
6. 人工策展参考补丁：人工审查变异补丁与漏洞根因，剔除与漏洞无关的修改，确保参考补丁精准消除根因。
7. 验证支持筛选：保留具备有效模糊测试引擎且能在基准和修复后仓库均通过至少一个单元测试的任务。

双重补丁验证机制

要求智能体生成的补丁同时满足两项验证条件：

1. 输入空间生成：结合 PoC 导向的定向模糊测试（CONCFUZZ，运行 10 分钟，中位数产生 33 个新 PoC）与无向常规模糊测试（运行 10 分钟），构建崩溃语料库（仅在任务仓库触发崩溃）与良性语料库（两仓库均不崩溃）。
2. 安全性验证：运行崩溃语料库中的所有输入，要求智能体补丁仓库均不触发 Sanitizer 错误，排查仅拦截单个原始 PoC 的表面修复。
3. 语义正确性验证：包含三重检查：Sanitizer 回归检查（良性输入不触发新 Sanitizer 报错）、程序级输出状态检查（良性输入下输出与参考仓库完全一致，经 3 次运行剔除不稳定输入）、项目单元测试检查（通过参考仓库能通过的所有单元测试）。

实验设置

• 被测模型与智能体：通用智能体包括 Codex + GPT-5.6 Sol、Claude Code + Claude Opus 4.8，以及 OpenHands 搭配 6 种模型（GPT-5.6 Sol、GPT-5、Claude Opus 4.8、Claude Sonnet 4.5、Gemini 3.5 Flash、Gemini 3.1 Pro）；AIxCC 决赛系统包括 Atlantis（运行 GPT-5.6 Sol 与 Claude Opus 4.8）、Buttercup（GPT-5.6 Sol）和 RoboDuck（GPT-5.6 Sol）。
• 测试基准与规模：PATCHBENCH 基准（213 个 C/C++ 任务，涵盖 32 个项目和 16 种 CWE）及用于对比记忆的 SEC-BENCH（300 个任务）。
• 基线与环境：在 Docker 容器中提供仓库、构建工具链、PoC 与 Sanitizer 报告，禁用一切外部网络检索。所有模型配置为中等推理强度（medium reasoning effort）。
• 指标定义：PoC Pass（原始 PoC 消除崩溃比例）、Security Pass（通过扩展崩溃语料库比例）、Semantic Pass（通过良性输入三项检查比例）、Solved（同时通过安全与语义验证比例）、Budget Exhausted（耗尽预算比例）。
• 评审方式与判定标准：自动化执行模糊测试生成的崩溃与良性输入，比对 Sanitizer 报错、程序级输出状态与单元测试结果，不使用 LLM 打分。
• 预算与重复：通用智能体每任务预算上限 5 美元（Atlantis 4 个节点各 5 美元共 20 美元）；输出状态检查运行 3 次剔除不稳定输入；总计推断成本约 6500 美元。

主结果

表格较宽，可左右滑动

注：据 Table 2，表格限制行数，省略了 OpenHands + Claude Opus 4.8（47.9%）、OpenHands + GPT-5（42.3%）、OpenHands + Claude Sonnet 4.5（38.0%）、OpenHands + Gemini 3.1 Pro（31.5%）。

• PoC 通过率虚高且扭曲能力排名：全智能体原始 PoC 平均通过率为 83.1%，而最终解决率仅 45.3%（膨胀 1.83 倍）；如 OpenHands + GPT-5 的 PoC 通过率排第 4（96.2%），但解决率仅排第 8（42.3%），低于 PoC 通过率仅 77.9% 的 Gemini 3.5 Flash（44.1%）。
• 语义验证是主要失败瓶颈：全智能体语义验证平均通过率仅 63.4%，主要失败集中在输出状态（平均通过率 75.5%）和单元测试（平均通过率 79.9%），而 Sanitizer 回归平均通过率达 95.7%（Table 4）。
• 专用 AIxCC 系统落后于同底座通用智能体：基于 GPT-5.6 Sol 的 Buttercup（42.7%）和 RoboDuck（29.6%）落后于相同模型的 Codex（59.2%）与 OpenHands（58.2%）；作者称其原因在于过度受限的工作流约束（如限制单函数修改或固定模板）以及框架故障（如 RoboDuck 补丁失败直接退出、Buttercup 上下文检索失败率达 23.5%）。

预算扩展与求解上限分析

• 测试设置：将 Codex + GPT-5.6 Sol、Claude Code + Claude Opus 4.8 和 OpenHands + Gemini 3.5 Flash 的每任务预算从 5 美元逐步提高到 25 美元（Figure 6）。
• 测试结果：Codex 解决率从 5 美元的 59.2% 升至 15 美元的 61.5% 后完全停滞（20 与 25 美元仍为 61.5%）；Claude Code 从 56.8% 升至 58.2% 停滞；OpenHands 从 44.1% 升至 46.4% 停滞。在 25 美元时，因预算耗尽而中断的任务比例不超过 1.4%。
• 作者的解读：作者认为增加预算收益微弱且迅速达到平台期，表明预算并非阻碍当前智能体的主要瓶颈，213 个任务中有 67 个任务所有 11 个智能体均无法解决。

失败模式归纳与分析

作者对通过原始 PoC 但未通过全面验证的补丁进行了人工归类，总结出 4 类失败模式：

• 模式 1：用不完备的局部检查防护表象：最常见的失败模式，在 Codex + GPT-5.6 Sol 产生的 81 个此类失败补丁中占 41 个（Claude Code 占 47/87，OpenHands + Gemini 3.5 Flash 占 39/72）。智能体仅在 Sanitizer 报错位置添加局部边界检查或提前返回，无法防御相同根因的其他变异输入。
• 模式 2：未定位引发功能异常的漏洞根因：补丁能通过安全性检查，但破坏了良性输入行为或保留了错误逻辑，导致输出状态或单元测试失败（如重写循环导致网格数据与计数不符）。
• 模式 3：直接删除引发崩溃的操作或整个功能：智能体通过删除崩溃代码或功能模块来阻止崩溃（如 Buttercup 删除整个 TLS 元数据提取代码块）。
• 模式 4：添加过于宽泛的检查破坏合法功能：新增条件不仅拦截了 PoC，还将良性合法输入一并拒绝。

其他消融与分析

• 输出状态检查贡献（Table 3）：移除输出状态检查后，全智能体平均解决率上升 8.1 个百分点；OpenHands + GPT-5 上升最多（11.3 个百分点），RoboDuck 增幅最小（4.7 个百分点）。
• 输出状态拦截补丁的人工审查：Codex 仅因输出状态检查未通过的 18 个补丁中，经人工复查全部确认为无效补丁（15 个属于模式 2，3 个属于模式 4），无一例由检测工具缺陷导致。
• PATCHBENCH 防记忆效果（Figure 9）：在 0.75 的 DiffBLEU 阈值下，Codex、Claude Code 与 OpenHands 被判定为记忆的补丁比例分别为 0.0%、1.4% 和 0.9%，约 40% 的补丁得分为 0；而在 SEC-BENCH 上这三个系列模型的对应智能体比例分别为 22.0%、27.7% 和 24.3%。

作者指出的局限与后续方向

• 部署阶段对参考补丁仓库的依赖：作者在 Section 6 指出，在智能体真实部署场景中不存在参考补丁仓库来进行语义验证；虽然可以比对易受攻击仓库与补丁后仓库的输出状态，但这一弱参考无法兼顾正确补丁特意修复的功能变更。
• 输入语料覆盖不足带来的验证盲区：作者在 Section 6 指出，人工审查发现通过验证的 Atlantis 补丁中有 6.8%、Codex 补丁中有 7.1% 仍未完全修复根因，原因是模糊测试无法保证覆盖所有相关路径；后续方向提出可通过符号执行或混合执行生成能同时触达补丁路径与开发者路径的输入来减少假阳性。
• 静态基准存在未来数据污染风险：作者在 Section 6 指出，PATCHBENCH 是静态基准，未来模型若在基准上训练仍有污染风险；后续方向提出研究者可利用论文的漏洞移植与变异方法，对新披露的真实漏洞进行动态构建以持续评测。
• 无法直接确定私有模型的具体训练数据：作者在 Section 6 指出，由于无法获取专有模型的实际训练数据，记忆度量研究的目的并非直接指出具体记忆了哪些训练数据，而是揭示模型可以在不推理根因的情况下生成高度相似补丁的现象。

实验覆盖范围

• 编程语言与漏洞类型：被测任务全部针对 C/C++ 语言，共涵盖 16 种 CWE 类型和 32 个开源项目，总计 213 个任务。
• 被测系统：评测覆盖了 3 个商业与开源通用框架（Codex、Claude Code、OpenHands）以及 3 个 AIxCC 决赛系统（Atlantis、Buttercup、RoboDuck），共计 11 种智能体配置。
• 任务筛选限制：仅收录开发者补丁位置在 Sanitizer 崩溃调用栈之外，且调用栈重叠度 Jaccard 相似度 rho <= 0.5 的离栈漏洞任务。
• 测试开销与算力预算：主实验每任务预算上限为 5 美元（Atlantis 4 个节点各 5 美元共 20 美元），扩展实验最高测试至 25 美元；全基准推断总成本约为 6500 美元。
• 论文未报告的信息：论文未报告不同采样温度（temperature）对补丁多样性的影响，亦未报告各模型在非中等推理强度（如低或高 reasoning effort）下的表现对比。

• 定位与核心问题：该论文针对 AI 漏洞修复智能体评测中的“补丁记忆”与“表面抑制”两大效度漏洞，提出了包含代码变异与跨版本移植的评估基准 PATCHBENCH 及双重验证流程。
• 要解决的问题：现有评测仅凭单个 PoC 不再崩溃即判定修复成功，导致模型倾向于直接复现训练集中记忆的开发者补丁，或仅在崩溃栈附近添加局部判断屏蔽报错，产生高达 1.83 倍的通过率虚高，且扭曲对不同智能体能力的评判。
• 方法要点：通过程序切片与差分分词设计了 DiffBLEU 补丁相似度指标；基准选取补丁点位于崩溃调用栈之外的漏洞（调用栈重叠度 Jaccard 相似度不超过 0.5），通过将历史漏洞反向移植到新版本并施加 NATGEN 与 CODE-MORPH 代码语义变异打破字面记忆；建立结合 PoC 定向模糊扩展的安全验证，以及包含良性输入程序级输出状态一致性比对的语义验证。
• 核心实验结果：
  1. 在 SEC-BENCH 上，通用智能体生成的补丁平均有 25% 与历史开发者补丁高度相似（DiffBLEU > 0.75），而在 PATCHBENCH 上该比例降至 0% 到 1.4%。
  2. 在 PATCHBENCH 的 11 个顶尖智能体评测中，原始 PoC 平均通过率达 83.1%，但经安全与语义双重验证后平均解决率仅 45.3%（最高解决率为 Codex + GPT-5.6 Sol 的 59.2%）。
  3. 全智能体良性输入语义验证平均通过率仅 63.4%，其中输出状态检查平均通过率仅 75.5%，是最主要的失败瓶颈。
  4. 将预算从 5 美元上限提升至 25 美元，解决率仅微弱提升 1.4 到 2.3 个百分点并迅速进入平台期，全基准有 67 个任务所有智能体均无法修复。
• 作者结论与启示：作者指出，单 PoC 崩溃抑制不仅造成评价失真，还会掩盖智能体缺乏程序全局推理能力的事实；未来的漏洞自动修复系统必须摆脱基于崩溃栈局部修补的捷径策略，强化真正的根因定位以及跨输入的功能等价性保障。