Trail of Bits 称 1Password 的 AI 补丁基准测试误导了安全防御者

Trail of Bits 在 1Password 的 AI 补丁基准测试发布六周后提出质疑，称其宣称的 26%“干净修复”率具有误导性。

这场争议并不只是关于 AI 是否能编写安全代码，而是关乎：当智能体收到错误指令、工具受限且评分标准不一致时，基准测试究竟在衡量什么。

1Password 的 Off-by-1 Labs 针对六类高难度漏洞测试了 6,080 个补丁。其报告发现，26% 的补丁在未实质改变应用行为的情况下，完整修复了漏洞。

另有 20.1% 的补丁修复了报告中的漏洞，但改变了行为。其余 53.9% 未能修复问题、引入了另一项漏洞，或两者兼有。

Trail of Bits 并未声称这些失败无害。其研究人员认为，汇总结果混合了代表截然不同补丁任务的实验条件。

该公司表示，数据集中的 22% 来自引导智能体采用错误修复方案的提示词。另有 36% 来自智能体无法编译或测试代码的试验。

Trail of Bits 还在批评文章发布的同时推出了两项智能体技能。其中一项会根据原始漏洞、相关变体和回归情况验证补丁；另一项则为工程师创建交互式审查演练。

这一回应将对基准测试的分歧，扩大为关于 AI 辅助安全的更大讨论。核心问题是，团队应将智能体视为孤立的补丁生成器，还是视为经验证工程流程的参与者。

1Password 的 AI 补丁基准测试混合了差异极大的实验

Trail of Bits 认为，26% 的结果描述的是一项混合实验，而非配备正常开发工具的典型智能体。

Off-by-1 Labs 于 2026 年 8 月 6 日发布了 FLAWED 研究。FLAWED 是 Fix-Like Artifacts With Embedded Defects 的缩写。

该研究考察了 ChatGPT-5.5 和 Opus 4.8 在六个近期披露漏洞上的表现。测试目标包括 Linux、ActiveMQ、Chrome、Exim、Spring AI 和 Gemini CLI。

研究人员选择了上游修复涉及多个文件、函数或代码路径的漏洞。其较新的披露时间也降低了模型记住完整补丁的可能性。

这种设计有其正当目的。困难且陌生的漏洞能够揭示普通编程基准测试可能掩盖的不完整推理。

不过，它也限制了读者对平均值的泛化范围。根据 Trail of Bits 的分析，六个目标的干净修复率在 3% 至 60% 之间。

因此，六个目标的平均值高度依赖目标选择。它无法确定常规补丁、较简单漏洞或具有代表性的软件待办事项中的失败率。

实验也改变了智能体的工作方式。一次性运行不提供 shell 访问权限，并阻止模型构建或执行受影响的软件。

迭代运行提供复现脚本，并允许多次尝试。探索性运行提供开发访问权限，但要求智能体自行决定如何验证其工作。

这些模式回答的是不同问题。一次性响应衡量的是在严格限制下的代码生成。迭代式智能体则衡量能够获得可执行反馈的补丁修复能力。

将两者合并为一个标题数字，掩盖了这一差异。没有编译权限的补丁智能体无法利用人类开发者视为基本工程实践的反馈循环。

Trail of Bits 表示，无法测试的模式占所报告数据的 36%。这一比例使工具限制成为总体结果的重要输入因素。

提示词构造带来了另一项差异。FLAWED 研究针对每个漏洞使用了九种结构化提示词模板，其中包括包含错误或不完整指引的提示词。

测试模型是否能抵制错误建议很有价值。它可以揭示自动化偏见，并显示智能体会在多大程度上遵循错误诊断。

但 Trail of Bits 表示，其中两种提示词明确引导智能体采用错误修复方案。这些提示词占数据集的 22%。

评估自主补丁修复的组织应关注这种失败模式。面对准确漏洞报告、评估智能体的开发者则处于不同情境。

因此，争议在于汇总方式，而非这些实验是否应当存在。Trail of Bits 认为，误导性提示词应与常规修复尝试分开报告。

其重新分析保留了智能体能够执行代码且未被引导至错误修复方案的试验，同时排除了被标记为参考上游补丁的尝试。

在这些条件下，3,067 个补丁中的 2,634 个阻止了所提供的利用方式，占筛选后尝试的 86%。

阻止一种利用方式并不能证明完成了全面的安全修复。Trail of Bits 明确承认这一局限。

狭窄的防护措施可以阻止所提供的输入，但仍让底层弱点通过另一条路径被触发。86% 的结果衡量的是即时阻断利用，而非彻底修复。

尽管如此，筛选后的结果说明了实验条件为何重要。同一数据集既可以支持悲观的干净修复率标题，也可以得出更乐观的利用阻断结果。

单独来看，这两个百分比都无法决定 AI 智能体是否是可靠的补丁作者。结合起来看，它们表明基准测试标签必须精确描述所测试的工作流程。

为什么提示词设计和测试权限会改变答案

这场基准测试争议揭示了智能体评估的一条基本规则：工作条件本身就是被测系统的一部分。

编程智能体不仅是语言模型。它还包括指令、工具、执行环境、上下文、停止规则和验证流程。

改变其中任何一个组成部分都可能改变结果。能够运行复现程序的模型，可获得仅根据静态文本生成一次响应的模型无法取得的证据。

原始 FLAWED 报告 描述了三种运行模式。每种模式代表了隔离、迭代和智能体自主性之间不同的平衡。

一次性模式不提供 shell 和互联网访问权限，要求模型在单次响应中创建完整补丁。

这种设置可以代表高度受限的环境，但它将编译、测试、消毒器、调试和检查命令排除在修复循环之外。

迭代模式提供复现脚本并允许多次尝试。智能体可通过记忆文件利用早期运行的反馈。

探索性模式允许类似访问权限，但不向模型提供准备好的复现程序。智能体必须在报告完成前选择自己的验证路径。

这些模式的区别不只是便利程度不同，而是在测试不同的能力。

一次性生成考察模型能否从源代码和文字说明中推断出完整修复方案。迭代式补丁修复则考察其能否诊断失败并通过执行来改进。

探索性补丁修复增加了另一项负担。智能体必须构建其改动有效的证据，而不是将这些证据作为任务的一部分直接获得。

Trail of Bits 认为，基准测试应披露这些条件的影响，而不应将其合并后的平均值视为通用能力评分。

提示词质量也会造成类似问题。安全报告通常包含利用方式、疑似根本原因、受影响路径和缓解建议。

这些输入可能不完整或有误。衡量模型在各类条件下的表现，有助于团队设计更安全的工作流程。

不过，刻意提供错误指引代表的是对抗性或错误的任务框定。它不应悄然影响用于描述常规 AI 补丁修复的数字。

一份有用的报告应分别展示正确指引、不完整指引、错误指引和无指引探索下的干净修复率。这样，读者便可将结果映射到自身环境。

推理设置构成第三个变量。实验按照默认设置，以中等推理强度运行 ChatGPT-5.5，以高推理强度运行 Opus 4.8。

Trail of Bits 指出，两种模型均未使用其可用的最高设置。实验也没有单独分析推理强度如何影响修复质量。

这一遗漏并不意味着观察到的补丁无效，但它限制了关于各模型可达性能的主张。

当模型获得不对等的设置时，这一问题更为重要。否则，读者可能会将差异理解为模型能力差异，而非配置效果。

评分又增加了一层复杂性。FLAWED 使用模型评估补丁，包括由另一模型进行交叉审查。

根据 Trail of Bits 的说法，在已审查案例中，模型评分与人工审查员对完整五类结果的判断一致率为 65.9%。

当审查员只判断原始漏洞是否已修复时，一致率升至 87.7%；对于是否出现新漏洞的判断，一致率则降至 70.5%。

Trail of Bits 报告称，两个模型评分器对同一批补丁中 36.8% 的结果给出了不同判定。对这些判断取平均值，并不能消除分歧。

这很重要，因为干净修复状态结合了多项判断。评分器必须确定旧漏洞是否仍存在、行为是否发生变化，以及是否出现了另一项弱点。

即便是正确补丁，如果评分器将预期的行为变化视为回归，也可能获得不利标签。若测试忽略另一条易受攻击的路径，不完整补丁也可能通过。

Trail of Bits 表示，8% 的 ActiveMQ 判决将预期变更错误地视为回归。它还指出，Chromium 的一条评分路径据称接受了不完整的 use-after-free 修复。

该批评还指出，一个 Linux 参考补丁存在 off-by-one 漏洞。模型在 248 个生成补丁中重复了该错误，而自动评分器只发现了其中 24 个。

这些主张来自 Trail of Bits 的重新分析，仍属于持续的方法论争议。它们并不能抹去 Off-by-1 Labs 记录的失败补丁。

它们说明，AI 基准测试也需要验证其自身的评估器。评分流程与补丁修复流程一样，都可能引入假阳性和假阴性。

真正的争议：AI 补丁生成与经验证的修复

1Password 衡量生成的补丁有多常符合干净修复的标准，而 Trail of Bits 强调将提案转变为已接受修复的工程流程。

原始 1Password 研究结果 提出了一个重要警告：看似合理的代码可以阻止概念验证利用，却无法解决漏洞的根本原因。

Off-by-1 Labs 发现，被归类为成功的补丁中，超过三分之一包含安全性脆弱的元素。这些补丁依赖狭窄的检查，而非完整修复。

Spring AI 提供了一个有用案例。模型通常会转义所提供恶意输入中的字符，而不是解决底层的表达式语言暴露问题。

这样的补丁可以击败某一个载荷，却仍允许替代输入生效。针对一项测试的功能性成功，因而会造成虚假的信心。

Trail of Bits 并不否认这一教训。其新的验证技能也体现了类似考量：它要求针对同一失败情况验证第二条路径。

这场分歧聚焦于生成前后发生的事情。基准测试既可以评估模型的原始响应，也可以评估由智能体辅助的开发过程。

这两种分析单位会得出不同结论。原始生成结果能暴露模型的失效模式；完整工作流则衡量工程师是否能借助智能体获得正确结果。

Trail of Bits 通过其 Patch the Planet 计划支持后一种观点。工程师指导智能体、审查其工作，并向开源维护者提交补丁。

该公司审查了截至 9 月 14 日维护者已合并或关闭的 186 个公开拉取请求。维护者合并了其中 126 个，接受率为 67.7%。

在这些已合并的提交中，91 个保留了最初提出的安全修复，且未观察到与安全相关的修改。另有 33 个在被接受前经历了安全相关变更。

这些数字并不能证明其正确性。维护者可能会合并存在缺陷的代码，公开审查结果也无法揭示之后出现的所有回归问题。

Trail of Bits 承认这一局限。该公司将接受情况视为实用价值和修订负担的证据，而非完美安全性的证明。

该公司还审查了 Patch the Planet 项目中约 33,500 次后续提交，并寻找用于修复其补丁引入问题的变更。

这项调查至少发现了十个功能性 bug、四个构建、测试或发布自动化 bug，以及一个性能问题。报告称未发现可被利用的安全漏洞。

未发现漏洞并不意味着漏洞不存在。Trail of Bits 表示，其更广泛的审查仍在进行中。

有一个案例说明，为人类与智能体划定对立框架可能具有误导性。一名智能体针对 freenginx 嵌入式 Perl 模块中的内存安全问题提出了补丁。

该补丁留下了一条易受攻击的路径，并引入了一个清理阶段崩溃问题。Off-by-1 Labs 对此提出了恰当批评。

一名维护者随后另行创建了一个修复方案，覆盖全部三条易受攻击的路径。该由人类编写的变更也引入了同样的清理阶段崩溃问题。

两位作者都延长了回调的存活时间，随后在请求变得不可用后释放它。清理过程可能会运行访问无效请求的 Perl 代码。

这个案例并不能证明人类与智能体能力相当。它表明，二者都可能忽略直接利用路径之外的后果。

Trail of Bits 将该案例与其咨询记录进行了比较。该公司审查了 2024 年至 2026 年间开展的 236 次安全评估中，2,265 个漏洞的首次修复方案。

开发者首次尝试时未能彻底解决 283 个问题，占比 12.5%；报告的 95% 置信区间为 10.5% 至 14.5%。

这些开发者熟悉自己的软件，并收到了详细的漏洞报告。他们也知道 Trail of Bits 会审查其变更。

这种比较仍不完美。人类开发者和基准测试中的智能体并未在完全相同的条件下解决完全相同的任务。

尽管如此，这些数据挑战了“人类补丁天然正确”这一不现实的基线假设。安全修复始终依赖审查、测试与迭代。

这一背景改变了实际问题。团队并不需要一个首次提交补丁就绝无差错的智能体。

他们需要证据表明，智能体能够提升吞吐量，同时不会将残余风险提高到不可接受的水平。衡量这一点需要可比较的团队、任务和验证关卡。

Trail of Bits 的补丁计划体现了这种工作流视角。智能体负责生成和调查，而工程师与维护者仍对接受补丁承担责任。

1Password 的报告反映了另一种担忧。快速生成可能会让审查者被大量看似完整、实则暗藏细微缺陷的补丁淹没。

两种担忧都可能成立。智能体辅助能够增加可修复漏洞的数量，同时也让严格验证变得更加重要。

两项智能体技能将批评转化为可测试的工作流

Trail of Bits 正在通过操作性控制措施回应这项基准测试，而不只是对数据作出更有利的解读。

该公司发布了 post-patch-validation，用于在提交前检查安全修复。它接收漏洞报告，以及存在漏洞和已打补丁的代码版本。

第一项任务是复现原始 bug。该技能要求验证：检查在漏洞代码上失败、在补丁应用后通过。

这一条件可避免一种常见测试错误。若测试在两个版本上均能通过，就无法证明变更消除了漏洞。

第二项任务针对导致同一故障的另一条路径。这条路径应追溯根本原因，而不是重复原始概念验证。

例如，智能体可能检查另一个调用方、替代输入、错误路径或清理序列。freenginx 的崩溃案例表明，清理过程值得特别关注。

第三项任务检查修改代码周边的回归和新增漏洞。它比较两个版本中本应保持稳定的行为。

验证计划还必须纳入更广泛的证据。Trail of Bits 将项目测试、sanitizer 检查或有边界的模糊测试列为可选组成部分。

sanitizer 可检测无效内存访问等运行时错误类别。有边界的模糊测试则在限定时间或范围内探索生成的输入。

第四项任务将基础设施故障视为结果不确定。构建失败或依赖缺失，不能算作漏洞已被复现的证据。

这条规则看似显而易见，但自动化流水线常将执行错误压缩成通过或失败的标签。将无效证据区分开来，能够保护最终结论。

该技能会为维护者保留检查过程和结果。这让智能体的结论可供审查，而不是要求审查者相信一段文字保证。

第二项发布的技能 review-walkthrough 则处理工作流中的人为环节。它将完整的分支 diff 转换为交互式、有序的审查流程。

变更会按符合逻辑的阅读顺序呈现，而不是原始文件顺序。发现的问题会显示在相关代码旁，供工程师检查并回应。

该 walkthrough 可以准备 GitHub 审查，但提交评论的责任仍由审查者承担。这一边界对问责至关重要。

这两项工具均可通过公开的安全技能仓库获取。它们加入了现有的变体分析、基于属性的测试和变异测试技能。

变体分析会在整个代码库中搜索缺陷的相关实例。基于属性的测试会检查生成输入下的行为，而不是只测试少数人工挑选的案例。

变异测试会有意修改代码，以观察测试套件能否捕捉错误行为。未被检测到的变异可能暴露缺失的断言或薄弱的覆盖率。

这些技术共同构成了一道验证阶梯。复现检查针对报告中的利用方式，而变体测试则挑战补丁对根本原因的覆盖程度。

回归测试保护预期行为。sanitizer 和模糊测试器则寻找预期案例之外的失败。

随后，变异测试评估这些测试是否能够发现有意义的错误。人工审查则评估设计、可维护性及自动化覆盖范围之外的风险。

这一工作流并不保证补丁安全。没有任何有限的测试套件能够证明不存在任何漏洞。

但它能够产出支持更可靠决策的工件。审查者可以看到此前哪些检查失败、当前哪些检查通过，以及哪些路径尚未测试。

这是 Trail of Bits 回应中最有力的部分。该公司将其方法论异议转化为其他团队能够评估的实践。

这些技能也暴露了这项批评的潜在弱点。它们的价值必须被衡量，不能仅因编码了合理程序就被视为理所当然。

博客文章所分析的 Patch the Planet 工作并未使用 post-patch-validation。因此，它对缺陷率的影响仍不得而知。

团队应测试它是否能捕捉已知的不完整修复、新植入的回归问题，以及所提供概念验证之外的缺陷。

他们还应衡量误报和审查时间。若验证工具产生过多噪声，可能只会转移瓶颈，而不会改善结果。

同样的标准也适用于 review-walkthrough。更好的呈现方式可以提升理解，但若解释有误，也可能制造缺乏依据的信心。

交互式叙述应辅助检查，而不是取代检查。审查者仍需访问完整 diff、测试、构建输出和项目上下文。

Trail of Bits 已提出了一个可证伪的方向。下一步是提供比较证据，说明每项技能能在多大程度上改善补丁质量和审查效率。

安全团队接下来应关注什么

这场争议将通过受控比较和可复现工件来解决，而不是靠选择一个更吸引人的标题百分比。

第一个信号是，1Password 或独立研究人员是否发布按条件划分的结果。读者需要看到按提示质量、工具访问权限、运行模式和推理强度分组的结果。

这种分析将揭示，在现实开发条件下，26% 的无瑕修复率是否仍然偏低。它还将显示哪些限制导致了最显著的下降。

按漏洞划分的结果同样重要，因为这六个目标差异很大。平均值可能掩盖智能体是否在特定语言、架构或漏洞类别上表现不佳。

研究人员还应同时报告阻断利用和修复根本原因的情况。前者衡量即时效用，后者衡量修复的完整性。

第二个信号是，专家对有争议评分进行复核。审查者应依据公开标准检查完全相同的补丁，并记录判断分歧所在。

这项工作应包括 Linux 的 off-by-one 案例、Chromium 的回调路径，以及 Trail of Bits 指出的 ActiveMQ 行为变更。

若复核确认存在广泛的评分错误，基准测试的标题性结论将被削弱。若与原始标签高度一致，则会削弱 Trail of Bits 的批评。

第三个信号是，对两项新技能进行受控评估。智能体应在有无验证工作流的条件下修复相同的漏洞。

比较应衡量无瑕修复、未解决的变体、引入的回归、审查者耗时，以及在被接受前所需的修订次数。

它还应纳入条件相当的纯人工团队和智能体辅助团队。没有这一基线，有关取代或优于开发者的主张就缺乏支持。

组织无需等到每项研究完成后再制定政策。他们现在就可以将补丁生成与补丁批准分开。

由 AI 生成的补丁应进入与陌生贡献者变更相同的审查系统。其来源既不应获得额外信任，也不应触发自动拒绝。

团队应保留漏洞报告、复现程序、智能体记录、补丁、验证命令和结果。这些工件使故障可被诊断，也让后续审计成为可能。

他们应在批准前要求提供根本原因说明。仅过滤所提供载荷的补丁应受到更严格审查。

高风险变更需要围绕身份验证、内存安全、密码学、解析器、访问控制和生命周期清理进行更广泛的检查。这些领域会严厉惩罚狭隘的修复方式。

构建内部审查系统的组织还可以维护一个可搜索的工程知识库，用于记录既往漏洞、被拒绝的补丁和反复出现的失效模式。

这类记录可以帮助审查人员识别跨代码仓库反复出现的错误，也能保留看似简单的修复方案为何被否决的原因。

不应把 1Password AI 补丁基准测试简化为“智能体四分之三时间都失败”的说法。其数据记录了真实且影响重大的修复失败。

也不应把 Trail of Bits 的批评简化为“智能体成功率达 86%”的说法。阻止一个提供的漏洞利用方式，比完成一次安全修复要容易得多。

有价值的结论介于这两个数字之间。AI 智能体能够产出有价值的补丁，但基准测试的设计和验证方式决定了这些补丁究竟意味着什么。

对于安全负责人而言，眼下的行动很明确：审查每项补丁指标背后的条件，然后在智能体实际将被使用的工作流中测试它们。

要问智能体能否完成编译、复现问题、探索变体并发现回归。接着还要问，专家是否审查了证据，而非仅仅相信一份看起来干净的 diff。

这一流程能比任何单一标题提供更好的决策依据。1Password AI 补丁基准测试真正的考验，在于其发现能否改进验证流程，同时不妨碍具备充分依据的自动化。