开源软件安全基金会（OpenSSF）发布了一项动员计划，以提高开源软件（OSS）的适应性和安全性。 现代软件供应链之所以广泛使用 OSS，是因为它提供了更快的创新和更高质量的产品，但由于 OSS 组件固有的漏洞，其广泛采用会伴随一定风险。

该计划的一个重要部分是使用软件物料清单（SBOM）作为基础构建块，改善整个开源生态系统的安全状况。 这个计划概述了 OSS 项目应如何向下游用户提供 SBOM，从而将 OSS 组件的可见性提升到一个新的高度。 因此，使用 OSS 的企业和组织将需要一套用于 SBOM 管理的流程，使他们能够生成、获取、分析、存储、监控和共享 SBOM，以提高其自身软件供应链的安全性。

“SBOM 无处不在”究竟是什么？

开源软件安全动员计划包含 10 个行动项目被称为“活动组”。 第9组的目标为 “SBOM 无处不在： 改进 SBOM 工具和培训，以推动其广泛应用”，旨在帮助推动 SBOM 作为基础构建块的应用，以改善整个开源生态系统的安全状况。 该计划的核心思想是让 OSS 生态系统能够为其软件的每个版本提供准确的 SBOM。 对于 OSS 厂商、用户和维护者，SBOM 提供的软件产品中所有组件的最终列表，可用于在软件开发生命周期的每个阶段识别现有漏洞和新漏洞。

“SBOM 无处不在”工作小组将确保现有的 SBOM 格式与记录的用例相匹配，同时开发高质量的开源工具来创建 SBOM 文档。 尽管目前已有相关工具，但还需要搭建更多工具。 该工作小组还负责开展以 SBOM 为主题的教育活动，以推动 SBOM 在开源领域、政府和商业行业生态系统中的应用。

值得注意的是，美国联邦政府采取了积极主动的措施，要求政府机构消费和生产的所有软件都使用 SBOMs。 《关于改善国家网络安全的行政命令》指出，网络攻击的频率和复杂性的增加催化了公共和私有部门联手保护软件供应链的局面。 这也标志着 SBOM 驱动的未来已经到来。

SBOM 驱动的未来会是什么样子？

计算机科学家先驱 Alan Kay 有一句名言： “预测未来的最好方法就是创造它。 ” SBOM 的变革必然是一种创新和发明。 当我们使用 SBOMs 时，我们将找到新的方法来改进和构建目前已有的模式。 关于未来的 SBOM，我们先睹为快：

目前存在多种 SBOM 格式标准，而这些标准将不断改进并演变出其他标准。 当下两种最常见的 SBOM 格式是 SPDX 和 CycloneDX。 虽然某一种格式可能会成为行业标准，但是只要有多个标准存在，我们仍有可能需要继续使用多种格式。 因此对于 OSS 用户来说，选择能够支持多种格式的工具则是最优方案。

我们运行和构建的许多东西实际上是由许多较小的部件组装起来的。 同样，现代软件应用程序使用数百甚至数千个较小的构建块像拼乐高一样将它们组装起来。 我们需要将每个组件中的 SBOM 组装起来，以便为特定应用程序制作一个全面的 SBOM。

我们使用的组件的 SBOM 可能来自 OSS 项目或商业软件，亦或者可能需要我们自己为某些组件生成 SBOM。 重要的是要能够以不同的格式引入这些组件级 SBOM，然后组装它们来建立一个更全面的 SBOM。

当组装完应用程序级 SBOM，我们将在内部进行使用和共享（出于安全性和合规性目的）。 我们将为现有软件引入 SBOM，为创建的新软件生成新的 SBOM，然后输出包含最终应用程序所有组件的 SBOM。

如果没有工具管理 SBOM，输出 SBOM 的过程将非常复杂且费时。 大多数应用程序将具有用于各个单独组建的，多个版本的 SBOM，所有这些部分都要合并到最终的 SBOM 中。 如果没有 SBOM 工具，跟踪和准确创建应用程序级的 SBOMs 将是一项不可能完成的任务。

目前，“SBOM 无处不在”的重点是使用 SBOM 进行漏洞扫描。 通过维护软件应用程序中所有 SBOM 的存储库，您可以持续监控 SPOM 并及时发现新的漏洞，在部署后也是如此。 SBOM 管理还包括维护软件组件的清单，根据项目参与者发布的内容，来验证正在使用的内容，获得对开源许可证的可见性，以及评估 OSS 项目的运行状况和风险。 而在未来，SBOM 数据将有更多其他用途。

开启 SBOMs 的四个步骤

1. 了解 SBOMs

“SBOM Everywhere”倡议的其中一个重点是意识和教育。 SBOM 有很多自学资源，例如来自不同平台的博客文章。 通过开始学习 SBOMs 以及日益累积相关认知，您将为SBOM 驱动的未来做好更充分的准备。

开始为软件或开源组件生成 SBOM。 有许多开源工具可用，比如docker sbom，Syft 和 GoReleaser。 通过为构建和部署的软件创建 SBOM，我们可以了解共享 SBOM 的最佳方式。

向开源项目维护人员以及商业软件供应商获取 SBOMs。 客户和用户请求 SBOM 的频率越高，SBOM 在功能请求列表中就越靠前。

对于所有人来说，对于全新的 SBOM 采用模式应当有一个合理的预期。 我们将不断地从过往的成功或失败中获取经验。 秉持耐心和理解，努力探索如何创建，管理和输出SBOM，最终将帮助我们更快地迈向 “SBOM 无处不在” 的未来。

通过采用 SBOM 作为最佳实践，来保护在更大的生态系统中创建共享依赖关系的常用 OSS 组件，由此在极大程度上提高整个软件供应链的安全性。