Mythos一声惊雷，IBM砸50亿保卫开源

James
James

James谈安全

2026年5月29日 11:26
江苏

在小说阅读器读本章

去阅读

Mythos一声惊雷，IBM砸50亿保卫开源

开源安全防护概念图

IBM CEO Arvind Krishna说了句大实话：\"Mythos was the critical triggering factor on this.\"

翻译：Anthropic的Mythos模型，是IBM砸50亿美元搞开源安全的直接导火索。

5月28日，IBM和Red Hat联合发布Project Lightwell——50亿美元承诺、2万名工程师、一个企业级开源安全\"票据交换所\"。高盛、摩根士丹利、摩根大通、美国银行……华尔街最有钱的那批银行，已经成了第一批吃螃蟹的人。

这不是一次普通的安全投资。这是一家巨头对AI时代安全范式转移的全押。

Krishna为什么被Mythos吓到了？

Krishna在CNBC采访里原话是：\"大语言模型在发现漏洞方面remarkably adept（异乎寻常地擅长）。\"

这话说得客气了。来看看Mythos到底干了什么——

• Anthropic的Mythos Preview在开源软件中发现了近3900个高危和严重级别漏洞
• Project Glasswing首月总共产生23019个候选发现，外部安全公司审查了1900个，90.8%确认为真实漏洞
• 向维护者报告了1596个经验证的漏洞，只有97个被修复，修复率约6%

6%的修复率。这就是Krishna被吓到的真正原因——AI发现漏洞的速度，已经远远超出了人类修复的速度。

Krishna说了一句更耐人寻味的话：尽管开了多次会议讨论应对方案，\"领导人尚未宣布一个连贯的战略来应对Anthropic最新模型带来的网络威胁。\"

换句话说：所有人都知道问题来了，但没有人知道怎么办。

所以IBM决定自己来。

Project Lightwell到底是什么？

简单说，IBM要建一个开源安全的\"中央结算系统\"。

运作流程是这样的：

企业发现漏洞 → 向Clearinghouse报告（可信中间人） → AI辅助审查、分类、排优 → 2万名工程师开发安全补丁、依赖加固 → 订阅企业获得生产级验证补丁 → 补丁协调推向上游开源社区

这里有个关键设计——可信中间人。企业不敢把漏洞直接报给开源社区（怕被攻击者利用），需要一个可信任的机构来中转。IBM要做的就是这个\"安全的中转站\"。

Krishna的精明：不抢地盘，补空白

Krishna在采访里把话说得很圆：

\"他们（传统安全厂商）擅长保护边界，擅长发现正在发生什么，但他们不做补丁，不做其他软件的保护。所以我认为，这是对他们工作的极大补充。\"

这不是客套。传统安全公司——CrowdStrike、Palo Alto、Zscaler——做的是检测和响应，是发现入侵后的止血。而Lightwell做的是补丁和修复，是在漏洞被利用之前把洞堵上。

theCUBE Research的分析直接把安全分成了四层，Lightwell每一层都在补位：

Krishna的策略很清晰：不去抢CrowdStrike们的饭碗，而是在它们身后建一个它们不想建也建不了的\"修复层\"。

海外分析机构的观点

RBC Capital：IBM有天然动机

RBC分析师Matthew Swanson的判断直指核心——IBM是全球最大的开源软件提供商之一，它有天然动机保护这个生态系统。

这句话的潜台词是：如果开源软件被认为不安全，IBM整个Red Hat产品线都会受冲击。50亿不是慈善，是护城河。

theCUBE Research：执行决定一切

theCUBE给出了最详细的分析，核心结论是：Project Lightwell在战略上对位精准、雄心勃勃，但执行将决定它是一个\"变革性信任层\"还是\"一个有前景但定制化的安全服务\"。

他们列了6个悬而未决的问题——

1. 运营模式

：提交漏洞的流程是什么？严重性怎么判定？谁验证可利用性？紧急补丁怎么分发？
2. 社区治理

：补丁推上游的机制是什么？披露时间线怎么管？不同治理结构的社区怎么协调？
3. 覆盖范围

：第一天覆盖什么？路线图是什么？\"深度掌握\"每个包意味着什么？定价模型？
4. AI验证透明度

：误报、漏报、幻觉怎么处理？客户需要审计证据证明补丁经过测试
5. 与现有工具集成

：是融入现有DevSecOps管道，还是又多一个孤立门户？
6. 责任和SLA

：验证过的补丁引入了不稳定怎么办？谁负责？关键漏洞的响应时间承诺？

SimplyWall.st：财务风险不可忽视

从投资角度看，SimplyWall.st指出了一个尖锐问题——IBM本身负债已经很高，50亿美元承诺叠加在现有债务上，对量子和收购等其他战略优先级构成压力。

他们的判断：战略方向积极，早期验证强劲（顶级银行客户），但50亿承诺增加了财务风险，投资者应等待商业化和超越金融行业的扩张信号。

IBM内部都有人唱反调

gnerdsec的分析提到一个有趣的细节——IBM研究员Lav Varshney公开表示：\"我不认为我们进入了什么新时代。\"

但gnerdsec的评论一针见血：EU AI Act不在乎内部争论。8月2日，它照常生效。

这件事对行业的深层影响

第一，安全行业的\"分工重构\"已经开始

2月份Mythos消息传出时，网络安全股集体暴跌——CrowdStrike跌10%，Zscaler跌10%，Cloudflare跌9%。代码扫描平台更惨，JFrog暴跌25%。

但Bank of America当时就指出：AI威胁的主要是代码扫描平台，不是端到端的安全平台。 CrowdStrike CEO George Kurtz在LinkedIn上回怼：\"AI扫描代码不等于替代Falcon平台。\"

Krishna的Lightwell聪明就聪明在——它不去抢检测层的生意，而是开辟了修复层。 这可能会催生一个新的安全细分市场：漏洞修复即服务（Patching-as-a-Service）。

第二，开源安全的商业化困局

theCUBE指出了Project Lightwell最核心的矛盾——

\"做好了，Lightwell能加固开源。做不好，它会被批评为商业化了一个应该保持广泛可及的信任层。\"

如果IBM和Red Hat成了漏洞情报和企业级修复的\"特权通道\"，小公司和社区项目能拿到同样的补丁吗？Clearinghouse是商业订阅制——付不起钱的企业怎么办？

这个矛盾不是IBM独有的。Anthropic的Glasswing也一样——50家组织入选，全凭Anthropic一家说了算，没有外部监督，没有审计机制，没有透明标准。

gnerdsec的分析挖出了Anthropic的一个矛盾：它一边运营着最受批评的封闭访问模型（Mythos/Glasswing），一边又参与Shared AI License Foundation推动AI许可标准。

IBM CCO Rob Thomas的话说得很漂亮：\"在基础设施规模下，安全更多是通过审视而非隐藏来改善的。这是开源软件的持久教训。\"

但gnerdsec也留了一个问号：\"对于能自主生成可运行exploit的模型，这个历史先例是否成立，是一个比Thomas的文章所承认的更开放的问题。\"

第三，金融行业成了安全创新的\"试验田\"

Lightwell的早期客户名单简直就是华尔街名人堂——高盛、摩根大通、摩根士丹利、美国银行、花旗、Visa、万事达、道富银行、加拿大皇家银行、纽约梅隆银行、富国银行。

theCUBE的分析说得很到位：\"如果你能让这套系统为摩根大通、花旗和高盛服务，你就拥有了向其余企业市场证明的极其可信的证据。\"

路径清晰：银行业 → 医疗、政府、电信、制造、关键基础设施。

金融行业就是安全赛道的\"首发阵容\"。谁拿下了华尔街，谁就拿下了行业定价权。

第四，EU AI Act是硬约束，不是软建议

8月2日，EU AI Act全面生效。高风险AI系统必须满足强制性透明度、人类监督和可审计性要求。

一个能在所有主流操作系统和浏览器上自主发现漏洞的模型，算不算\"高风险\"？这个问题不用IBM或Anthropic回答——监管机构会替他们回答。

写在最后

50亿美元，2万名工程师，11家顶级银行——IBM的Lightwell不是在做一个产品，它是在定义一个品类。

在Mythos之前，开源安全是\"社区的事\"。在Mythos之后，开源安全变成了\"基础设施的事\"。当AI能把0Day发现的成本降到接近零，当修复率只有6%的时候，\"等社区慢慢修\"就不再是选项了。

Krishna看得清楚：旧模式——定期扫描、提交工单、等维护者有空再看——已经太危险了。AI可以比人类更快地找到弱点，防御者也需要AI加上工程规模来工业化修复。

但IBM的挑战也很明确——50亿投下去，如果Lightwell只是又一个IBM式的\"大而笨重\"的企业服务，而不是一个真正融入DevSecOps管道的敏捷平台，那它就会变成theCUBE说的那种结局：\"一个有前景但定制化的安全服务\"。

更大的问题是：当一家公司同时是开源最大的商业受益者和开源安全的\"看门人\"，这种角色冲突谁来监督？

Rob Thomas说\"开放是设计要求\"，但Clearinghouse是收费的。Krishna说\"这是对传统安全的补充\"，但2万名工程师一旦跑起来，边界在哪里？

Mythos改变了游戏规则，IBM第一个下注。但这场牌局的终局，不是由IBM决定的——是由8月2日欧盟的法规、由开源社区的接受度、由6%修复率能否被改写来决定的。

最后一句：在AI时代，开源安全的最大威胁不是闭源模型，而是修复速度赶不上发现速度的结构性困局。IBM看到了这个困局，但50亿够不够填这个坑——这才是真正的问题。