2026-05-27 05:33:13 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文探讨了在AI技术推动下，软件漏洞数量激增的通胀现象及其带来的挑战，并提出了三层破局架构。文章分析了Mythos等AI工具对代码安全审计的影响，指出漏洞发现速度远超修复能力。解决方案包括：第一层构建SBOM数据底座以清晰掌握产品构成；第二层通过流程自动化提升漏洞响应效率；第三层采用主动防御，利用大模型进行自动化漏洞挖掘，以从根源上减少漏洞。 综合评分： 85 文章分类： AI安全,代码审计,应用安全,网络安全,解决方案

cover_image

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

原创

aerfa21 aerfa21

我的安全视界观

2026年5月25日 06:06 北京

在小说阅读器读本章

去阅读

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

📋 文章结构概览一、背景：Mythos 三事件冲击波├─ 事件一：Mythos 发布（2026-04-07）├─ 事件二：curl&nbsp;维护者实测（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。两个能力，以前的工具做不到：

| 能力 | 说明 | | — | — | | 自主推理 32 步以上逻辑链 | 能发现”A 调 B、B 调 C、最后在 D 爆炸”的深层逻辑漏洞 | | 自动生成 Exploit | 不仅告诉有漏洞，还能直接写出攻击脚本 |

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

💡 这意味着什么？

攻击门槛被压到历史最低。

以前挖一个深层逻辑漏洞要高级安全研究员花几周，现在 AI 几小时搞定。

防守方的时间窗口，正在急剧收缩。

#

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

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

| Mythos 报告 | Stenberg 验证结论 | | — | — | | 漏洞 1 | ❌ 误报 | | 漏洞 2 | ❌ 误报 | | 漏洞 3 | ❌ 误报 | | 漏洞 4 | ⚠️ 普通 bug（非安全问题） | | 漏洞 5 | ⏳ 待确认 | | 真实安全漏洞 | 仅 1 个，且为低危 |

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

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

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

💡 这说明什么？

Mythos 不”神话”。

AI 挖洞的时代确实到来了，但真正的瓶颈不在”能不能发现”，而在”发现的问题里，哪个真的危险、该优先修“。

#

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

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

| 指标 | 数据 | | — | — | | 合作伙伴数量 | 约 50 家 | | 扫描开源项目 | 1,000+ 个 | | 漏洞发现总数 | 23,019 个 | | 高危+严重漏洞 | > 10,000 个 |

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

💡 残酷现实：

以前一个高危漏洞从发现到修复，可能要几周甚至几个月。

现在 AI 一个月能发现 1 万个高危漏洞——修复速度根本追不上发现速度。这个剪刀差，就是产品安全团队下一个十年最核心的问题。

#

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

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

必须先于攻击者，用 AI 把自家产品的漏洞先挖出来、先修完

漏洞响应流程必须提速，从”天级”压缩到”小时级”

最终目标：让漏洞少一点，而不是被动跟着漏洞跑

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

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

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

| 发现方式 | 年度发现量（估算） | | — | — | | 传统 SAST/DAST 工具扫描 | 50~200 个（误报率 30%~70%） | | 人工渗透测试（1~2 次/年） | 5~20 个 | | 第三方漏洞众测/赏金计划 | 3~15 个 | | 合计 | 约 60~235 个 |

而 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 数据底座

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

| 工具 | 作用 | | — | — | | 产品安全管理平台 | 管理产品与仓库的关联关系，产品历史漏洞信息 | | SCA 工具 | 自动扫描代码仓库中的组件信息 |

两者结合，建起SBOM 清单：

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

有了这个数据底座，后面的自动化才有了根基。

就像做研发安全流程设计时说的一样——安全不能自己造流程，必须结合公司的实际情况。

数据底座也是一样，不是从零搭一个完美体系，而是在已有基础上把关键数据补齐、连起来。

#

踩过的坑

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

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

#

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

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

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

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

#

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

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

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

极速模式下（理想型）：

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

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

极速模式能不能跑起来，取决于 SBOM 数据准不准、客户台账清单准不准。

数据不准，自动推送就是灾难。

#

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

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

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

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

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

#

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

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

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

#

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

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

一句话总结：

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

#

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

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

| 方案 | 优点 | 缺点 | | — | — | — | | 开源模型私有化部署（DeepSeek/Qwen/Llama3） | 代码和数据完全在内网，一次性投入，成本可控 | 需要自建算力 | | 企业版 API 服务（Azure OpenAI / GLM） | 无需自建算力，开箱即用 | 代码需传到外部，有泄露风险 |

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

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

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

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

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

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

五、为什么现在必须做

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

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

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

长按识别二维码，和我交流

More…

—— 拥抱AI ——

AI for Security：方法不对，干活越累？

— 深耕研发安全 —

数字化转型下的研发安全痛点
从安全视角，看研发安全
基于研发过程的漏洞治理及经验
DevSecOps实施关键：研发安全团队
DevSecOps实施关键：研发安全流程
DevSecOps实施关键：研发安全规范

— SDL 100问 —

SDL100问：我与SDL的故事
SDL 1/100问：SDL与DevSecOps有何异同？
SDL 2/100问：如何在不同企业实施SDL？
SDL 3/100问：SAST误报太高，如何解决？
SDL 4/100问：SDL需要哪些人参与？
SDL 5/100问：在devops中做开发安全，会遇到哪些问题？
SDL 6/100问：如何实施安全需求？
……
SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？
SDL 99/100问：如何进行软件安全需求分析？
SDL100问：阶段性的完结

— 软件供应链对抗探索 —

软件供应商面临的攻防实战风险
软件供应商实战对抗十大安全举措
软件供应商攻防常规战之SDL

——— 实战演习 ———

1 何为多维度的视角
2 关于对演习的期望
3 公司层面统筹布局
4 实战攻防演习下的产品安全保障
5 产品安全事件定级评分方法
6 演习前红队暗泉涌动投毒
7 面向情报公司付费信息的应急
8 面向互联网侧情报信息的应急
9 客户侧产品推送样本事件处置
10 某邮箱被攻击情报的自我检查
11 办公网出口地址攻击客户蜜罐
12 SRC白帽子突破边界进业务网
13 某部门下发零日漏洞确认函处置
14 公司溯源团队查到团队内部成员
15 演习后对工作技能的复盘总结
16 演习后认知外的见微知著

——— 安全运营 ———

安全事件运营SOP：软件供应链投毒事件
安全事件运营SOP：接收漏洞事件
安全事件运营SOP：webshell事件
安全事件运营SOP：蜜罐告警
安全事件运营SOP：网络攻击
安全事件运营SOP：钓鱼邮件
企业级供应链投毒应急安全能力建设
应急能力提升：实战应急困境与突破
应急能力提升：挖矿权限维持攻击模拟
应急能力提升：内网横向移动攻击模拟
应急能力提升：实战应急响应经验
应急能力提升：应急响应报告点评
应急能力提升：应急响应专题总结会
应急响应：redis挖矿（防御篇）
应急响应：redis挖矿（攻击篇）
应急响应：redis挖矿（完结篇）

——— 软件安全 ———****

开篇
安全培训
安全需求
安全设计
安全开发
安全测试
安全审核
安全响应
完结篇（全系列paper下载）
浅谈安全产品的hvv安全之道
Shift Left在开发安全中的应用

——— 企业安全 ———****

企业安全建设需求
企业安全威胁简述
企业安全架构建设
企业安全项目-测试环境内网化
企业安全项目-Github信息泄露
企业安全项目-短信验证码安全
企业安全项目-前端绕过专项整改
业务安全之另类隐患
应用发布之安全隐患
甲方眼里的安全测试
基于堡垒机的自动化功能实践1
基于堡垒机的自动化功能实践2
基于堡垒机的自动化功能实践3
基于堡垒机的自动化功能实践4
Nmap操作系统探测技术浅析
漏洞情报调研
漏洞调研报告（非完整版）
从漏洞视角看敏捷安全

——— 渗透测试 ———****

安全运维那些洞
安全业务那些洞
那个简单的威胁情报
Android APP数据存储安全
搜集SRC信息中的“技术活儿”
常规渗透瓶颈，发散思维突破

——— 安全开发 ———****

python武器库
漏洞扫描器资产处理
python代码审计武器I
python代码审计武器II
Nodejs代码审计武器
fortify漏洞的学习途径

——— 个人体验 ———****

如何学习这么多的安全文章（实践篇）
如何学习这么多的安全文章（理论篇）
漫谈在安全公司做内部安全的体验
C3安全峰会参后感
提高认知效率秘籍
向上型技术人的职业素养
关于勇气的一次突破
推荐：探索精神和财富自由之路

免责声明：

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

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

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

本文转载自：我的安全视界观 aerfa21 aerfa21《漏洞通胀时代：产品安全的三层破局架构思考》