Trail of Bits 发布 patching-bugs 与 regression-hunt 两个智能体补丁插件

Trail of Bits：AI安全研究·2026-10-21 23:00· 2 小时前AI 评分62

你的 AI 智能体修复了这个 bug，但它还改动了什么？

AI 导读

Trail of Bits 发布 patching-bugs 和 regression-hunt 两个插件，让智能体代为开发补丁并检查回归，源自其与 OpenAI 合作的 Patch the Planet 计划。

正文 · 原文

今天我们发布 patching-bugs 和 regression-hunt，这两个插件让工程师可以把补丁开发和回归检查委托给智能体。我们的 patching-bugs 插件会复现已报告的 bug、开发修复并对其进行测试。regression-hunt 插件则检查任何改动是否会破坏此前正常工作且受支持的行为。工程师可以指导工作并审查结果；维护者可以提供自己的安全假设和补丁要求，使智能体在项目规则内工作。

我们通过 Patch the Planet 构建了 patching-bugs 和 regression-hunt，这是我们与 OpenAI 的联合计划，我们已为广泛使用的开源项目共同编写了数百个安全补丁。受我们在 Scapy 等项目上取得重大成功的激励，我们的插件基于我们对已合并补丁的分析以及我们工程师数千次 Codex 会话。

这些插件为维护者提供结构化的工作流程、证据、独立检查和最佳实践，以改善其补丁卫生。在我们的初步评估中，regression-hunt 产生的误报发现比被提示“审查 PR 是否有回归”的基线 Codex 智能体少 25%。

标准化补丁流程

我们九月的文章报告了我们的部分 Patch the Planet 补丁引入的回归。此后，我们审查了 Trail of Bits 工程师编写并由维护者合并上游的每一个补丁。审查确认了 130 多个已合并 PR 中的 21 个回归：16 个功能性问题、一个性能问题和四个构建/测试问题。没有一个破坏了安全防护。

（“回归”是指某项改动引入的新缺陷，它破坏了真实用户或攻击者可达路径上此前正确且受支持的行为。）

对于每个补丁，一个智能体会寻找潜在的回归，用概念验证（PoC）在改动前后运行来确认每一个回归，然后将结果交给工程师审查。

这次审查噪声很大：如今的漏洞披露以空前的速度和规模到来，为了让补丁跟上节奏，行业需要提高信噪比。21 个确认的回归是在单次运行中的 58 个候选中识别出来的（约 36% 精确率）。但由于智能体采取许多不同的方法并得出不同结果，每次运行都会产生更多需要人工筛选的候选。

这让我们得出两个结论：

1. 为了引入更少的回归，我们需要一种标准的补丁编写方式，每次都应用相同的检查。
2. 为了捕获我们仍然引入的回归，我们需要一种标准的检查方式，并明文规定什么算作回归。

将这两个步骤标准化还能让每次运行可重复、可比较。没有固定的检查清单能捕获所有回归，因此我们收集工程师补丁会话中的智能体轨迹，并用早期版本未能完成的任务来为下一个版本做基准测试（图 1）。

我们如何设计这些插件

我们使用两个主要来源来指导我们插件的设计：对我们在上游合并的每个补丁的审查，以及我们的工程师用来编写这些补丁的数千次 Codex 会话。

这引出了塑造我们的 patching-bugs 和 regression-hunt 插件的四项原则：

1. 尽可能少的话语提供有主见的指导。 我们给予智能体很大的自由度，只记录 Trail of Bits 对什么是好补丁和真实回归的判断。目标是以尽可能少的指导引导智能体走向期望的结果。
2. 模块化步骤。 你不必端到端地运行任一插件，因为两者都提供了多个技能，可以串联使用或单独使用。
3. 严格的输入和输出模式。 每一步都接收并返回一个定义好的模式，其中包括声明、代码修订、所需检查、原始证据和未决问题。固定的模式减少了运行间的可变性，并允许每一步验证上一步的工作，而不是信任其摘要。
4. 每个声明都有实时概念验证。 每个结论都依赖于针对实时部署运行的 PoC：一个已构建、运行中的项目实例，通过真实用户会使用的接口访问。在复现 bug、证明修复和确认回归时，如果某一步无法产生实时 PoC，其结果就是不确定的。

regression-hunt 降低误报率

regression-hunt 插件（图 2）：

1. 枚举候选回归，通过追踪更改的代码（diff）从其调用者到其真实接口。
2. 在系统的实时部署上复现每个候选回归。
3. 在全新上下文的智能体上，在实时部署上重放 PoC。
4. 评判所有先前步骤的结果，以验证证明满足回归的要求。

除了上述四项原则外，还有两个核心方面对插件至关重要：

1. 定义回归： 插件对什么是回归有强烈的意见，更重要的是，什么不是回归。举证责任被放在智能体上（特别是在“裁决智能体”步骤中），以证明有足够的证据表明疑似回归不是误报、不完整的修复、潜在 bug、预先存在的 bug 等等。只有当所有这些关卡都通过时，插件才会报告回归。
2. 纳入威胁模型： 如果威胁模型可用，编排器将有意将此文档作为全局上下文的一部分传递给每个单独的智能体步骤。这是为了要求每一步/智能体在得出结论之前回顾威胁模型。

我们对已合并 PR 的审查产生了一组 21 个确认的回归，我们可以用来评估 regression-hunt。我们使用整个集合将插件与一个被提示“审查 PR 的回归”的基线 Codex 智能体进行比较。

在这些运行中，regression-hunt 产生的误报比基线少 25%，置信区间为 14% 到 38%（95% 置信水平）。其严格的证据要求也导致一些已知回归被归类为“边缘”：插件识别出可能的回归，但未能收集到足够证据予以确认。因此，误报减少的代价是它能够有把握报告的已知回归数量有所下降。

接下来，我们将调查这些案例为何仍处于边缘状态，并改进插件收集证据的策略。我们的目标是确认更多真实回归，同时在证据仍不充分时向维护者提供更清晰的信息。

patching-bugs 汇集了来自数千次 agent 会话的最佳实践

patching-bugs 插件是对我们通过分析 Trail of Bits 工程师数千次 Codex 会话所识别出的所有最佳实践的提炼（图 3）。除了更传统的能力（例如在实时部署上复现和独立的对抗性审查）之外，该插件还强调：

1. 三臂证明：该证明对同一复现运行三种规格：原始代码必须失败，打补丁后的代码必须通过，而完全回退必须再次失败。通过移除补丁让 bug 重现，提供了更强有力的证据，表明是补丁——而非无关的环境或测试变更——真正修复了该 bug。
2. 不变量引导修复：补丁尝试修复被违反的底层安全不变量，而不是修复特定 bug。这有助于将补丁泛化到同一类 bug 的可能变体。
3. 纳入回归分析：插件强制要求运行 regression-hunt，以确保任何补丁都经过相同的标准流水线来检查错误。

插件的下一步

patching-bugs 和 regression-hunt 都将继续演进。我们的工程师目前正在他们的 Patch the Planet 工作中使用它们，我们正在收集有关它们如何被使用、哪些有效、哪些无效的数据。这些数据以及更好的评估将塑造下一版本的能力：

• 评估 patching-bugs。我们正在构建一项评估，衡量该插件的补丁是否修复了所报告的 bug 及其变体，且不引入回归。
• 从 agent 轨迹中学习。我们正在分析来自工程师会话的第一批轨迹级数据。它将显示 Codex 是否遵循每一步所需的规则和定义、跳过了哪些步骤，以及其证据最薄弱的环节。
• 让插件更可配置。patching-bugs 已经会读取项目自身的补丁指南（稍后会详细介绍）。接下来，我们希望维护者能够选择是最小化补丁集——或者在更广的覆盖范围值得更多误报时，放宽 regression-hunt 的规则以呈现更多候选。

这些插件编码了我们发现的、让 agent 正确修补 bug 的最佳实践，并且当你告诉它们你的项目如何运作时，它们会变得更好。

当你输入两类项目知识时，这些插件效果最佳：

1. 一份 THREAT_MODEL.md，它告诉智能体什么算作漏洞或回归。regression-hunt 插件会把它传给每一步，因此每个智能体都必须对照该文件检查自己的结论。它应当定义以下内容：哪些资产被攻陷会造成影响、信任边界、访问控制、受支持的配置、关于什么算或不算漏洞的规范，以及一份有效缺陷报告所需的证据（示例）。
2. 一份 PATCHING_GUIDELINES.md（或 AGENTS.md），它告诉智能体和 patching-bugs 你的项目希望如何编写修复。它应当概述如何构建和测试项目、修复的规模应该多大、修复应该放在哪里、如何呈现提议的更改，以及回归测试必须证明什么（示例）。

在我们与 GPAC 合作的 Patch the Planet 工作中，我们的工程师编写了一份威胁模型和项目专用的打补丁技能，其中记录了 GPAC 的维护者希望如何复现缺陷、修复需要哪些证据，以及补丁必须保留什么。Liboqs 和 validator.js 也已按照我们的指南发布了威胁模型。

这些文件对你的项目、代码约定和运作方式描述得越全面、越具体，你得到的输出就越好。

行业需要聚焦于打补丁

随着 AI 加速缺陷发现，我们需要同样迅速地把这些发现转化为可靠的修复。解决方案需要在速度和质量之间取得平衡：智能体需要理解一份报告，决定需要更改什么，并检查补丁是否修复了问题且没有引入回归。我们的 patching-bugs 和 regression-hunt 插件把我们从 Patch the Planet 中学到的经验带入这一工作流，帮助维护者从缺陷报告推进到可以放心审查和发布的补丁。

安装 patching-bugs 和 regression-hunt，向你的仓库添加一份 THREAT_MODEL.md 和一份 PATCHING_GUIDELINES.md，然后让它们处理你的下一份缺陷报告。把项目的上下文提供给这些工具，这样它们就能帮助你聚焦于正确的修复并更快地验证它。然后分享你的反馈，包括关于我们的默认设置在哪里不适合你的项目的意见。这些真实案例将帮助我们构建下一个版本。

来源：Trail of Bits：AI安全研究 · blog.trailofbits.com