文章总结： 文章分析Cloudflare测试MythosPreview模型在漏洞挖掘中的能力突破，指出其核心价值在于组合低危漏洞形成利用链并生成PoC，而非单纯提升扫描速度。关键发现包括模型需配合harness流程管理以控制信噪比，且企业应注重安全工程体系建设而非仅追求修复速度。可操作建议包括采用独立验证机制、避免模型自我验证偏差、强化漏洞可达性评估。 综合评分： 89 文章分类： 漏洞分析,AI安全,安全建设,安全工具,安全运营

Mythos彻底改变了安全工作，但并不只是加快了挖洞

原创

裴伟伟 裴伟伟

洞源实验室

2026年6月22日 23:51 北京

在小说阅读器读本章

去阅读

最近 Cloudflare 发布了一篇关于 Project Glasswing 和 Mythos Preview 的文章。表面上看，这是一篇关于“AI 模型帮助发现漏洞”的技术博客，但如果放到企业安全工作的实际场景中，它讨论的其实是一个更大的变化：

当模型已经可以发现漏洞、构造利用链、生成 PoC，并在一定程度上自我验证时，安全团队原有的漏洞管理流程还能不能承受这种能力。

这里需要先把几个概念说清楚。

Mythos Preview 是 Anthropic 在 Project Glasswing 中提供给部分合作伙伴使用的前沿模型。这里的“前沿模型”不是普通聊天机器人，而是具备较强代码理解、推理、工具调用和自主实验能力的大模型。

Project Glasswing 则是 Anthropic 发起的防御性安全计划，目标是让关键软件厂商、云厂商、开源组织和安全公司优先使用这类能力，尽可能在攻击者大规模掌握类似能力前修复重要软件中的漏洞。

Cloudflare 的观察很直接：Mythos Preview 的关键变化，不只是能“找 bug”，而是能把多个小问题组合成可利用路径，并通过实验生成证据。

这对安全行业的意义，比“扫描更快”要大得多。

从“发现漏洞”到“证明可利用”

传统安全工具经常停在一个尴尬位置：它可以指出某段代码“可能存在问题”，但无法证明这个问题是否真的能被攻击者触达、触发，并造成实际影响，于是安全团队需要投入大量人力做验证、分级、复现和排除。

Cloudflare 通过测试发现 Mythos Preview 最突出的能力之一，就是漏洞利用链构造，即通过构建攻击原语（Attack Primitives）形成更加严重的安全漏洞。

所谓“攻击原语”，可以理解为攻击过程中的基础能力。例如一次越界写、一次任意读、一次控制流劫持，本身未必构成完整攻击，但它们像积木一样，可能被组合成更严重的利用链。现实攻击往往不是靠一个单点漏洞完成，而是把多个低严重性问题串起来，越过边界，拿到更高权限。

这也是原文中最值得关注的地方：过去很多低严重性缺陷可能长期躺在 待处理漏洞（backlog） 里，因为单独看它们“不够紧急”。但当模型具备链式推理能力时，这些看起来不够严重的小问题，可能被组合成一个真正严重的漏洞利用。

另一个关键能力是 PoC 生成。PoC 是 Proof of Concept，即概念验证，它不是完整攻击工具，而是用最小化方式证明一个漏洞确实存在、可触发、可复现。对防御方而言，PoC 的价值在于减少猜测。一个没有复现路径的发现，很容易变成安全队列里的噪声；一个能在受控环境中稳定触发的 PoC，则更接近可以处置的工程事实。

但这并不意味着模型输出都可信。恰恰相反，Cloudflare 反复强调，AI 漏洞研究最大的现实问题之一仍然是信噪比。

模型会扩大能力，也会扩大噪声

信噪比在这里指的是：模型报告的发现中，真正有价值、可复现、可修复的部分，占全部输出的比例。

AI 模型有一个天然倾向：当你要求它“找漏洞”时，它往往会给出一些看起来合理的发现，即使代码中并不存在真正漏洞。很多报告会使用“可能”、“理论上”、“潜在”等措辞。这在探索阶段可以接受，因为探索工具宁可多报，也不愿漏报；但进入漏洞分级队列后，每一条模糊发现都会消耗安全团队的注意力、验证资源和修复排期。

这里还有一个常被忽略的因素：编程语言会影响噪声率。

C 和 C++ 属于典型的内存不安全语言，开发者可以直接操作内存，因此更容易出现缓冲区溢出、越界读写、释放后重用等问题。Rust、Go 等语言在一部分场景下能通过类型系统、所有权模型或运行时机制减少这类错误，但“内存安全语言”并不等于“没有安全问题”。一旦使用 unsafe、FFI、JNI、ctypes，或者在协议解析、权限设计、业务逻辑上犯错，仍然可能形成漏洞。

所以，模型能力提升以后，企业面对的不是一个简单问题：买一个更强模型，然后让它扫代码。

这有点像让一个很聪明的实习生翻仓库，他可能找到真正的问题，也可能把每个可疑角落都标上便利贴。问题不在于他有没有价值，而在于你有没有一套机制，把线索、证据、验证、去重、可达性判断和修复流程接起来。

为什么通用编码智能体不适合做大规模漏洞研究

Cloudflare 对通用编码智能体的判断比较克制，但结论很明确：它可以辅助人工调查，却不适合承担企业级高覆盖率漏洞发现。

第一个原因是上下文。通用编码智能体通常适合单线程任务，例如修一个 bug、写一个功能、完成一次重构。它会围绕一个目标读代码、形成假设、迭代修改。但漏洞研究不是这种单线程任务，真正的漏洞研究往往是窄而并行的：针对某个入口点、某条信任边界、某类攻击方式，反复做成百上千次调查。

第二个原因是吞吐量。一个智能体再聪明，也很难在一个大代码库里同时覆盖大量组件、大量攻击类型和大量上下游依赖关系。上下文窗口填满后，模型还可能丢失早期发现。对于十万行、百万行级别代码库来说，这种方式的覆盖率很容易低得不成比例。

因此，Cloudflare 的结论不是“Mythos模型不行”，而是“交互形态不行”。

Harness 才是安全工程的主角

原文反复提到 harness，这个词直译为“驾驭框架”或“测试框架”，但在这里更准确的理解是：围绕模型构建的一套任务编排、状态管理、验证、去重和报告系统。它不是一个提示词，也不是一个聊天窗口，而是一条流水线。

Cloudflare 的流程大致包括几个阶段：

1. Recon（侦察），侦察代码库结构，生成架构文档，识别构建方式、入口点、信任边界和攻击面。

2. Hunt（挖掘），按攻击类型和具体范围分配任务，让多个窄范围智能体并行寻找漏洞。

3. Validate（验证），用独立模型或独立提示词尝试推翻原始发现，而不是让发现者自己批改作业。

4. Gapfill（补位），对覆盖不足的区域重新排队，避免模型只盯着它熟悉或刚刚成功过的攻击类型。

5. Dedupe（去重），把同一根因导致的多个发现合并，防止漏洞队列被重复项淹没。

6. Trace（追踪），追踪共享库和消费仓库之间的关系，判断“代码中有缺陷”是否真的变成“生产环境中攻击者可达的漏洞”。

7. Report（报告），将结果写成结构化数据，而不是自由格式的长篇描述。

这套机制背后的思想很重要：模型只是计算单元，真正决定效果的是流程。好的流程让模型做窄任务，让状态留在数据库里，让验证者独立，让输出可查询，让修复进入正常工程管道。把模型当作员工，会期待它自觉、稳定、全知；把模型当作能力组件，才会设计权限、上下文、验证和回滚。

安全团队不应只盯着“两小时修复”

Cloudflare 提到，有些团队已经在讨论从 CVE 发布到生产环境完成补丁部署不超过两小时的 SLA（服务等级协议）。这个方向可以理解，攻击者利用窗口越来越短，防御者当然希望响应更快。

但速度不是唯一解决攻防不对称的灵丹妙药。

如果一个系统的回归测试本来需要一天，强行压到两小时，通常不是工程能力突然提升，而是测试被跳过了。这样上线的补丁，可能修复一个漏洞，却引入新的生产事故或新的安全问题。原文中 Cloudflare 也提到，他们曾尝试让模型自动写补丁，结果部分补丁修掉了原漏洞，却悄悄破坏了其他依赖逻辑。

所以更重要的问题是：漏洞存在时，系统架构能不能降低它被利用的概率和影响范围。

这包括在应用前面布置可快速更新的防护层，减少漏洞可达性；在系统内部做隔离和最小权限，避免一个组件出问题就横向扩散；在发布体系中支持统一、快速、可验证的修复；在修复后保留回归测试、人工审核和变更记录。

换句话说，AI 缩短的是发现与利用的时间线，但企业要建设的是承压能力。

Mythos对企业的现实启示

这篇文章给安全团队的启示可以概括为四点。

第一，不要把 AI 漏洞研究理解为传统扫描器升级版。它更像一种新型研究能力，可以提出假设、构造实验、生成证据，但仍然需要流程约束。

第二，不要把 PoC 等同于风险结论。PoC 证明漏洞可触发，但还需要判断攻击者身份、入口条件、生产环境可达性、影响范围和修复成本。

第三，不要让同一个模型完成发现、验证、定级、修复和合并。模型自我验证很容易形成确认偏差，独立验证、确定性检查、人工审核仍然不可替代（参考笔者之前的文章从籍籍无名到排行第一：XBOW智能漏洞挖掘的构建）。

第四，不要只追求补丁速度。真正成熟的防御体系，应当让漏洞在存在时也更难被触达、更难扩散、更容易统一修复。

这也是 Cloudflare 文章中最有价值的部分，它没有把 AI 描述成一个可以替代安全团队的万能工具，而是把问题重新拉回工程现实：覆盖率、信噪比、状态管理、可达性、回归测试、责任边界。

AI 正在改变安全漏洞的工作形式和状态，但它不会自动改变组织能力。

如果一个团队原本没有资产清单、没有代码所有人、没有测试门禁、没有变更审计、没有漏洞分级流程，那么更强的模型只会更快地暴露这些短板，它会让问题更早出现，也会让队列更快堆积。

真正的差距，不在于有没有接入某个前沿模型，而在于是否能把模型输出变成可验证、可处置、可复盘的安全工程流程。

这才是 Project Glasswing 和 Mythos Preview 给防御方最现实的提醒：

未来的安全竞争，不只是模型能力的竞争，而是组织把模型纳入工程体系的能力竞争。

参考资料

1. Cloudflare：Project Glasswing: what Mythos showed us
2. Anthropic：Project Glasswing
3. Anthropic：Assessing Claude Mythos Preview’s cybersecurity capabilities
4. Cloudflare：Build your own vulnerability harness

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：洞源实验室 裴伟伟 裴伟伟《Mythos彻底改变了安全工作，但并不只是加快了挖洞》