XZ安全事件：声誉在安全中的重要性

为了有效保护软件供应链，开源社区必须优先考虑一套全面的声誉指标系统。

译自 XZ Security Incident: The Importance of Reputation in Security，作者 Eric Braun。

过去一个月，开源社区围绕 XZ 安全事件 展开热烈讨论。该事件涉及对 XZ 压缩库的复杂攻击，突显了开源软件生态系统中迫切需要 改进安全措施 和信任机制。

据报道，化名“Jia Tan”的个人在两年时间里为 XZ 库 的繁忙维护者提供帮助。该维护者是 Linux 社区备受尊敬的长期贡献者，最终授予 Jia 提交权限和 XZ 维护权限。此外，还有其他几个人或别名出现，通过向原始维护者施压以加快修复实施来支持 Jia。

一旦 Jia 获得对库存储库的控制权，就会将一个精心隐藏的后门谨慎地引入 liblzma，这是 Debian、Ubuntu 和 Fedora 等各种 Linux 发行版中 OpenSSH 的依赖项。该后门嵌入在压缩库中，监视攻击者在 SSH 会话开始时发送的特定命令，可能在受感染系统上启用未经授权的远程代码执行，而无需登录。

提高 OSS 安全性的三大问题

后门的发现可以归功于 PostgreSQL 项目的首席维护者 Andres Freund 的警惕，他在对 SSH 进行基准测试时检测到异常，表现为错误和 CPU 消耗增加。Freund 及时的检测有力地验证了开源社区在安全背景下坚持的“所有错误都是浅层的”原则。如果此漏洞存在于闭源软件中，其被发现的可能性将大大降低。

及时的检测有力地验证了开源社区在安全背景下坚持的“所有错误都是浅层的”原则。

尽管如此，XZ 事件强调了一个基本事实，需要开源社区和更广泛的软件行业关注。为了增强开源软件生态系统的安全性，必须解决三个关键问题：

1. 什么构成了最关键的软件？
2. 谁创建了该软件，他们值得信赖吗？
3. 他们开发的代码安全吗？

软件物料清单 (SBOM) 的持续快速采用最终将为我们提供分析和持续更新软件关键性的工具。在规模上，SBOM 将提供全面的普查，通过允许我们衡量软件使用情况及其功能角色的总和来准确确定软件关键性。一个能够跨标准规范化 SBOM 的新部分称为 Protobom，由 CISA（网络安全和基础设施安全局）、DHS 和 OpenSSF 提供，解决了迄今为止一直是重大挑战的兼容性问题。

关于代码安全性，CISA、MITRE、OpenSSF 和其他社区利益相关者等组织已经实施了各种举措来改进代码安全验证。这些措施包括为开源项目提供免费的模糊测试服务、扩大安全扫描工具的可用性以及倡导使用内存安全语言（如 Rust 和 Golang）重写关键软件。

对 OSS 信任的系统方法

在 XZ 情况下，问题在于信任。开源开发的开放性和民主性允许任何人，无论背景如何，随时为任何项目做出贡献。虽然这种包容性值得称赞，但缺乏可靠的机制来评估新贡献者的可信度构成了重大风险。社区目前缺乏声誉系统，该系统可以将没有先前参与记录的个人（如 Jia Tan）标记为潜在可疑人员，并保证对其贡献进行更严格的审查。

虽然声誉系统并非万无一失，但实施它们会让恶意行为者更难渗透和破坏开源生态系统。

至关重要的是要强调，声誉系统不会旨在排斥或减少社区中的匿名参与。匿名性和信任并不相互排斥，前提是个人已通过先前的互动和贡献建立了记录和声誉。有并且将有长期匿名贡献者通过时间证明自己的价值，通过不断出现在邮件列表、拉取请求和其他社区论坛中进行讨论和辩论。他们的贡献可以得到审查，但当然需要时间，并且他们将积累更多的信任。

声誉系统是获得信任的捷径。虽然声誉系统并非万无一失，但实施它们将使恶意行为者更难渗透和破坏开源生态系统。许多在线游戏社区已经这样做了，无论是公开的还是作为自动化审核系统的一部分。Uber 和 Lyft 为其司机建立了声誉系统。它是技术世界的组成部分，当它起作用时，声誉就成为信任的良好代表。

明确地说，信任和安全虽然相关，但却是不同的概念。仅凭信任并不能保证安全；任何代码，无论其作者是谁，都应接受相同严格且客观的安全性分析。在分配角色（例如维护人员）时，信任变得相关，这些角色涉及对代码更改背后的意图进行判断。在 Jia 的案例中，这些意图是恶意的。

正如 XZ 攻击明确展示的那样，缺乏健壮的声誉框架使开源软件面临重大风险。为了有效保护软件供应链，开源社区必须优先考虑开发和部署全面的声誉指标系统。这样的系统将授权维护人员负责保护关键软件，以便对信任谁做出明智的决定。它还将向社区透明地展示，提出代码的人是否值得怀疑，或者是否应该对其代码进行更严格的审查。启用跨开源的声誉指标将加强软件开发过程的完整性，并使我们所有人更加安全。