深度解读 |《构建软件组件透明度：建立通用的软件物料清单（SBOM）》（上）

1. 摘要

2021年10月21日，美国国家电信和信息管理局（NTIA）发布《构建软件组件透明度：建立通用软件物料清单（SBOM）》第二版。该文件旨在建立一个通用的、格式化的、可操作的方法，以便识别并列出软件组件及组件信息和关系依赖清单，从而实现对软件的组成、安全和知识产权等方面的有效跟踪。

本文将简要解读该文件的前两章内容。前两章主要阐述了构建通用软件物料清单（SBOM）的背景和目的，并给出SBOM的具体定义，指出首先应创建一个基线SBOM，再根据具体情况对其进行扩展，最后详细介绍了基线SBOM的必要属性、非必要属性、映射格式、组件关系以及附加元素等内容。建立通用SBOM有助于我国软件安全领域实现SBOM标准统一化，进一步加快修复漏洞的速度，提升安全漏洞修复能力。

2. 背景

现代软件系统与日益复杂且动态变化的供应链息息相关。如果缺乏对软件系统组件和功能的全局可见性，将大大增加网络安全风险及开发、采购和维护的成本。随着全球互联性日益增加，这些风险和成本不仅会影响到个人用户和相关组织，还会影响到公共安全和国家安全等集体利益。

通常软件供应商并不了解其产品具体使用了哪些开源软件，也无法确定产品是否使用了不安全或存在漏洞的软件组件，因此供应商无法在开发阶段及时规避这些风险，从而导致软件发布后势必会产生安全风险与修补成本。当有漏洞被揭露时，很少有企业可以快速、准确地定位并响应一些关键性问题，例如，产品是否受到该漏洞的影响，该漏洞影响了哪些产品线，哪些软件的版本是否存在这些问题等。实际上这一问题的根源在于未在开发阶段管理产品的软件组成所造成的，从而大幅增加了开发、采购、维护与处理的成本。

为解决软件供应链透明度不佳的问题，2018年7月，NTIA召开了由多部门利益相关者参加的会议，讨论提升软件透明度以及用于描述软件组件通用格式的提案。这次会议启动了一个多利益相关方流程[1]，最终设立多个工作组。本文件由框架研究工作组编写。

通过提高软件供应链透明度，以达到降低网络安全风险和总体成本的目的，具体体现在以下几个方面：

• 提高识别易受攻击的软件组件的能力；

• 减少因供应链复杂性而导致的计划外和低效的工作；

• 帮助支持透明度的供应商在市场中脱颖而出；

• 使用通用的标准化格式以减少重复性工作；

• 协助识别可疑的或假冒的软件组件。

3.  正文解读

3.1.  SBOM概述

为了提高供应链透明度，NTIA框架研究组的首要目标是创建一个可以在各个行业之间透明共享软件组件信息的模型。该模型能够定义并描述SBOM，还能说明组件之间的关系、SBOM的创建和共享、参与者的角色以及SBOM与供应链的集成。

SBOM是一个包含软件组件列表和层次依赖信息且机器可读的规范性清单。这些清单应当是全面的，或者应当明确说明不全面之处。SBOM可能包括开源软件或专有软件，它可以是公开可见或设置限制访问，SBOM还应能够识别并列出软件组件、提供这些组件的相关信息以及它们之间的供应链关系。但特定SBOM中所包含的组件信息的数量和类型可能会根据行业或部门以及SBOM消费者需求等因素而有所不同。对于这一情况，关键是要形成一个基线SBOM的最低预期，只要求该基线包含可以支持基本组件及其特性所需的最少信息量和流程。在最低基线SBOM的基础上，随着各部门进一步完善和实践日益成熟，SBOM可以逐步融入到各部门的开发流程中，成为企业与生俱来的DNA的一部分。

此外，任何SBOM都应该具备两个重要功能，一个是捕获和交换软件组件之间的链接，获取组件间依赖层次关系信息，通过每个组件与其他组件的联系实现对完整的软件供应链安全管理；另一个是将数据格式和交换协议结构化，SBOM格式标准化对提高效率和可推广性至关重要，标准化也有利于识别、跟踪和管理用特殊方式命名的组件。

为了使该模型能在全球范围内推广普及，还需要识别和定义软件组件特定部分的通用性。为此，一方面要选择一组核心的基线属性集，以识别具有充分的、相对唯一性的组件；另一方面要关联SBOM应用程序，考虑在基线集之外可能需要哪些附加属性和外部元素。

 

3.2.  SBOM属性

如下图所示，通用SBOM属性主要包括基线属性集、未确定的属性值、映射到现有的格式、组件关系以及附加元素，接下来将对通用SBOM的属性集进行详细展开介绍。

3.2.1 基线属性集

(1) 作者姓名

指SBOM的作者。

SBOM的作者并不总是供应商。即除了供应商，SBOM还可以由作者创建。

(2) 时间戳

指上次更新SBOM的日期和时间。

更改SBOM条目时，应当更新时间戳；初次创建也不例外。跨时区和地区的时间戳设置应保持一致，并使用国际通用格式，如ISO8601[2]。

(3) 供应商名称

指SBOM条目中组件供应商的名称或其他标识符。

供应商名称应该具备处理多个名称或别名的能力。当作者和供应商名称相同时，供应商应为其组件创建一个SBOM。当作者和供应商名称不同时，作者应对该供应商的组件作出声明或断言。本文档没有提供关于供应商标识的进一步说明，但它依然可能是实现大规模组件识别的重要因素[3]。

(4) 组件名称

指组件的名称或其他标识符。

组件名称应该具备处理多个名称或别名的功能。供应商（或作者）定义了组件及其名称。

组件名称可以包含供应商名称。组件（和供应商）名称也可以包含在通用名称空间：名称（namespace: name）构造中；可以使用供应商名称作为命名空间指示符。

(5) 版本字符串

指组件的版本。

版本信息有助于进一步识别组件。供应商和作者可以自由选择版本控制方案；在此我们建议使用语义版本控制[4]。

如果组件最初没有版本字符串，作者应当创建一个。

(6) 组件哈希值

指组件的加密哈希值。

加密哈希值是软件组件的固有标识符[5]。数字签名可以代替哈希值；它能提供更强的完整性和真实性，但会增加密钥管理和签名验证的复杂性。除了哈希值之外，哈希值的生成过程也需要清楚展示给SBOM的消费者，以便消费者能够复制该值。例如，软件包数据交换（SPDX）格式指定了一个包验证码，该验证码为单个文件组件创建了哈希值[6]。SBOM格式负责指定如何生成哈希值。

为一个组件或多个组件的集合提供多个哈希值是可能实现的，而且这一操作或许有好处。供应商和作者选择如何定义组件，进而定义了哈希值的范围。例如，SBOM可以包括源组件的哈希值、编译该组件的二进制形式的哈希值，以及组件集合的哈希值。如前所述，组件哈希值是《软件物料清单（SBOM）的最小元素》中推荐但不必需的数据字段元素[7]。

(7) 唯一标识符

指帮助唯一标识组件的附加信息。

唯一标识符可以通过与全局唯一层次结构或命名空间对比或参考已有的全局坐标系来生成。一些可用作唯一标识符的系统包括通用平台枚举（CPE）[8]、包URL（PURL）[9]、通用唯一标识符（UUID）[10]（也称为全局唯一标识符[GUID]）、软件遗产ID（SWHID）[11]和组件哈希值等都可以作为有效的唯一标识符。

(8) 关系

指SBOM组件之间的关联。

组件关系是SBOM模型设计中固有的组成部分，默认的关系类型是包含（includes）—表示包含或依赖于一个单独的上游组件。为了简化演示，本文档颠倒默认关系的方向为包含于（include in）。只要选定并贯彻一个方向，方向的选择不会影响使用SBOM模型。使用3.2.5节中的示例，以下语句是等效的：

1. Acme Application的1.1版本包含Bob’s Browser的2.1版本。

2. Bob’s Browser的2.1版本包含于Acme Application 的1.1版本中。

当组件在SBOM中没有确定的上游依赖项时，使用主要（primary）关系类型。主要组件定义了SBOM的主体（例如表2中的Acme Application），包括SBOM只包含一个组件的情况（例如表3中的Carol’s Compression Engine )。

其他类型的关系将在第3.2.4节中简要讨论；关系属性也可以展示SBOM作者关于其他上游关系和SBOM信息的知识，更多相关信息请参阅第3.2.4.1节。

3.2.2 未确定的属性值

在某些情况下，某些属性可能不可用、没有意义，或对组件识别没有实质性贡献，其中一个重要原因是缺乏组件组成的第一手知识。当SBOM作者不是软件组件的供应商时，作者可能会缺乏生成某些属性所需的信息或可见性。另一个原因在于创建SBOM（和组件）的时间点，大致为：预构建、构建或打包时以及构建后。例如，由（非供应商）作者在构建后执行的二进制软件组成分析可能会检测到组件，但不会提取二进制组件以生成哈希值。

SBOM必须恰当地处理缺失或不适用属性的情况。为此我们提出一个小建议：总是提供所有的基线属性，但需明确定义区分“无断言（no assertation）”(即数据缺失)，和“没有值（no value）”(即该属性不适用于此特定的SBOM)。或者，SBOM格式可以允许缺少基线属性，并将缺失某几项属性视为默认值（例如“无断言”或“没有值”）。

3.2.3 映射到现有的格式

表1（来自《现有SBOM格式调查》表1[12])映射了SPDX、CycloneDX和SWID的基线属性。稍后的调查文档中将会给出更多格式及其映射。除了基线属性之外，作者还应该遵守他们选择的SBOM格式的规范。

表1：将基线组件信息映射到现有格式

3.2.4 组件关系

开发SBOM的第一步是列举供应商直接列入主要组件中的一级组件。然而，为了有效推广SBOM，SBOM还需要捕获组件之间已知的嵌套供应链关系。物理组件的物料清单通常将这些关系描述为“多级BOM”[13]。

虽然SBOM可能会支持多种类型的关系，但在第2.2.8节中描述的基线关系属性定义了一种单一类型的关系：包含（或包含于）。上游组件（通常称为依赖项）包含在下游组件或组件中。在图1中，BingoBuffer是Acme Application的上游依赖项，Bingo是Acme的上游供应商。

其他类型的关系可能是必要的或是有用的，而现有的SBOM格式支持不同类型的关系。由此可以进一步细化“包含于”关系，例如明确下列三种情况的差异：

• 直接包含（未修改的）一个上游二进制组件；

• 通过链接或编译包含（未修改的）一个上游源代码组件；

• 选择一个上游的源代码组件，对其进行修改（新建分支），然后通过链接或编译将其包含在内。

修改一个组件会创建一个新组件(例如，一个分支) ；修改者会成为该新组件的供应商。在本示例中，重要的是保留修改组件的修改信息并传递其修改记录。例如，SPDX支持GENERATED_FROM和DESCENDANT_OF[14]关系类型。

虽然上游组件的信息通常是SBOM功能的一部分，但不使用组件的某些部分的情况也很常见。软件程序（组件）可能包含一个库（组件），但只调用库提供的一些函数。或者，组件的某些特性可能会在构建或打包期间被禁用。这在一些SBOM用例中很重要，特别是在漏洞管理用例中。如果一个漏洞影响到上游组件，则该漏洞可能会影响也可能不会影响下游组件[15]。漏洞可利用性交换(VEX)旨在传达组件中漏洞的状态[16]。

组件关系详见第3.2.5节。

3.2.4.1. 关于关系的知识 

理想情况下，每个供应商都为其组件创建并提供SBOM，所有消费者都将获得这些权威SBOM的完整链。对于每个组件，作者姓名等于供应商名称；在这个理想的世界中，SBOM信息将包含完美的知识。在实现这种超前的SBOM乌托邦状态之前，SBOM作者可能想要对作者不是供应商的组件做出非权威的声明或断言。一个可以预料的的情况是，供应商希望维护他们对非权威 SBOM的上游组件的立场。

可以使用附加的可选属性来记录这些关系断言。以下四类涵盖了作者对另一个供应商组件的知识范围：

1. 未知（Unknown）。这是默认值。表示目前还没有任何关于上游组件的声明、知识或断言。可能目前并不知道组件当前的上游组件，因此尚未列出；或者可能没有任何上游组件。这个默认值暗含着开放视角的本体假设[17]。

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

3. 部分已知（Partial）。至少有一个直接的上游关系；可能是也可能不是其他关系。部分已知关系会列出来。

4. 已知（Known）。已知并列出了完整的直接上游关系集。

关系断言适用于组件，描述了它的直接上游关系。图2和表4向图1和表2中的示例添加了关系断言。

关于上游关系的断言支持至少两种类型的分析或解释。在第一种相对有限的解释中，由于所有直接的上游组件都是已知的，关于Acme Application v1.1的知识也被视为已知。这使得供应商或作者能够传递他们已经提供了的上游组件的完整列表。在第二种解释中，Acme Application v1.1被视为“部分已知”，因为它的一些上游组件是部分已知或未知。虽然这两种解释可能都行得通，但重点在于，我们要明白第一种解释的范围是有限的。 

3.2.5 SBOM示例

下面提供一个SBOM示例来进一步说明上一节中描述的关系。图1和表2显示了查看SBOM信息的两种不同方法。这些都是概念表征，而非像SPDX、CycloneDX或SWID的特定格式。

在图1和表2中，Acme为名为“Acme Application”的组件所编写的SBOM有四个组件。其中一个主要组件是Acme Application，它定义了SBOM的主体。Acme制作了一个名为“Application”的组件，它使用了两个上游组件，分别为Bob’s Browser和Bingo’s Buffer。在此示例中，Acme能够从Bob那里获得关于Bob’s Browser的SBOM信息，而Bob’s Browser又使用了Carol’s Compression Engine和可能的其他上游组件。Acme无法从Carol或Bingo那里获得SBOM，因此Acme为这些组件编写了SBOM。Carol’s Compression Engine不包括上游组件，而Bob’s Browser可能有也可能没有任何上游组件。

图1：SBOM概念图

表2：SBOM概念表[18]

在最简单的情况下，单个组件是完全从零开始创建的，不存在任何依赖关系，如Carol’s Compression Enginev3.1。此组件的SBOM只包含一个条目，该条目使用“主要”关系类型定义组件和SBOM。如表3所示。

表3：单个（和主要）组件的SBOM概念表

在图2和表4中，由Acme为组件“Acme Application”编写的SBOM也有四个组件，现在通过关于完整性的断言完善了其关系信息。

图2：具有上游关系断言的SBOM概念图

表4：具有上游关系断言的SBOM概念表

Acme Application(此SBOM的主体和主要组件)断言为“已知”，因为所有直接的上游依赖项都被它覆盖了。BOb’s Browser断言为“部分已知”，因为它有至少包含一个Carol’s Compression Engine组件的上游组件。Carol’s Compression Engine没有上游组件，关系断言为“无”。已知Bingo Buffer是Acme Application的直接上游依赖项，但由于Bingo Buffer上游没有任何已知信息，因此关系断言是“未知”。

3.2.6 附加元素

除了基线属性外，SBOM可能还需要附加元素和组件属性以支持不同的用例。并不是所有附加的元素或属性都支持每个用例，所需的具体信息取决于用例的具体情况。原报告第3.6节中描述了SBOM用例，以及这些用例所需的一些附加元素和属性。附加元素和属性包括但不限于：

• 组件的使用寿命结束日期或技术支持结束日期；

• 显示组件实施或支持技术的能力；

• 对组件进行分组的机制；可能是通过生产线或已实现的技术进行分组（一组可以被视为一种特殊类型的上游组件）。

例如，如果已知“组件X和组件Y实现了DNS”，就允许用户识别所有与DNS相关的组件，并将它们视为一个集合。 

3.2.6.1. 真实性和完整性

SBOM生态系统必须支持以加密方式进行身份验证和验证SBOM信息的能力。换句话说，作者必须能够对SBOM进行数字签名，而消费者必须能够验证签名。身份验证和完整性保护需要对应的数字签名和公钥基础设施。

4. 影响

在2019年的白皮书草案中，NIST推荐了一套高级安全软件开发实践。其中，建议组织为存储库中存储的每一块软件创建并维护一个SBOM以保障其软件产品的安全。

Gartner在其报告《 Technology Insights for Software Composition Analysis》中强调SBOM的重要性并指出，到2024年，软件供应商应提供详细、定期更新的SBOM。对于至少一半的企业软件采购方来说，这将是一项不可谈判的要求，而在2019年这一比例低于5%。根据该报告，到2024年，60%的企业将自动为他们创建的所有应用程序和服务构建SBOM，而2019年这一比例同样不到5%。

不止在美国，这种情况在全球范围内并不少见。政府和行业已经逐渐认识到SBOM对于软件网络安全的重要性。对于软件供应商来说，构建SBOM提升了软件供应链透明度，可以帮助企业组织全面洞察每个应用软件的组件情况，从而更高效的定位并响应漏洞问题。此外，SBOM的标准规范化有助于组织间的友好协作，进而提高客户信任度；对于采购方来说，可以清晰直观地看到其感兴趣的产品信息，例如基线组件信息或许可信息等。对于运营商来说，SBOM增加了软件及其组件的可见性，有助于他们在其生产业务之前验证软件的状态。

 

5. 趋势判断

趋势一：实现SBOM生成和维护自动化

生成SBOM的最有效方式是在开发阶段一并记录与建立相关信息清单。但是对于已经存在或正在进行的项目来说，从无到有的一步步建立可能会耗费大量的人力物力，导致许多企业组织无法完整实现软件供应链的安全管理。加强或改造现有的工具和流程，以便辅助开发团队生成和维护SBOM，同时致力于实现工具和流程自动化，将有效减少对团队工作的干扰，有利于快速达成目标。

趋势二：SBOM将成为标准实践

NTIA提出了一系列通用SBOM指导原则，确定了基线SBOM已包含的核心基线属性以及其他附加属性和附加元素，该原则能够促进SBOM在全球范围内推广普及。此外，SBOM数据格式规范化也有助于统一不同供应商对相同组件的说明，同时便于识别、跟踪和管理以特殊方式命名的组件。随着用于创建和维护SBOM的工具不断升级和流程日益完善，SBOM将在全球范围内实现标准统一化。

6. 总结语

SBOM作为独立的实体，并非是所有安全问题的解决方案。但SBOM有助于获得做出正确选择的信息，是团队做出智慧安全决策的信息来源。我们正在见证SBOM 被认可和发挥作用的过程。未来，将会有越来越多的组织机构采用SBOM方法并帮助社区优化软件网络安全工具，以满足行业内的更多需求。

7. 参考文献

[1] https://www.ntia.doc.gov/SoftwareTransparency

[2] https://www.iso.org/iso-8601-date-and-time-format.html

[3] See Section 5 of https://www.ntia.gov/files/ntia/publications/ntia_sbom_software_identity-2021mar30.pdf

[4] https://semver.org

[5] https://hal.archives-ouvertes.fr/hal-01865790/file/main.pdf

[6] https://spdx.org/spdx-specification-21-web-version#h.2p2csry

[7] https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom

[8] https://nvd.nist.gov/products/cpe

[9] https://github.com/package-url/purl-spec

[10] https://en.wikipedia.org/wiki/Universally_unique_identifier

[11] https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html

[12] https://www.ntia.gov/SBOM

[13] https://medium.com/@openbom/openbom-fundamentals-all-about-openbom-multi-level-boms-f06f50ca7f74

[14] https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/

[15] https://www.ntia.doc.gov/files/ntia/publications/wysopal_swct_kickoff_perspective.pdf

[16] https://ntia.gov/files/ntia/publications/vex_one-page_summary.pdf

[17] https://en.wikipedia.org/wiki/Open-world_assumption

[18] In all similar tables, the Timestamp attribute is omitted and other attribute names shortened for presentation purposes. 

 

 

内容解读：悬镜安全 子芽 董毅 奇秋月 刘美平 杜玉洁

审核校验：中国信通院 杨文钰 马越 

                  中国联通 贾倩倩

欢迎大家扫码联系小镜

加入OpenSCA社区技术交流群

 

OpenSCA是悬镜安全旗下源鉴OSS开源威胁管控产品的开源版本，继承了源鉴OSS的多源SCA开源应用安全缺陷检测等核心能力。

OpenSCA用开源的方式做开源风险治理，致力于做软件供应链安全的护航者，守护中国软件供应链安全。

OpenSCA的代码会在GitHub和Gitee持续迭代，欢迎Star和PR，成为我们的开源贡献者，也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目，敬请期待更多功能的支持。

GitHub：

https://github.com/XmirrorSecurity/OpenSCA-cli/

Gitee：

https://gitee.com/XmirrorSecurity/OpenSCA-cli/

OpenSCA官网：

https://opensca.xmirror.cn/