论文指出 LLM 漏洞修复基准可靠性受评测设计影响

LLM漏洞补丁基准的通过率会随评测设计变化，PoC通过并不等于按开发者意图修好了缺陷。

• 场景：作者称LLM自动程序修复已从合成代码补全走到在真实项目中定位、修补并验证的端到端智能体；SWE-bench及其多语言后续工作被当作事实标准，新模型按“解决”的issue比例被评判。作者认为，若这些结果再被用来训练下一代代码模型，评测缺陷会被写进权重。
• 不足：作者称典型流程把智能体放进有缺陷的仓库，给出缺陷报告、工具和辅助材料，再用自动化oracle打分。作者认为“所给测试是否通过”把三类结果记成相同分数：维护者会接受的补丁、只让oracle满意的症状抑制，以及利用git历史、联网或权限误配置等评测缺陷得到的通过。部署上，作者认为压住PoC却破坏功能的修复比不修更差；训练上，作者认为每次假阳性通过都在教模型做表层修补。
• 观察：作者认为报告的成功率只相对于harness向智能体提供的信息才有意义；评测流水线本身，而不只是模型或数据集，应被当作研究对象。他们把不改变模型、却能改变测量成功率的变量称为因素，并用对照消融研究系统性因素，用个别失败研究偶然性因素。
• 做法：作者给出智能体、框架、数据集三层缺陷分类；整理112个历史安全相关缺陷、84个C/C++、Go和Rust项目，每例有PoC、回归测试和从上游提交提取的开发者测试。并用三组对照实验、五个案例和13个已有基准的调查展示影响，在§8给出设计准则和报告清单。作者称该数据集用于在受控条件下突出评测缺陷，不是用于竞争式排名。

仓库级修复基准与智能体

• SWE-bench（Jimenez et al., 2024）及Multi-SWE-bench（Zan et al., 2025）：用真实仓库issue的解决比例衡量代码智能体。引言称它们已成为事实标准。
• SWE-agent（Yang et al., 2024）、Agentless（Xia et al., 2024）：分别提供智能体脚手架，以及不依赖自主智能体循环的修复流程。论文在§10称自己的目标不是再做一份基准目录。
• 训练用途：引言引用用通过轨迹做监督或强化学习信号的工作，并认为假阳性通过会进入后续模型。论文未在本文中复现这些训练实验。

面向漏洞的修复评测

• SEC-bench（Lee et al., 2025）、ARVO（Mei et al., 2024）、PatchAgent（Yu et al., 2025）、ExtractFix（Gao et al., 2021）、Vul4J（Bui et al., 2022）、VJBench（Wu and Lin, 2023）、Vul4C（Li et al., 2025）：用CVE、advisory、exploit输入或sanitizer trace做安全修复评测。
• 作者的区别：§10称这些工作比一般issue解决更接近本文设定，但多数仍主要用PoC抑制或已有回归测试评判修复。本文关注的是设计选择如何改变测得的可靠性，而不是提出新排行榜。
• 漏洞集合：§7还讨论Big-Vul、CVEfixes、VADER。它们提供漏洞元数据，没有执行基础设施。

评测方法、弱oracle与污染

• APR评测批评：Liu et al.（2021）批评修复系统的评测实践。Long and Rinard（2016）、Qi et al.（2014）、Smith et al.（2015）讨论测试通过的补丁仍可能不正确，或过拟合弱oracle。
• SWE-bench审计：Wang et al.（2025）、Martinez and Franch（2026）讨论表面上的issue解决可以偏离真正正确性。Sculley et al.（2018）警告基准进展可能快于实证严格性。
• 污染：Cao et al.（2024）、Xu et al.（2024）讨论基准数据污染。作者在§9把公开历史缺陷可能进入训练数据列为对绝对通过率的威胁。

经典程序修复与LLM软件工程

• GenProg（Le Goues et al., 2012）及经典APR：作者称测试充分性与语义正确性的张力已有先例。开发者测试继承这一教训，但放到智能体可定位、编辑、执行工具并利用评测设施的设定中。
• 综述：Fan et al.（2023）、Hou et al.（2024）覆盖代码生成、测试、漏洞检测和修复。作者称自己的范围更窄，只关注补丁生成评测流水线的完整性。

基线与数据集：论文没有把外部补丁系统当作对照基线。对照是同一112例和同一harness上的因素开关：有无构建/测试说明、有无及何种PoC、三个Claude代际。§7按同一因素轴调查13个基准或数据集，但未把它们当作实验基线重跑。

作者称贡献是把评测完整性问题具体化到智能体漏洞补丁：可靠性不仅取决于数据集和oracle，还取决于harness权限、源码消毒、隐藏的智能体机制和补丁后评测流水线。

整体做法是把评测流水线中不改变模型、却能改变测量成功率的变量分成三层，再用带开发者测试的112例、可单独切换的harness来观察这些因素。作者称因素之间并不独立，正文为清晰起见隔离分析，并在§7指出真实基准可能同时存在多个因素。

三层因素

• 智能体层：A1是提示中是否给出构建和测试说明，作者标为系统性因素；没有说明时，智能体须从仓库推断构建系统。A2是互联网与网页搜索，标为偶然性因素；对来自公开GitHub issue的基准，作者认为搜索可能直接取回修复。
• 框架层：F1是权限过宽或过窄；F2是超时和闭源智能体中文档未写明的机制；F3是智能体自己写入的测试与后续评分补丁发生冲突。三者都标为偶然性因素。
• 数据集层：D1是oracle粒度，PoC是否崩溃相对开发者测试；D2是PoC以二进制还是源码级harness呈现；D3是浅克隆、tarball或保留git历史会暴露多少 incidental 信号；D4是语言构成。D1、D2、D4标为系统性，D3标为偶然性。
• 作者预期：构建说明应主要提高PoC通过率，且C/C++大于Go/Rust，因为前者构建系统更不统一。可读的源码级PoC应比不透明二进制PoC提供更多API意图。模型变新时，作者预期PoC通过率上升快于开发者测试通过率。

数据集与开发者测试

• 规模：112个历史缺陷、84个项目。Table 1：C/C++为10个项目、25例，缺陷描述来自GitHub/GitLab issue加ASan trace；Go为51个项目、62例；Rust为23个项目、25例。来源包括公开issue、GHSA、RUSTSEC和提交历史。附录B列出每例的Case ID、Bug Source、PoC形式和commit。
• 筛选：只保留在容器化harness中构建加测试能在半小时内完成的项目。每例钉住trigger commit和patch commit，并做成独立Docker构建。上游开发者补丁只给ground-truth校验器，不暴露给智能体。
• PoC来源：C/C++的PoC是上游issue所附输入。Go中25个PoC来自上游issue或advisory，37个是作者在没有上游PoC时手写的最小harness。Rust在有RUSTSEC参考exploit时使用该exploit，其余由上游报告改写或作者手写；论文未给出Rust这两部分的例数。
• 开发者测试：从上游修复提交提取、由开发者编写的单元或集成测试，重构成可打到修复前源码树上的test.diff。它要回答的是补丁在缺陷邻近输入上是否符合开发者意图，而不是已知崩溃输入是否仍崩溃。上游提交没有新增或实质修改测试的案例被排除，不由作者事后补写；只在沙箱需要时规范化测试设施。
• PHP GH-13094示例：range()的类型混淆可使PoC崩溃。作者描述两种都能压住崩溃并通过修复前回归套件的补丁：上游用语义检查并保留混合数值/字符串强制转换；另一种在不安全解引用前加类型检查并报错。上游提交中的开发者测试检查混合输入的预期输出，所以上游补丁通过、防御性补丁失败。作者用该例说明只看PoC和修复前回归会把二者都记为成功。

oracle流水线与运行配置

• 四阶段：智能体给出补丁后依次做Build、PoC、Regression、Developer’s test。PoC脚本只在与漏洞相关的崩溃时返回非零，而不是程序因非法输入正常非零退出就算失败。PoC每例执行10次，以覆盖触发率不确定的缺陷。回归测试在打上开发者测试之前运行；开发者测试阶段再应用test.diff并重跑。
• 计分：四阶段都通过才算完全解决。论文同时分别报告PoC、回归和开发者测试通过率。案例只有在上游补丁通过全部四阶段后才进入数据集。
• 两套智能体：§5对照实验用OpenCode加Claude Sonnet 4.0；作者称OpenCode开源，便于端到端审计。§6案例用Claude Code加Claude Sonnet 4.5，用来观察闭源生产智能体的框架层问题。模型调用经LiteLLM代理。
• 默认隔离：容器内项目树在智能体应修改的路径；元数据与评测器可见的上游补丁、开发者测试分开。默认配置下智能体为非root，且容器只连到暴露LiteLLM的内部网络，不连公网。附录A写明除非另述，墙钟预算1800秒、轮数预算500。实验机为16核CPU、32GB内存。提示中的构建/测试说明和PoC暴露通过配置开关切换。

实验与案例如何隔离因素

• Experiment 1：112例跑两遍，仅切换提示是否包含评测器用来构建项目和跑回归测试的脚本原文。
• Experiment 2：按PoC自然形式分子集。Go的62例比较无PoC与内联源码harness；C/C++的25例比较无PoC与给出文件路径的二进制或文本blob。两种条件都包含构建和测试说明。
• Experiment 3：同一OpenCode harness、含构建/测试说明、不提供PoC正文，只换模型：Claude Sonnet 4.0、Claude Sonnet 4.5、Claude Opus 4.7。作者称这是从较旧基线到当时的前沿推理模型。
• 案例：五个偶然性事件来自Claude Code加Sonnet 4.5的真实运行。作者称它们只影响部分案例，但对训练、泄漏检测或排行榜仍重要。用于制造泄漏的git历史变体只作案例对照，不属于标题数据集。

调查与报告准则

• 调查范围：13个基准或数据集分成三类。LLM智能体补丁基准适用A1–A2、F1–F3、D1–D4；传统自动漏洞修复基准直接适用D1–D4，若改用于智能体则F1–F3变得相关；无执行设施的漏洞集合只讨论D1–D4。
• 准则：§8的G1–G7要求公布信息预算和提示、对PoC与构建脚本做差分消融、同时报告开发者测试、隔离ground truth并消毒源码树、监控闭源智能体的隐藏机制、把测试冲突与补丁错误分开，并发布失败分类而不是只报通过率。报告清单包括提示、工具与网络范围、源码来源和消毒步骤、oracle定义，以及对失败日志的检查。
• 作者给出的理由：他们选择向自己的数据集注入因素，而不是逐个运行已有基准，以便固定智能体harness和数据集、单独控制每个因素。

实验设置

• 被测模型：对照实验的补丁模型是Claude Sonnet 4.0，经OpenCode调用。Experiment 3另加Claude Sonnet 4.5和Claude Opus 4.7，仍用OpenCode。案例研究用Claude Code加Claude Sonnet 4.5。案例4中Claude Code还向claude-haiku-4-5-20251001发内部安全分类请求；该模型不是补丁结果表中的被测模型。
• 数据：112例、84个项目。Table 1的分母为C/C++ 25、Go 62、Rust 25。Experiment 2的Go子集n=62，C/C++子集n=25。
• 对照：没有外部补丁系统基线。对照是有无构建/测试说明、无PoC相对源码级或二进制PoC、三个模型代际。Table 2的无说明列标成Without (Exp. 2)，但该对比属于§5.1的Experiment 1；§5.2才是Experiment 2。
• 指标：PoC通过率、回归通过率、开发者测试通过率，以及PoC与开发者测试的差距。Table 2写明百分比的分母是该行全部案例。完全解决要求四阶段都通过，但Table 2–4未报告Build通过率或四阶段全部通过的比例。
• 判定与重复：论文未使用LLM评审，成功由脚本退出状态判定。PoC每例10次。Experiment 3的“three times”指三个模型各跑一遍112例，不是同一模型重复三次。作者在§5.1把Go上的小幅反向变化称为单次运行噪声。论文未报告统计检验。
• 环境：16核、32GB；附录A的默认预算为1800秒和500轮，默认无公网。工件含逐例阶段结果。

主结果

Experiment 3在含构建/测试说明、无PoC正文时比较三个模型。Figure 1与Table 4对应；图注称PoC通过率随代际向饱和上升，开发者测试通过率有改善但仍保持在更低水平，回归通过率持平。图中未另标超出Table 4的数值。

表格较宽，可左右滑动

模型	PoC	回归	开发者测试	PoC−Dev	PoC-only
Sonnet 4.0	77.7%	97.3%	43.8%	33.9	43.7%
Sonnet 4.5	84.8%	94.6%	48.2%	36.6	43.2%
Opus 4.7	90.2%	94.6%	60.7%	29.5	32.7%

据Table 4，OpenCode，n=112。PoC−Dev为百分点；PoC-only是PoC通过但仍未过开发者测试的比例。

• 作者解读：作者称PoC通过率随模型代际上升，到Opus 4.7接近饱和；开发者测试通过率也上升，但慢得多。摘要称该率仍然较低，且随更新模型只小幅改善；§5.3给出的是43.8%、48.2%、60.7%这一序列。
• 差距：作者称PoC−Dev差距在三代中都大，到Opus 4.7仍有约三分之一的PoC通过案例会被与维护者意图对齐的oracle拒绝。作者称已有回归套件几乎不能区分症状抑制和开发者可接受的修复。
• 作者的结论：作者称在能力曲线顶部，只看PoC会把任务说成接近解决，而开发者测试仍留有空间；只用PoC或测试oracle的基准所报告的扩展曲线，会高估剩余空间中实践者关心的部分。

构建与测试说明

• 测了什么：112例、OpenCode/Sonnet 4.0，只切换提示是否包含构建和回归脚本原文。Table 2按语言报告三个oracle。
• 结果：有说明时总体PoC/回归/开发者测试为77.7%、97.3%、43.8%；无说明时为74.1%、97.3%、41.1%。C/C++的PoC从72.0%到92.0%，回归从92.0%到88.0%，开发者测试从28.0%到36.0%。Go的PoC从72.6%到69.4%，回归均为100.0%，开发者测试从40.3%到41.9%。Rust的PoC从80.0%到84.0%，回归从96.0%到100.0%，开发者测试均为56.0%。
• 作者解读：作者称C/C++提高20个百分点，Rust变化较小，Go在单次运行噪声内略降。§3.1写C/C++约提高≈20%，§7.3写不同harness配置可使PoC通过率变化最多20%。作者认为说明主要改变信息预算，而不是开发者测试所测的补丁质量；并称若论文对这一细节披露不一致，跨基准分数不能直接比较，差异幅度还依赖语言。

PoC呈现形式

• 测了什么：Table 3。Go的n=62比较无PoC与源码级harness；C/C++的n=25比较无PoC与binary blob。两种条件都含构建/测试说明，模型为Sonnet 4.0。无PoC行与Experiment 1中对应语言、含说明的数字相同。
• 结果：Go无PoC为69.4%、100.0%、41.9%，源码级PoC为95.2%、98.4%、48.4%。C/C++无PoC为92.0%、88.0%、36.0%，给出二进制blob后为92.0%、92.0%、36.0%。PoC和开发者测试在C/C++没有变化，回归从88.0%到92.0%。
• 作者解读：作者称收益更取决于PoC的表示，而不是是否提供了PoC；两个都“提供PoC”的基准若未披露表示，就不可比。作者认为收益更多落在与oracle对齐，而不是与开发者对齐的补丁质量。作者对不对称的解释是：Go源码harness暴露崩溃调用点和API预期，二进制输入基本不透明；C/C++的缺陷描述已含能定位故障的ASan栈。§5.2称这25例使用binary or text-blob；Table 6中若干C/C++案例的PoC列写为src，Table 1则写binary/text blob与C source harness。

偶然因素与已有基准

• 五个案例：Case 1中，默认开启网页工具时，智能体检索到上游修复，PoC和开发者测试都通过。Case 2保留完整.git历史时，智能体用缺陷描述中的旧issue提示查到包含同类API改动的历史提交。Case 3中，智能体可读到含上游补丁路径和提交哈希的元数据目录，随后编辑与上游补丁文本相同。Case 4中，未路由的claude-haiku-4-5-20251001安全分类每次约挂起120秒后才允许Bash；作者称这会不成比例地惩罚需要很多次Bash的大项目，且不能通过智能体设置或提示关闭。Case 5中，智能体改了与开发者测试相同的测试文件，git apply整份失败，功能上与上游修复相当的补丁被记为失败。
• 出现比例：作者称在一次全量运行中，单个偶然因素可低至约5%（权限误配置）、高至约32%（测试冲突）。作者认为影响是系统性偏差而不是均匀噪声；低至5%的案例受影响就可能扭转排行榜名次。论文未给出该名次对应的具体分差，也未报告用这些轨迹再训练后的指标。
• 13个基准：§7称五个LLM智能体基准没有一个处理全部九个因素；§5–§6的每个缺陷至少出现在一个被调查基准中。散文中的例子包括：多个安全基准只用PoC或sanitizer报告；提供PoC的SEC-bench、PatchAgent、ARVO、ExtractFix、Vul4C都只用二进制输入，且没有基准记录或控制PoC格式；若干基准保留未消毒的完整git历史，只有SWE-bench的Python实例做多步消毒；没有被调查基准同时在应用层和网络层执行完整权限模型，也没有基准做网络级隔离或监控隐藏子模型调用；只有PatchAgent和SWE-bench记录超时阈值。有执行设施的安全基准各覆盖一个语言族；作者称只有MultiSWE-bench同时有多语言和执行设施。

其他消融与分析

• §5.4：合并全部受控条件的语言级结果后有734个案例级结局，只有1例同时PoC失败且开发者测试通过。
• §5.4：只过PoC、未过开发者测试的案例数为Sonnet 4.0的38、Sonnet 4.5的41、Opus 4.7的33。
• 作者称开发者测试通过率与PoC通过率之比随条件和模型变化很大；有些配置改善的是与oracle对齐，而不是补丁质量。论文未另给该比值表。
• Table 2：总体回归通过率在有无构建说明时都是97.3%；C/C++回归在无说明时为92.0%，有说明时为88.0%。
• Table 3：Go加上源码级PoC后，回归从100.0%到98.4%，开发者测试只从41.9%到48.4%。
• Table 2–4未报告Build阶段通过率；论文也未报告四阶段全部通过的总体比例。

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

论文没有单列Future Work。§8是给基准设计者的准则，不是作者声明将要完成的实验。§9写出的局限如下。

• 外推（§9 Scope and external validity）：数据集有意做小并经过筛选，限于可Docker复现、有可执行PoC、且上游添加了测试的项目。作者称这带来选择偏差，可能过多代表维护较好的项目，以及复现和校验材料更干净的缺陷。作者明确不声称绝对通过率可推广到全部真实缺陷，或其他语言生态中的基准。
• oracle（§9 Oracle validity）：开发者测试强于只看PoC，但不是补丁可接受性的完美代理。它只在上游修复提交添加或实质修改测试的程度上反映维护者的正确性概念，上游测试本身也可能不完整或过窄。作者称通过开发者测试应被理解为更接近维护者意图，而不是绝对正确的证明。
• 智能体、模型与运行（§9）：绝对表现依赖所选智能体/模型组合和运行级随机性。对照实验用OpenCode加Sonnet 4.0，案例用Claude Code加Sonnet 4.5。作者称§5的百分比不应被读成模型能力的普遍估计；他们更看重大而一致的变化，而不是可能落在单次运行方差内的小百分点差。
• 记忆化与泄漏（§9）：案例来自公开仓库的历史缺陷，部分修复可能出现在训练数据中，这主要影响绝对成功率。作者认为它不能解释模型固定时由配置变化驱动的发现；若成功主要来自精确回忆上游修复，应更能对齐开发者意图oracle。作者将其视为标题通过率的可能贡献者，但不是所报告的基准敏感性的充分解释。

实验覆盖范围

• 补丁结果涉及的模型为Claude Sonnet 4.0、Claude Sonnet 4.5、Claude Opus 4.7。§5.1和§5.2使用OpenCode加Sonnet 4.0；§5.3用同一OpenCode harness对三个模型各跑一遍112例。§6使用Claude Code加Sonnet 4.5。
• 数据为112例、84个项目，语言为C/C++ 25例/10个项目、Go 62例/51个项目、Rust 25例/23个项目（Table 1）。每例有PoC、回归测试和从上游修复提交提取的开发者测试。
• 系统因素实验为构建/测试说明、PoC呈现和模型代际。偶然因素以五个案例呈现，并在一次全量运行中给出出现比例（§6.6）。PoC阶段每例执行10次（§4.3）。论文未报告对照条件的独立重复次数，也未报告统计检验。
• §7按九个因素调查13个基准或数据集。作者在§9称，不直接运行各个已有基准，是为了固定harness和数据集并单独切换因素。论文未报告在这13个基准上重跑智能体的分数。
• 判定方式是四阶段脚本oracle，论文未使用LLM评审。Table 2–4未报告Build通过率或四阶段全部通过的比例。附录A写明默认墙钟预算1800秒、轮数预算500，以及默认不连接公网。

作者把LLM漏洞补丁基准的评测流水线当作会改变测量结果的对象，并明确说本文不是再做一个用于排名的基准。

• 问题：只看PoC或已有测试是否通过，会把维护者可接受的修复、症状抑制，以及利用评测缺陷得到的通过记成同一分数。作者认为这种分数若进入后续训练，会教模型做表层修补。
• 做法：因素分成智能体、框架和数据集三层。112个C/C++、Go、Rust历史缺陷都带PoC、回归测试和从上游提交提取的开发者测试。三组对照在固定harness上单独切换说明、PoC形式和模型；五个案例展示偶然性泄漏和误评分。§7调查13个已有基准，§8给出披露和报告清单。
• 说明与PoC：Table 2中，OpenCode/Sonnet 4.0在C/C++上的PoC通过率，有构建/测试说明时为92.0%，无说明时为72.0%；Go则是69.4%对72.6%，作者称后者落在单次运行噪声内。Table 3中，Go源码级PoC使PoC通过率从69.4%到95.2%，开发者测试只从41.9%到48.4%；C/C++给出二进制blob后，PoC和开发者测试仍为92.0%和36.0%。
• 模型代际：Table 4在含说明、无PoC正文、n=112时，PoC通过率从Sonnet 4.0的77.7%到Opus 4.7的90.2%，开发者测试从43.8%到60.7%。Opus 4.7仍有32.7%的PoC通过案例未过开发者测试。摘要称开发者测试通过率只小幅改善；§5.3称它上升得慢得多。
• 偶然因素：作者称一次全量运行中，权限误配置可低至约5%，测试冲突可高至约32%，而且偏差不是均匀噪声。网页搜索、未消毒的git历史和过宽的文件权限都能把上游修复暴露给智能体；隐藏子模型超时和测试补丁冲突则可能把可用补丁记成失败。
• 作者的结论：作者认为，若基准分数要被用来展示模型能力、支持科学主张，或给后续补丁系统提供训练信号，评测流水线本身必须被当作贡献的一部分。对这一任务，基准测量的是什么至少和分数多高同样重要。