近日，美国网络安全与基础设施安全局（CISA）发布《软件组件透明度框架》。该框架由CISA通用软件物料清单(SBOM)和实施工作组创建，旨在提高软件组件透明度。CISA表示，本次文件扩大了2021 年发布指南中引用的建立软件透明度所需的基线内容。新文件阐明了每个SBOM 基线属性内涵，添加了两个新的基线属性“许可证”和“版权所有者”，并且强调SBOM消费过程中的风险管理。据悉，国土安全部科学技术理事会2023年4月已选择七家公司构建基于SBOM 的产品。

问题陈述

现代软件系统涉及日益复杂和动态的软件供应链。与许多实体商品行业不同，软件供应链历来不需要提供软件系统构成的透明度。这种缺乏透明度的情况导致了网络安全和供应链风险，并增加了软件开发、采购、运营和维护的成本。在我们这个相互联系日益紧密的世界，风险和成本不仅影响个人和组织，也影响集体财产。

软件供应链透明度可以通过以下方式降低风险和总体成本：

  • 识别可能影响主要组件的组件，使组织能够分析风险

  • 加强漏洞管理和事件响应流程

  • 减少因复杂的供应链而造成的计划外和非生产性工作

  • 通过多个部门的数据标准化减少重复工作

  • 便于识别可疑或假冒软件组件

  • 通过鼓励利益相关者合作和实现对共同威胁的集体防御，提高复原力

  • 通过透明度提高安全软件开发实践的问责制

为了提高软件供应链的透明度，NTIA最初召集了一个名为 “框架工作组 ”的多方利益相关者进程。CISA将这项工作作为 SBOM工具和实施工作组的一部分。本文件是这些由社区推动的工作组逐步形成的成果。

1.1 目标

为了提高软件供应链的透明度，本文档描述了一种可在软件生态系统中普遍应用的软件组件信息共享SBOM。本文档涉及SBOM 的创建和共享、参与者的角色以及SBOM 与所有供应链的整合。

要在全球范围内推广这一模式，必须通过以下方法解决普遍识别和定义软件构件某些方面的难题：

声明一套必要的最低基准属性，以识别具有足够相对唯一性的组件；(2) 识别基准属性之外的补充、可选属性和外部元素，以服务于各种 SBOM 应用；(3) 使 SBOM 与外部资源相关联，以便进行相关分析。

何为SBOM

SBOM 是一份正式的、机器可读的软件组件和依赖关系、这些组件的相关信息及其关系的清单。SBOM清单应尽可能全面，并应明确说明无法阐明关系的地方。SBOM可以包括开源软件或商业授权软件，可以广泛使用，也可以限制访问以保护专有或敏感信息。

许多现代软件开发流程都支持在整个软件开发生命周期内自动生成SBOM。然而，软件供应链仍在使用可能需要手动方法生成SBOM 的旧系统。正如 “软件物料清单 (SBOM) 类型 ”中所述，不同类型的 SBOM提供了有关设计、源代码、已构建软件或已部署软件的特定信息。这些SBOM自然会在软件生命周期的不同阶段创建。在某些情况下，有必要使用启发式方法对已完成的软件工件进行分析，以生成SBOM。

SBOM 包含其所列组件的基线属性。收集和声明组件基线属性可实现两个目标：唯一识别单个组件以及监控和管理分发软件的风险。SBOM中包含的信息数量和类型可能会根据各行业或部门内指定消费者的需求而有所不同。

2.1 SBOM 要素

最初，NTIA “软件组件透明化多方利益相关者进程 ”的参与者审查了现有的软件识别格式，考虑了各种概念验证活动的反馈意见，并对创建一个可扩展且功能强大的SBOM 系统所需的要素进行了深入讨论和质疑。许多答案都取决于在足够数量和质量的SBOM 基准数据基础上构建的预期用例。自本文档首次发布以来，SBOM元素的实施和工具的发展不断壮大，并阐明了本文档中可以明确基线数据数量和质量的领域。通过系统、一致地定义和识别软件组件及其关系，可以实现预期用例的规模化运作。至少需要基线属性。可加入补充元素和属性，以支持本文档后面确定的SBOM 用例。

2.2 基准属性

SBOM 的主要目的是唯一、明确地识别软件组件及其相互关系。因此，SBOM系统的一个必要元素就是一套可用于识别组件及其关系的基线属性（Baseline Attributes）。遵循本文档所建议的指南和框架的SBOM 系统必须支持这些基线属性。

作者姓名、时间戳和主要组件（或依赖关系根）属性提供了有关SBOM 的元信息；其余属性适用于作为主要组件的直接或传递依赖关系的组件。

三个属性成熟度等级描述了属性条目中提供的不断发展的内容，以及达到更高的成熟度的可能方法。如果属性没有成熟度等级，则所提供的说明为最低预期。每个属性的数据成熟度级别和网络安全工具自动化支持旨在传达以下指导：

  • 最低预期：该成熟度级别描述了在全球范围内记录 SBOM 的主要组件及其包含组件的最低数据元素。

  • 推荐实践：这一成熟度等级描述了补充组件识别的属性数据，以及创建 SBOM 的实践

  • 期望目标：该成熟度等级描述了 SBOM 创建者可考虑用于记录动态和/或远程依赖关系的领域，这些依赖关系可在 SBOM 中进行唯一且明确的标识。

2.2.1 SBOM 元信息

2.2.1.1 作者姓名

作者姓名是指创建 SBOM数据的实体（如个人或组织，但不是工具）的名称。包含作者姓名可让下游用户了解创建SBOM 的背景，从而明确数据的来源和可靠性。作者姓名属性应尽可能多地列出参与SBOM 数据创建的人员姓名。还可声明创建SBOM 所用的工具，以协助SBOM 数据的使用。

  • 最低预期：SBOM 必须列出促使创建 SBOM 的实体。这些实体可以是软件供应链中负责软件系统开发、部署、运行和/或支持的组织、项目团队或个人，包括软件开发人员。如果可能，作者姓名属性应包括法律实体的名称和某种形式的唯一标识。如果没有法律实体名称，则应尝试唯一标识 SBOM 创建者以及联系信息。

  • 推荐实践：除了列出促使创建 SBOM 的实体外，还应指明协助作者创建 SBOM 的工具和版本。

2.2.1.2 时间戳

时间戳是 SBOM制作的日期和时间。作为最低要求，不同时区和地区的时间戳应保持一致，并使用通用的国际格式，如ISO 860111（如2024-05-23T13:51:37Z）。

2.2.1.3 类型

类型属性（Type Attribute）提供了创建SBOM 的方式和原因。，不同类型的SBOM 可由不同的软件工件创建。记录SBOM 类型可帮助了解所创建SBOM 的用途和消耗情况。本属性为可选属性，是一个理想目标。

2.2.1.4主元件

主元件（或依赖关系的根）是SBOM 的主体或SBOM 中描述的基础元件。第2.2.2节详述的组件属性也是为该组件确定的，就像为直接组件和传递组件确定的一样。每个属性部分都描述了成熟度等级。

2.2.2 组件属性

在 SBOM元信息中确定 SBOM的主组件及其属性后，开发SBOM 的下一步是唯一枚举供应商直接包含在主组件中的顶层组件。对于SBOM中的每个组件，应按照数据成熟度级别的要求，尝试识别每个属性。有关在这些属性中唯一识别组件和供应商的更多信息，请参阅 “软件识别挑战与指导”，了解有关组件和供应商识别的更多详情。

此外，为了有效扩展，SBOM需要捕捉组件之间的传递或嵌套供应链关系，只要这些依赖关系是已知的。物理组件的物料清单通常将这些关系描述为 “多级物料清单”。

根据创建 SBOM的实体的成熟度和所使用的创建工具，SBOM的内容在深度和广度上会有所不同。SBOM深度和广度的成熟度级别如下：

  • 最低预期：SBOM 应识别根组件或主要组件的所有静态直接依赖关系。

  • 推荐实践：除了直接依赖关系外，SBOM 还应尽可能多地识别子组件。

  • 目标：除了在 SBOM 中识别直接依赖关系和子组件外，还应努力唯一、明确地识别动态和/或远程依赖关系。

2.2.2.1 元件名称

组件名称（Component Name）是由组件的原始供应商定义的组件的公共名称。组件名称可以传达供应商名称。作为一种替代方法，组件（和源供应方）名称也可以使用通用的名称空间：名称（namespace:name）结构来表达，其中源供应方名称被用作名称空间代号。格式和工具需要具备处理多个名称或别名的能力。

2.2.2.2 版本

版本（Version）是供应商定义的标识符，用于指明软件在先前版本基础上的更新变化。该属性有助于进一步识别组件，应与组件名称分开。由于目前使用的版本方案种类繁多，准确记录供应商提供的版本是首要目标。最好采用语义版本管理。

如果组件没有可供声明的唯一语义版本，请确保为组件提供加密哈希值。请注意，这并不能表明该组件与其前代和后续组件的相对版本。

作为最低要求，应声明由供应商提供的版本字符串。

2.2.2.3 供应商名称

供应商名称是创建、定义和识别组件的实体。供应商名称是创建、定义和识别组件的实体，应仔细识别，因为它是实现组件大规模识别的重要因素。值得一提的是，合并和收购可能会影响正在创建的SBOM的供应商名称。供应商名称应识别为创建SBOM时提供软件的供应商。

作为最低要求，所有组件都应申报 “供应商名称”。但是，所提供软件的 “供应商名称 ”应根据该软件是未经修改就集成到主组件中，还是根据上游供应商提供软件的方式进行了修改，以不同的方式进行声明。

如果所提供的软件包或组件在包含在内时未经修改，则输入的 “供应商名称 ”为上游供应商的名称，并遵循以下指导：

○对于商业许可软件的供应商，请输入法人实体名称。如果法律实体名称不是全球唯一的，可考虑添加供应商的辖区。如果法律实体名称未知，可考虑使用https://nvd.nist.gov/products/cpe中的软件供应商名称。

○对于开源软件供应商，请列出项目名称。如果知道，请在项目名称前添加主机基础（如Apache Tomcat）。参考开放源码软件(OSS) 版权声明有助于确定软件的供应商或创建者。例如，facebook/react的版权声明将供应商名称确定为 “Meta Platforms, Inc 及附属公司”。

尽管不是建议，但如果组件的其他属性能唯一、明确地识别该组件，而上游供应 商又难以识别，也可以这样做：

■ 输入软件的域 URL和/或软件包URL (PURL) 的命名空间：

■ 输入未知的供应商名称。

如果所提供的软件包或组件在并入前由主要组件的供应商修改过，请将主要组件的 供应商作为供应商名称输入。此外，在 “属性 ”字段中输入组件的上游供应商，传达其传承关系（如传承或血统）是可能 的 “属性 ”字段。

2.2.2.4 唯一标识符

唯一标识符提供额外信息，帮助唯一定义组件。标识符可以是全局唯一的，也可以是全局唯一命名空间（如组织）内局部唯一的。两者都可以在SBOM中声明并提供值。

唯一标识符可根据某些全球唯一的层次结构、命名空间生成，也可参考现有的全球坐标系，或使用哈希算法从内容中生成。

此外，一些供应商可能在其全球唯一的组织名称空间内拥有专有的唯一标识符。

唯一标识符举例：

  • CPE

  • PURL

  • 软件识别 (SWID) 标签

  • 通用唯一标识符 (UUID)

  • 软件遗产 ID（SWHID）

  • OmniBOR 人工制品 ID（以前称为 gitoid 名称空间相对 ID）

  • 唯一标识符的成熟度级别为：

  • 最低预期 ：SBOM中列出的每个组件至少应声明一个唯一标识符。首选全球唯一标识符。

  • 推荐实践：为组件列出尽可能多的全球唯一标识符。

2.2.2.5 加密哈希值

加密哈希值是软件组件的内在标识符 。除了哈希值之外，还必须清楚哈希值是如何生成），以便可以复制。

值得考虑的是，SBOM格式选项可以为单个文件组件创建哈希值。为一个组件或组件集合提供多个哈希值是可能的，也是有益的。供应商和作者可以选择如何定义组件，这反过来又定义了哈希值的范围。例如，一个SBOM可以包括源组件的哈希值、该组件编译后二进制形式的哈希值以及组件集合的哈希值。

加密哈希数据成熟度等级如下：

  • 最低预期：为 SBOM 中列出的任何组件提供哈希值，并为其提供哈希值或提供足够的信息来生成哈希值。如果没有足够的信息，请注明未知。

  • 在提供散列值的同时，还需提供散列算法和被散列的组件对象，以实现可重复性。此成熟度级别接受的散列算法有 MD5、SHA1 和 SHA2 系列（包括 SHA256 和 SHA512）。

  • 建议使用安全的哈希算法。请注意，不再推荐使用 MD5 和 SHA1，并将于 2030 年正式停止使用。

  • 推荐实践：在此成熟度级别至少提供一个主要组件的哈希值。在提供最低预期哈希值的同时，还应提供哈希算法和被哈希的组件对象，以实现可重现性。

2.2.2.6 关系

关系属性（Relationship Attribute）描述了 SBOM中列出的组件与其他组件之间的关联。组件之间的关系可以多种多样。SBOM中列出的组件可能是静态的、远程的、提供的或动态的。考虑到组件及其交互的其他组件，就可以确定该组件所声明的关系类型。在SBOM 中声明的关系的数据成熟度级别是

  • 最低预期：主要组件和直接依赖组件声明的关系和关系完整性。

  • 推荐实践：为 SBOM 中列出的所有包含组件声明关系和关系完整性。

  • 理想目标：确定与尽可能多的动态和远程组件（如加载组件或服务）的关系和关系完整性。

下面的小节给出了几种常见的关系类型，可以考虑在SBOM 中声明。

2.2.2.6.1 主要关系

当组件是 SBOM的主体时，就会使用主关系类型。如第2.2.1.4 节所述，主组件定义了SBOM 的主体（如表2 中的 Acme Application），包括 SBOM只包含一个组件的情况（如表3 中的 Carol"s Compression Engine）。

2.2.2.6.2 “包含 ”关系

组件之间的依赖关系是SBOM 模型设计中固有的。默认关系类型为 “包含”。这表示包含或依赖于一个独立的上游组件。为简化表述，本文件将这种关系的方向反转为 “包含在”。方向的选择对模型并不重要，只要选择一个方向并始终如一地使用即可。以第2.6 节中的示例为例，下面的表述是等价的：

1. Acme 应用程序 v1.1 “包括 ”鲍勃的浏览器

2. 2.1. 2. Bob"s Browser v2.1 “包含 ”在 Acme Application v1.1 中。

可以进一步细化 “包含在 ”之间的关系，例如，表达以下两者之间的区别：

  • 直接包含上游二进制组件，不作任何更改。

  • 通过链接或编译，将上游源代码组件包含在内，且不作任何更改。

  • 选择上游源代码组件，对其进行修改（分叉），然后通过链接或编译将其包括在内。

2.2.2.6.3 传统或血统关系

修改一个组件实际上是创建了一个新的组件（如分叉），修改者成为了这个新组件的供应者。在这个例子中，重要的是要保持被修改组件的传统，并表明它已被修改。例如，SPDX支持 GENERATED_FROM和 DESCENDANT_OF关系类型，而 CycloneDX则支持 “血统 ”关系。

2.2.2.6.4 关系完整性

理想情况下，每个供应商都将为其组件创建并提供SBOM，而所有消费者都将获得这些权威SBOM 的完整链。对于每个组件，作者姓名(2.2.1.1) 等于供应商名称(2.2.2.3)，在这个理想的世界里，产品组件的知识将是完整的。在达到这种境界之前，SBOM作者可能希望对其并非供应商的组件做出非权威性的声明或断言。一种可能的情况是，供应商希望对上游组件提出自己的看法，而权威的SBOM 并不存在。

关系完整性可通过一个可选的补充属性来记录。以下四个类别涵盖了作者对另一个供应商组件的了解范围。

1.未知。这是默认设置。尚无任何关于上游组件的主张、知识或断言。上游组件目前尚不为人所知，因此尚未列出，或者可能不存在任何上游组件。此默认值意味着开放世界本体论假设。

2. 无。没有直接的上游关系。根据供应商的定义，该组件没有上游组件。

3. 部分。至少有一个直接上游关系，可能有也可能没有其他关系。已列出已知关系。

4. 已知。已知并列出完整的直接上游关系。

关系完整性断言的目的只是断言一个组件的直接上游关系的完整性。因此，具有 “已知 ”完备性断言的组件可能有一个具有 “部分 ”或 “未知 ”完备性断言的传递组件

2.2.2.7 许可证

组件许可证确定了所提供软件组件的法律条款。组件许可证的标识使软件使用、修改和发布的条款和条件透明化。

许可证透明度对软件安全非常重要，因为未经授权/未获得许可证的代码使用可能会导致无法使用或升级软件组件。

此外，从工作流程的角度来看，同时满足许可审查和漏洞/信任审查的单一工件具有重要价值。软件供应商将不得不同时满足两个工作流程的要求，而且评估机制可能会支离破碎；这将增加组织内部有关软件构成的摩擦和潜在的信息差异。

在大多数情况下，为组件提供的许可证信息将包括标准形式的许可证标识符，即SPDX 许可证标识符。如果组件的许可证无法以标准形式提供，则请参阅所使用的SBOM 格式规范，了解声明许可证信息的其他方法。

组件许可数据成熟度级别为：

  • 最低预期：为主要组件提供许可证信息。

  • 推荐实践：为尽可能多的组件提供许可证信息。

  • 理想目标：为所有列出的 SBOM 组件提供许可信息。证明 SBOM 中包含已缔结的许可信息，即许可文本和已缔结的条款和条件。

2.2.2.8 版权声明

组件版权持有者（Component Copyright Holder）标识了对SBOM中所列组件拥有专有合法权利的实体。版权信息非常有助于在处理安全漏洞时确定组件的合法所有者。传达开放源代码组件的版权声明也是许多开放源代码许可证的标准条件。通过包含版权声明，SBOM可以更全面地同时满足安全和法律工作流程的要求，而不需要为这一特定许可条件建立第二个工作流程。

此外，不遵守许多（如果不是大多数）开源许可软件的基本许可义务，会带来向下游分发组件的安全风险。

版权信息可在软件文件头、LICENSE.txt、NOTICES.txt、THIRD PARTY.txt 或组件库中的其他文件中找到。

组件版权持有者数据成熟度级别为：

  • 最低预期：为主要组件提供版权声明。

  • 推荐实践：为尽可能多的组件提供版权声明。

  • 理想目标：为所有列出的 SBOM 组件提供版权声明。

2.3 未声明的SBOM 数据

在某些情况下，某些组件或组件属性可能是不可用的、没有意义的、由于合同义务而不可共享的，或者在创建SBOM 时对组件识别没有实质性贡献的。以下是在已知用例中处理未声明数据的建议。

由于 SBOM的目标是提供软件供应链透明度，因此在使用这些替代提供组件属性的方法时一定要谨慎。为SBOM 数据提供未声明选项的目的并不是要促进组件数据的混淆。这些选项旨在使SBOM 在数据缺失、数据冲突或合同义务成为障碍时仍能真诚地创建。如果一个SBOM 有未声明的数据，作者应继续努力消除障碍，并用适当的数据重新发布SBOM。

2.3.1 未知组件属性

由于缺乏对组件组成的第一手知识，因此需要一种方法来管理缺失或不足的组件识别数据。如果SBOM 的作者不是软件组件的供应商，那么作者可能缺乏生成某些属性所需的信息或可见性。另一个因素是创建SBOM（和组件）的时间点，大致包括：构建前、构建或打包时以及构建后。例如，由非供应商在构建后进行的二进制软件构成分析。作者可能会检测到一个组件，但不会提取二进制组件来生成哈希值。

SBOM 必须从容应对属性缺失的情况。基本建议是始终提供所有基准属性，但要明确定义值，以区分 “无断言”（即数据缺失）和 “无值”。另外，SBOM格式也可以允许基线属性缺失，并将其视为默认值（即 “无断言 ”或 “无值”）。未知组件属性数据成熟度级别为：

  • 最低预期：将基准属性声明为 “无断言 ”或 “无值 ”仅在必要时使用，以便合理及时地提供 SBOM。

  • 推荐实践：将基准属性声明为 “无断言 ”或 “无价值”，只有在花费了足够的精力来匹配该组件的潜在安全风险时，才会很少使用。

  • 理想目标：当一个组件的基准属性被宣布为 “无断言 ”或 “无价值 ”时，它将作为合规差距被主动跟踪。

2.3.2 保密组件

有时，软件的下游分销商会与上游供应商签订合同协议，要求不得公开软件的内容。因此，需要对公开发布的SBOM 中的组件进行编辑。在这种情况下，推荐实践：

  • 标明编辑的组件并提供编辑理由。

  • 删除任何组件识别信息，但保留组件的版本或加密哈希值。

  • 以尊重编辑的方式保留与被编辑组件之间的任何依赖关系。

编辑组件的成熟度级别为：

  • 最低预期：只有在供应商合同要求时，才会编辑可识别组件的属性。

  • 推荐实践：与需要编辑的组件供应商联系，重新谈判一份允许供应链透明的合同。或者，为今后的软件开发选择一个透明度更高的上游供应商。

2.3.3 未知的依赖关系

当众所周知所提供的软件存在依赖关系，但所包含的依赖关系却不为人知或仅部分知晓时，SBOM系统就需要能够指出组件依赖关系列表不完整。例如，如果分发软件中包含一个专有操作系统，但该操作系统中包含的许多依赖项都是未知的，那么SBOM 就会列出已知的依赖项，并说明还有其他未知的依赖项没有列出。

未知依赖关系数据成熟度等级为：

  • 最低预期：在 SBOM 中确定了主要组件的每个直接依赖关系，并确定了所有基线属性（或如第 2.3.1 节所示）。必要时，可将更深层次的依赖关系声明为未知。如果将依赖关系声明为未知，建议说明理由。

  • 建议 ：联系上游供应商，获取其 SBOM，以提供所需的组件数据。提供这些信息时，可以嵌套在主要组件的 SBOM 中，也可以单独提供。

  • 理想目标 ：在无法采购 SBOM 的情况下，使用工具为上游提供的软件制作 SBOM。同时，利用工具从上游供应商的 SBOM 和贵公司的组织发展中收集数据，以协助制作强大的 SBOM。

2.4 支持用例的补充信息

除基线属性外，SBOM还可补充包含支持不同用例的元素和组件属性。补充的具体信息取决于用例，并非所有补充元素或属性都支持每种用例。第3.6 节描述了潜在的SBOM 用例。以下是可增强SBOM 数据的补充元素和属性的几个示例。

补充属性示例：

  • 组件的报废日期或支持级别。

  • 组件实施或支持哪些技术的说明。

2.5 与现有格式的映射

表 1 列出了SPDX 和CycloneDX SBOM 格式的基准属性。除基线属性外，作者还应遵守其所选SBOM 格式的规范。

表 1：基线组件信息与现有格式的映射

2.6 SBOM 示例

为了进一步说明前几节中描述的关系，请看这些SBOM 示例。图1 和表 2显示了查看 SBOM信息和关系的两种不同方法。这些都是概念表述，而不是像SPDX 和CycloneDX 这样的特定格式。可以利用SPDX31 和CycloneDX32 格式支持的SBOM 示例来获得更多信息。

在图 1 和表2 中，Acme编写的 SBOM包括四个组件。其中一个主要组件是Acme 应用程序，它定义了SBOM 的主题。Acme制作了一个名为 “应用程序 ”的组件，它使用了两个上游组件 Bob"s Browser 和 Bingo Buffer。在本例中，Acme从 Bob 处获得了有关Bob 浏览器的SBOM 信息，而Bob 浏览器又使用了Carol 的压缩引擎，还可能使用了其他上游组件。Acme无法从 Carol或 Bingo 处获得SBOM，因此Acme 为这些组件编写了SBOM。Carol的压缩引擎不包括上游组件，而Bingo 缓冲器可能有也可能没有任何上游组件。

图 1：SBOM概念图

表 2：SBOM概念表

在最简单的情况下，一个组件是完全从零开始创建的，没有任何依赖关系：Carol"s Compression Engine v3.1。该组件的SBOM 只有一个条目，使用 “主要 ”关系类型定义了组件和 SBOM。该示例如表3 所示。

表 3：单一（主）组件的概念SBOM 表

在图 2 和表4 中，Acme为组件 “Acme应用程序 ”编写的 SBOM也有四个组件，现在关系信息通过完整性断言得到了增强。

图 2：具有上游关系完整性的SBOM 概念图

表 4：包含上游关系完整性的概念SBOM 表

Acme 应用程序（本 SBOM的主题和主要组件）断言 “已知”，因为所有直接的上游依赖关系都包括在内。Bob的浏览器断言 “部分”，因为至少Carol 的压缩引擎是它的上游。卡罗尔的压缩引擎没有上游组件，因此关系完整性断言为 “无”。已知宾果缓冲区是 Acme应用程序的直接上游依赖关系，但由于宾果缓冲区的上游没有任何已知内容，因此关系完整性断言为 “未知”。

SBOM 流程

本节介绍如何从三个利益相关者的角度创建和交换SBOM 信息：软件的生产者、选择者和操作者。

三个特殊的 SBOM用例--漏洞管理、知识产权和安全供应链软件保证--说明了SBOM 作为独立数据源的作用，以及如何将SBOM 集成到典型的业务流程中。第3.6 节将讨论这些案例。

3.1 创建SBOM： 如何创建

要创建SBOM，供应商需定义自己创建的组件，为这些组件生成基准属性和任何补充属性，并列举所有直接包含的组件。SBOM信息最好是作为供应商软件构建和打包流程的一个组成部分来生成，这可以通过修改现有开发工具来实现。

任何创建、修改、打包和交付软件或软件系统的实体都被视为供应商，因此有责任定义组件和创建SBOM。这包括系统集成商，他们基本上被视为SBOM 的供应商。企业也可以作为内部开发组件的供应商。当上游供应商可提供包含组件的SBOM 时，这些SBOM 将与主SBOM 一起提供或纳入主SBOM。如果无法获得此类信息，供应商可提供 “尽力而为 ”的 SBOM，具体表现为包含组件SBOM 的作者与组件供应商不同。

SBOM包括用于识别组件的属性和用于捕捉组件特征或相关信息的补充属性。标识属性是必不可少的，而补充属性可能需要也可能不需要，这取决于用例或应用。

组件供应商提供的 SBOM可作为记录系统或组件信息的权威来源。如其它地方所述，有些信息可能需要与其它外部来源进行验证。例如，有时可使用CPE 从 NVD中获取有关组件的漏洞信息。

3.2 创建SBOM： 何时

组件发布时需要创建SBOM。这与构建、打包或部署活动大致对应。如第2 节和第2.2.1.3 节所述，可以考虑使用SBOM 的类型属性（Type Attribute）来表示创建或组装SBOM 的上下文。当组件更新或版本升级（包括添加新的上游组件）时，应创建新的SBOM。组件的变更通常被称为更新、升级、发布和补丁。理想情况下，组件的变更会通过 “版本字符串属性”（Version String Attribute）的变更来表示。当新的SBOM 信息可用时，即使组件本身没有变化，原始SBOM 也可能需要更新。因此，维护一个包含尽可能完整的信息和基线属性的最新SBOM 至关重要。

在更改现有组件（包括打补丁或更新）时，有两种方式可用于记录更改：A) 作为一个单独的新组件添加到现有的SBOM 中，或B) 作为同一组件添加新的版本字符串。这两个选项在下面的示例中进行了说明。

表 5：在SBOM 中记录补丁或更新的选项

3.3 SBOM 交换

有必要交换 SBOM信息。主要交换方式是通过单一的下游供应链环节，从供应商直接交换到消费者。作为交付组件的一部分，供应商也交付SBOM 或消费者可以轻松获取SBOM 的方式，如URL 或其他参考资料。这种直接交付并不排除供应商、消费者或其他方对SBOM 信息进行汇总或编目。

由于软件和设备生态系统的多样性，单一的SBOM交换机制不太可能满足需要。它们可以作为附加文件提供，作为组件分发或交付的一部分。对于有存储和电源限制的设备，一种方法是提供一个URL，以便在供应商的网站上查找SBOM 信息。对这类设备来说，动态访问SBOM 也是一个不错的选择。互联网工程任务组（IETF）开发了一种协议和格式，供终端用户发现SBOM（无论是在本地设备上还是在网站上共享）。该规范是 “格式中立 ”的，这意味着它可以支持 SPDX、CycloneDX和未来的格式。

3.4 软件供应链规则

安全软件供应链的参与者包括创建SBOM 信息的供应商和作者、接收SBOM信息的消费者，以及可选中介服务（如组成分析和依赖性分析）的提供者。在许多情况下，参与者既是供应商又是消费者，处于供应链的中间位置。

参与者遵循一套供应链规则，使SBOM 系统能够大规模运作。供应商为自己开发的组件创建SBOM，并由供应商定义这些组件。对于上游组件，供应商从相应的上游供应商处获取SBOM。如果没有上游SBOM，供应商或其他作者可以创建SBOM，即使这需要研究适当的条目或省略基线属性。

SBOM 必须列出一个主要组件，它定义了SBOM 的主题。SBOM列出的组件必须是

1. 最初由作为软件权威来源的供应商创建

2. 作为组件集成自上游供应商，该供应商也提供SBOM；

3. 作为组件集成自上游供应商，但该供应商不提供SBOM。作为向用户交付组件的一部分，供应商也交付相关的SBOM，或提供一种方法让消费者轻松获得SBOM。

如图 1、图2 和图 3所示，由许多相互连接的供应链组成的集合可能是一个有向无环图。最终上游供应商只生产原始组件，不包括来自其他供应商的组件（即不存在依赖关系）。在第2.6 节中，Carol就是这样一个供应商的例子。在整个图中，组件沿着供应链向下游流动。在图的两端，最终消费者只获取部件和SBOM，而不生产部件或SBOM。在整个图的中间部分，大多数参与者既是供应商又是消费者。甚至最终用户组织也可能充当供应商，为内部组件或外部组件（如网站、移动应用程序或物联网（IoT）设备）生产SBOM。

供应商对其创建并包含在SBOM中的组件负责。供应商还负责向其下游消费者提供所收集的组件集。从宏观经济意义上讲，供应商是成本最小的规避者，因为他们拥有关于其组件的高质量权威信息，而且生成和共享这些信息的成本相对较低。这种模式将生成SBOM 信息的成本分配给供应商。

在这个安全的供应链网络中，供应商可能会为上游组件创建SBOM，此时供应商是SBOM 的作者，而不是上游组件的供应商。当供应商创建此类SBOM 时，应明确表示他们只是SBOM 的作者，而不是组件的供应商。这将告知消费者该组件缺乏第一手的权威SBOM 信息。在这种情况下，“作者名 ”和 “供应商名 ”应有所不同。

围绕 SBOM交换和网络规则的概念旨在让选择和操作软件的人能够获得他们在不同供应商和供应链中使用的组件的完整列表。图3 对图 2中的示例进行了扩展，显示了一个使用来自两个不同供应链的两种软件产品（主要组件）的用户。该用户有两个SBOM：一个如表4 所示，另一个如表6 所示。

图3：有两条供应链的用户图

表 6：Nancy的NanoPhone 的概念SBOM 表格表示法

3.5 角色和视角

3.5.1 角度

不同的利益相关者使用SBOM 的方式互为补充，但又截然不同。“本文档借鉴了 “整个供应链中 SBOM 的角色和优势 ”中介绍的定义，并根据使用案例对术语进行了更新。

3.5.1.1 生产

这种 SBOM模型的设计理念是，所有供应商都为自己的组件创建SBOM。如果没有上游组件的SBOM，供应商可能需要为其他供应商的组件创建SBOM。在供应商不提供SBOM信息的情况下，这种缺乏清晰度的情况更有可能导致下游用户对产品的未知部件产生最坏的假设。供应商的另一个好处是能够确定与哪个组织联系，以获得上游组件漏洞的修复。

3.5.1.2 选择

潜在的选择者（如开发、购置或采购）在考虑使用具有相关SBOM 的组件或产品时，可以使用SBOM。选择者可能会对与产品直接相关的信息感兴趣，如基线组件或许可证信息。有关漏洞、当前认证状态和支持水平的补充SBOM 信息也会成为选择过程中的考虑因素。

3.5.1.3 运营

在任何行业中，运营商都在为缺乏有关他们需要支持的组件或产品的完整信息而苦恼。而SBOM则是这些信息的重要来源，可为软件及其组件提供可见性。其中一些信息可能是静态的，例如许可信息。但是，由于软件的动态性质，其中一些信息可能会在组件首次发布后发生变化或更新。

预计 SBOM更新中会提供大多数操作员持续关注的信息。运营商还可以在软件投入生产之前，利用当前信息来验证软件的状态。

3.6 SBOM 用例

本 SBOM模型和基线属性的核心重点是识别组件及其关系。补充元素和属性（如新属性、关系类型或外部数据连接）可以添加到SBOM 中，以实现不同的用例。本节重点介绍几种值得注意的SBOM 用例。3.6.1漏洞管理和VEX

漏洞管理是比较突出的SBOM用例之一。如今，要确定是否使用了存在漏洞的上游组件，以及下游组件中是否存在或可利用该漏洞，往往需要耗费大量成本和时间。SBOM和漏洞可利用性交换(VEX)数据可帮助供应商、用户和其他维护者更快、更准确地评估易受攻击组件带来的风险，而这些组件往往隐藏在不透明的供应链关系之后。

虽然上游组件通常是为提供功能而包含的，但组件中未使用的部分也很常见。一个软件程序（组件）可能包含一个库（组件），但只调用库提供的部分功能。此外，组件的某些功能可能会在构建或打包过程中被禁用。这在某些SBOM用例中变得非常重要，尤其是在漏洞管理方面。例如，如果一个漏洞影响到上游组件，那么该漏洞可能会也可能不会影响到下游组件3VEX的设计旨在传达组件中漏洞的状态（未受影响、已受影响、已修复、正在调查）。

漏洞管理需要漏洞信息源、漏洞与组件的映射（如NVD 中使用的CPE），以及传达漏洞或可利用性状态的方法（如VEX）。虽然VEX 是为解决漏洞管理用例而开发的，但VEX 并不局限于与SBOM 一起使用，也不希望包含在SBOM本身中。一个令人担忧的问题是，基于版本字符串、协议标语或其他启发式方法等有限信息的漏洞检测不正确。即使SBOM 显示上游组件存在漏洞，VEX也可用于表明软件不存在漏洞或不可利用。这可以为供应商和用户节省管理、生产和应用不受影响组件的安全更新的成本。

此外，作为 SBOM的补充，包括组件的生命周期结束日期和支持级别，可为执行漏洞影响评估的实体提供关键信息，以选择缓解方案。

3.6.2 知识产权

有了更好的库存数据，许多知识产权(IP)用例都可以得到改进。管理软件许可证和版权声明信息（包括对使用或再分发的限制），以及跟踪权利（允许使用组件的副本或功能）是两个常见的用例。软件构成分析工具存在一个显著的市场，可帮助确定组件的内容，部分用于确定许可要求。SBOM数据可以在不依赖二进制分析工具的情况下提高对组成的了解。SPDX和 CycloneDX最初都是为了传递许可证和授权信息而设计的。本用例要求将不同的许可证和许可证类型与组件关联起来，并提供一种方法来评估具有不同许可证的不同组件组合成组装产品后的净效果。

3.6.3 安全供应链软件保证

组件来源和完整性的安全供应链需要有关组件血统和出处的信息，如组件是如何构建和打包的、谁创建和修改了组件以及组件在供应链中的监管链。与其他用例一样，安全供应链文档将需要有关组件的附加属性、不同的关系类型以及可能不同的供应商信息。

3.7 工具支持

SBOM 生成和管理工具的可用性对于广泛应用至关重要。现有工具和工具清单包括CycloneDX 工具中心和SPDX 工具。SBOM功能需要集成到软件开发、包装和资产管理系统中。

结论

世界各地的组织都面临着有关在其环境中积极部署的软件的操作和安全供应链软件保证问题。这些软件中的很多都在处理其业务活动的关键部分，但却很少或根本不提供软件组件的可视性。由于缺乏可视性，有关已知漏洞的问题一直得不到解答。要提高网络安全自动化和软件透明度，使企业能够更好地管理其网络安全，并使供应商能够监控其组件，一种方法就是建立一个统一的模式来创建和共享SBOM。

为了对最终用户组织有用，SBOM需要包含基线身份和关系信息，使软件组件在安全软件供应链中移动时能够相互关联和链接。为了便于快速采用，我们定义了一套最低基准属性。这些属性与SPDX 和CycloneDX 等现有格式基本一致。然而，正如本文档所指出的，将SBOM 限制在这些基线信息中，并不足以支持许多已确定的用例和应用。

随着 SBOM的使用日趋成熟和普及，SBOM基线信息的随时可用性将推动进一步的工作，为共享和管理SBOM 建立更加协调和标准化的方法。对SBOM 的结构和内容进行标准化的原因之一就是为了实现这些后续步骤。工具也将是SBOM 的采用和进一步发展的一个重要因素。

总之，我们的目标是确保通过SBOM获取和交换的必要信息可供需要者使用，从而改进资产管理、知识产权管理、漏洞管理、实施缓解措施和风险管理。

声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。