漏洞通胀时代：产品安全的三层破局架构思考

漏洞发现成本趋近于零，但修复能力严重滞后。这个剪刀差，就是产品安全的下一个主战场。

📋 文章结构概览
一、背景：Mythos 三事件冲击波
├─ 事件一：Mythos 发布（2026-04-07）
├─ 事件二：curl 维护者实测（2026-05-13）
└─ 事件三：Glasswing 首月战报（2026-05-22）

二、问题：漏洞正在"通胀"
├─ 开源软件漏洞暴涨
├─ 自研产品同样面临通胀
└─ 软件厂商面临的全新挑战

三、方案：三层破局架构
├─ 第一层：数据可信（SBOM 数据底座）
├─ 第二层：流程自动化（漏洞响应 + 日志分析前置）
└─ 第三层：主动防御（大模型漏洞挖掘）

四、总结：三层递进，环环相扣

五、行动：为什么现在必须做

最近一直在关注Mythos。从 4 月 7 日发布，到 curl 维护者实测，再到 5 月 22 日 Glasswing 首月战报——这三件事，越想越觉得紧张。不是说 AI 挖洞有多厉害（大家应该早就有预期），而是速度。一个月 1 万个高危漏洞，这个数量级，不止"进步"，是"通胀"。

作为产品安全负责人，第一反应不是"哇，AI 真强"，而应该是"我们怎么办？"漏洞发现已经“白菜化”了。攻击者能用，我们也能用。但能不能在用之前，先把自家产品看清楚？能不能在用之后，让漏洞少一点、修得快一点？

这篇文章，就是这段时间思考的总结。

一、背景：Mythos 三事件冲击波

1.1 事件一：Mythos 发布（2026-04-07）

Anthropic 发布了Claude Mythos Preview。两个能力，以前的工具做不到：

Anthropic 自己的评价是："过于强大，危险到不宜公开发布"。同时宣布启动Project Glasswing（玻璃翼计划），联合 AWS、Apple、Google、Microsoft 等 50 多家科技巨头，仅向合作伙伴开放防御性使用。

💡 这意味着什么？ 攻击门槛被压到历史最低。 以前挖一个深层逻辑漏洞要高级安全研究员花几周，现在 AI 几小时搞定。 防守方的时间窗口，正在急剧收缩。

1.2 事件二：curl 维护者实测（2026-05-13）

curl 的创始人Daniel Stenberg，决定亲自测试 Mythos。他让 Mythos 扫描 curl 代码库，看看能发现什么。结果：

Stenberg 的态度很有意思，两方面都说到了：

✅认可：LLM 做代码安全审计的能力，确实远超传统静态扫描工具

⚠️质疑：Mythos 的能力被过度营销了，其他顶级 LLM（GPT-4、Claude Opus）同样可以做到，并不存在代际差距

💡 这说明什么？ Mythos 不"神话"。 AI 挖洞的时代确实到来了，但真正的瓶颈不在"能不能发现"，而在"发现的问题里，哪个真的危险、该优先修"。

1.3 事件三：Glasswing 首月战报（2026-05-22）

Anthropic 公布 Project Glasswing 运行1 个月的成果：

这个数据很震撼，但更震撼的是背后透露出的信号：AI 的漏洞发现能力，已经大幅领先于人类现有的修复能力。

💡 残酷现实： 以前一个高危漏洞从发现到修复，可能要几周甚至几个月。 现在 AI 一个月能发现 1 万个高危漏洞——修复速度根本追不上发现速度。这个剪刀差，就是产品安全团队下一个十年最核心的问题。

1.4 三件事串起来，结论是什么？

这三件事串起来的核心逻辑是：

1. 必须先于攻击者，用 AI 把自家产品的漏洞先挖出来、先修完
2. 漏洞响应流程必须提速，从"天级"压缩到"小时级"
3. 最终目标：让漏洞少一点，而不是被动跟着漏洞跑

二、问题：漏洞正在"通胀"

2.1 开源软件漏洞正在经历"通胀"

在 Mythos 出现之前，一个中型产品的年度漏洞发现量，大致可以这样估算：

而 Glasswing 首月战报告诉我们：50 家合作伙伴，1 个月发现了 1 万+ 高危漏洞。如果把这个能力引入到产品安全流程中，可以预见：

产品每年发现的漏洞数量，可能会在短期内暴涨 5~10 倍。

这不是因为产品变不安全了，而是因为以前看不见的漏洞，现在被 AI 看见了。对于软件厂商来说，这意味着：产品依赖的每一个开源组件——无论是直接依赖还是传递依赖——都可能包含已被 AI 发现、但尚未修复的漏洞。

更危险的是：攻击者也在用类似的 AI 工具。Mythos 能发现的漏洞，恶意攻击者同样能发现。供应链攻击面，正在被 AI 以前所未有的速度"扫荡"。

2.2 自研产品同样面临漏洞"通胀"

除了开源组件，公司自有产品的代码库同样面临漏洞"通胀"：

原因一：AI 辅助代码生成引入新风险

GitHub Copilot、Cursor、Claude Code 等工具正在被大规模采用。

AI 生成的代码，安全质量参差不齐——有些有严重逻辑漏洞，有些有传统注入类漏洞。产品代码库中，AI 生成代码的比例正在快速上升，这些代码有没有经过安全审查？

原因二：AI 能挖出人和传统工具发现不了的漏洞

这是最值得警惕的。

传统 SAST/DAST 工具只能匹配已知漏洞规则，人工审计受限于时间和经验，很多深层逻辑漏洞、业务逻辑漏洞，以前根本完全发现不了。但 AI 工具能理解代码语义、能串联多个模块做推理，以前发现不了的漏洞，现在能被 AI 发现了。

原因三：攻击者用 AI 做自动化渗透测试

以前攻击者要手工测一个产品的所有接口，需要数周。现在用 AI 工具，可以在几天内完成全量接口的安全审计。

作为网络安全产品，被攻击者盯上的概率远高于一般产品。产品的暴露面，可能在下次 HW 或真实攻击中，被攻击方用 AI 工具"扫荡"。

2.3 软件厂商面临的全新挑战

作为网络安全产品厂商，场景和一般企业不一样：

挑战一：漏洞曝光 = 客户侧风险

产品部署在成百上千家客户侧。

一旦产品爆出高危漏洞，影响的是所有客户。修复速度，直接决定客户信任和品牌声誉。

挑战二：漏洞情报来得快，修复速度跟不上

早上爆出漏洞，中午客户就来问了。

需要在几小时内给出修复方案或临时缓解措施。传统流程（发现→验证→排期→修复→测试→发布）根本来不及。

挑战三：攻击者也在用 AI 审计产品

产品是网络安全产品，攻击者有极强的动力去挖产品的漏洞。

Mythos 级别的 AI 工具，能让攻击者在几天内完成产品全量安全审计。

产品的代码，可能正在被 AI"逆向工程"。

这一节的核心结论： 漏洞"通胀"不仅是内部问题，更是客户信任和品牌声誉问题。 修复速度，就是软件厂商的生命线。

三、方案：三层破局架构

漏洞越来越多，忙不过来怎么办？ 答案分三层，环环相扣，从"排水"到"少来水"。

第一层：数据可信——先知道自己有什么

处理漏洞最浪费时间的一步是什么？

找影响面。现在的流程（问题）

情报来了 → 人工判断严重性 → 逐个问产线"你们用了这个组件没？" → 等回复 → 确认影响 → 研究怎么修 → 通知产线改 → 改完手动复测 → 归档

最卡脖子的一步：问产线。因为往往不知道产品到底用了什么版本的什么组件。漏洞量少的时候还能扛；量一翻倍，线性流程直接崩。

解决方案：SBOM 数据底座

把家底摸清楚，比如我们靠两个工具：

两者结合，建起SBOM 清单：

哪个产品、哪个版本、包含哪些组件、责任人是谁。

有了这个数据底座，后面的自动化才有了根基。 就像做研发安全流程设计时说的一样——安全不能自己造流程，必须结合公司的实际情况。 数据底座也是一样，不是从零搭一个完美体系，而是在已有基础上把关键数据补齐、连起来。

踩过的坑

这些坑都不高深，但就是这些基础工作，决定了后面所有自动化的效果：

数据不准，自动化再强也是空中楼阁。

第二层：流程自动化——从"人工跑"到"机器跑"

数据底座有了，第二步是让流程跑起来。

漏洞响应自动化效果对比，先看效果：

自动化不是目的，省下来的时间去干更重要的事才是目的。

极速模式：小时级给客户答复

国家级攻防演练期间，压力是完全不一样的。客户直接找上来要方案、要补丁、要时间点，SLA 压到几个小时，多方客户并发，品牌声誉悬于一线。基准流程（理想型）：

T+0H 漏洞情报到达 → T+4H 输出漏洞定位文档 → T+8H 输出修复方案文档 → T+24H 输出完整解决方案包

极速模式下（理想型）：

漏洞通报 → 平台秒级查影响产品+客户 →内部IM@负责人 + 工单自动创建 + 修复建议附送 → 2 小时给客户答复 → 4 小时出补丁

从"客户在等答案，我们还在查影响面"变成"客户刚开口，答案已经准备好了"。

极速模式能不能跑起来，取决于 SBOM 数据准不准、客户台账清单准不准。 数据不准，自动推送就是灾难。

应急响应的第一步：日志分析前置

传统应急响应流程里，日志分析往往排在"确认影响面"之后，甚至被跳过。但攻击者留下的痕迹，第一时间就在日志里。在国家级攻防演习中，第一时间就是要确定漏洞。

做法：在应急响应的第一步就启动日志分析，定位漏洞。实现方式上，走了两条路：

• AI 辅助编写日志分析工具——针对不同产品的日志格式快速生成解析脚本和检测规则，降低人工编写成本
• 基于历史案例建攻击特征库——把常见攻击手法的日志特征沉淀下来，持续更新

这两条路都不算难，难的是持续运营。检测规则要跟着攻击手法变化持续更新，日志格式变了要同步调整解析脚本，这些不跟进，前期建得再好也会慢慢失效。

第三层：主动防御——让漏洞少一点

前两层解决的是"水来了怎么更快排水"，但更根本的问题是——能不能让水少来一点？

既然攻击者在用自动化工具挖洞，我们为什么不用同样的武器？

自动化漏洞挖掘，到底能多发现什么？

这是最常被问到的问题，必须回答清楚：

一句话总结：

传统工具查"已知模式"，自动化工具能查"未知逻辑"。而未知逻辑漏洞，恰恰是最危险的。但也要说清楚——自动化漏洞挖掘不是万能的。它发现的问题仍然需要人工复核，尤其是业务逻辑类的判断，目前工具还做不到完全替代人的经验。

代码安全吗？会不会泄露？

这是第二个最关心的问题，也必须回答好。方案：私有化部署，代码不出企业边界。

推进节奏上，倾向于先选 1~2 个非核心产品试点 3 个月，积累效果数据，再全面推广。不急着一步到位，先跑通再扩大。

四、总结：三层递进，环环相扣

把前面说的串起来，其实就三层：

┌─────────────────────────────────────┐
│  第三层：主动防御（自动化漏洞挖掘）       │
│  → 先于攻击者，把漏洞先挖出来、先修完     │
├─────────────────────────────────────┤
│  第二层：流程自动化（响应 + 日志分析前置） │
│  → 漏洞响应从"天级"压缩到"小时级"        │
├─────────────────────────────────────┤
│  第一层：数据可信（SBOM 数据底座）       │
│  → 先知道自己有什么，影响面确认秒级完成    │
└─────────────────────────────────────┘

安全建设最忌讳一上来就搞大而全。

先解决最痛的问题，把基础打扎实，再逐步往上走，效果往往比一口气搞个大平台要好得多。

五、为什么现在必须做

最后说一个不太好听但必须面对的事实：

攻击者已经在用自动化工具了，国家级攻防演习就要来了...

这不是"未来趋势"，是"正在发生"。不用同样的技术守护自己的产品，等于用冷兵器对抗热武器。但做的时机很重要。不是所有事都要今天干完，但方向要对、起步要早。