文章总结： 微软MDASH多模型Agent漏洞扫描系统在CyberGym基准测试中实现96.5%的崩溃触发率，但关键发现是剩余3.5%失败案例中65.4%源于漏洞证明阶段瓶颈。系统需处理复杂二进制格式输入、环境不一致性及构建复杂度等工程挑战。改进方向包括整合OSS-Fuzz生态、扩展非传统代码分析能力及强化Agent结构化输出验证。 综合评分： 87 文章分类： 漏洞分析,AI安全,安全工具,安全运营,渗透测试

漏洞分析超越Mythos还不够！微软真正厉害的是知道MDASH还差在哪

原创

玄月调查小组 玄月调查小组

玄月调查小组

2026年6月20日 14:09 上海

在小说阅读器读本章

去阅读

你知道吗？

微软 MDASH 最近在 CyberGym 上跑到了 96.5% crash。

目前排名断层领先。

但微软这次最有价值的地方，不是展示成功，而是把分析了剩下的为什么会失败！

剩下的 3.5%，一共 52个失败案例。

微软逐个拆解后发现，最大瓶颈并不在「发现漏洞」，而在「证明漏洞」。

96.5%的背后，是1507个真实漏洞

微软在6月2日披露，名为 MDASH 的多模型 Agent 漏洞扫描系统，在 CyberGym 上取得了 96.5% any crash 的表现。

CyberGym不是随便拼出来的小测试集，而是基于 1,507个真实世界漏洞 的行业评测。

这让它比普通靶场更接近真实世界的漏洞挖掘：仓库复杂、依赖复杂、漏洞描述可能模糊，验证路径可能很绕，构建环境还可能出问题。

MDASH的任务也不是简单回答“有没有漏洞”，而是沿着设定的流水线推进：

1. 准备目标代码和范围
2. 扫描并发现潜在漏洞
3. 验证漏洞是否真的可达
4. 生成能触发问题的漏洞利用证明
5. 进入修复流程

这个流程越往后，越接近真实安全工程，也越难。

52个任务的失败原因

微软没有只报喜。

在96.5%的成绩之外，它分析了剩下 52个失败任务。

• 扫描阶段失败：8个，占15.4%
• 验证阶段失败：10个，占19.2%
• 证明阶段失败：34个，占65.4%

也就是说，MDASH多数时候已经能找到方向，但真正让它失败的，是最后那一步：写出一个能触发漏洞的输入，证明问题真实存在。

这非常符合安全工程常识。

AI能读代码，能推理路径，能提出风险，但一旦进入复杂文件格式、二进制输入、构建环境、评测框架，真实世界没有这么简单。

为什么证明阶段最难？

微软列出的失败原因，其实人也会遇到。

首先是高度结构化输入。

有些目标需要非常复杂的二进制格式，比如视频、音频、字体、PDF。

输入必须先通过格式校验，才能走到漏洞代码。

随便造一个文件，程序根本不吃；造得太规范，又未必触发崩溃。

不是简单的让 AI“写一段代码”就能解决的。

其次是Fuzz测试超时。

系统有时会尝试通过Fuzz测试不断变异输入，寻找崩溃。

但面对复杂格式，如果没有合适种子、构建流程、反馈信号，很容易一直跑到超时。

第三是环境不一致。

本地能崩，评测环境不崩；构建参数不同，目标选择不同，执行路径不同，都会让证明失效。

最后是构建复杂度。

真实项目的编译链条可能又长又脆。

依赖装不上、构建太慢、预算耗尽，Agent还没来得及证明，时间已经没了。

跑分为什么仍然有用？

有人可能会说，那基准测试还有意义吗？

当然有。

对于一个企业使用的产品，没有基准测试，产品团队就会陷入玄学。

今天换了模型，到底变强还是变弱？

改了扫描流程，到底提升在哪里？

Agent 分工调整后，是更容易发现问题，还是只是在制造更多误报？

没有一个稳定的评估，很难回答这些问题。

CyberGym 的价值就在这里。

它给 MDASH 提供了一个可重复、可量化的反馈。

可以快速迭代，看到MDASH在哪些漏洞类型上变强，在哪些阶段仍然失败。

这就像做硬件产品要有跌落测试、耐久测试、温度测试。

测试环境虽然不能代表全部真实世界，但没有测试环境，产品根本没法稳定进步。

产品团队最怕能力团队黑盒自嗨。

有了指标，才有工程化。

GPT-5.5带来了什么？

博客还提到，微软做了 GPT-5.5 和 GPT-5.5-cyber 的实验，最高大约能到 98.1%。

但建议大家别只盯着98.1%。

因为OpenAI自己的 CyberGym 测试结果只有 81.8%

新模型带来的提升，说明系统和模型是互补关系。

模型越强，Agent 在扫描、理解、生成证明时的能力越高；系统越强，模型的能力越能被正确调用、约束和验证。

这就是今天 AI 产品的典型逻辑。

模型是发动机，基准测试是赛道，一台车不仅仅要看发动机马力，也得看赛道表现。

MDASH 的产品逻辑也是这样。

一个产品如果只靠模型能力，那它不是真产品。

MDASH将如何提升漏洞挖掘能力

MDASH团队给出的改进方向很明确。

第一，整合已有的Fuzz测试生态，比如 OSS-Fuzz。这样可以复用构建流水线和种子语料，而不是每次让Agent从零搭环境、造输入。

第二，扩展源代码之外的分析能力。传统C/C++代码处理得比较好，但像 lex/yacc 这类工具生成的代码或非传统代码工件，还需要更好支持。

第三，提升Agent推理和输出质量，减少含糊描述，强制结构化输出，并加入更多验证检查。

这些听起来不炫，但非常工程化。

而安全真正需要的，恰恰不是演示视频里的炫技，而是每天稳定跑、能复现、能派单、能修复的系统。

微软的思路带来了什么启发？

不是每个团队都能做 MDASH，也不是每个公司都有 Windows 和 Azure 这种超大规模系统。

但 MDASH 的方法论，普通团队依然可以学习。

第一，别只买买买，要看工具能不能进流程。

如果一个安全工具只能在独立页面里生成报告，不能接入代码仓库、问题跟踪、修复验证，那它的价值会大打折扣。

第二，别只看总分，要看阶段指标。

你的工具到底是扫不到，还是扫到了验证不了，还是验证了证明不了？不同问题，对应完全不同的优化方向。

第三，别迷信单一模型。

模型很重要，但安全场景里，工具调用、上下文组织、结果验证、人工协作同样重要。

参考资料：https://www.microsoft.com/en-us/security/blog/2026/06/17/beyond-the-benchmark-advancing-security-at-ai-speed/

免责声明：

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

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

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

本文转载自：玄月调查小组 玄月调查小组 玄月调查小组《漏洞分析超越Mythos还不够！微软真正厉害的是知道MDASH还差在哪》