Linux内核拥抱CVE！为应对欧盟CRA，开源项目需重视安全。成为CNA可控漏洞管理，避免虚假CVE。利用Git仓库以JSON格式公开漏洞信息，实现自动化。CVSS评分需谨慎，考虑项目多用例。拥抱云原生安全，刻不容缓！
译自：How Linux Kernel Deals With Tracking CVE Security Issues
作者：Steven J Vaughan-Nichols
NAPA, Calif. — 不管你喜不喜欢，我们都依赖于 Common Vulnerabilities and Exposures (CVE) 公告来追踪安全问题。这些公告又由 CVE Naming Authorities (CNA) 分配。你可能会问，谁来运行这些机构？很快，如果你、你的开源项目或项目想要运行，就可以成为其中一员。准备好了吗？可能还没有。
CVE 是安全漏洞的标准化标识符，而 CNA 是被授权分配这些标识符的实体。传统上，像 Red Hat 和 Oracle 这样的公司为开源项目管理 CVEs。这种方法一直存在一个问题，即供应商当然只关注与其产品相关的漏洞。
但现在这已经不够了。由于欧盟 (EU) 的《网络弹性法案》(CRA) 已经通过，任何在“商业活动”中使用的开源软件都必须“制定并记录网络安全策略，向网络安全机构通报被积极利用的漏洞”。简而言之，你很可能需要成为 CNA 并发布 CVE。
还有其他充分的理由这样做。例如，你可以确保所有漏洞，无论使用情况如何，都能被识别和解决。另一方面，你可以。正如 Red Hat 开发者 Nikita Popov 在 Ycombinator 上所说，你可以“ 减少因安全研究人员试图充实他们的投资组合而为你的项目发布的虚假 CVE 的数量”。
大量半生不熟的 CVE 可能会让人非常头疼。问问流行的开源命令行复制工具 cURL 的创始人兼首席开发者 Daniel Stenberg 就知道了，他多年来一直在 与虚假的 CVE 作斗争。由于这些 CVE 浪费了 cURL 开发者的时间和精力，Stenberg 在 2024 年决定是时候 控制 cURL 的 CVE，并“让未来更难提交更多愚蠢的 curl CVE”。
Linux 内核开发者也在同年成为了 CNA。正如 Linux 稳定内核维护者 Greg Kroah-Hartman 当时写道，虽然他认为“[CVE] 系统总体上在很多方面都已崩溃](http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/)，但这种改变是我们承担更多责任的一种方式，并希望随着时间的推移使流程变得更好。” Kroah-Hartman 补充说，“看起来所有开源项目都可能被强制执行最近的规则和法律。” 那一天已经到来。
在 Linux Foundation Member Summit 上，Kroah-Hartman 在一次演讲中表示，在欧盟，“CRA 将使项目承担责任，而美国则假定项目承担责任。因此，“开源项目不能再躲在公司背后了。” 换句话说，“Red Hat 只为 Red Hat 着想，而不是为你着想。”
幸运的是，Kroah-Hartman 继续说道，开源组织成为 CNA 已经变得容易得多。这要归功于 CVE.org 和 Open Source Software Security Foundation (OpenSSF) 的工作，成为 CNA 已经变得容易得多。要了解如何做到这一点以及如何保持良好信誉，GitHub 整理了一份有用的 CNA 操作指南。
哪些安全漏洞需要 CVE？根据 CVE 组织的说法，它是“产品中一个或多个弱点的实例，可以被利用，从而对机密性、完整性或可用性产生负面影响；一组允许违反明确或隐含安全策略的条件或行为。”
然而，Kroah-Hartman指出，你可能认为某些是漏洞，需要分配一个CVE，但实际上并没有分配。例如，数据损坏和性能问题不被认为是值得分配CVE的。请注意，你可能会认为“一个用零覆盖你磁盘的错误”是一个严重的问题。Greg当然认为，“如果我丢失了我的数据，我会很生气。但既然你不是因为受到攻击而‘丢失’了你的数据，那么它就不是一个‘安全问题’。”
虽然在美国和中国（也使用CVE）可能仍然这样看待这些情况，但欧盟可能会改变其CVE规则。布鲁塞尔的官员正在考虑将数据损坏和系统性能问题纳入程序员、公司和开源组织需要跟踪的事项。请继续关注。
现在Linux内核开发人员正在发布CVE，Kroah-Hartman解释说，他们还在Linux安全漏洞信息公开Git仓库中以JSON格式提供这些信息。他“认为所有项目都应该有一个公共仓库，以可读的形式存储这些信息，以便可以扫描和搜索。”
这很重要，因为这可以帮助你自动化你的CVE分配、报告和解决流程。相信我，你会想要自动化这个流程的。仅Linux内核平均每周就有94个CVE。不要对这个数字感到恐慌，这些CVE中很少会给你带来麻烦。Kroah-Hartman补充说，“成为CNA大大减少了[CVE]阴性误报，同时略微增加了阳性误报，但总的来说，对于识别已修复的缺陷是有益的。”
他继续说，CVE只有在补丁发布后才会发布。“根本没有预先披露！”这是因为从Linux内核团队的角度来看，“所有‘提前通知’列表都是泄露。”
另一点重要的是，对于Linux内核和一些其他项目（如cURL）而言，他们不会为他们的CVE分配通用漏洞评分系统（CVSS）分数。这些分数范围从0.1到10，用于揭示给定安全漏洞的严重程度。
为什么？正如Greg解释的那样，“Linux有很多用例。”例如，“最著名的是，有一个Linux漏洞被分配了一个非常非常高的风险评分，因为当它在Android中使用时，你可以利用该漏洞接管一部锁定的手机。服务器人员会说，‘为什么这个分数这么高？它根本不影响我们，因为这不是我们的用例。’”但最终，这个CVE“最终出现在美国政府的名单上，该名单规定所有Linux系统都必须进行此修复，即使它对服务器根本没有影响。因此，对他们来说，它的CVSS评分为零。”因此，如果你的项目也有多个用例，他警告说，你最好不要分配CVSS。
Kroah-Hartman还强烈建议所有开源项目应该：
- 成为CNA，以便他们可以控制自己的命运。
- 编写工具来自动化事情
- 以中立的方式保存信息
是的，这将需要更多的工作，但除了很快成为在欧盟开展业务的必要条件之外，如果做得正确，它将使你能够提供关于漏洞的高质量、详细的报告，包括特定的提交和受影响的代码范围。反过来，这将使你的内部和外部开发人员，甚至你的用户，能够更好地理解和解决安全问题。