Project Glasswing：Mythos 教会我们的事
Project Glasswing：Mythos 教会我们的事
过去几个月，我们一直在自家基础设施上测试一系列安全专用大语言模型。这些模型帮助我们识别自身系统的潜在漏洞，从而修复它们——同时，它们也向我们展示了攻击者借助最新模型能做什么。
在这些模型中，最引人注目的莫过于 Anthropic 的 Mythos Preview。几周前，我们受邀作为 Project Glasswing 的一部分使用 Mythos Preview。我们将它指向了我们自己的五十多个代码仓库——看看它能发现什么，也看看它是如何工作的。
本文分享了我们的观察：哪些方面做得好、哪些做得不够，以及围绕它们的架构和流程需要如何改变，才能实现规模化使用。
Mythos Preview 带来了什么改变
在深入其他内容之前，有必要先坦率地说：Mythos Preview 确实是真正意义上的进步。我们运行模型分析代码已经有一段时间了，从之前通用前沿模型能做什么，到如今 Mythos Preview 能做什么，这中间的跨越绝非简单的改进。
这是一种不同种类的工具，在做一种不同种类的工作——这使得它与早期模型之间难以进行干净的同类比较。因此，与其尝试对 Mythos Preview 进行基准测试，不如描述它实际能做什么，以及我们使用过程中脱颖而出的两个特性：
漏洞利用链构建——真正的攻击很少只用一个漏洞。它把多个小的攻击原语串联成一个可工作的利用。例如，它可能把一个释放后使用（use-after-free）漏洞转化为任意读写的原语，劫持控制流，并使用面向返回的编程（ROP）链完全控制系统。Mythos Preview 可以拿多个这样的原语，推理如何将它们组合成一个可行的概念验证。它在这个过程中展现的推理能力，看起来像资深研究者的工作，而非自动化扫描器的输出。
概念验证生成——发现漏洞和证明漏洞可被利用是两回事，而 Mythos Preview 两者都能做。它会编写能触发可疑漏洞的代码，在沙箱环境中编译并运行。如果程序行为符合模型预期，那就是证明。如果没有，模型会读取失败信息，调整假设，再试一次。这个循环和它找到的漏洞同样重要——因为一个没有可行证明的可疑缺陷只是猜测，而 Mythos Preview 能自行弥合这个差距。
我们上面描述的某些能力并非 Mythos Preview 独有。当我们把其他前沿模型放入同样的测试框架时，它们也能发现相当数量的底层漏洞，有时在推理方面也比我们预期的更进一步。它们的短板在于把碎片拼接起来。一个模型会识别出有趣的漏洞，写出深思熟虑的描述说明为什么重要——然后停下来，实际的利用链条未完成，可利用性的问题悬而未决。Mythos Preview 的突破在于，模型现在能把这些低严重性漏洞（传统上会悄无声息地沉睡在 backlog 里）串联成单个更严重的漏洞利用。
模型在合法漏洞研究中的拒绝行为
Anthropic 提供作为 Project Glasswing 一部分的 Mythos Preview 模型，不具备公开发布模型（如 Opus 4.7 或 GPT-5.5）所具备的额外安全防护。
即便如此，模型仍会自发地拒绝某些请求——就像它在漏洞挖掘方面的网络能力一样，模型也有自己涌现的护栏。这些护栏有时会导致它拒绝合法的安全研究请求。但正如我们的发现，这些自发的拒绝并不一致——同样的任务，换种方式提出来或放在不同的上下文中，可能产生完全不同的结果，如下面的例子所示。
例如，模型最初拒绝了对一个项目做漏洞研究，然后在项目环境发生一个无关变更后，却同意对同一代码做同样的研究。被分析的代码本身没有丝毫变化。在另一个案例中，模型发现并确认了一个代码库中多个严重的内存漏洞，然后拒绝编写演示用的利用代码。同样的请求，换个问法得到不同的答案，甚至同一个请求在不同运行中也可能产生不同结果——因为模型本质上具有概率性。
这很重要，因为尽管模型的自发拒绝/护栏是真实存在的，但它们不够一致，无法单独作为完整的安全边界。这也正是为什么任何在未来公开发布的有能力的网络前沿模型，都必须在这一基础行为之上增加额外的安全防护。
信噪比问题
分类安全漏洞最困难的部分之一，是判断哪些漏洞是真实的、哪些是可利用的、哪些需要立即修复。即使在 AI 之前的世界里，这也是个难题。AI 漏洞扫描器和 AI 生成的代码让情况变得更糟——在 Cloudflare，我们构建了多个后验证阶段来应对这个问题。
有两个因素主导了噪声率：
编程语言——C 和 C++ 给你直接的内存控制权，也带来了一系列漏洞类型——缓冲区溢出、越界读写——而 Rust 等内存安全语言在编译时就能消除这些问题。我们从内存不安全语言编写的项目中看到持续更多的误报。
模型偏差——优秀的人类研究者会告诉你他们发现了什么以及有多确定。模型不会。让模型找漏洞，它就找——不管代码里有没有。发现结果中充斥着"可能"、"潜在"、"理论上可以"之类的措辞，而这些模棱两可的结果远超可靠的发现。对于探索性工具来说，这是合理的偏差；但对于分类队列来说，这是灾难性的。
Mythos Preview 在这方面有明显的改进，尤其是在链式利用的能力上——将多个漏洞组合成一个可工作的概念验证，而不是孤立地报告它们。一个附带了 PoC 的发现，就是你可以采取行动的发现。
为什么把通用编码代理指向仓库行不通
去年我们刚开始 AI 辅助漏洞研究时，本能的做法很直接：把通用编码代理指向一个任意仓库，要求它发现漏洞。这种方法从某种意义上说也"工作"——模型会产生发现——但在覆盖真实代码库方面并不有效。
上下文——编码代理是为单一聚焦的工作流优化的：构建功能、修复缺陷、编写重构。它们摄入大量源代码，一次持有一个假设，并反复迭代。这恰恰不适合漏洞研究——漏洞研究本质上是窄而并行的。人类研究者会挑选一个特定方向，彻底调查，然后进入下一个。
吞吐量——单流代理一次只做一件事，但真实的代码库需要对多个组件同时提出多个假设。你可以更用力地驱动单个代理，但到某个临界点，瓶颈不再是模型本身，而是交互方式的固有局限。
测试框架（Harness）实际上解决了什么
规模化运行这项工作带来了四条经验教训，每条都指向构建一个管理整体执行的测试框架的必要性：
窄化范围产生更好的发现——告诉模型"在这个仓库里找漏洞"会让它四处游荡。告诉它"在这个特定函数里找命令注入，上方有这个信任边界"就能让它做更接近研究者实际会做的事。
对抗性审查降低噪声——在初始发现和队列之间增加第二个代理——使用不同的提示词、不同的模型，且没有能力产生自己的发现——能捕获大量噪声。
跨代理拆分链条产生更好的推理——问"这段代码有 bug 吗？"和问"攻击者能从系统外部实际到达这个 bug 吗？"是两个不同的问题，分开问时模型在每个问题上表现更好。
并行的窄任务胜过单个穷举代理——当许多代理在处理范围严格的问题时，覆盖面会提高，之后再做去重合并结果。
我们的漏洞发现测试框架
以下是我们的漏洞发现测试框架（harness）的分阶段结构。该框架用于扫描我们运行环境、边缘数据路径、协议栈、控制平面以及依赖的开源项目中的实时代码。
| 阶段 | 说明 |
|---|---|
| 侦察（Recon） | 代理从上到下阅读仓库，分叉出负责每个子系统的子代理，生成一份架构文档，包含构建命令、信任边界、入口点和可能的攻击面。
|
| 狩猎（Hunt） | 每个任务是一个攻击类别搭配一个范围提示。狩猎者并发运行，通常约50个同时进行，每个再分叉出探索子代理。每个狩猎者都拥有编译和运行概念验证代码的工具。
|
| 验证（Validate） | 独立的代理重新阅读代码，试图证伪原始发现。使用不同的提示词，且没有能力产生自己的新发现。
|
| 补漏（Gapfill） | 狩猎者标记他们触及但未深入覆盖的区域。这些区域被重新排队进行下一轮扫描。
|
| 去重（Dedupe） | 共享同一根本原因的发现合并为单条记录。
|
| 追踪（Trace） | 对于共享库中每个确认的发现，追踪代理进行分叉，使用跨仓库符号索引，判断攻击者控制的输入是否实际从系统外部到达漏洞点。
|
| 报告（Report） | 代理按照预定义架构编写结构化报告，提交到接收 API。
|
这对安全团队意味着什么
其他安全负责人对 Mythos Preview 反应最强烈的一点是速度——扫描更快、修复更快、压缩响应周期。我们接触过的团队中，不止一个现在以 CVE 发布后两小时内完成生产环境修补为目标。这种直觉可以理解：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但"更快"还不够。
更快地打补丁并不能改变生成补丁的流程本身。如果回归测试需要一天，你不可能在不跳过它的情况下实现两小时的 SLA——而跳过回归测试发布的漏洞，往往比你想修补的漏洞更糟糕。
更困难的问题是：围绕漏洞的架构应该是什么样的。原则是——即使存在漏洞，也让攻击者更难利用。这意味着在应用程序之前设置防御，阻止漏洞被触及；意味着设计应用程序时，代码某一处的缺陷不会让攻击者获得对其他部分的访问权限；意味着能够在同一时刻将修复推送到所有运行该代码的地方。
我们也认识到这个话题是双刃剑。帮助我们找到自身代码漏洞的相同能力，在错误的人手中，将加速对互联网上每一个应用的攻击。Cloudflare 坐落在数百万个应用的前方，上述架构原则恰恰是我们的产品代表客户所应用的。
如果你的团队也在做类似的工作，希望交流心得，请通过 security-research@cloudflare.com 联系我们。
我们与 Mythos Preview 的研究是在可控环境中针对我们自己的代码进行的；通过这项工作发现的每一个漏洞都经过了分类、验证和修复（在需要采取行动的情况下），并遵循 Cloudflare 正式的漏洞管理流程。
这项工作是一个团队成果。感谢 Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl 和 Rohit Chenna Reddy 对这篇博文背后研究、工程和分析的贡献。
——
zhirenhun
一个热爱技术的程序员，喜欢分享前沿AI知识和开发经验。
