1Password 的 AI 修补基准测试具有误导性

Lobsters Hottest 新闻

摘要

Trail of Bits 批评 1Password 的 AI 修补基准测试由于实验设计缺陷而具有误导性,并发布了辅助补丁验证和审查的工具。

<p><a href="https://lobste.rs/s/qx8dxe/1password_s_ai_patching_benchmark_is">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/09/15 21:18

# "1Password的AI补丁基准测试存在误导性" 来源:https://blog.trailofbits.com/2026/09/15/1passwords-ai-patching-benchmark-is-misleading/ 1Password发布的有缺陷的报告(https://1password.com/blog/why-ai-generated-patches-still-require-human-review)(发布于2026年8月6日)为防御者描绘了一幅关于AI补丁的误导性图景。其标题声称模型仅在26%的情况下生成了干净的修复。该数据包含了故意指示智能体应用错误修复的实验,以及智能体无法编译或测试其补丁的实验。该报告可能会打击防御者使用可能帮助他们修复更多漏洞的技术的积极性,从而降低其工作效率。盲目相信其标题的团队可能会对可修复的漏洞置之不理。 我们希望我们的工作能帮助防御者修复更多漏洞。本文将分享来自我们的咨询项目和Patch the Planet计划中关于人类和智能体补丁质量的现实世界数据。我们还将发布两个智能体技能:后补丁验证(post-patch-validation)(https://github.com/trailofbits/skills/tree/main/plugins/post-patch-validation) 以帮助智能体测试修复,以及审查流程(review-walkthrough)(https://github.com/trailofbits/skills/tree/main/plugins/review-walkthrough) 以帮助工程师进行审查。 ## 该实验如何产生误导性标题 我们对1Password的代码和数据(https://github.com/Off-by-1-Labs/FLAWED/tree/2d3d15693b155873709bcf0daa247c2f0221d694)的审查发现了四项选择,使其26%的干净修复率成为对常规补丁工作的误导性指南。[^1] - **样本是针对困难修复挑选的。** 作者选择了六个漏洞,因为它们的修复很复杂。这些漏洞的干净修复率在3%到60%之间,因此平均值在很大程度上取决于哪些漏洞被列入了名单。[^2] - **两个提示指示智能体应用错误的修复。** 这些提示占了22%的数据。将它们与普通的修复尝试相结合,使得报告的比率在一定程度上取决于研究人员选择给予智能体错误建议的频率。 - **超过三分之一的试验禁止测试。** 一种评估模式禁止智能体构建或运行代码,占了36%的数据。该标题将这些试验与智能体可以测试其补丁并根据结果采取行动的实验混合在一起。 - **模型在不同的推理设置下运行。** GPT-5.5以中等努力程度运行,Opus 4.8则以高努力程度运行。这些是工具的默认设置。两个模型都没有在其最高可用设置下进行测试,作者也没有测量增加努力程度如何影响结果。 1Password的标题还掩盖了其自身数据中一个有用的结果。我们重新分析了补丁,并记录了随研究一起发布的测试结果,仅保留了智能体可以运行代码且未被指示应用错误修复的试验。**在这些试验中,1Password模型生成的3,067个补丁中有2,634个(86%)阻止了提供的漏洞利用。** 我们排除了该研究分类为咨询了上游修复的运行。阻止该漏洞利用并不能确定完全修复,但这些结果表明,在合理的工况下,该模型具有有用的补丁能力,而标题未能传达这一点。 指令和评分引入了进一步的问题,其中一些Davi Ottenheimer(https://www.flyingpenguin.com/disinformation-pushed-by-1password-ai-patching-report-is-false/)也曾指出: - **停止规则和评分标准不一致。** 被给予概念验证漏洞利用的智能体被指示一旦其修复击败了该利用就停止。然后,评分器评估了所提供的漏洞利用未触及的漏洞路径。 - **评分惩罚了预期的行为变更。** 智能体被告知不要修改现有测试,即使正确的修复可能需要更新测试以反映行为变化。我们发现8%的ActiveMQ裁决将预期的行为变更作为回归错误进行惩罚。 - **自动评分与人工审查不一致。** 模型对自己补丁的评分在65.9%的审查案例中与人工审查者在完整的五类结果上达成一致。在原始错误是否已修复方面的一致率为87.7%,在是否引入了新错误方面的一致率为70.5%。(表24 [^3]) - **更改审查者会改变结果。** 两个模型对36.8%的相同补丁给出了不同的结果。标题平均了他们的评估。(表20 [^4]) - **Linux参考修复包含一个漏洞。** 作者发现了248个生成的补丁,它们重复了上游修复中的一个差一错误。自动评分器仅在其中24个中捕获了这个新漏洞。(第4.4节 [^5]) - **Chromium评分器接受了不完整的修复。** 它将许多补丁标记为干净,尽管它们在回调中留下了一个释放后使用漏洞。(第4.9节 [^6]) 评分错误可能惩罚有效的修复,同时让有漏洞的补丁通过。结合精心挑选的样本和故意错误的指令,这些错误使得报告对其标题缺乏可信的依据。**防御者不应将1Password的标题比率认真视为衡量AI补丁能力的标准。** ## 开发者在理想条件下仍有八分之一的修复出错 理解智能体的失败也需要理解开发者提交不完整修复的频率。我们的安全咨询工作让我们详细记录了开发者如何修复自己软件中的漏洞。我们向客户提供详细的漏洞报告,然后进行“修复审查(https://github.com/trailofbits/publications)”,以检查他们提出的补丁是否完全解决了问题。我们的记录将每个漏洞与开发者提出的第一个修复以及我们对其是否有效的评估联系起来。它们保留了那些在问题被认为已解决之前被开发者修改的不成功尝试。 我们审查了2024年至2026年间236项Trail of Bits安全评估中,2,265个漏洞所提交的第一个修复。开发者维护着受影响的软件,拥有我们工程师的详细报告,并且知道我们将审查他们的补丁。即使在这些有利条件下,仍有283个第一次修复未能完全解决报告的问题:占12.5%,即八分之一。*显示第一次修复提交结果的图表* [图:显示第一次修复提交结果的图表] 考虑到同一评估中的多个修复,95%的置信区间是**10.5%到14.5%**。有时我们在非正式交谈中指出客户补丁中的错误,他们会在正式修复审查之前更正它。这些早期的失败可能永远不会出现在审查记录中,因此我们的数据可能低估了失败的第一次尝试。我们还排除了现有记录未能确定修复是否有效的情况。与智能体的直接比较需要相同的任务和工作条件。 ## 我们的补丁在真实项目中发生了什么 通过Patch the Planet(我们与OpenAI的联合倡议),Trail of Bits为广泛使用的开源项目共同撰写了数百个补丁(https://trailofbits.com/patch-the-planet/dashboard/)。智能体在工程师的指导和检查下编写补丁。然后项目维护者决定是合并、修改还是拒绝每个提交。 ## 维护者如何审查Patch the Planet补丁 我们检查了我们数据集中每个Patch the Planet提交的公开审查历史,这些提交在2026年9月14日前已被维护者合并或关闭:186个拉取请求。1Password的基准测试使用了六个因其修复复杂而被选中的漏洞。 维护者合并了我们186个拉取请求中的126个,接受率为67.7%。[^3] **在这126个拉取请求中,有91个(72.2%),维护者接受了我们最初提议的安全修复。** | 审查结果 | PR数 | 占已合并PR的百分比 | | :--- | :--- | :--- | | **已合并总数** | 126 | 100% | | 接受且未观察到安全相关修订 | 91 | 72.2% | | 接受但有安全相关修订 | 33 | 26.2% | | 不确定 | 2 | 1.6% | *表1:维护者对126个已合并的Patch the Planet拉取请求请求的更改。安全相关修订包括对提议修复的修补及其安全覆盖范围的扩展。* 维护者的接受并不意味着每个补丁都是正确的。维护者关闭了另外60个提交而未合并。大多数是被其他工作取代,或因政策、流程、范围或维护原因而被拒绝。有四个在技术上被明确拒绝。 | 关闭原因 | PR数 | 占已关闭PR的百分比 | | :--- | :--- | :--- | | **未合并而关闭总数** | 60 | 100% | | 被取代、重新实现或在别处重新提交 | 36 | 60.0% | | 政策、流程、范围或维护原因 | 14 | 23.3% | | 与另一个修复重复或趋同 | 3 | 5.0% | | 在技术基础上被明确拒绝 | 4 | 6.7% | | 其他或不确定 | 3 | 5.0% | *表2:维护者未合并而关闭60个Patch the Planet拉取请求的原因* 其中一个被关闭的提交是我们的freenginx补丁。 ## 一位维护者和一个智能体引入了相同的freenginx崩溃 1Password的案例研究考察了Patch the Planet对freenginx嵌入式Perl模块中一个内存安全漏洞的修复。一个智能体在Trail of Bits工程师的指导下编写了我们的补丁。它留下了一个有漏洞的代码路径未关闭,并在请求清理期间引入了一个新的崩溃。论文对我们补丁的批评是正确的。维护者关闭了我们的拉取请求(https://github.com/freenginx/nginx/pull/35)并提交了一个单独的修复(https://github.com/freenginx/nginx/commit/cf26435a029e75af7b0a2e8a26b1eefe445890c6)。该修复覆盖了所有三个有漏洞的代码路径,但在清理期间引入了相同的崩溃。论文也记录了维护者的回归错误。两位作者遇到了相同的陷阱。 原始漏洞允许Perl在freenginx使用它之前销毁一个回调。两个修复都保持了回调存活,以便freenginx可以稍后使用它。但如果请求首先超时,freenginx将使该请求不可用,然后释放该回调。释放它可能运行仍然试图使用该请求的Perl代码,导致工作进程崩溃。两位作者都忽略了他们的修复可能在清理阶段引发的问题。捕捉它需要超越原始漏洞,查看请求提前结束时发生的情况。两位作者,一位是人类,一位是智能体,分别独立工作,在同一个漏洞上犯了相同的错误。 决定是否使用智能体的读者需要知道它们的失败与人类开发者的失败相比如何。在可比条件下测量两者,才能确定哪个更可靠。 ## 我们检查了补丁合并后发生了什么 我们检查了Patch the Planet项目中大约33,500个后续提交。当后续提交更改了我们补丁修改过的文件时,我们调查了它是否修复了我们补丁引入的问题。对于每个可疑的回归,一个智能体尝试用概念验证来证明其影响。然后其他智能体和我们的工程师对发现进行了质疑。 审查发现了至少10个功能错误;4个构建、测试或发布自动化错误;以及1个性能错误。未发现可利用的安全漏洞。两个例子说明了我们发现的问题: - 在go-jose中,PR #240 (https://github.com/go-jose/go-jose/pull/240) 修复了一个缺失头部的崩溃,但暴露了一个现有的验证缺陷,即使密钥长度与声明的算法矛盾,也允许加密消息成功。PR #266 (https://github.com/go-jose/go-jose/pull/266) 在解密前增加了显式的密钥长度检查。 - 在Noble FROST中,PR #250 (https://github.com/paulmillr/noble-curves/pull/250) 在未首先检查重试是否包含相同的已认证记录的情况下,返回了缓存的第二轮结果。因此,更改或过时的重试数据可以绕过该检查。维护者通过在返回缓存结果之前根据原始记录验证重试,纠正了该行为(https://github.com/paulmillr/noble-curves/commit/27a2133d492f7ec355caf41a45d40a51f0edb9ad)。 我们正在将这项调查扩展到我们撰写的每个补丁,包括有维护者贡献的补丁。这些发现将帮助我们添加检查,在我们提交未来补丁之前捕获这些失败。 ## 用于更好安全补丁的智能体技能 我们随本文发布两个智能体技能:后补丁验证(post-patch-validation)(https://github.com/trailofbits/skills/tree/main/plugins/post-patch-validation),帮助智能体测试安全修复;以及审查流程(review-walkthrough)(https://github.com/trailofbits/skills/tree/main/plugins/review-walkthrough),帮助工程师审查代码变更。 后补丁验证(Post-patch-validation)是我们编写的一个新技能,旨在帮助智能体在提交补丁审查之前捕获不完整的修复和回归。它未用于上述描述的Patch the Planet工作。该技能从漏洞报告和补丁前后的代码开始。它引导智能体完成四项任务: - **重现原始错误。** 智能体编写一个检查,该检查必须在有漏洞的代码上失败,在补丁后的版本上通过。在两个版本上都通过的测试无法证明修复有效。 - **测试导致相同失败的另一条路径。** 该技能要求至少一个基于错误根本原因的独立变体,例如不同的调用者或清理路径。 - **检查回归和新漏洞。** 它比较应保持不变的行为,并测试修改代码周围的安全属性。该计划还必须包括项目测试、消毒器检查或有限的模糊测试运行。 - **将损坏的测试运行视为不确定。** 失败的构建或缺失的依赖项不得被误认为是漏洞已重现的证据。失败的检查为智能体提供了在提交补丁前需要调查和修复的具体问题。 该技能保存测试和结果,以便维护者可以看到检查了哪些内容。要尝试后补丁验证,请安装该技能 (https://github.com/trailofbits/skills/tree/main/plugins/post-patch-validation#installation) 并向您的智能体提供漏洞报告以及有漏洞和已修补的版本:“使用 post-patch-validation 验证 HEAD 中相对于 [有漏洞版本] 的补丁,使用 [漏洞报告路径] 中的漏洞报告。” 审查流程(review-walkthrough)(https://github.com/trailofbits/skills/tree/main/plugins/review-walkthrough) 帮助工程师审查他们负责合并的补丁。它将分支的完整差异转换为交互式演练,按逻辑阅读顺序解释变更。审查发现显示在相关代码旁边,工程师可以在那里检查它们并起草自己的评论。该演练还可以准备提交给GitHub的审查。按照快速入门指南(https://github.com/trailofbits/skills/tree/main/plugins/review-walkthrough#quick-start)为您的分支生成演练。 这些发布加入我们其他用于改进安全补丁的公共智能体技能: - 变体分析(variant-analysis)(https://github.com/trailofbits/skills/tree/main/plugins/variant-analysis) 帮助智能体在代码库的其他地方查找相关缺陷。 - 基于属性的测试(property-based-testing)(https://github.com/trailofbits/skills/tree/main/plugins/property-based-testing) 帮助它们跨生成的输入测试行为。 - 变异测试(mutation-testing)(https://github.com/trailofbits/skills/tree/main/plugins/mutation-testing) 帮助测试套件发现更多问题。 [^1]: https://blog.trailofbits.com/2026/09/15/1passwords-ai-patching-benchmark-is-misleading/#fn:1 [^2]: https://blog.trailofbits.com/2026/09/15/1passwords-ai-patching-benchmark-is-misleading/#fn:2 [^3]: https://1password.com/files/resources/frontier-models-vulnerability-patches-flawed.pdf#page=17 [^4]: https://1password.com/files/resources/frontier-models-vulnerability-patches-flawed.pdf#page=16 [^5]: https://1password.com/files/resources/frontier-models-vulnerability-patches-flawed.pdf#page=20 [^6]: https://1password.com/files/resources/frontier-models-vulnerability-patches-flawed.pdf#page=24 [^7]: https://blog.trailofbits.com/2026/09/15/1passwords-ai-patching-benchmark-is-misleading/#fn:3

相似文章

AI生成的安全漏洞补丁需要人工审查

Lobsters Hottest

Off-by-1 Labs(1Password)的研究发现,对于复杂且最近披露的漏洞,LLM生成的补丁有53.9%的概率存在缺陷,通常无法解决问题或引入新的漏洞。该研究强调AI生成的补丁需要人工审查,并发布了相关工具、数据集和论文。

AI Security Leaderboard:对模型鲁棒性进行基准测试 [P]

Reddit r/MachineLearning

作者介绍了AI Security Leaderboard,该排行榜通过让模型接受1500次自动化越狱尝试来评估前沿模型的鲁棒性,突出了各模型在安全性上的差距,并邀请社区就方法和后续步骤提供反馈。

你的 AI 代理修复了 Bug,但它还改了什么?

Lobsters Hottest

Trail of Bits 发布了 patching-bugs 和 regression-hunt 两个代理插件,用于标准化 Bug 修复开发流程和回归检查,其中 regression-hunt 比基线 Codex 代理的误报率低 25%。这项工作源自他们与 OpenAI 合作的 Patch the Planet 计划,该计划在 130 多个已合并的 PR 中发现了 21 个回归问题。