前言

我们中的许多人都会记得2021年12月，我们在亲戚家的客房里，弯腰驼背地坐在小型旅行笔记本电脑前，应对 Log4j 危机。Apache 软件基金会开发的开源 Java 日志框架中的这个漏洞被官方指标和软件专家评为严重漏洞。无论是通过补丁还是其他内联缓解措施，它都不是难解决的漏洞。然而，大多数组织面临的真正挑战是定位漏洞：这个该死的东西在哪里？它深藏在无数现代应用程序的供应链中，软件的生产者和用户根本没有可用的路线图来聚焦错误。

安全的难点是识别漏洞和发现潜入我们供应链的攻击者。相反，我们发现，了解我们制作的软件中有什么还需要大量的工作。

追踪软件中的内容的想法并不新鲜。自1990年代以来，学术界一直在谈论它。2000年代，软件世界的不同角落都在讨论早期的想法。未能考虑到开源许可证，许多大公司陷入了严重的法律麻烦。收集和利用供应商数据是重工业质量革命不可或缺的一部分，这场革命可以追溯到20世纪40年代末，戴明和“丰田革命”启发了几十年后的DevSecOps和现代软件革命。

确实，我们的软件供应链透明度太低，这真是太不可思议了。我经常用 Twinkie 来举例（由 Audra Hatch 和 Josh Corman 首次提出），提出这样一个问题：为什么我们对不可生物降解的零食的了解比对公司、政府和关键基础设施中运行的软件的了解更深入？

在我们开始了解如何实施软件物料清单 (SBOM) 的过程中，花点时间了解一下为什么我们一开始没有这种能力、我们如何开始取得进展以及这种透明度的价值是什么是很有用的。很少有组织愿意分享，原因有些不那么令人高兴，包括不想面临前面提到的开源许可证合规风险。坦率地说，许多组织不想承认技术债务的规模，也不想承担建立基本内部基础设施和流程来跟踪其依赖关系数据的成本。此外，应该承认，开始这段SBOM之旅并不容易——它需要汇集技术专业知识、对多样化软件生态系统的理解以及对激励措施的重视。但在过去五年中，已经取得了巨大的进展。

我们首先需要的是SBOM的共同愿景。许多专家都有一个大致的想法；这些想法在2018年至2020年期间在美国国家电信和信息管理局 (NTIA) 召集的开放、国际“多利益相关方流程”中进行了讨论和完善。社区定义了 SBOM 的基本知识并列出了其核心用例。然后，我们需要一种机器可读的方式来在整个供应链中传达这些信息。 幸运的是，软件界的一些人走在我们前面，所以我们能够调整 Linux 基金会的软件包数据交换 (SPDX) 和开放全球应用安全项目 (OWASP) 的 CycloneDX 以满足这些模型。

下一步是创建工具来生成和使用这些机器可读的数据。软件界在普遍实施 SBOM 方面取得了巨大进展，整个生态系统中都出现了新的工具。我们看到更多特定行业和技术的工具，因为工业控制系统 (ICS) 和运营技术 (OT) 固件领域的需求与传统企业软件有所不同，而传统企业软件与云原生领域相比具有独特的功能和集成。生成工具已经开始成熟，新工具不断涌现，以帮助组织在运营和战略上利用这些数据。（这是我工作中的一项福利，首先是在 NTIA，现在在网络安全和基础设施安全管理局 [CISA]，我会与初创企业和开源创新者会面，寻找满足整个软件市场实际需求的方法。）

当然，除了技术和市场之外，三脚架的第三条腿就是政府。近年来，美国政府一直致力于确保供应链安全，我们在世界各地的合作伙伴对此表现出浓厚的兴趣，并进行了政策创新。2021 年 5 月，SBOM 进入了网络安全政策的主要阶段，当时总统关于改善国家网络安全的行政命令 (EO) 宣布，除其他事项外，美国政府的供应商将向购买者提供 SBOM。在本书付印时，预计这些法规的最终细节将公布。这与美国食品药品监督管理局 (FDA) 对美国医疗器械的监管、其他美国监管机构的活动以及世界各地出现的拟议法规相一致。

因为这本书已经在您的手中或者屏幕上，所以您可能已经认识到整个软件供应链透明度的价值。但您可能必须说服其他人，在您的组织或软件生态系统中宣传，争取预算，或说服您的供应商共享数据。尽管信息安全供应商通常会夸大其词，但SBOM中的“SB”并不代表“银弹”。SBOM 是一个数据层。我们仍在构建工具和流程，将这些数据转化为情报，并最终付诸行动。就像公共漏洞和暴露(CVE)标识符实际上并不能修复您网络上的漏洞一样——而 CVE 现在是我们的全球漏洞生态系统不可或缺的一部分——因此，SBOM 也将成为软件安全和质量领域不可或缺的一部分。

软件供应链中的透明度有助于整个软件生命周期。对于软件开发人员来说，SBOM 是一种强大的工具，可以帮助我们了解流程，并确保我们不会构建设计不安全或存在已知风险的产品。对于选择或购买软件的人来说，为什么要使用不了解他们交付的产品的供应商？为什么我们可能会采用在使用前就已过时的软件？对于操作软件的人来说，如果没有SBOM，我们如何应对新发现的风险或为基于寿命终止或支持终止的软件构建的系统制定计划？当然，我们中的许多人都担任这三个角色。随着 SBOM 变得越来越普遍，不可避免地会发现和构建这些数据的更多用途。

软件透明度运动做出了许多令人难以置信的贡献，他们倡导 SBOM 的理念、构建工具并讨论重要的边缘案例。作者 Hughes 和 Turner 出色地捕捉了这些进步（包括他们自己的一些进步），并解释了从SBOM理念到SBOM实践的细节和细微差别。虽然我希望世界各地的从业者都能拿起这本书，为他们的组织和客户取得令人难以置信的成功，但我矛盾的是，我希望这本书的关键价值实际上是短暂的。随着我们中越来越多的人开始使用作者如此有益地设想的可互操作自动化类型来构建和管理我们的软件，并遵循他们制定的路线，SBOM 将不再是新奇和闪亮的，而是成为所有软件制造、销售和使用过程中自然而然的自动化部分。

到那时我们就可以迎接下一个挑战了。

Allan Friedman 博士 Allan Friedman 是网络安全和基础设施安全局的高级顾问和战略家。他负责协调围绕软件物料清单 (SBOM) 的全球跨部门社区工作。他曾担任 NTIA 的网络安全计划总监，领导漏洞披露、SBOM 和其他安全主题的开创性工作。在加入联邦政府之前，Friedman 曾在哈佛大学计算机科学系、布鲁金斯学会和乔治华盛顿大学工程学院担任著名的信息安全和技术政策学者十多年。他是畅销书《网络安全和网络战：每个人都需要知道什么》（Cybersecurity and Cyberwar: What Everyone Needs to Know）的合著者，拥有斯沃斯莫尔学院计算机科学学位和哈佛大学博士学位。