在这个时代构建安全的软件产品或应用程序需要全面了解您正在构建的应用程序的确切组件。构成软件包的依赖项、许可证、文件和其他资产是潜在的漏洞点，恶意行为者可以通过这些漏洞对您的软件和供应链上的其他应用程序发起攻击。
作为应对最近增加的频率和影响的努力的一部分 对软件供应链的攻击，联邦政府与 NTIA 协调发布了一项行政命令，详细说明了改善网络安全并保证软件包中使用的第三方组件完整性的各种措施。其中一项措施是 软件物料清单。
这是一份正式文档，包含软件包的所有组件以及这些组件之间的供应链关系。准备全面的软件物料清单不仅是标准做法，也是法律要求的。这篇文章定义了软件物料清单的范围和 最小元素 必须包含在综合材料清单中。
NTIA 的 SBOM 最低组件提供什么？
SBOM 作为构建、购买或运营软件的公司的正式指南，提供他们增强对软件供应链的理解所需的所有信息。它还有助于轻松追踪新出现的漏洞（如果发生），并且 降低软件供应链风险。然而，为了使 SBOM 满足联邦政府的规定要求，它应该包含一些基本要素。这些元素通常分为三类：
- 数据字段： SBOM 预计会提供有关软件组件的重要数据，例如组件名称、供应商名称、软件版本和其他唯一标识符。它还应该详细说明依赖关系之间的关系。这些数据使得准确识别所有软件组件并在整个软件供应链中追踪它们成为可能。
- 自动化支持： 软件物料清单应该是机器可读的并且能够自动生成。这允许连续跟踪 SBOM 中包含的数据。通常，这些文档采用标准格式，例如 SPDX、CycloneDX 和 SWID 标签，这使得它们也易于人类阅读。
- 做法和流程： SBOM 文档还预计将详细说明准备和更新 SBOM 的标准实践和流程。它还应包括分发和访问 SBOM 的实践以及处理偶然错误的措施。
NTIA SBOM 文档的最低要求元素为软件物料清单的基本用例（例如管理漏洞、盘点软件组件和管理软件许可证）的 SBOM 指南中的预期内容提供了明确的标准。该框架正在更新，并且可能包含其他元素，以在不久的将来扩展其可用性。在本页的后续部分中，我们将更详细地解释软件物料清单的这些关键组成部分。软件物料清单的最低要求元素包括如下指定的七个数据字段。
数据字段：最低要求
软件物料清单的目的是提供帮助用户和其他利益相关者轻松识别软件组件的信息。预计，SBOM 的第一个也是最重要的元素之一是文档中详细说明的每个组件应包含的数据。除了帮助识别各个组件之外，这些数据还可以更轻松地跟踪组件在软件供应链中使用的各个位置。
- 供应商名称： 供应商是相关软件组件的发起者或制造商。这是创建、定义和标识软件组件的个人或组织的名称。
- 组件名称：这是指由原始供应商或制造商定义的分配给软件的指定名称。如果软件有多个名称和别名，也可能会注明。
- 组件版本： SBOM 应包括供应商或制造商指定的版本号或类别号。版本数据用作指定软件相对于软件后续版本的先前识别版本的任何更改的标识符。
- 其他唯一标识符： 这是指除组件名称和版本之外的其他标识符。这些附加标识符为组件提供了附加的标识层，并且还可以用作在相关数据库中查找组件的查找键。
- 依赖关系： 这是软件物料清单中最重要的数据组件之一，因为 SBOM 旨在详细说明软件组件如何组合在一起。依赖关系指定应用程序中使用的软件 X 与其上游组件之间的关系。
- SBOM 数据作者： 这是指创建 SBOM 数据的个人。有时，软件供应商也可能兼任作者。然而，在许多情况下，作者是另一个个人或团体。
自动化支持：最低要求
软件物料清单的使用通常跨越组织边界。这意味着 SBOM 中包含的数据通常由组织内的多个部门以及多个组织使用。为了确保本文档的易用性，NTIA 建议 SBOM 应采用机器可读和人类可读的格式。像这样以标准自动化格式准备和传输 SBOM 可以提高本文档针对其各种预期目的的互操作性。
NTIA 识别用于生成和传输 SBOM 的三种交付格式。您的软件物料清单应与这些格式中的任何一种相匹配，以符合 政府网络安全行政命令。这些标准格式包括：
- 软件包数据交换（SPDX）
- 软件识别 (SWID) 标签
- 旋风DX
软件包数据交换（SPDX）
SPDX 是用于传送 SBOM 数据的开放标准。它捕获有关软件的重要信息，包括其组件、出处、许可证和版权。它还提供安全参考。这 SPDX 2.2 版是最新版本，它支持 YAML 1.2 文件类型、JavaScript 对象表示法和资源描述框架 (RDF/XML)。标签：值平面文本文件和 .xls 电子表格
软件识别 (SWID) 标签
SWID 标签旨在帮助识别任何软件产品的组件并使其上下文化。软件识别标签项目（SWID标签）是一组用于生成和验证软件识别标签的工具。这些基于 Java 的工具支持基于 ISO/IEC 19770-2:2015 定义的标准化格式的 XML SWID 标签和简洁二进制对象表示 (CBOR)。这 NIST 有一个网站 包含以下有用资源列表：
- 构建 SWID 和 CoSWID 标签
- 根据特定架构要求和最佳实践指南验证 SWID 和 CoSWID 标签
- 提供 SWID 标签验证服务的 Web 应用程序，可部署到 Java 应用程序服务器
- SWID 存储库客户端，用于将标签发布到国家漏洞数据库
旋风DX
旋风DX 声称是“轻量级软件物料清单 (SBOM) 标准”。它对于供应链组件分析和应用程序安全非常有用。采用 CycloneDX 的组织可以无缝满足最低 SBOM 要求，并随着时间的推移成熟为更复杂的 SBOM 文档用例。
CycloneDX SBOM 通常以 XML、JSON 或协议缓冲区格式呈现。该规范通常包括以下五个字段：
- 物料清单元数据：这包括有关应用程序或软件产品本身的一般信息。
- 组件：这是一个全面的清单，涵盖了软件的所有专有和开源组件。
- 服务信息：详细介绍了应用程序在其操作期间可能调用的所有外部 API。它包括所有端点 URL、身份验证要求和信任边界遍历。
- 依赖关系：该文档还详细介绍了软件包中的所有组件和服务。这包括直接关系和传递关系。
- 组合：这是指所有组成部分的完整性，包括各个组件、服务和依赖关系。每个作品通常根据其是否完整、不完整、仅不完整的第一方、仅不完整的第三方或完全未知来描述。
实践和流程：最低要求
软件物料清单的最后一个元素重点关注 SBOM 使用本身的机制。这些实践和流程涵盖了生成和使用 SBOM 的操作细节，并且必须包含在任何有要求的政策或合同中。以下是必须在软件物料清单的实践和流程部分中详细说明的关键要求：
- 频率： 本节详细介绍了组织生成新材料软件账单的频率。通常，NTIA 建议您在软件组件更新或发布新版本时生成新的 SBOM。每当供应商在原始版本中发现错误或了解初始文档中未包含的有关其软件组件的新详细信息时，他们也应该生成新的 SBOM。
- 宽度： SBOM 的深度取决于文档中包含的内容。为了保持合规性，您的 SBOM 应包含所有顶级组件和所有传递依赖项。在作者无法包含所有传递依赖项的情况下，文档应指示消费者在哪里可以找到它们。
- 在某些情况下，SBOM 作者由于某种原因无法提供完整的依赖关系图。这可能是因为该组件没有进一步的依赖关系，或者它们不知道这些依赖关系是否存在。 SBOM 作者需要说明此原因。
- 配送及交付： 此要求的目标是确保 SBOM 以易于理解的格式快速交付。尽管此要求没有指定 SBOM 的交付天数或周数，但应尽快上交。此外，SBOM 在交付时应设置适当的角色和访问权限。最后，该要求规定 SBOM 可以与产品的每个实例一起分发，也可以以任何其他易于访问的方式（例如通过公共网站）提供。
- 访问控制： 如果供应商决定限制特定用户或客户对 SBOM 数据的访问，则作者需要指定访问控制条款。还需要为希望将 SBOM 数据集成到自己的安全工具中的消费者提供特定的津贴。
- 错误的容纳： SBOM 可以帮助提高软件保障和 软件供应链风险管理。然而，它还远未达到完美。因此，消费者需要容忍在准备 SBOM 时偶尔可能出现的无意错误或遗漏。
超越 NTIA 最低要求的思考
到目前为止，我们已经讨论了软件物料清单中所需的最少元素。这些最小元素代表了建议的要求，特别是对于本文档的最基本的用例。虽然它们为软件来源和安全性奠定了良好的基础，但我们必须超越这些要求。以下是针对更高级的 SBOM 用例需要考虑的一些建议。
附加数据字段
除了最低要求文档中涵盖的数据字段之外，还建议在需要更高级别安全性的情况下使用其他数据字段。其中一些附加数据字段包括：
- 软件组件的加密哈希
- 软件生命周期阶段数据
- 其他组件之间的关系
- 许可证信息
基于云的软件和软件即服务
SBOM 要求可能超出基本要求的另一个潜在领域是管理软件即服务 (SaaS) 产品。就 SBOM 数据而言，这些类型的软件产品面临着独特的挑战。首先，云环境中的安全风险是独一无二的。此外，处理这些风险的责任在于服务提供商。为基于云的软件准备 SBOM 文档也更加复杂，因为它们的发布周期往往较短。
SBOM 的完整性和真实性
另一个值得注意的可能问题是验证 SBOM 数据源本身的过程。目前，签名和公钥基础设施是当今数字世界中验证软件完整性的首选解决方案。 SBOM 的作者和供应商可能需要利用这些现有的软件签名来提高 SBOM 数据的可靠性。
依赖项中的漏洞和利用
尽管 SBOM 的目的是为了更容易地检测漏洞，但值得注意的是，并非依赖项中的所有漏洞都会对依赖它们的软件构成主要风险。为了避免浪费时间和资源，软件供应商需要采取措施来确定依赖漏洞对下游使用的软件的潜在影响，并向 SBOM 用户传达风险级别（或在本例中缺乏风险级别）数据下游。
实施中的灵活性与统一性
每当讨论软件安全时，灵活性和统一性问题总是会被提到。这也适用于 SBOM 的高级用例。为了成功实施 SBOM，需要制定适用于所有领域的广泛政策以及需要灵活性的具体情况。