教你自制漏洞检测框架

背景

几周前，我们通过 Project Glasswing 发布了初步发现，探讨了将前沿安全模型应用于企业代码库时会发生什么，以及我们的防御结构如何适应以保护基础设施和客户免受前沿 AI 带来的威胁。自那以后，AI 生态系统持续快速变化——那些紧密围绕单一模型构建的开发团队已经亲身体验到，当该模型不再可用或被更强大的模型取代时会发生什么。这些市场变化进一步强化了我们的核心论点：无论底层模型在某个时间点如何领先，智能体工作流的未来不会存在于独立的模型、提示词或单智能体会话中。

核心内容

从局部安全“技能”到全舰队扫描流水线

从局部的安全“技能”转向持续的全舰队扫描流水线，需要一种将模型视为可互换组件的架构。依赖单一模型本质上会限制防御覆盖面，因为同一系统会倾向于通过完全相同的视角审视代码路径。为了应对这一点，模型应频繁互换并进行交叉测试。通过在整个流水线中变化模型——例如，使用一个模型进行初步发现，使用完全不同的模型进行验证——可以确保漏洞被不同的逻辑集交叉检查。此外，一个真正的企业级框架必须超越孤立仓库，追踪跨仓库依赖关系中的漏洞，最终将数千个原始候选结果过滤为一个可靠、分诊的可操作修复队列。

本文旨在提供一个实践视角，说明如何构建该模型无关层，重点介绍我们如何管理状态控制、消除误报，以及在大规模下协调端到端的分诊。

两个预先的反对意见

第一篇文章已经解释了为什么通用编码智能体无法胜任这项工作。主要问题在于：智能体一次只持有一个假设，在覆盖真实仓库的一小部分后就会填满上下文窗口，随后在上下文压缩期间丢失信息。更多细节请参考那篇文章。

在继续之前，我们想回答两个可能的问题。

“为什么不用子智能体代替框架？” 子智能体是有用的，也是很好的起点。但安全分析需要数百次独立的调查，这些调查需要跨运行持久存在，不共享上下文窗口，并且可以在后期重新定范围和交叉引用。它需要持久性、去重、可恢复性，以及最终的舰队级依赖追踪。这是一个编排问题，提示词无法解决它。

“这篇博客文章只是前沿模型的广告吗？” 不是。我们的方法核心是框架，而非模型。在漏洞发现方面，我们使用当前在所需任务上表现最佳的任何前沿模型。当我们将不同模型指向同一目标时，它们各自会找出不同份额的错误。框架才是持久的组件。如果你构建自己的系统，请从一开始就设计为模型无关。这将使你能够自由选择任何模型，不受约束。

一切都始于一个技能

我们从一条约450行的安全审计技能开始，在单个仓库上运行，并调整提示词直到发现真正的错误。后来，我们添加了编排，这成为了整个系统的管道。真正的价值在于提示词本身，我们的提示词几乎原封不动地保留了初始技能的攻击场景、错误类别和反模式检测。

该技能被设计为在一个会话中执行7阶段审计：

• 三个并行研究智能体进行侦察并编写 architecture.md。
• 一个 Hunter 智能体按攻击类别运行，试图破坏代码而非审查它。
• 对抗性验证器试图反驳每个发现。
• 幸存者被编写为人类可读的漏洞报告。
• 它们也按照模式以 findings.json 形式输出，并通过机械检查验证该文件。
• 最后，一个新的智能体独立地对照源码重新验证每个发现。
• 幸存且经过再验证的发现被提交到摄取 API。

该第一个技能几乎直接映射到后来的框架：

| 技能阶段 | 框架阶段 | | --- | --- | | 侦察智能体写 architecture.md | 侦察 | | Hunter 按攻击类别运行 | 狩猎 | | 验证器反驳发现 | 验证 | | 幸存发现成为报告 | 报告 | | 机械检查 findings.json 的模式合规性（而非正确性） | 发现中行号和函数的机械验证 | | 新智能体重新验证发现 | 独立验证 |

技能暴露的三个瓶颈

技能有效，但很快就暴露了局限性。从覆盖率指标来看，单次运行只能发现约一半的错误（多轮运行才能捕获更多的错误）。根据我们的经验，单次找到的错误偏向于更简单、更不微妙的。一旦你的流程基本上是“运行十次然后手动 diff”，你可能就需要开始考虑一个真正的框架了。

在运行和微调技能的过程中，我们遇到了三堵墙：

• 上下文耗尽：一小时后，上下文窗口填满，模型会蚕食自己的记忆，瞬间忘记它花了一上午追踪的错误。我们通过完全外部化状态、将 LLM 视为无状态计算引擎来打破这个瓶颈。
• 持久性：运行中途崩溃意味着重新开始。由于一次 AI 速率限制错误或网络不稳定而丢失数小时的工作，是非常昂贵的方式，让人意识到需要更好的架构。
• 跨仓库推理：单次仓库会话完全无视消费它的应用程序之间的关系，而在检查组件之间的接口时浮现的错误数量可能比预期的要多。

建议：一个真正但最小化的框架仅由存储在数据库中的侦察、狩猎和验证阶段组成，加上一个不能自行提交发现的独立验证器。在你有多个重要的仓库之前，完全跳过跨仓库追踪。跳过专门的去重智能体，直到你被噪声淹没。从开发环境中的一个技能开始，让你的提示词运行良好，只有当缺少某个架构阶段确实成为瓶颈时，才构建下一个阶段。

将技能编纂为流水线

该领域大多数 AI 安全文章都涉及单个仓库或精心策划的基准测试；像这样对整个舰队进行跨仓库追踪运行，我们还没有在其他地方看到过。我们的代码库混合了大量语言——Rust、Go、C、Lua、TypeScript 和 Python，以及各种配置管理系统、静态配置和所有其他上下文。所以我们不得不提出适合我们的新方法。从首次斜杠命令运行到覆盖 128 个不同仓库的舰队扫描器，自动查找和询问相关依赖项，花了大约六周时间。编纂过程大多是机械的：我们将技能的每个阶段提升为独立的智能体，在其背后放一个数据库，在其前面放一个编排器。映射几乎是1:1的。

整个舰队在一个统一的框架上运行，没有针对每种语言进行调整，并追踪仓库之间的依赖关系。将语法卸载给模型使系统语言无关，其差异化能力在于追踪仓库间的依赖关系。框架本身不关心它是在看 C 指针还是 TypeScript 文件；它专注于安全编排的高级逻辑。这使我们能够跨数百个不同代码库进行扩展，而无需编写自定义语言解析。

两阶段漏洞研究工作流程

我们的整个漏洞研究工作流程建立在两阶段操作框架之上：漏洞发现框架（VDH）和漏洞验证系统（VVS）。

VDH 充当我们的发现引擎，主动扫描代码库以发掘潜在的安全问题。VVS 则负责对 VDH 发现的候选漏洞进行独立验证、去重和分诊，确保只有经过严格验证的高置信度漏洞才会被报告。

关键要点

• 模型无关性是核心架构原则：未来的智能体工作流不应绑定到单一模型，而应将模型视为可互换组件，能够灵活切换以应对市场变化。
• 技能到流水线的映射：从450行的单仓库安全审计技能开始，几乎一对一映射到多阶段框架（侦察、狩猎、验证、报告、机械验证、独立验证），但需要解决上下文耗尽、持久性和跨仓库推理三个关键瓶颈。
• 外部化状态是关键：将LLM视为无状态计算引擎，通过数据库持久化状态，避免上下文窗口填满导致的遗忘，并支持中断恢复。
• 先简单后复杂：建议从最小框架开始（仅含侦察、狩猎、验证并存入数据库），跳过跨仓库追踪和去重智能体，直到实际需要时再添加。
• 跨仓库依赖追踪是差异化优势：统一框架无需为每种语言定制解析，通过模型处理语法，专注于安全编排逻辑，能覆盖上百个不同语言的代码库。
• 两阶段工作流（VDH + VVS）：发现引擎与验证系统分离，确保漏洞发现后经过独立验证和分诊，提高结果可信度。

意义与影响

本文提供了一种构建企业级 AI 安全扫描系统的实用蓝图，打破了依赖单一模型的传统思路。其核心意义在于：

• 应对模型快速迭代的现实：当前AI模型市场变化频繁，模型无关架构使安全系统能够快速适应，无需