LWN：2024年开源软件最重要的安全事件是哪些！

关注了就能看到更多这么棒的文章哦～

The top open-source security events in 2024

By Jonathan Corbet
November 11, 2024
OSS Japan
Gemini-1.5-flash translation
https://lwn.net/Articles/996955/

Marta Rybczyńska 最近进行了一项投票，并得到了一些有趣的结果。在 2024年Open Source Summit Japan上，她展示了这些结果，并发表了一些她自己的评论。这些事件对于 LWN 的读者来说不太可能令人意外，但是所呈现的总体情况值得一看。

CVE 编号趣闻

在她投票中得分相对较低（但仍然很重要）的一个事件与 CVE 编号的处理有关。她一开始就说，在今年早些时候才首次出现对 CVE 编号进行统计的可供机器读取的数据库。在那之前，一直是用各种自由格式的文本进行管理。她引用了CVE-2009-1377 作为示例，该条目的内容只有一句话描述了漏洞。没有简单的方法可以从该条目中提取相关信息——易受攻击的软件包、版本号、漏洞的性质或严重性等。国家漏洞数据库 (NVD) 正是为了解决这个问题而创建的；它的设计目的是吸收带有额外元数据的 CVE 数据。例如，将CVE-2009-1377 的 NVD 条目 与原始条目进行比较。NVD 数据库现在被漏洞扫描程序和其他类型的安全软件广泛使用。

她说，“NVD 危机”发生在今年 2 月，当时 NVD 突然停止添加新条目；目前尚不清楚为什么会发生这种情况。CVE 编号仍在分配，但它们并没有进入 NVD。几个月后，该流程重新启动，但 NVD 条目的添加仍然缓慢，并且积压量很大。这给依赖 NVD 数据的软件带来了问题。

在 CVE 方面，编号的分配速度比以往任何时候都快。许多著名的项目，包括 curl、Linux 内核和维基媒体基金会，都已成为 CVE 编号机构 (CNA)——但它们行动迟缓，因为大多数大型项目已经采取了这一措施。其中一些项目，如内核，正在发布大量的 CVE 编号。现在正在推出一种新的基于 JSON 的 CVE 条目格式；这应该有助于将来自动处理 CVE 编号。

她说，作为对 NVD 危机的回应，安全开发人员一直在要求创建一个不依赖于任何单一供应商解决方案的开放安全数据库。但是，只有当所有 CVE 条目都是机器可读的，这个数据库才有可能创建和维护。新的立法将强制自动处理漏洞信息，而来自新 CNA 的 CVE 数量的增加正在造成可扩展性问题。是否应该创建一个新的漏洞数据库或改进现有的数据库是一个悬而未决的问题。有很多数据库，包括OSV和GitHub Advisory Database，但它们都是单一供应商的解决方案。另一个悬而未决的问题是是否需要具有区域或国家重点的漏洞数据库。

与此同时，NVD 积压仍然很高，CVE 项目仍在努力让 CNA 正确编码其条目。一份完整的CVE数据以 JSON 格式从 GitHub 提供，但它是一个只读数据库。没有人可以提交拉取请求来修复或改进条目；相反，所有这些更改都必须通过相应的 CNA 进行。

趋势

谈到 2024 年出现的趋势，Rybczyńska 提到了支持使用 Rust 编写内核代码的工作。然而，内核并不是唯一发生这种变化的地方。像美国网络安全和基础设施安全局这样的机构一直在大力推动这一方向。她说，Android 项目自 2019 年以来一直在转向 Rust，这已经导致了错误数量的显著减少。

同时，C和 C++等语言的编译器正在获得新的警告，旨在避免漏洞。她说，现在已经很难做到在 C 语言中编写缓冲区溢出漏洞而不引发编译时警告。GCC 14 版本的静态分析器也获得了检测和说明多种类型错误（包括缓冲区溢出和无限循环）的能力。

在立法方面，最大的新闻是欧洲网络弹性法案 (CRA)，该法案为在欧洲销售的所有产品增加了强制性安全要求。她说，默认情况下，供应商必须对其是否符合这些要求进行自我评估，尽管被认为重要或关键的产品需要更高的审查程度。供应商必须免费提供安全更新，最短支持期限为五年。他们必须修复漏洞，包括其产品中包含的依赖项引入的漏洞。还有一个要求是对包含的软件尽职调查并报告安全事件。

她说，CRA 可能会在 11 月发布，三年后将全面生效。这项立法对开源项目的影响一直是人们讨论的话题；随着时间的推移，这导致 CRA 进行了许多修改。为项目的贡献者制定了保护措施；责任落在将项目货币化的人身上，而不是向其贡献补丁的人身上。支持开源项目的“管理者”也受到保护，但他们需要有安全相关的流程。

她说，开源软件现在规模太大，立法者无法忽视。这可以在 CRA 以外的领域看到；她提到了最近移除一些俄罗斯内核维护者 作为一个例子。然而，CRA 是最大的例子之一；这是一个“大事”，三年时间不足以为此做好准备。

她说，有一些倡议用于资助开源安全工作。OpenSSF Alpha-Omega 项目和Sovereign Tech Agency是两个突出的例子；后者明确地将拨款定向给维护者。然而，经济环境正变得越来越困难，这些资源是否会继续可用尚不完全清楚。

关于软件物料清单 (SBOM)，她指出，SPDX 3.0 于 4 月发布；它是该标准的完整重写，包括漏洞报告。CycloneDX 标准也发布了新版本。她说，SBOM 的生成正在增长，但这些数据的实际/使用/却落后了。

其他小事件

今年还有一些具体的漏洞也引起了人们的注意。XZ 后门尝试 就是其中之一；这是一项为期两年的努力，试图将恶意代码插入到鲜为人知（但无处不在）的软件中。这次攻击几乎成功了；就像Log4j漏洞一样，它突出了单一维护者项目带来的风险。在这两种情况下，问题都出现在一个通常不像安全风险的项目中。而且它提出了一个问题，即我们如何才能在我们编写和维护软件的开发人员身上建立和保持信任。

然而，根据她的投票结果，XZ 并不是今年最重要的安全事件；相反，是CrowdStrike事件。但是，她问道，既然它只影响 Windows，谁在乎呢？CrowdStrike 软件有一个 Linux 版本，但并没有崩溃；也许这是由于 Linux 端的更好架构（包括使用 BPF 而不是内核模块）的结果。但这也是运气的问题，这次我们很幸运。

她总结说，如果 XZ 攻击被检测到的时间更晚，它将导致一个影响网络上大约一半 SSH 服务器的后门。这很容易成为与 CrowdStrike 事件同等规模的事件——或者更糟。从这些事件中吸取的教训是，这种规模的安全故障也可能发生在开源社区中。

这段演讲的视频可在 YouTube 上观看。

[感谢 Linux 基金会，LWN 的旅行赞助商，支持我们参加此次活动。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～