构建您自己的漏洞利用工具

构建您自己的漏洞利用工具 2026-06-18 Dan Jones Alexandra Godoi Grant Bourzikas 阅读 17 分钟 几周前，我们发布了 Glasswing 项目的初步发现，看看当您将前沿安全模型指向企业代码库时会发生什么。我们还探讨了我们的防御结构如何适应以保护我们的基础设施和客户免受前沿人工智能构成的威胁。从那时起，人工智能生态系统继续快速变化——紧密围绕单一模型构建的开发人员已经经历过当该模型不再可用或被更强大的模型取代时会发生什么。这些市场变化只会强化我们的核心论点：无论哪一天的底层模型处于领先地位，代理工作流程的未来都不会在独立模型、提示或单代理会话中找到。从本地化的安全“技能”转向连续的、整个车队范围的扫描管道需要一种将模型视为可互换组件的架构。依赖单一模型本质上限制了防御范围，因为同一系统往往会通过完全相同的镜头来查看代码路径。为了解决这个问题，模型应该经常互换和交叉测试。通过改变整个管道的模型（例如使用一个模型进行初始发现，使用完全不同的模型进行验证），我们可以确保通过不同的逻辑集交叉检查漏洞。此外，真正的企业级利用必须超越孤立的存储库来跟踪跨存储库依赖项的漏洞，最终将数千个原始候选者过滤到一个可信的、经过分类的可操作修复队列。这篇文章实际探讨了如何构建与模型无关的层，重点关注我们如何管理状态控制、消除误报以及大规模协调端到端分类。前面有两个反对意见 第一篇文章阐述了为什么通用编码代理无法完成这项工作。主要问题是代理一次只持有一个假设，在覆盖一小部分真实存储库后填充上下文窗口，然后在上下文压缩期间丢失信息。有关更多详细信息，请阅读该帖子。在我们继续之前，我们想回答两个可能的问题。 “为什么不使用子代理而不是安全带呢？”子代理很有用，并且是一个很好的起点。但安全分析需要数百个独立的调查，这些调查可以在运行中生存，不共享上下文窗口，并且可以在以后重新确定范围和交叉引用。它需要持久性、重复数据删除、可恢复性，以及最终的舰队范围的依赖性跟踪。这是一个编排问题，提示无法帮助您实现这一目标。 “这篇博文只是前沿模特的广告吗？”不。我们的方法集中于线束，而不是模型。当涉及到漏洞发现时，我们会使用当前最适合我们需要的前沿模型来运行它。当我们将不同的模型指向同一目标时，它们各自会出现不同比例的错误。安全带是持久的部分。如果您构建自己的系统，请从第一天起将其设计为与模型无关。这将使您可以不受限制地自由使用任何选择的模型。这一切都始于一项技能，我们从在单个存储库上运行的约 450 行安全审核技能开始，并调整提示，直到发现真正的错误。后来，我们添加了编排，成为整个系统的管道。真正的价值在于提示本身，我们的提示继续承载初始技能的攻击者场景、错误类别和反模式检测，几乎没有变化。该技能的编写目的是在一次会话中运行 7 阶段审计：三个并行研究代理进行侦察并编写架构.md 。一名 Hunter 代理针对每类攻击运行，试图破坏代码而不是对其进行审查。对抗性验证者试图反驳每一个发现。幸存者被写成人类可读的漏洞报告。它们还根据模式作为 discovery.json 发出，并通过机械检查验证该文件。最后，一名新特工独立地根据来源重新验证每项发现。幸存的、重新验证的结果将提交给摄取 API。第一个技能几乎直接映射到后来的工具： 技能阶段 工具阶段 侦察代理编写架构.md 侦察猎人在每个攻击类中运行 狩猎验证器反驳结果 验证幸存的发现成为报告 报告结果.json 被机械检查以确保架构符合性，而不是正确性 对结果中的行号和功能进行机械验证 新代理重新验证发现 独立验证 该技能有效，但很快就暴露了其局限性。查看覆盖率指标，单次运行只能发现多次运行中发现的错误的大约一半。根据我们的经验，它确实发现了一些更简单、更不微妙的内容。一旦你的流程基本上“运行它