Linux内核成为CNA后，CVE数量激增，淹没了安全团队。这导致关键内核漏洞被忽略，威胁系统信任根。现有CVE系统不适用于复杂内核安全。
译自：Linux kernel scale is swamping an already-flawed CVE system
作者：Jed Salazar
Linux 内核开发人员在极少数其他开源社区维护者所经历的约束下运作。发展世界上最流行操作系统的功能只是硬币的一面。另一方面是，你“永远不能破坏用户空间”，并且必须为数百万运行在 Linux 上的设备和用户维护向后兼容性和稳定性。
一年前，Linux 内核社区决定成为 CVE 编号机构 (CNA)，这在很大程度上被视为一场胜利。对于运行世界基础设施的最大平台来说，与安全行业事实上的安全披露机制保持一致，感觉是迟来的。透明度长期以来一直是 Linux 内核社区最强大的特征之一。这听起来像是一场巨大的胜利。
CVE 信息洪流中最吵的新贡献者
Linux 内核不仅仅是另一个依赖项。它是这种依赖。每个容器、每个命名空间、每个策略引擎最终都通过它运行。历史上，内核漏洞很少见，披露谨慎，并被严肃对待。当一个内核错误很重要时，你会知道。
当它成为 CNA 时，内核社区做出了一个有意的决定，广泛地分配 CVE，通常针对以前只存在于邮件列表中的错误。这是对要求为所有内容提供标识符的 CVE 模型的一种合规形式。结果是，内核问题现在与用户空间库和应用程序错误出现在相同的提要、仪表板和扫描器中。
现在，内核是已经压倒性的漏洞流中最吵的贡献者。
Cisco 的 Jerry Gamblin 最近发布了2025 年 CVE 数据回顾。2025 年，报告了 48,185 个 CVE。Linux 内核首次以纯粹的数量位居榜首，成为最易受攻击的技术。
其中一些内核漏洞是可能影响程序中特定路径的逻辑错误。其他可能取决于配置。此外，有些可能只是理论上的影响。其中一小部分问题可能会允许攻击者在生产环境中利用漏洞。然而，无论问题的类型或其是否可以在生产环境中被利用，CVE 模型将每个问题视为相同的工件。
安全专业人员正在被训练去分类和忽略
安全团队没有无限的时间或认知带宽。当漏洞披露达到如此高的数量时，分类成为默认操作。警报被确认，风险被常态化。
这种情况使得行业习惯性地忽略这些漏洞。当所有事情看起来都很紧急时，真正威胁系统信任根的警报反而会被错过。内核 CVE 特别容易遭受这种命运——不是因为它们不那么重要，而是因为它们位于团队用来遏制故障的所有其他控制之下。许多需要特定的配置或访问模式。有些是理论上的。另一些是可利用的。谁有时间和认知带宽来理解这些区别呢？
“当所有事情看起来都很紧急时，真正威胁系统信任根的警报反而会被错过。”
用大量披露信息淹没系统并不能自动产生更好的安全结果。它更有可能产生自满情绪。
我们一直在讨论的边界问题
内核不仅仅是另一个需要修补的组件。它是云原生环境中几乎所有安全控制的执行层。命名空间、cgroups、seccomp、LSMs 和基于 eBPF 的工具都假定内核是可信的。当这个假设失败时，其上的一切也都会被攻破。如果该层的一个漏洞被错过，则没有更高级别的控制来弥补。
但 Linux 执行模型创造了分离的表象，却没有提供大多数人认为容器所提供的硬边界。容器感觉是隔离的，因为它们隐藏了资源，但没有强制执行分离。容器仍然只是一个进程。边界是通过共享内核状态实现的。当该状态被破坏时，隔离完全崩溃。
然而，安全对话很少围绕这一点展开。它侧重于漏洞数量、严重性和合规性，而不是内核级别的故障是否真的可以被遏制。
忽略内核安全漏洞并非胜利
Linux 内核社区值得巨大的赞誉。很少有项目能在如此大的规模和悠久的历史下，像 Linux 一样在几十年里保持如此高的稳定性和安全性。成为 CNA 是一项善意的安全努力。
“当内核每周产生几十个 CVE 时，大多数团队没有现实的方法来理解哪些威胁到他们的隔离模型，哪些没有。”
但一年过去了，公平地问，行业到底从这场信息洪流中获得了什么价值？当内核每周产生几十个 CVE 时，大多数团队没有现实的方法来理解哪些威胁到他们的隔离模型，哪些没有。CVE 在编目已知缺陷方面是有效的，但它们是推理系统信任根中未知故障模式的错误接口。
危险在于，最重要的漏洞正在被悄悄忽略，因为这个系统已经教会我们停止倾听。
