Linux内核现在可是个重灾区，CVE系统直接给它压垮了。自从Linux成了CNA以后，CVE的数量那是刷刷往上涨，搞得安全团队都忙不过来。关键是吧，有些严重的内核漏洞就被大家给忽略了，这直接影响到了系统信任根。 这就好比我们的心脏出了问题一样，你说要命不要命？原来那个CVE系统根本没法应付这么复杂的内核安全问题。还是得说Jed Salazar说的对。 Linux内核开发人员平时工作压力那是真的大。一方面要给世界上最流行的操作系统开发新功能，另一方面还得保证老用户的设备能继续用，根本不能随便动用户空间。 一年前社区决定自己当CNA时，大家都觉得这是件好事儿。毕竟对运行世界基础设施的大平台来说，跟安全行业统一标准总感觉是有点迟来的福分。 不过自从当了CNA以后，内核社区开始大面积地分配CVE了。以前邮件列表上的小毛病也被标上了CVE。这其实也是为了符合那个啥CVE模型嘛。结果呢？现在看漏洞报告的时候，内核问题跟用户空间库、应用程序的错误都混在一起了。 最近Cisco的Jerry Gamblin把2025年的CVE数据发出来了，真的是吓人一跳！今年一共报告了48,185个CVE。Linux内核居然以绝对的数量优势拿下了头把交椅，成了最脆弱的技术。 这些漏洞有的就是逻辑错误，有的需要特定配置才会出问题。还有的就是理论上的影响。只有一小部分是能在生产环境里直接利用的。但CVE模型不管这些区别，直接把每个问题当成一样的东西来看待。 安全专业人士现在都被训练成那种看一眼就分类忽略的样子了。谁也没那么多时间和精力去仔细分析每一个漏洞啊！当警报多到这种程度时，大家反而会觉得“哎呀这就平时那样呗”，久而久之就习惯了。 当所有事情看起来都很急的时候，真正威胁到系统信任根的警报反而最容易被漏掉。内核CVE就是最容易遭受这种待遇的受害者——不是因为不重要，而是因为它们总是被排在其他控制措施之后。 其实“淹没式披露”并不能自动带来更好的安全效果，反而容易让人变得麻木不仁。我们一直讨论的边界问题你知道吗？Linux内核可不是随便一个需要修补的组件那么简单。它是云原生环境中所有安全控制的执行层啊！ 什么命名空间、cgroups、seccomp还有LSMs和基于eBPF的工具啊，都是建立在“相信内核”的基础上的。如果这个假设不成立了，那上面的一切都会被攻破。要是这个层面的漏洞漏了网眼，那就真的没人能救了。 但说实话啊，大多数人都觉得容器之间有硬边界其实是错觉啦！容器只是个进程而已，真正的隔离是靠共享内核状态实现的。一旦这个状态被破坏了，所谓的隔离就彻底崩溃了。 可是安全讨论经常绕开这个点不谈。大家老是盯着漏洞数量、严重性和合规性看，却不去思考那些内核级别的故障到底能不能真的被控制住。 所以啊，忽略内核安全漏洞根本不是什么胜利。Linux社区绝对值得大大赞扬一番。能做到这种规模还保持几十年的稳定性和安全性真的很不容易了。 当内核每周都产生几十个CVE的时候，大多数团队真的没有什么现实的办法去搞清楚到底哪些威胁到了他们的隔离模型。 CVE在记录已知缺陷上确实有用处，但它们是用来推理系统信任根中未知故障模式的错误接口啊！最危险的情况就是最重要的漏洞正在悄悄地被忽略掉呢！