如何构建自己的漏洞利用框架
几周前，我们发表了针对[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`。
- 一名**猎手**代理针对每一类攻击进行尝试，试图破坏代码而非审核。
- 对抗性验证者尝试反驳每一个发现。
- 存活下来的结果将编写为一个人类可读的漏洞报告。
- 这些结果也会以`findings.json`的格式生成，并且一个机械检查将验证该文件。
- 最后，一名新代理独立重新验证每个发现。
- 生存下来的、重新验证的发现将提交至摄取 API。
这个初始技能几乎直接映射到后来的框架：
| 技能阶段 | 框架阶段 |
| --- | --- |
| 侦查代理编写 `architecture.md` | 侦查 |
| 猎手针对每一类攻击进行尝试 | 猎杀 |
| 验证者反驳发现 | 验证 |
| 生存结果形成报告 | 报告 |
| `findings.json` 由于符合规范的检查而非正确性被系统验证 | 发现中的行号和功能的机械验证 |
| 新代理重新验证发现 | 独立验证 |
因此，技能有效，但很快暴露出其局限性。根据覆盖度指标，单次运行仅发现大约一半的漏洞，而你跨越多次运行会捕捉到的漏洞。在我们的经验中，它发现的那些漏洞往往偏向于简单且不复杂的类型。当你的流程基本是“运行十次并手动差异化”时，你可能需要开始关注真正的框架。
在运行和微调技能时，我们遇到了三道墙：
- **上下文耗尽**：一个小时后，上下文窗口填满，模型会自行吞噬内存，瞬间忘记它花了整个上午追踪的漏洞。我们通过将状态完全外部化来打破这个瓶颈，将 LLM 视为一个无状态的计算引擎。
- **持久性**：运行中途崩溃意味着需要从头开始。因为一个 AI 速率限制错误或连接不稳定而失去数小时的工作是一种昂贵的方式来意识到你需要更好的架构。
- **跨代码库推理**：单个代码库的会话对消费它的应用之间的关系完全盲目，而在检查组件间接口时出现的漏洞数量可能超出预期。
**建议**：真正但极简的框架仅包括在数据库中存储的侦查、猎杀和验证阶段，以及一个无法提交自身发现的独立**验证者**。直到你有不止一个重要代码库时，应该完全跳过跨代码库追踪。直到你在噪声中积极淹没为止，请跳过专门的去重代理。先在你的开发环境中开始构建技能，让提示正常工作，只有在缺失导致你效率低下时才构建下一个架构阶段。
---
原文链接：[点击查看](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)
将局域的安全“技能”转变为持续、全舰范围的扫描管道，需要一种架构，将模型视为可互换的组件。始终依赖单一模型会在防御覆盖方面导致固有的限制，因为同一系统往往只能通过相同的视角来看待代码路径。为了解决这个问题，模型应该被频繁替换和交叉测试。通过在管道中更换模型——比如使用一种模型进行初步发现，而使用完全不同的模型进行验证——我们可以确保漏洞是由不同逻辑集交叉检查的。此外，真正的企业级框架必须超越孤立的代码库，以追踪跨代码库的依赖漏洞，最终将数千个原始候选项过滤到一个值得信赖、已分类的可操作修复队列中。
本文将实际探讨如何构建这一模型无关的层，重点关注我们如何管理状态控制、消除假阳性以及在规模上协调端到端的分类。
## 两个初步反对意见
首次发布中阐述了为什么通用编码代理无法完成此工作的理由。主要问题在于，代理一次只能持有一个假设，在覆盖真实代码库的一小部分后填充其上下文窗口，然后在上下文压缩过程中丢失信息。有关更多详细信息，请[阅读那篇文章](https://blog.cloudflare.com/cyber-frontier-models/)。在我们深入讨论之前，我们想要回答两个可能的问题。
**“为什么不使用子代理而使用框架？”** 子代理是有用的，且是个不错的起点。但是安全分析需要数百个独立的调查，这些调查在运行期间得以存续，不共享上下文窗口，并且可以稍后重新设定和交叉引用。它需要持久性、去重、可恢复性，最终需要整个舰队范围的依赖追踪。这是一个编排问题，而单一的提示无法达成此目的。
**“这篇博客文章只是对前沿模型的广告吗？”** 不是。我们的方法侧重于框架，而不是模型。在漏洞发现方面，我们使用目前最适合我们需求的任何前沿模型来执行。当我们将不同的模型指向相同目标时，每个模型会发现不同比例的漏洞。框架的部分是持久的。若要构建自己的系统，从第一天起就设计为模型无关。这将使你在选择模型时没有限制。
## 一切始于技能
我们从约450行的`security-audit`技能开始，在单个代码库上运行，并调整提示，直到我们发现实际的漏洞。后来，我们加入了成为整个系统管道的编排。真正的价值在于提示本身，我们的提示继续保留初始技能的攻击场景、漏洞类别和反模式检测，几乎没有改变。
该技能设计为在一个会话中运行7个阶段的审计：
- 三个并行的研究代理进行侦查并撰写`architecture.md`。
- 一名**猎手**代理针对每一类攻击进行尝试，试图破坏代码而非审核。
- 对抗性验证者尝试反驳每一个发现。
- 存活下来的结果将编写为一个人类可读的漏洞报告。
- 这些结果也会以`findings.json`的格式生成，并且一个机械检查将验证该文件。
- 最后，一名新代理独立重新验证每个发现。
- 生存下来的、重新验证的发现将提交至摄取 API。
这个初始技能几乎直接映射到后来的框架：
| 技能阶段 | 框架阶段 |
| --- | --- |
| 侦查代理编写 `architecture.md` | 侦查 |
| 猎手针对每一类攻击进行尝试 | 猎杀 |
| 验证者反驳发现 | 验证 |
| 生存结果形成报告 | 报告 |
| `findings.json` 由于符合规范的检查而非正确性被系统验证 | 发现中的行号和功能的机械验证 |
| 新代理重新验证发现 | 独立验证 |
因此，技能有效，但很快暴露出其局限性。根据覆盖度指标，单次运行仅发现大约一半的漏洞，而你跨越多次运行会捕捉到的漏洞。在我们的经验中，它发现的那些漏洞往往偏向于简单且不复杂的类型。当你的流程基本是“运行十次并手动差异化”时，你可能需要开始关注真正的框架。
在运行和微调技能时，我们遇到了三道墙：
- **上下文耗尽**：一个小时后，上下文窗口填满，模型会自行吞噬内存，瞬间忘记它花了整个上午追踪的漏洞。我们通过将状态完全外部化来打破这个瓶颈，将 LLM 视为一个无状态的计算引擎。
- **持久性**：运行中途崩溃意味着需要从头开始。因为一个 AI 速率限制错误或连接不稳定而失去数小时的工作是一种昂贵的方式来意识到你需要更好的架构。
- **跨代码库推理**：单个代码库的会话对消费它的应用之间的关系完全盲目，而在检查组件间接口时出现的漏洞数量可能超出预期。
**建议**：真正但极简的框架仅包括在数据库中存储的侦查、猎杀和验证阶段，以及一个无法提交自身发现的独立**验证者**。直到你有不止一个重要代码库时，应该完全跳过跨代码库追踪。直到你在噪声中积极淹没为止，请跳过专门的去重代理。先在你的开发环境中开始构建技能，让提示正常工作，只有在缺失导致你效率低下时才构建下一个架构阶段。
---
原文链接：[点击查看](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)
评论
暂无评论。