构建你自己的漏洞测试框架

# 构建你自己的漏洞检测框架 来源：https://blog.cloudflare.com/build-your-own-vulnerability-harness/ 2026\-06\-18 阅读时间 17 分钟 几周前，我们发布了关于 Project Glasswing（https://blog.cloudflare.com/cyber-frontier-models/）的初步发现，探讨了将前沿安全模型指向企业代码库时会发生什么。我们还探讨了我们的防御结构如何适应以保护我们的基础设施和客户免受前沿 AI 带来的威胁（https://blog.cloudflare.com/frontier-model-defense/）。自那以后，AI 生态系统继续快速变化——那些紧密围绕单个模型构建的开发者已经体验到了当该模型不再可用或被更强大的模型取代时会发生什么。这些市场变化只会强化我们的核心论点：无论底层模型在某一天处于领先地位，代理工作流的未来都不会存在于独立的模型、提示或单代理会话中。 从局部的安全“技能”转变为持续的全舰队扫描管道，需要一种架构，其中模型被视为可互换的组件。依赖单一模型本质上限制了防御覆盖范围，因为同一个系统倾向于完全通过相同的视角查看代码路径。为了应对这一点，应该频繁互换模型并进行交叉测试。通过在管道中变化模型——例如，使用一个模型进行初始发现，使用完全不同的模型进行验证——我们可以确保不同的逻辑集对漏洞进行交叉检查。此外，一个真正的企业级框架必须超越孤立的仓库，追踪跨仓库依赖项中的漏洞，最终将数千个原始候选结果过滤成一个可信、已分类的可操作修复队列。 本文作为构建该模型无关层的实用指南，重点介绍我们如何管理状态控制、消除误报以及大规模协调端到端分类。 ## 两个前置反对意见 第一篇文章论证了为什么通用编码代理无法完成这项工作。主要问题是代理一次只持有一个假设，在覆盖真实仓库的一小部分后就会填满上下文窗口，然后在上下文压缩期间丢失信息。更多详情，请阅读那篇文章（https://blog.cloudflare.com/cyber-frontier-models/）。 在我们继续之前，我们希望回答两个可能的问题。 **“为什么不用子代理代替框架？”**子代理很有用，并且是一个很好的起点。但安全分析需要数百项独立的调查，这些调查需要跨越多次运行而持续存在，不共享上下文窗口，并且可以在以后重新调整范围和交叉引用。它需要持久性、去重、可恢复性，最终还需要全舰队范围的依赖关系追踪。这是一个编排问题，提示无法解决。 **“这篇博客文章只是前沿模型的广告吗？”**不是。我们的方法以框架为中心，而不是模型。在漏洞发现方面，我们使用当时最适合我们需求的前沿模型来运行它。当我们把不同的模型指向同一目标时，它们各自发现了不同比例的漏洞。框架是持久的部分。如果你构建自己的系统，请从一开始就设计成模型无关。这将使你能够自由使用任何选择的模型，而不受限制。 ## 一切都始于一个技能 我们从大约450行的 `security-audit` 技能开始，在单个仓库上运行，并调整提示直到发现真正的漏洞。后来，我们添加了编排，成为整个系统的管道。真正的价值在于提示本身，我们的提示几乎未加改动地延续了初始技能的攻击者场景、漏洞类别和反模式检测。 该技能被编写为在一个会话中执行7阶段审计： - 三个并行研究代理进行侦察并编写 `architecture.md`。 - 每个攻击类别运行一个 **Hunter** 代理，试图破坏代码而不是审查代码。 - 对抗性验证器试图反驳每个发现。 - 幸存的结果被编写为人类可读的漏洞报告。 - 它们也按照模式以 `findings.json` 形式输出，并通过机械检查验证该文件。 - 最后，一个新的代理独立地根据源代码重新验证每个发现。 - 幸存、重新验证的发现被提交到摄入 API。 第一个技能几乎直接映射到后来的框架： **技能阶段** **框架阶段** 侦察代理编写 `architecture.md` Recon 侦察 猎人按攻击类别运行 Hunt 狩猎 验证器反驳发现 Validate 验证 幸存发现成为报告 Report 报告 `findings.json` 被机械检查以符合模式，而不是正确性 发现中行号和函数的机械验证 新代理重新验证发现 Independent validation 独立验证 这个技能有效，但很快暴露了其局限性。从覆盖指标来看，单次运行只能发现多次运行中捕获的漏洞的一半。根据我们的经验，它发现的漏洞倾向于更简单和不太微妙。一旦你的过程基本上是“运行十次然后手动对比差异”，你可能就需要考虑真正的框架了。 在运行和微调技能的过程中，我们遇到了三个障碍： - **上下文耗尽**：一小时后，上下文窗口填满，模型会蚕食自己的记忆，瞬间忘记它整个早上追踪的漏洞。我们通过完全外部化状态来打破这个瓶颈，将 LLM 视为无状态计算引擎。 - **持久性**：运行中途崩溃意味着从头开始。由于一次 AI 速率限制错误或连接不稳定而损失数小时的工作，是意识到你需要更好架构的极其昂贵的方式。 - **跨仓库推理**：单个仓库会话完全看不到使用它的应用程序之间的关系，当你检查组件之间的接口时浮现的漏洞数量可能比人们预期的要多。 **建议：**一个真正的最小框架仅包括存储在数据库中的 Recon、Hunt 和 Validate 阶段，以及一个单独的**Validator**（不能自行提交发现）。在你有多个重要的仓库之前，完全跳过跨仓库追踪。在你被噪音淹没之前，跳过专门的去重代理。从开发环境中的技能开始，让你的提示良好工作，只有当缺少某个架构阶段成为具体阻碍时，才构建下一阶段。 ## 将技能编纂为管道 大多数关于 AI 安全的技术文章都在讨论单个仓库或精心策划的基准测试；以这种方式运行整个舰队并进行跨仓库追踪，我们还没有在其他地方看到过。我们的代码库包含多种语言的巨大混合——Rust、Go、C、Lua、TypeScript 和 Python，以及各种配置管理系统、静态配置和各种额外的上下文。因此，我们必须想出一些对我们有效的新方案。从第一次斜杠命令运行到能够覆盖 128 个不同仓库、自动发现并询问相关依赖项的舰队扫描器，花费了大约六周时间。编纂主要是机械性的：我们将技能的每个阶段提升到自己的代理中，在其后面放置数据库，在前面放置编排器。映射几乎是直接对应的。 整个舰队在一个统一的框架上运行，无需针对每种语言进行调整，并追踪仓库之间的依赖关系。虽然将语法卸载给模型使得系统语言无关，但区别在于它能够追踪仓库*之间*的依赖关系。框架本身不关心它是在查看 C 指针还是 TypeScript 文件；它专注于安全编排的高层逻辑。这使我们能够跨数百个不同的代码库进行扩展，而无需编写自定义语言解析。 ## 两阶段漏洞研究工作流 我们的整个漏洞研究工作流建立在两阶段操作框架之上：**漏洞发现框架 (VDH)** 和**漏洞验证系统 (VVS)**。 VDH 作为我们的发现引擎，主动扫描代码库以发现潜在安全问题。一旦漏洞进入 VVS（允许多个框架向其中输入数据），它们将经历去重、判断和最终修复的阶段，我们稍后将讨论这些阶段。 我们在 VDH 中使用一种模型，但在 VVS 中使用完全不同的模型，因此模型实际上是在相互检查。这有一个明显的好处：通过强制模型 B (VVS) 判断模型 A (VDH) 的输出，你确保该发现由完全不同的逻辑权重和训练数据集评估——这个评估者充当公正、对抗的第三方，其唯一任务是无情地压力测试模型 A 的假设。在操作上，我们也受益于将模型提供者视为可互换的商品。模型提供者可以随时间改变温度、缓存和推理努力预算，甚至在同一模型版本内。我们的框架不是建立在依赖模型随时间稳定行为的基础上，而是设计为吸收下游波动而不会崩溃。 ## 阶段 1：漏洞发现框架 (VDH) 第一篇文章涵盖了每个代理/阶段的用途，因此我们将讨论它没有涉及的部分：阶段之间的粘合剂，以及决定一切是否有效的少数细节。 **Agent/Stage 代理/阶段** **Primary Role 主要角色** **Sub-agents / Tooling 子代理/工具** **Recon 侦察** 绘制目标架构图并映射潜在威胁向量 3 个并行的 Recon 子代理编写 `architecture.md` **Hunt 狩猎** 按类别运行攻击，编译片段，探测二进制文件 它会产生兄弟代理（这些代理根据模型不同处理舰队范围任务的 9% 到 20%）。它会联系并写入 Wishlist 工具。 **Validate 验证** 机械检查发现，然后对抗性地反驳它 分两遍运行：纯代码处理初始的模式/路径检查，然后一个单独的隔离代理在发现被提交之前尝试反驳它。 **Gapfill 填补空白** 为空的覆盖单元生成新的狩猎任务 为任何看起来仍然薄弱的（区域 × 攻击类别）单元加入新的狩猎任务 **Dedup 去重** 识别并合并重叠的发现 结合确定性代码和代理，按根本原因聚类发现，实时合并它们 **Trace 追踪** 遍历依赖图；生成消费者仓库任务 遍历图，在每个已识别的消费者仓库内添加狩猎任务，以确保跨仓库漏洞被捕获 **Feedback 反馈** 从已有的报告中学习并优化未来的运行 获取验证失败、浅层运行和反复遗漏，并立即重写队列中的提示，使未来的任务更精确。 **Report 报告** 生成人类可读报告 只是一个脚本，不需要模型 *表 1：漏洞发现框架 (VDH)* 第四到第八阶段作为一个持续的生产者-消费者循环运行。随着初始狩猎的进行，**Gapfill、Feedback** 和 **Trace 代理**会生成新任务；**Dedup** 将重叠的发现合并回一起，循环的其余部分继续消耗队列。这确保了在循环后期发现的漏洞仍然得到验证、报告，并与其他代码进行核对，以确保不包含相同的漏洞，所有这些都在同一运行中完成。 以这种方式拆分管道确保了严格的上下文控制。如果填满上下文窗口，模型就会开始产生幻觉。我们将每个代理的工作保持高度专注，使上下文使用量低于总窗口的 25%。一个天真的“*读取所有文件*”方法每次都会超过这个限制。 有一件事让我们措手不及：持久性需要在并行化之前考虑。你不想因为一个不可预见的错误而丢弃五小时的运行。每个阶段写入一个以 (`run_id`, `repo`, `stage`) 为键的 SQLite 数据库。任何阶段都可以恢复、重试或在不重做工作的情况下被拉入后续运行。发现结果在发生时即被流式传输并保存，因此崩溃只会损失正在处理的任务，而不会损失其他任务。 **建议：**有时瞬态 API 错误会作为文本出现在 (`200 OK`) 响应流中，而不是抛出代码异常。对编排器来说，这看起来完全像一个干净完成的任务。你必须显式地对响应文本进行分类，而不仅仅是信任异常类型，否则你最终会将空运行记录为成功。 ### 动态威胁建模 在 **Recon** 阶段，代理会编写威胁模型，而不是被提供一个。除了大约十个内置攻击类别（多种注入形式、内存损坏、协议解析、定时侧信道等），**Recon** 代理可以即时发明特定于仓库的类别，每个类别都有其自己的方法论。它会编写一个针对该代码库量身定制的自定义分类法，用于更严格地限定 **Hunter** 代理的范围。 仅阅读源代码不足以理解它在压力下的行为，尤其是对于 C 和其他低级语言中的微妙未定义行为漏洞。**Hunter** 代理超越代码阅读，过渡到主动执行。它们编译片段，构建小型版本，并攻击它们。质量的最大提升来自于给 **Hunter** 一个沙箱（基于 `unshare`）来使二进制文件崩溃。 **建议：**如果框架本身在 Docker 内部运行，该沙箱需要 `seccomp=unconfined` 和 `apparmor=unconfined`，否则它将静默失败而无法启动。这是一个一行代码的修复，可以为你节省一天的头疼时间，如果你不像我们一样是嵌套容器化的专家的话。 ### 微分叉和愿望清单 除了核心管道阶段，我们还添加了两个专门的机制，赋予 **Hunter** 相当大的自主权，以调整其焦点并请求外部资源，而不会干扰正在进行的分析： **兄弟分叉**：这有助于确保如果 **Hunter** 代理在超出当前范围的代码路径上偶然发现有趣的东西，它不会偏离轨道。它使用工具调用来分叉一个兄弟代理，并带有精确的结构种子。在整个舰队中，这大约占任务的 9%，尽管该比率高度依赖于模型——从接近零到大约五分之一，取决于哪个模型在狩猎。 **愿望清单**：当代理需要它没有的工具时（通常是 **Validator** 确认概念验证 (PoC)，或 **Hunter** 想要构建某些东西，比如特定的构建环境、虚拟机或一些生产配置文件），它会写入一个中央愿望清单。它提供足够的上下文，以便系统在人类提供依赖项后自动重新运行该确切任务。其中一些可以部分自愈：如果容器需要重建并进行一些更改，这可以在运行后自动发生，通过让一个通用的编码框架监控日志来实现。 自从添加愿望清单以来，它已在 128 个仓库中被写入 25,472 次，并且是代理向我们反馈的主要方式。在我们写这篇文章时，有一条记录是：“我需要一个 FreeBSD 虚拟机来端到端确认这个 PoC。” ### 全舰队跨仓库追踪 在初始清理之后，**Tracer** 代理检查不同软件组件是如何连接的。它寻找一条特定路径：潜在攻击者能否从外部向系统的脆弱部分发送有害输入？如果答案是肯定的，**Tracer** 代理会自动在消费者仓库内部生成新的狩猎任务。为了使其工作，你需要一个统一的跨仓库符号索引和准确的依赖关系图。