Mythos首个报告：30天挖出10000致命漏洞¶

📊 Level ⭐⭐⭐⭐ | 9.0KB

摘要¶

Anthropic 首度公开「玻璃翼计划」（Project Glasswing）的首月战报：由 Claude Mythos Preview 驱动的漏洞挖掘在 30 天内覆盖 1000+ 开源项目，扫描出 23019 个漏洞，其中 6021 个为高危或严重级别；通过与全球 50 家网络巨头的合作，另有 10000+ 高危/严重漏洞被发现。经 6 家独立安全公司人工复核，AI 报告的真阳性准确率为 90.6%。

报告的另一面是修复侧的全面吃紧。人类在收到详细报告后平均需要 2 周才能修复一个高危漏洞，而目前已提交的 1129 个高危漏洞中只有 75 个真正被打上补丁；开源维护者甚至发来邮件请求放缓披露节奏。这构成本报告最重要的结构性结论：AI 把「发现」环节的生产率提升了一个量级，瓶颈随之整体迁移到修复、协调与披露节奏的治理环节。原文（新智元 / ASI启示录，2026-05-23）称数据出自 Anthropic 官方 X 账号。

核心数据¶

以下数字按原文口径直接列示，未做换算、合并或外推：

指标	数值	原文口径
高危/严重漏洞发现量	10000+	全球 50 家网络巨头合作发现
扫描漏洞总数	23019	覆盖 1000+ 开源项目
其中高危/严重	6021	同一批开源项目扫描结果
AI 真阳性准确率	90.6%	6 家独立安全公司人工复核验证
电诈实时拦截金额	150 万美元	某合作银行真实业务场景
Firefox 高危漏洞修复	271 个	Firefox 150；原文称是 Firefox 148（Opus 4.6）的 10 倍以上
OpenBSD 陈年老 Bug	27 年	长期未被发现的遗留缺陷
Cloudflare 核心路径漏洞	2000 个	其中 400 个为高危/严重
企业客户漏洞	2100+	Claude Security 上线 3 周内完成修复
人类修复单个高危漏洞耗时	2 周	收到详细报告后计时
高危漏洞提交数 / 已打补丁数	1129 / 75	修复缺口约 15 倍

深度分析¶

发现速度与修复速度的产能错配¶

报告的「发现」与「修复」两条曲线已经脱钩。挖掘侧以批量并行方式产出洞见——23019 个扫描结果、10000+ 高危发现——而修复侧仍受制于串行、人力密集、跨组织协调的流程：一个高危漏洞平均需要 2 周，1129 个已提交高危中仅 75 个被打上补丁，缺口接近 15 倍。这意味着提高发现能力不会自动转化为安全性提升；当边际发现成本趋近于零，真正稀缺的资源变成分诊注意力、维护者时间与发布窗口。开源维护者发来的「求饶」邮件是最直观的信号：他们面对的不是漏洞不够多，而是超出了其修补与协调能力的负载。

90.6% 真阳性率：意义与口径¶

90.6% 是本报告中最需要谨慎阅读的数字。它的价值在于来源——由 6 家独立安全公司人工复核验证，而非厂商自评，这使「AI 报告的漏洞里有多少是真的」第一次有了可引用的外部证据。但口径边界同样重要：它衡量的是已复核样本中为真的比例（precision），不等于召回率——无法回答「还有多少真漏洞没被找到」；它也不等于独立审计结论，复核方的选取标准、样本构成与判定标准，原文均未披露。合理读法是把它当作分诊资源规划的先验值（约每 10 份报告中 9 份值得投入人工确认），而不是对模型整体安全能力的背书。

wolfSSL 案例：密码学库逻辑漏洞的杠杆放大¶

全球数十亿设备使用的密码学库 wolfSSL 被 Mythos 发现一处隐蔽的逻辑漏洞，可被用于伪造数字证书，从而造出毫无破绽的银行网站或邮箱登录页。这类漏洞的危害与普通内存漏洞不在同一量级：内存漏洞通常影响单个进程或主机，而证书伪造攻击的是「信任根」——它不打破加密强度，而是让验证链条本身失效，使钓鱼站点在浏览器与邮箱客户端中呈现为合法站点。密码学库、TLS 栈、系统库这类被广泛依赖的基础设施组件，其漏洞有典型杠杆效应：一处缺陷沿依赖树复制到数以亿计的终端，且这类深层缺陷往往不触发崩溃、不产生日志，常规扫描与模糊测试难以触及——「27 年 OpenBSD 遗留 Bug 被找出」指向同一类盲区。Cloudflare 核心路径的 2000 个漏洞（含 400 个高危/严重）同属这一杠杆结构。

从「AI 挖洞」到「AI 防御」：工具包、建议与披露节奏¶

Anthropic 在报告中给出防御侧三件套：面向企业、可直接写好补丁的 Claude Security；允许白帽在合法靶场中解除部分安全限制的「网络验证计划」；以及开源的抓 Bug 流水线——用定制化指令（Skills）做深度代码审查、用自动化框架（Harness）遍历代码库并克隆子代理并行扫描、用威胁建模生成器（Threat Model Builder）识别系统最易被攻击的软肋。配套建议则是流程性的：缩短补丁周期（不要攒着一个月一发，用 Opus 4.7 等现有工具尽快推送安全修复）、强制升级策略（让用户尽量无脑安装更新，对不升级用户强制断网）、以及强化 MFA、加固默认配置、保留详尽日志。这些建议的共同指向是把修复与分发的产能提上来。同时，开源维护者请求放缓披露节奏一事说明 coordinated disclosure 的老假设（发现速度与修复速度大致匹配）已经失效。

实践启示¶

把修补产能当作一等安全指标：发现量增长在修复产能不变时只转化为积压（1129 → 75），安全团队应把平均修复周期、待补丁队列长度与维护者响应时间列为与发现量同级的指标。
用真阳性率而非报告总数做分诊规划：以 90.6% 为先验值估算人工确认工作量，同时记住它是精度而非召回，不能据此认为「没被报告的地方就是安全的」。
优先修复基础设施与密码学类依赖：wolfSSL 式证书伪造、Cloudflare 核心路径、OpenBSD 遗留缺陷表明，被广泛依赖的库和核心路径应按杠杆倍数而非单点风险定优先级。
缩短补丁周期、放弃「攒一批发一次」：按报告建议改用现有 AI 工具加速安全修复的生成与推送，把发布窗口变成持续动作。
让升级尽可能无痛：推动自动/无感更新，配合默认配置加固、强制 MFA 与详尽日志，减少「补丁已发布但用户未安装」的失效模式。
与上游维护者协商披露节奏：把披露时限做成可分级、可协商的机制，维护者明确请求放缓时优先保障修复窗口，而非机械执行公开时限。