亲爱的 Linux 内核 CNA，你做了什么？

原文 ↗ Hacker News 讨论 ↗

CVE 的角色与含义

  • 几条评论强调，CVE 最初主要是作为唯一标识符，方便人们讨论同一个问题，而不是一份完整或权威的“真实”安全漏洞清单。
  • 也有人反驳说，在实践中，监管机构、企业和工具链已经把“有 CVE”视为“已知安全漏洞”的同义词，无论这是不是最初的设计。
  • 这种“预期用途”和“现实用途”之间的不匹配，被认为是核心张力所在。

Linux 内核“每个 Bug 都是安全 Bug”的做法

  • 内核社区长期以来的立场是：通常不可能可靠地区分“安全”与“非安全” bug，因此应当假定所有 bug 都可能与安全相关。
  • 成为 CNA 并为几乎所有修复都发布 CVE，在一些人看来是这一立场的逻辑延伸；在另一些人看来，则是有意“烧掉整个系统”，以暴露 CVE 流程的缺陷。

监管、合规与下游负担

  • 许多人担心，内核 CVE 激增会带来合规痛苦：更多分流处理、更多强制补丁周期，以及在受监管或长生命周期系统中的潜在安全/稳定性风险。
  • 有人认为，PCI-DSS、ISO、SOC2、CRA 等标准主要要求建立流程去发现并处理可被利用的漏洞，而不是盲目修补所有 CVE。一位评论者声称，CRA 明确排除了上游 OSS，并专注于可利用性。
  • 一个反复出现的观点是：从 Linux 受益的大公司应该为自己的分流处理付费，而不是指望无偿的内核开发者替他们对 bug 进行分类。

安全结果与攻击者视角

  • 支持者认为，更多 CVE 会提高透明度，并推动落后者采用滚动更新，这才是保持内核安全的现实方式。
  • 批评者则认为，含糊、无评分、事后补发的 CVE——再加上未修复 bug 没有 CVE——可能延长漏洞的可利用期，并使防御更复杂，尤其是对无法彻底升级的遗留系统而言。

质量、评分与工具链问题

  • 许多人认为 CVSS 评分带有主观性、可被“操纵”，而且常常误导人，但也承认工具链和监管体系都建立在 CVE + CVSS 之上。
  • 有人担心，Linux 大量仅作最低限度描述、且不评分的 CVE 会破坏或贬低现有自动化以及“清单式安全”流程的价值。

提出的应对与缓解措施

  • 建议包括：
    • 仅把 CVE 当作分流处理输入，而不是硬性要求。
    • 付费请供应商提供经过筛选的“干净数据流”和经过测试的更新。
    • 通过禁用未使用的内核组件、自动合并小版本更新来降低暴露面。
  • 也有人认为，那些天真地按 CVE 逐条合规的组织“只能怪自己”，并且必须改进自己的流程。