Project Glasswing: Mythos 的启示

# Project Glasswing：Mythos 向我们展示了什么 来源：https://blog.cloudflare.com/cyber-frontier-models/ 2026-05-18 阅读时间：9 分钟 在过去的几个月里，我们一直在自己的基础设施上测试一系列专注于安全的大语言模型。这些大语言模型帮助我们识别自身系统中的潜在漏洞，以便我们进行修复——同时，它们也向我们展示了攻击者能够利用最新模型做到什么。 在这些大语言模型中，没有一个比 Anthropic 的 Mythos Preview 更受关注。几周前，我们受邀作为 Project Glasswing (https://www.anthropic.com/glasswing) 的一部分使用 Mythos Preview。我们很快将其指向了五十多个我们自己的代码仓库——以了解它能发现什么，以及它是如何工作的。 本文将分享我们的观察结果：模型做得好和不好的地方，以及围绕它们的架构和流程需要如何改变，才能使其得以大规模使用。 ## Mythos Preview 带来的变化 Mythos Preview 确实是向前迈进了一大步，在展开其他内容之前，值得明确说明这一点。我们已经使用各种模型分析我们的代码有一段时间了，而从之前通用前沿模型所能做到的，到如今 Mythos Preview 所能达到的水平，这种跃升不仅仅是前代作品的改良。 它是一种不同类型的工具，执行着不同类型的工作，这使得与早期模型进行清晰的同类比较变得困难。因此，与其试图将 Mythos Preview 与通用前沿模型进行基准测试，不如描述它实际能做什么更加有用，以及在我们使用 Mythos Preview 完成的工作中，有两个突出的特点： - **利用链构造** — 真正的攻击很少只使用一个漏洞。它将多个小的攻击原语链接成一个可工作的利用。例如，它可能将一个释放后使用漏洞转化为任意读写原语，劫持控制流，并使用面向返回编程（ROP）链来完全控制系统。Mythos Preview 能够获取这些原语中的多个，并推理如何将它们组合成一个可工作的验证。它在这个过程中展示的推理，看起来像是高级研究员的工作，而非自动扫描器的输出。 - **验证生成** — 发现漏洞和证明其可利用性是两码事，而 Mythos Preview 两者都能做到。它会编写能够触发疑似漏洞的代码，在沙盒环境中编译并运行该代码。如果程序的行为符合模型预期，这就是验证。如果不符合，模型会读取失败信息，调整假设，然后重试。这个循环与它发现的漏洞同样重要，因为一个没有工作验证的可疑缺陷只是猜测，而 Mythos Preview 自主地弥补了这一差距。 我们上面描述的一些特性并非 Mythos Preview 所独有。当我们通过同样的框架运行其他前沿模型时，它们也发现了相当数量的相同底层漏洞，并且在某些情况下，它们在推理方面也比我们预期的走得更远。它们不足的地方在于将这些碎片拼接起来。一个模型可能会识别出一个有趣的漏洞，写出关于它为何重要的深思熟虑的描述，然后就停止了，留下了未完成的利用链和未解决的可利用性问题。Mythos Preview 带来的改变在于，模型现在能够将这些低严重性漏洞（这些漏洞传统上会无声无息地躺在积压工作中）链接起来，形成单一的、更严重的利用。 ## 模型在合法漏洞研究中的拒绝行为 作为 Project Glasswing 一部分由 Anthropic 提供的 Mythos Preview 模型，并不具备普遍可用模型（如 Opus 4.7 或 GPT-5.5）中存在的额外安全措施。 尽管如此，该模型会自然地对某些请求产生抵触——就像使其用于漏洞挖掘的网络安全能力一样，该模型有其自身涌现的护栏，有时会导致其对合法的安全研究请求产生抵触。但正如我们发现的那样，这些自然的拒绝并不一致——同样的任务，以不同的方式表述或在不同的上下文中呈现，可能会产生完全不同的结果，如下面的例子所示。 *Mythos Preview 拒绝构建工作验证概念的示例* 例如，该模型最初拒绝在一个项目上进行漏洞研究，然后在项目环境发生一个无关更改后，又同意对相同的代码进行相同的研究。被分析的代码本身没有任何改变。在另一个案例中，模型发现并确认了代码库中的几个严重内存错误，然后拒绝编写演示利用。同样的请求，换一种表述方式，得到了不同的回答；甚至同样的请求，由于模型的概率性质，在不同运行中也可能产生不同结果。语义上等同的任务，根据如何以及何时呈现给模型，可能会产生相反的结果。 这一点很重要，因为虽然模型自然的拒绝/护栏是真实存在的，但它们本身并不够一致，无法作为完整的安全边界。这正是为什么未来任何普遍可用的、能力强大的网络前沿模型，必须在这些基础行为之上包含额外的安全措施——使其适合在像 Project Glasswing 这样的受控研究环境之外的更广泛使用。 ## 信号与噪声问题 对安全漏洞进行优先级排序最难的部分之一是判断哪些漏洞是真实的，哪些是可利用的，以及哪些需要立即修复。即使在 AI 出现之前的世界，这也是一个难题。AI 漏洞扫描器和 AI 生成的代码使情况变得更糟，而在 Cloudflare，我们构建了多个后期验证阶段来处理这个问题。 有两个因素主导着噪声率： - **编程语言** — C 和 C++ 允许直接内存控制，随之而来的是漏洞类型——缓冲区溢出、越界读写——而像 Rust 这样的内存安全语言在编译时就能消除这些漏洞。我们在内存不安全语言编写的项目中观察到的一致更高的误报率。 - **模型偏差** — 优秀的人类研究员会告诉你他们发现了什么以及他们的信心程度。模型不会。让模型寻找漏洞，它就会找到，无论代码中是否真的有漏洞。发现结果中充斥着“可能”、“潜在”、“理论上可以”等含糊措辞，而含糊其辞的发现数量远远超过可靠发现的。对于一个探索性工具来说，这种偏差是合理的。但对于一个优先级排序队列来说，这是灾难性的，因为每一个推测性的发现都会消耗人力时间和 tokens 来排除，并且这种成本会随着数千个发现的累积而剧增。 Mythos Preview 在这方面有了明显的改进，尤其是在它链接原语的能力上——将多个漏洞组合成一个可工作的验证概念，而不是孤立地报告它们。一个附带 PoC 的发现是你能够采取行动的发现，这意味着花费在问“这到底是不是真的？”上的时间大大减少了。 我们的工具框架故意调高以过度报告，这样我们能看到更多（并且错过更少），但这伴随着更多的噪声。但在优先级排序时，Mythos Preview 的输出质量明显更高：含糊的发现更少，复现步骤更清晰，到达修复或驳回决策所需的工作更少。 ## 为什么将通用编码代理指向一个仓库行不通 当我们去年首次开始 AI 辅助的漏洞研究时，我们的本能反应很直接：将一个通用编码代理指向任意一个仓库，并让它去发现漏洞。这种方法有效，因为模型会产生发现，但它无法有效覆盖一个真实的代码库并识别有价值的发现。主要有两个原因： - **上下文** — 编码代理针对单一专注的工作流进行了调优：构建一个功能、修复一个漏洞、编写一次重构。它们会摄入大量源代码，每次持有一个假设，并迭代处理。这与漏洞研究的形态完全相反，漏洞研究本质上是狭窄且并行的。人类研究员会选择一件具体的事情去查看，并彻底调查。这一件事情可能是一个单一复杂功能、跨安全边界的转换，或者是一个特定的漏洞类别，比如输入未经充分审查导致的注入问题，攻击者输入最终作为 shell 命令执行。然后他们再为不同的功能、安全边界或漏洞类别重复这个过程，在代码库中进行数千次。一个单一的代理会话（即使带有子代理）针对一个十万行的仓库，可能只能以有用的方式覆盖大约千分之一的攻击面，然后模型上下文窗口就会填满，压缩开始——可能会丢弃之前本应重要的发现。 - **吞吐量** — 单流代理一次只做一件事，但真实的代码库需要同时针对许多组件提出许多假设，并且当有趣的事情出现时能够进一步展开。你可以更努力地驱动单个代理，但在某个时刻，限制因素不再是模型本身，而是交互的形态本身。在编码代理中直接使用模型，对于当研究员已经有一个线索并想要第二双眼睛时进行手动调查是好的。然而，对于实现高覆盖率来说，它是错误的工具。一旦我们接受了这一点，我们就不再试图让 Mythos Preview 做错误的工作，而是开始围绕它构建工具框架。 ## 工具框架实际上解决了什么 从大规模运行工作中得出了四个教训，每一个都指出了需要一个管理整体执行的工具框架： - **狭窄范围产生更好的发现** — 告诉模型“在此仓库中查找漏洞”会让它漫无目的。告诉它“在此特定函数中查找输入未经充分审查导致的注入，这是它上面的信任边界，这是架构文档，这是该区域之前的覆盖范围”，会让它做一些更接近研究员实际会做的事情。 - **对抗性审查减少噪声** — 在初步发现和队列之间添加第二个代理——它使用不同的提示、不同的模型，并且没有能力生成自己的发现——可以捕捉到第一个代理在检查自己工作时可能遗漏的大量噪声。事实证明，让两个代理处于故意的分歧状态，比仅仅告诉一个代理要小心有效得多。 - **跨代理拆分链产生更好的推理** — 询问“这段代码有缺陷吗？”和“攻击者能从系统外部实际到达这个缺陷吗？”是两个不同的问题，模型在分别回答每个问题时表现更好，因为每个问题都比组合版本更狭窄。 - **并行的狭窄任务胜过单一的详尽代理** — 当许多代理在严格限定范围的问题上工作，并且我们随后对结果进行去重时，覆盖率会提高，而不是要求一个代理做到详尽。 以上每个观察都关乎模型行为，它们共同描述了一个不再是聊天界面的东西。这是一个帮助你实现最终结果的工具框架。构建工具框架的第一步很简单，因为你可以让模型帮忙，我们就是这么做的。我们使用了 Mythos Preview 来构建、定制和改进我们最初的工具框架，以发挥其优势。下面描述了一个工具框架在实践中的示例。 ## 我们的漏洞发现工具框架 以下是我们漏洞发现工具框架的逐步描述。它被用于扫描我们运行时、边缘数据路径、协议栈、控制平面以及我们所依赖的开源项目中的实时代码。 | **阶段** | **作用** | **为何重要** | | :--- | :--- | :--- | | **侦察** | 一个代理从上到下阅读仓库，展开到负责每个子系统的子代理，并生成一份涵盖构建命令、信任边界、入口点和可能攻击面的架构文档。它还会为下一阶段生成初始任务队列。 | 为所有下游代理提供共享上下文。减少漫无目的的问题。 | | **狩猎** | 每个任务是一个攻击类别配上一个范围提示。狩猎者（实际寻找漏洞的代理）并发运行，通常一次约五十个，每个展开到少量探索子代理。每个狩猎者都可以访问工具，这些工具可以在每个任务的沙盒目录中编译和运行验证概念代码。 | 这是大部分工作发生的地方。许多狭窄任务并行，而不是一个详尽的代理。 | | **验证** | 一个独立的代理重新阅读代码，试图反驳最初的发现。它使用不同的提示，并且没有能力自行发出新发现。 | 捕捉到狩猎者在审查自己工作时不会捕捉到的显著比例的噪声。 | | **补缺** | 狩猎者标记他们接触过但未彻底覆盖的区域。这些区域被重新加入队列进行下一轮扫描。 | 抵消模型倾向于转向它已经取得成功的攻击类别的趋势。 | | **去重** | 共享同一根因的发现合并为一个记录。 | 变体分析是一个特性，而不是膨胀队列重复项的方式。 | | **追踪** | 对于共享库中的每个确认发现，一个追踪代理展开（每个消费者仓库一个实例），使用跨仓库符号索引，判断攻击者控制的输入是否实际从系统外部到达该漏洞。 | 将“存在缺陷”转化为“存在可触及的漏洞”。这是最重要的阶段。 | | **反馈** | 可触及的追踪结果成为漏洞实际暴露的消费者仓库中的新狩猎任务。 | 闭环。管道在运行中不断改进。 | | **报告** | 一个代理根据预定义的模式编写结构化报告，自行修复任何针对该模式的验证错误，并将报告提交到接收 API。 | 输出是可查询的数据，而不是自由形式的散文。 | ## 这对安全团队意味着什么 其他安全领导者对 Mythos Preview 最强烈的反应是关于速度——扫描更快、修补更快、压缩响应周期。我们交谈过的不止一个团队现在正在以两小时内从 CVE 发布到生产环境修补的 SLA 运作。这种直觉是可以理解的：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但更快是不够的，我们认为很多团队即将花费大量时间、精力和金钱，并会通过艰难的方式学到这一点。 修补得更快并不会改变产生修补程序管道的形状。如果回归测试需要一天时间，你就无法在不跳过它的情况下达到两小时的 SLA，而你在跳过回归测试时发布的漏洞，往往比你要修补的漏洞更糟糕。当我们尝试让模型编写自己的修补程序时，我们学到了一个版本的经验：我们看到一些修补程序出去了，它们修复了原始漏洞，却悄悄地破坏了代码依赖的其他东西。 更难的问题是围绕漏洞的架构应该是什么样的。原则是让攻击者即使存在漏洞也更难利用，这样从漏洞披露到被修补之间的间隙就不那么重要了。这意味着要在应用程序前面设置防御措施，阻止漏洞被触及。这意味着要设计应用程序，使得代码中某一处的缺陷不能赋予攻击者访问其他部分的能力。这意味着能够在同一时刻将修复程序部署到代码运行的每一个地方，而不是等待各个团队来部署。 我们也认识到这个话题是双向的。同样帮助我们找到自身代码漏洞的能力，在坏人手中，将会加速攻击。