开源软件供应链安全五十年

数十年来，软件复用只是一个崇高的目标。现在它已成为现实。

Russ Cox

1972年3月，美国空军开始对 Honeywell Multics 系统进行审查，以了解它是否可以在安全环境中使用。该报告于1974年中期发布，结论是 Multics 虽然不安全，但比同类产品要好，并且可能是安全系统的合理起点。23 该报告提出了在无害的系统调用中添加后门（当时称为“陷阱门”）的可能性。当传递一个特定的、非常不可能的输入时，系统调用允许读取或写入内核内存的任意字。这个微小的改变会完全破坏系统的安全性，该报告调查了如何进行和隐藏这种改变的机制。

2024年3月，在 Microsoft 工作的 Postgres 开发者 Andres Freund 注意到，他的 Debian Linux 系统的 ssh 守护进程占用了比正常情况下更多的 CPU，以处理来自 Internet 的常见后台攻击流量，这些流量试图暴力破解登录到他的机器。经过仔细调查，Freund 发现最新版本的 liblzma（Debian 系统上链接到 ssh 的压缩库）包含一个专门针对 ssh 的后门。19 现在，当传递一个特定的、非常不可能的输入时，ssh 守护进程将允许 Internet 上的攻击者执行任意 shell 命令。这个微小的改变完全破坏了最前沿 Debian 系统的安全性，并且在接下来的几周内，世界各地的安全研究人员都在调查该改变是如何被进行和隐藏的机制。由于 liblzma 作为 xz 项目的一部分分发，因此这次攻击现在被广泛称为 xz 攻击。

半个世纪以来，软件供应链安全问题的大致轮廓并没有改变，因为它们是根本性的。计算机安全没有简单的答案；软件供应链安全也不例外。我们所能做的最好的事情就是不断改进我们的防御，并且许多有希望的增强措施尚未得到普遍部署。本文旨在重点介绍应更广泛使用的有希望的方法，并指出需要更多工作的领域。

我领导了 Go 编程语言和环境的开发15超过十年，而软件供应链安全是该工作的重点之一。本文借鉴了这项工作，并从我的个人经验中汲取了一些例子，此外还从整个软件行业中汲取了一些例子。

探索问题

开源软件供应链安全是一个热门话题，尤其是在 xz 攻击之后，但它到底意味着什么？在没有达成一致定义的情况下，我提出以下三部分定义：

  1. 开源软件供应链_攻击_是指在交付之前将恶意开源代码插入到受信任的软件中。（此定义改编自 Kim Zetter 的定义。35）
  2. 开源软件供应链_漏洞_是指由该软件的第三方开源组件引起的受信任软件中的可利用弱点。
  3. 开源软件供应链_安全_是对抗开源软件供应链攻击和漏洞的防御工程。

这个定义有一些重要的细微差别。

首先，硬件供应链不属于此处的关注范围。例如，Der Spiegel 在 2013 年报道说，美国 NSA（国家安全局）可以拦截目标订购的新计算机，并在其中安装后门软件或硬件组件。1 这种物理攻击超出了本文关于软件供应链的讨论范围，尽管在某些情况下可能仍然需要考虑和防御。

第二个细微差别是闭源软件组件不属于关注范围。例如，在 2012 年，攻击者闯入 Juniper Networks 并更改了 VPN（虚拟专用网络）源代码，替换了随机数生成器中的一些关键常量。其效果是创建一个后门，使攻击者可以解密 Juniper 的客户通过这些设备发送的所有 VPN 流量。8 这是一次软件供应链攻击，因为它在交付给 Juniper 的客户之前更改了软件。但这不是一次开源软件供应链攻击，因为恶意的更改不是在 Jupiter 的 VPN 中使用的开源组件之一中进行的。（由于 NSA 发起了可能被认为是一种算法供应链攻击的行为，随机数生成器最初很容易被植入后门。6）

作为另一个例子，中国的开发者经常在中国的文件共享网站上寻找 Xcode 的副本，因为下载速度更快。在 2015 年，安全研究人员发现攻击者发布了修改过的 Xcode 副本，并努力使其成为中文搜索“Xcode 下载”的首要结果。这个版本被研究人员命名为 XcodeGhost，它已被恶意更改，以便将恶意代码添加到它构建的每个 iOS 应用程序中。它被许多应用程序开发者下载和使用，注入的恶意软件进入了至少两个广泛使用的应用程序。34 这是一次针对分发机制而非原始软件的软件供应链攻击，但再一次，它不是针对开源软件。

第三个细微差别是，受影响的软件本身不需要是开源的。例如，在 2021 年，安全研究人员发现，当使用特定格式记录文本时，开源 Java 日志记录库 Log4j 会从任意 URL 下载并执行 Java 代码。33 Log4j 在 Java 生态系统中被广泛使用。作为数百万受影响程序中的一个例子，在流行的游戏 Minecraft 中，仅仅发送一条聊天消息就足以在游戏服务器上实现远程代码执行。因此，Minecraft 是一个受开源软件供应链漏洞影响的闭源程序的例子。由于几乎所有闭源程序都使用开源组件，2 因此它们都依赖于良好的开源软件供应链安全。

最后一个细微差别是，涉及以恶意意图编写的代码的攻击与涉及无辜错误的漏洞是不同的。例如，在 2021 年，Apple 修复了一个漏洞，该漏洞允许通过发送带有特殊制作的图像附件的 iMessage 来实现所谓的零点击接管 iPhone 设备。该附件将自己标识为 GIF，但实际上是一个包含 JBIG2 图像的 PDF。Apple 的软件使用了用 C 编写的开源 Xpdf JBIG2 解码器，并且该解码器没有正确验证图像中编码的 Huffman 树；这使得可以在攻击者控制的偏移处，在超出已分配区域的内存上触发按位操作。攻击者使用这些按位操作实现了一个完整的虚拟 CPU，然后在该虚拟指令集中实现了代码，以扫描进程内存、突破 iMessage 沙箱并接管手机。4 JBIG2 错误只是偶然（而非恶意）引入的，因此它是一个开源软件供应链漏洞，而不是攻击。漏洞和攻击是具有不同潜在解决方案的不同问题。

作为另一个例子，在 2018 年，研究人员发现 npm 包 event-stream 包含混淆的代码，当链接到 Copay 移动应用程序时，该代码会收集比特币钱包。21 恶意代码明确针对 Copay，使该应用程序成为受开源软件供应链攻击影响的闭源程序的例子。

虽然最后两个例子最终影响了闭源应用程序，但对纯开源软件堆栈的攻击也是可能的。xz 攻击正是这样做的，通过其软件供应链（liblzma）的组件攻击 OpenSSH，而不是直接攻击 OpenSSH 源代码或项目本身。即使是纯开源攻击也可能是毁灭性的：如果在发现之前又过去了几个月，带有后门的 sshd（安全 Shell 守护进程）将已部署在全球范围内的敏感环境中。

虽然没有灵丹妙药，但本文的其余部分重点介绍了工程化更好防御的一般主题以及今天正在采取的实际步骤。

了解软件供应链

要保护您的软件供应链，您首先必须了解它是什么。让我们从定义开始：_软件供应链_是可能发生软件供应链攻击或可能引入漏洞的所有地方。然而，_理解_更重要的含义是了解您特定的软件供应链是什么样的，而这最终变得非常困难。“链”这个词听起来很简单，但供应链就像一个分形：无论您多么仔细地观察它，它都是复杂的。

在最低级别，您可以查看为构建单个程序而执行的命令以及这些命令之间的依赖关系。这些构建图与程序本身的包依赖结构一致。即使对于简单的程序，这些图也非常复杂，以至于无法打印。Go 项目优先避免不必要的依赖关系并保持软件简单，15 但在我撰写本文时，构建 go 命令会执行 714 个命令来构建 297 个包，其包图中包含 3,132 个依赖关系边。go 命令的特殊之处在于它没有外部依赖关系：它使用的所有包都是 Go 项目本身的一部分。查看稍微复杂的命令，Kubernetes 的 kubelet 在其构建中执行 3,289 个命令，并依赖于来自 137 个 Go 模块的 1,581 个包，其中包括许多来自 Kubernetes 项目之外的模块。这两个例子都是相当小的底层实用程序。更高级别的程序具有更复杂的构建。在 acmqueue 本期中的另一篇文章中，Josie Anugerah 和 Eve Martin-Jones 更详细地研究了开源构建图的复杂性，以及大多数程序都有许多可能的构建图的令人惊讶之处，这取决于构建它们的确切上下文。

很容易认为这些类型的依赖关系图就是整个软件供应链，但它们只是最可见的部分。依赖关系图中的每个包或模块都可能由不同的人或组织编写，具有不同的安全实践、代码审查标准等等。了解您承担的每个依赖项的这些细节将很有帮助，但总的来说，此信息不可用，并且可能会随着时间的推移而发生变化。

另一种图显示了软件在构建期间和分发给用户期间经过的计算机和服务。可以在这些计算机或服务中的任何一个中进行恶意的更改，从而使每个计算机或服务成为不同的潜在攻击站点，更不用说漏洞的潜在来源了。您应该关注谁有权访问每个依赖项项目，谁将来可能有权访问，他们使用什么基础设施等等。在大多数情况下，在看不到任何这些信息的情况下，这些信息会被忽略。但它们仍然存在。

了解软件供应链对于确定哪些环节需要加强至关重要。作为一个行业，我们在这里还有很多工作要做，但对于本文，让我们继续讨论已知可以提供帮助的具体增强措施。

验证软件

Multics 审查考虑在“分发阶段”插入后门，利用“不安全电信”以及使用“伪造文具”发送恶意的更新。措辞可能已过时，但想法并没有。XcodeGhost 是完全符合该方法的现代示例。解决这个问题是现代软件供应链安全领域最接近真正成功案例的事情。密码签名使在签名和验证之间恶意更改代码成为不可能。剩下的唯一问题是密钥分发：验证者必须知道谁应该对代码进行签名。

对于密钥分发问题，有很多可能的答案。最简单的方法是忽略身份问题，而是简单地记录和分发给定构建或包管理器中使用的特定依赖项版本的预期密码哈希。验证这些预先分发的哈希完全消除了下载服务器、代理和其他网络中间盒作为潜在攻击站点。Debian 的依赖项打包系统包括这样的检查，这意味着 xz 攻击者不能简单地修改 xz 的现有副本；他们需要发布一个新版本。这并没有阻止攻击，但确实使攻击变得更加困难。

在更大的范围内，可以不在预先分发所有这些哈希，而是将它们保存在受信任的数据库中。Go 校验和数据库16是这种方法的真实示例，可以保护数百万 Go 开发者。该数据库保存每个公共 Go 模块的每个版本的 SHA256 校验和。每个数据库条目都由数据库服务器的私钥签名。相应的公钥被硬编码在 Go 命令源代码中，因此密钥分发搭在 Go 分发的其余部分上。

每次 go 命令下载新的开源 Go 包时，它都会查找预期的校验和。给定项目的依赖项有一个本地校验和缓存，因此只有在升级或添加新的依赖项时才会进行对校验和服务器的网络调用，但无论如何，都会检查每次下载。这意味着代码托管和用户计算机之间的所有代理和其他框都不能成为攻击站点。即使攻击代码托管站点也无法更改旧包。

当然，存在着应该将什么校验和放入数据库的问题。对于 Go 来说，如果数据库尚未记录特定的包版本，它会直接获取代码并存储它获取的代码的校验和。这种“首次使用时信任”的方法并不意味着代码是值得信赖的，但它确实意味着如果明天其他人在不同的计算机上下载它，代码就不能更改。这种不变性确保整个 Go 生态系统就 Kubernetes 版本 1.28.4 的含义达成一致，这为任何其他分析工作奠定了基础。

在可以解决身份问题的范围内，让作者对他们的软件进行签名可以提供更强的保证。在 xz 的情况下，分发包使用个人的 GPG（Gnu Privacy Guard）密钥进行签名，从而可以区分由 xz 的原始（值得信赖的）维护者签名的包和由已控制该项目的攻击者签名的包。

使构建可重现

Multics 审查指出，恶意的更改可能“最好隐藏在已编译例程的二进制代码的更改中”，而相应的源代码保持不变。只有在从源代码重建之后，这样的更改才会持续存在，但大多数安装不会在没有理由的情况下重建源代码。这仍然是今天的问题。例如，在构建期间触发 xz 攻击的关键代码行仅包含在打包的分发中，而不包含在实际的源代码控制存储库中。14

验证二进制文件是否已被修改的最好和最明显的方法是重建它们并将结果与分发的二进制文件进行比较，但这假设构建是可重现的。由于计算机是确定性的，因此这听起来很简单，但是诸如构建计算机体系结构或计算机名称、临时目录的名称或当前时间之类的上下文信息很容易最终出现在某些构建输出中，从而使整个构建不可重现。“可重现构建”31项目旨在提高对可重现构建的普遍意识，并构建工具来帮助朝着所有 Linux 软件的完全可重现性取得进展。

Go 项目最近安排 Go 本身完全可重现，仅给出源代码，这意味着尽管构建需要一些运行某些操作系统和某些早期 Go 工具链的计算机，但这些选择都不重要。给定目标的构建会生成相同的分发位，无论您是在 Linux、Windows 还是 Mac 上构建，无论构建主机是 X86 还是 ARM 等等。强大的可重现性使其他人可以轻松地验证为下载发布的二进制文件是否与源代码匹配。这些二进制文件也会记录在 Go 校验和数据库中，并在 go 命令下载新的工具链时进行验证，这样就无法在传输过程中修改下载内容。10

验证软件和使构建可重现可以消除潜在的攻击媒介，尽管肯定不是全部。现在让我们将重点转移到漏洞上。

快速查找和修复漏洞

五十年前，人们曾经希望通过正确的设计和仔细的实施，可以使软件完全安全。现在我们有了更好的认识。认识到软件总是会存在漏洞，我们必须准备好在出现漏洞时尽快查找和修复这些漏洞。

由于攻击者也在寻找这些漏洞，因此最好的防御方法是首先查找和修复它们。最简单的例子是具有已知漏洞的过时依赖项。有许多可用的漏洞扫描工具可以识别这种情况，无论是特定于语言的工具（如 govulncheck 和 npm audit）、通用开源工具（如 osv-scanner）30 还是商业工具。所有这些工具的工作原理都是通过将构建的软件输入列表（软件材料清单）与已知漏洞数据库进行交叉检查。

工具或数据库的特定选择不如以前重要。开源软件社区已标准化了 OSV（开源漏洞）格式7，用于单独的漏洞描述，包括受影响的包和版本的精确算法描述。然后，OSV 数据库29聚合了所有特定于语言的数据库。CVE（通用漏洞和暴露）数据库的 JSON 5.0 模式也采用了 OSV 关于受影响的包和版本的精确信息，从而实现了 OSV 和 CVE 之间的互换。对于所有工具都可以访问关于已知漏洞的相同完整信息，这对每个人都有好处。

定期扫描您的软件非常重要，理想情况下是每天，因为即使您的软件没有更改，数据库中也会始终添加新的条目。然后，您需要准备好更新到该依赖项的已修复版本。这需要进行全面的测试，以确保已修复的版本不会引入任何新的错误，并需要进行自动部署，以便可以在数小时或数天而不是数周或数月内发布软件的已修补版本。

测试和部署是标准的软件工程问题，并非专门针对供应链安全，但是如果没有它们，您的安全态势就会受到影响，您的法律风险也会受到影响。当在 2021 年发现 Log4j 漏洞时，大多数公司花费了数周或数月（或更长时间）来清点所有软件，以确定哪些软件受到了影响，然后更新和重新部署该软件。甚至美国 FTC（联邦贸易委员会）也发布了一份声明，警告公司更新 Log4j 以“减少对消费者的损害的可能性，并避免 FTC 采取法律行动”，18 并指出了 Equifax 先前因未经修补的软件导致的入侵而承担的责任。17

扫描已知漏洞只是最基本的要求。理想情况下，还应努力寻找开源依赖项中尚未发现的漏洞。当您对自己的源代码运行安全审核时，通常值得确定关键的开源依赖项并也对其进行审核。在您的软件及其依赖项上运行漏洞查找分析工具或模糊测试器也可能有效。攻击者将使用所有这些方法；您不妨首先使用它们。

预防漏洞

即使软件总是会存在漏洞，您也可以采取一些措施来预防某些类型的漏洞或降低它们发生的可能性。

首先，省略不必要的依赖项。Gordon Bell 曾经观察到，“计算机系统中最便宜、最快和最可靠的组件是不存在的组件。”5 最安全的软件依赖项是首先未使用的那些：每个依赖项都会增加风险。

OpenSSH 项目在不承担不必要的依赖项方面非常谨慎，但 Debian 并不那么谨慎。该发行版修补了 sshd，使其链接到 libsystemd，而 libsystemd 又链接到各种压缩包，包括 xz 的 liblzma。Debian 放松 sshd 的依赖项态势是攻击的关键推动因素，也是其影响仅限于基于 Debian 的系统（如 Debian、Ubuntu 和 Fedora）的原因，从而避免了其他发行版（如 Arch、Gentoo 和 NixOS）。在 xz 攻击部署前几周，系统开发人员一直在讨论删除对 liblzma 等压缩器的依赖项，特别是为了提高安全性。这纯粹是猜测，但这些讨论可能加速了启动攻击的时间表。3

同样的教训适用于所有项目，无论大小。如果有可能在没有依赖项的情况下生存，那通常是最好的。如果不是，则小依赖项比大依赖项更好，并且传递依赖项的数量很重要。不仅要查看正在添加的一个依赖项，还要使用诸如 Open Source Insights27之类的工具来查看其对整个依赖关系图的影响。

预防漏洞的另一种好方法是使用更安全的编程语言，这些语言可以消除容易出错的语言特性或减少对它们的需求。在 2022 年，NSA 发布了一份关于“软件内存安全”的建议，鼓励使用诸如 C#、Go、Java 或 Rust 之类的内存安全语言来代替 C 和 C++。26 在对 C 和 C++ 的众多攻击中，手动内存管理和缺乏任何类型的边界检查只是使程序太容易出错，从而产生安全漏洞。它们对“未定义行为”的依赖增加了另一层危险。9 当然，世界上存在大量的 C 和 C++ 代码，并且不能在一夜之间放弃这些程序。但是，对于新的工作，采用更安全的语言具有重要的安全优势。

资助开源

来自 2020 年的一部著名的 xkcd 漫画描绘了建立在“内布拉斯加州的某个随机人员自 2003 年以来一直在默默维护的一个项目”之上的“所有现代数字基础设施”。25 这部漫画仍然是对情况的令人不安的准确评估。

在 2014 年，研究人员发现，Internet HTTPS 服务器广泛使用的库 OpenSSL 会通过发送回任意的服务器内存块来响应特定类型的格式错误的包。在某些情况下，该内存包括服务器的密钥材料。这不是攻击，而是一个无辜的编码错误。（OpenSSL 是用 C 编写的，因此这个错误非常容易犯并且遗漏；在使用具有适当边界检查的内存安全语言中，几乎不可能。）

该漏洞被命名为 Heartbleed，并在整个行业内引发了一场关于 xkcd 漫画中描述的确切情况的清算。当时，OpenSSL 由少数志愿者维护，只有一名全职开发人员。研究人员估计，花费大约 100,000 美元的安全审核本可以发现这个错误，但该项目每年仅收到 2,000 美元的捐款，尽管每年有数十亿美元的商业依赖于该软件。这次清算的一个结果是创建并资助了 Linux 基金会的 Core Infrastructure Initiative，该计划演变为开源安全基金会 OpenSSF。28

OpenSSF 是向前迈出的重要一步，但它尚未解决现代数字基础设施依赖于资金不足的关键项目的问题。还需要做更多的工作。

xz 攻击是最清楚地证明问题未解决的例子。它在很大程度上是由于开源资金不足以及任何技术细节造成的。这是 xz 攻击的故事。

Lasse Collin 在 2005 年启动了 xz 项目，使用 LZMA 压缩算法，该算法将文件压缩到 gzip 的大约 70%。随着时间的推移，这种格式被广泛用于压缩 tar 文件、Linux 内核镜像和许多其他用途。在大多数情况下，该软件是稳定的，不需要大量的持续关注。Collin 没有为此获得报酬，这不是他的全职工作。

在 2021 年末，一个使用（几乎可以肯定不是真实的）名字“Jia Tan”的攻击者开始向 xz 开发邮件列表发送带有小的改进的无害补丁。22 在 2022 年中，攻击者开始在邮件列表中使用其他帐户和名称发布帖子，抱怨发布和新功能的缓慢速度，并向 Collin 施压，要求将其控制权让给有更多时间的人。他们写道：“当前的维护者失去了兴趣，或者不再关心维护了。对于像这样的存储库来说，看到这种情况令人难过。” 还有，“我知道这对于所有贡献者来说都是一个业余项目，但社区希望得到更多。为什么不转移维护权...？”

压力运动奏效了。在接下来的一年半中，Collin 将越来越多的开发责任转移给了攻击者，攻击者通过进行诚实的改进和完成重要的维护工作来建立信任。在 2023 年初，攻击者构建了他们的第一个官方 xz 版本；随着 2023 年的进行，他们为实际攻击奠定了技术基础，最终于 2024 年初启动。13

在发现攻击后的几个月中，大多数猜测都集中在 xz 攻击很可能是由民族国家黑客进行的可能性上，22 没有任何一方的确认。无论谁负责，可能花费都不多。一位胜任的软件工程师全职从事一个开源项目两年，以获得其维护者的信任，可能花费不到一百万美元。漏洞利用代码本身的开发（非常复杂）可能花费大约一百万美元左右。进入 Internet 上绝大多数 Linux ssh 服务器的隐藏后门将价值数十倍，可能数十亿美元。开源项目的普遍资金不足使它们直接容易受到这种看似诚实的免费帮助的影响。

xz 攻击的社会工程也不是孤立的事件。在前面提到的 event-stream 攻击中，攻击者只是询问原始作者是否希望有人接管维护。在 xz 攻击之后，OpenSSF 和 OpenJS 基金会发布了关于针对 OpenJS 实施的类似运动的警告，但未成功。20

如何最好地资助开源开发远非显而易见。在 Heartbleed 和 Core Infrastructure Initiative 启动十多年后，问题显然仍未解决。

结论

我们都在努力应对过去 10 或 20 年软件行业发生的巨大转变。数十年来，软件复用只是一个崇高的目标。现在它已成为现实。12 诸如 Go、Node 和 Rust 之类的现代编程环境使重用他人的工作变得微不足道，但是我们关于负责任行为的直觉尚未适应这种新现实。

1974 年的 Multics 审查预料到了我们今天面临的许多问题，这一事实证明这些问题是根本性的，并且没有简单的答案。我们必须努力不断改进开源软件供应链安全，使攻击变得越来越困难和昂贵。

我们今天可以采取重要的步骤，例如采用某种形式的软件签名，确保定期扫描已知漏洞，并准备好在发现关键的新漏洞时更新和重新部署软件。越来越多的开发应转移到更安全的语言，这些语言可以降低漏洞和攻击的可能性。我们还需要找到资助开源开发的方法，以使其不易受到仅仅是提供免费帮助的接管的影响。对 OpenSSL 和 xz 开发的相对较小的投资本可以预防 Heartbleed 漏洞和 xz 攻击。

xz 攻击似乎是对开源软件供应链的第一次重大攻击。event-stream 攻击类似但并不重要，而 Heartbleed 和 Log4j 是漏洞，而不是攻击。但是 xz 攻击本质上是偶然发现的，因为它使 sshd 的启动速度稍微慢了一些。攻击的本质是试图保持隐藏状态。我们有多大的机会会在短短几周内偶然发现对开源软件供应链的第一次重大攻击？也许我们非常幸运，或者也许我们错过了其他攻击。

Multics 审查以指出向编译器添加后门以在编译期间在关键系统程序中插入后门的可能性而闻名，正如 XcodeGhost 后来所做的那样，然后指出让编译器后门_本身_的可能性，以便即使在完全重新编译编译器之后，修改仍然存在。阅读该报告启发 Ken Thompson 在早期的 Unix 系统上实施了完全相同的攻击，可能在 1975 年初。他后来在他的 1983 年图灵奖演讲中解释了这次攻击，该演讲以“对信任信任的反思”为名发表在 Communications of the ACM 上。32 Thompson 保留了原始的攻击源代码，并且在他的允许下，我在 2023 年发布了一个带注释的副本。11 也许最令人不安的部分是它有多短：99 行 C 代码和一个 20 行的 shell 脚本。

在他的演讲中，Thompson 说：“寓意很明显：您不能信任您自己没有完全创建的代码。” 但是今天，我们一直在这样做，无论这种信任是否合理。我们使用从 Internet 上的陌生人那里下载的源代码，将其用于我们最关键的应用程序中；几乎没有人检查代码。

Lawrence Kesteloot 出色的短篇小说“编码机器”24 想象了一个受到 Thompson 的大规模后门攻击的计算世界。在我们实际的世界中，根本没有必要使用这种复杂的后门。有更容易的方法来发起供应链攻击，例如询问维护者是否需要一些帮助。如果生活在一个攻击需要 Thompson 和 Kesteloot 描述的复杂程度的世界中，那将是很好的。

我们都有更多的工作要做。

参考文献

  1. Appelbaum, J., et al. 2013. Documents reveal top NSA hacking unit. Spiegel International; https://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969.html.
  2. Bals, F. 2024. 2024 open source security and risk analysis report. Blackduck blog; https://www.blackduck.com/blog/open source-trends-ossra-report.html.
  3. Beaumont, K. 2024. Inside the failed attempt to backdoor SSH globally — that got caught by chance. DoublePulsar; https://doublepulsar.com/inside-the-failed-attempt-to-backdoor-ssh-globally-that-got-caught-by-chance-bbfe628fafdd.
  4. Beer, I., Groß, S. 2021. A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution, Google Project Zero blog; https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html.
  5. Bentley, J. 1985. Programming pearls. Communications of the ACM 28(9), 896–901; https://dl.acm.org/doi/10.1145/4284.315122.
  6. Bernstein, D. J., Lange, T., Niderhagen, R. 2015. Dual EC: a standardized back door. LNCS Essays on the New Codebreakers 9100 , ed. P. Y. A. Ryan, D. Naccache, J.-J. Quisquater, 256–281; https://eprint.iacr.org/2015/767.
  7. Chang, O., Catlin, K. 2023. Getting to know the Open Source Vulnerability (OSV) format, OpenSSF blog; https://openssf.org/blog/2023/05/02/getting-to-know-the-open source-vulnerability-osv-format/.
  8. Checkoway, S., et al. 2018. Where did I leave my keys?: lessons from the Juniper Dual EC incident. Communications of the ACM 61(11), 148–155; https://dl.acm.org/doi/10.1145/3266291.
  9. Cox, R., 2023. C and C++ prioritize performance over correctness. research!rsc blog post; https://research.swtch.com/ub.
  10. Cox, R. 2023. Perfectly reproducible, verified Go toolchains. The Go Blog; https://go.dev/blog/rebuild.
  11. Cox, R., 2023. Running the "Reflections on Trusting Trust" compiler. research!rsc blog post; https://research.swtch.com/nih.
  12. Cox, R., 2019. Surviving software dependencies. Communications of the ACM 62(9) , 36–43; https://dl.acm.org/doi/10.1145/3347446.
  13. Cox, R. 2024. Timeline of the xz open source attack. research!rsc blog post. https://research.swtch.com/xz-timeline.
  14. Cox, R., 2024. The xz attack shell script. research!rsc blog post; https://research.swtch.com/xz-script.
  15. Cox, R., Griesemer, R., Pike, R., Taylor, I. L., Thompson, K. 2022. The Go programming language and environment. Communications of the ACM 65(5), 70–78; https://dl.acm.org/doi/10.1145/3488716.
  16. Cox, R., Valsorda, F. 2019. Proposal: secure the public Go module ecosystem. Go design document; https://go.dev/design/25530-sumdb.
  17. Federal Trade Commission. 2019. Equifax to pay $575 million as part of settlement with FTC, CFPB, and states related to 2017 data breach. FTC press release; https://www.ftc.gov/news-events/news/press-releases/2019/07/equifax-pay-575-million-part-settlement-ftc-cfpb-states-related-2017-data-breach.
  18. Federal Trade Commission. 2022. FTC warns companies to remediate Log4j security vulnerability. FTC Office of Technology blog; https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2022/01/ftc-warns-companies-remediate-log4j-security-vulnerability.
  19. Freund, A., 2024. Backdoor in upstream xz/liblzma leading to ssh server compromise. oss-security mailing list, Openwall; https://www.openwall.com/lists/oss-security/2024/03/29/4.
  20. Ginn, R. B., Arasaratnam, O. 2024. XZ Utils cyberattack likely not an isolated incident. OpenSSF blog; https://openssf.org/blog/2024/04/15/open source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open source-projects/.
  21. Goodin, D., 2018. Widely used open source software contained bitcoin-stealing backdoor. Ars Technica ; https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open source-software-to-steal-bitcoin/.
  22. Greenberg, A., Burgess, M. 2024. The Mystery of "Jia Tan," the XZ backdoor mastermind. Wired; https://www.wired.com/story/jia-tan-xz-backdoor/.
  23. Karger, P. A., Schell, R. R. 1974. Multics security evaluation: vulnerability analysis. U.S. Air Force Electronic Systems Division report ESD-TR-74-193, Vol. II; https://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf.
  24. Kesteloot, L. 2009. Coding Machines ; https://www.teamten.com/lawrence/writings/coding-machines/.
  25. Munroe, R. 2020. xkcd: Dependency. Webcomic; https://xkcd.com/2347/.
  26. National Security Agency. 2022. Software memory safety. NSA Cybersecurity Information Sheet version 1.1 (updated April 2023); https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF.
  27. Open Source Insights website; https://deps.dev/.
  28. Open Source Security Foundation website; https://openssf.org/about/.
  29. OSV website. A distributed vulnerability database for Open Source; https://osv.dev/.
  30. Pan, R. 2022. Announcing OSV-Scanner: vulnerability scanner for open source. Google Security blog; https://security.googleblog.com/2022/12/announcing-osv-scanner-vulnerability.html.