软件供应链作为一个复杂、庞大的系统，这些系统的组成和功能缺乏透明度，难免存在脆弱节点。同时，开源组件的安全性也已成为软件供应链安全问题增长的重要因素。这些痛点难点包括：

组件成分分析技术缺乏规范及标准

供应链中组件间关系模糊、耦合

不同生态系统依赖管理方式及规则迥异

开源组件质量难以得到妥善保障

开源组件中漏洞信息多源、缺失、不一致

关键开源组件脆弱，可维护性无法保障……

由于软件供应链各个环节间缺乏系统的安全审查机制，导致一旦底层开源组件出现安全漏洞，这些问题组件将深刻影响业务领域。

企业这些安全困境应该如何解决？

开源组件治理是一个系统性的工程，SCA工具在其中可以助力关键的风险与合规检测，并提供修复建议。企业应提升对软件供应链安全攻击事件的防护、检测和响应能力，建立和维护一套完整的的软件物料清单（SBOM）管理体系，为每个应用程序持续构建详细的 SBOM。

Scantist SCA能为软件用户提供高效、便捷的解决方案，助力企业的安全投入发挥最大效能。作为一款“科研级”的软件成分分析工具，Scantist SCA支持识别开源详细组件建立开源基线和组件依赖关系图表，提供多维度组件清单及归类，可为应用和容器构建准确、完整的软件物料清单（SBOM），并按照组件、漏洞、许可合规维度输出详细报告，为被扫描的项目进行持续安全监控，确保这些项目能更好的面对不断变化的网络安全挑战。

随着行业朝着广泛标准化和采用软件物料清单(SBOM)的方向发展，新加坡南洋理工大学计算机学院教授、Scantist联合创始人刘杨博士也带领科研团队（Scantist中国区产品总监王宇、新加坡南洋理工大学聂黎明博士等）深度参与并支持了信息通信软件供应链安全社区发布的【SBOM政策文件研究】系列之《现有SBOM格式和标准调查》译文供行业参考。

以下内容原文转自“信息通信软件供应链安全社区”公众号文章“政策法规组|【SBOM政策文件研究】之 《现有SBOM格式和标准调查》译文”。

《现有SBOM格式和标准调查》译文

2021年，美国国家电信和信息管理局（NTIA）标准和格式软件透明工作组发布《现有SBOM格式和标准调查》。该文件主要包括工作组调查的现有标准、格式和倡议，它们适用于识别软件产品构建中使用的外部组件和共享库（专有或开源）。它也分析了其他组织在交流这些信息方面（以机器可读的形式）进行的工作。另外，尽管现存专有格式也可达到目的，但工作组还未将其纳入考虑范围。2021年发布的修订版基于2019年底的原始草案进行了多项改进，在进一步更新之前，应考虑利益相关者共识。总的来说，基线SBOM数据可以用下面描述的任何一种格式来传输，生态系统能够且应该支持下述数据格式之间的互操作性。

现代软件系统涉及日益复杂和动态变化的供应链。不幸的是，这些系统的组成和功能缺乏透明度，会大大增加网络安全风险，以及开发、采购和维护成本，这对我们这个相互联系的世界有着广泛的影响。除了会影响企业所依赖的产品和服务外，其风险和成本还会影响到公共安全和国家安全等集体利益。

在NTIA倡议下，NTIA标准和格式工作组于2018年成立。该工作组旨在评估现有可用的软件物料清单格式和其他工作组或实践社区确定的前瞻性用例。工作组的最初目标是：

（1）调查现有备选方案；

（2）记录可操作的机器可读格式；

（3）不要求单一的解决方案/格式（我们不会"宣布一个赢家"）；

（4）确定解决方案如何协调工作，因为不同的格式用来满足不同群体的需求（例如，开发人员、具有管理软件权力的CFO），并且在技术上，良好的文档格式之间的映射是可行的；

（5）支持国际反馈意见并引入解决方案，因为供应链安全和软件完整性不仅仅是一国的问题，更需要全球共同参与。

该文件的目标是，通过以下方式提高供应链透明度、降低网络安全风险和总体成本：

（1）加强对易受攻击的系统和事件根源的识别；

（2）减少计划外和无效工作；

（3）支持更透明的市场差异化和组件选择；

（4）通过标准化多个部门的格式来减少重复工作；

（5）识别可疑或假冒的软件组件。

纳入SBOM的信息最好可以从软件生命周期的每个阶段所使用的工具和流程中获得（见下文图1）。人们可以利用现有的工具和流程来生成SBOM。此类工具和流程包括知识产权审查、采购审查与许可证管理工作流工具、软件供应链风险管理、代码扫描器、预处理器、代码生成器、源代码管理系统、二进制代码分析工具、版本控制系统、编译器、构建工具、持续集成系统、打包程序、合规性测试套件、包分发存储库和应用程序商店。

图1：软件生命周期具有多个阶段，底层代码可能发生变化，因此SBOM会更新以反映这些变化

目前，并非所有现成的或开源的软件生命周期工具都具有生成SBOM的能力。软件的分析可能发生在初始生成之后。供应商应考虑加强或改造现有的工具和流程以生成和维护SBOM。对于特定用例的SBOM，一些用户可能认为它不完整，如果SBOM不完整，消费者应与供应商联系弄清情况，以便根据现有数据合理使用SBOM。

作为框架工作组的一部分，NTIA的多方利益相关者社区已经定义了SBOM数据元素的基线，1数据元素基线与后续行政命令规定的最小元素文件密切相关。2本文档中的讨论基于这些参考资料。

如何交付SBOM

目前，还没有一种单一固定方式将SBOM传输到下游用户。3在开源产品中，SBOM可以作为元数据存储，并带有指向组件的指针。对于已编译的软件，SBOM能够作为汇编与软件产品本身捆绑在一起，并与安装的软件一起存储。SBOM也可由供应商的门户网站提供，存储在预先约定的位置或存储在其他第三方处。

利益相关者提到了访问旧SBOM数据的潜在价值，以便用户在特定时间点了解软件的底层组件。例如，作为违规取证调查的一部分，客户可能想知道一个基于云的服务在过去的某一时间点是否存在潜在漏洞。本文档并未提供如何保存过去SBOM的指南。要了解供应商如何交付SBOM的更多信息，请阅读软件供应商手册：SBOM的生产和供应。

如何生成SBOM

SBOM应该反映软件的当前状态。如果更新了软件或软件的底层组件，那么底层组件列表也应相应更新，以此确保SBOM数据本身是最新的。除了源自软件本身的信息外，SBOM中的其他信息可以是声明性的，也可以由SBOM数据的作者声明。例如，组件名称的下载位置可以是SBOM的一部分。

同样的，如果软件的已知信息发生变化，或在原始SBOM中出现错误，供应商可以在不更新底层代码的情况下更新SBOM。

声明的信息可能需要随着时间的推移进行更正、更改或添加。这种改变可以附加到SBOM版本明细中。对一个SBOM进行更正或补充，可以产生一个新修订的SBOM，它应当是可审计的。

如何使用SBOM

为了最有效地使用SBOM信息，数据必须是机器可读的。使用时必须包括机器对机器的自动化流程。引言中讨论的每个用例（详见《软件使用者手册：SBOM的获取、管理和使用》5），只有通过集成到自动化流程中才能实现效率最大化。同样重要的是，该格式能够被转换成人类可读的版本。

消费者可以将SBOM作为输入以支持资产管理、许可证和权利管理、知识产权管理、监管和合规管理、供应、配置管理、漏洞管理、事件响应和软件供应链风险评估和证明。

使用SBOM进行风险管理可能需要额外的风险数据，这些数据可能不包含在SBOM中，例如，在采购过程中获取的供应商提供的数据。要了解消费者如何使用SBOM的更多信息，请阅读《软件使用者手册》。

软件包数据交换（SPDX®）规范是一个ISO/IEC标准6，用于传达软件物料清单信息。它有助于以多种文件格式描述与软件组件相关的组件、许可证、版权和安全信息。该项目创建并仍在继续发展一套数据交换标准，可使公司和组织能够共享人类可读和机器可处理的软件元数据，方便软件供应链流程。

全球的软件开发团队都在使用相同的开源组件，但在2010年，几乎没有可用的基础设施来促进协作、分析或共享分析活动的结果。因此，许多小组都在执行相同的工作，导致了重复工作和信息冗余。为了节省时间，提高数据准确性，SPDX项目成立，它创建了一种通用的元数据交换格式，可以收集和共享软件包以及相关内容的信息，并能开发工具，7促进任务自动化。

SPDX信息可以与特定的软件产品、组件或组件集、单个文件甚至代码片段相关联。SPDX项目致力于创建和扩展一种“语言”，来描述作为软件物料清单的一部分进行交换的数据，并能够以多种文件格式（RDF/XML、XLSX、tag-value、JSON、YAML）表示该语言，便于收集和共享软件包及相关内容信息，节省时间，提高准确性。

该规范是一个灵活的文件，随着在新用例中的使用，它会不断发展，并会注意提供向未来的兼容性。通过技术、业务、法律，以及现有安全专业人员之间的协作，开发过程得以进行，一个满足软件供应链中各种参与者需求的标准得以创建。

公司和组织正在广泛使用和再利用开源代码和其他软件组件。能够准确识别软件从可执行文件到构成可执行文件的源文件，对了解其中是否可能存在安全漏洞来说至关重要。

（1）描述

SPDX标准8描述了生成有效SPDX文档所需的部分和字段。请务必注意，并非所有这些部分都是必需的。创建信息的部分是唯一必须的。然后是使用部分，它用于描述SPDX文档创建者计划共享的软件和元数据信息（以及每个部分中字段的子集）。

图2：SPDX文档概述

（2）每个SPDX文档可以由以下内容组成：

a) 创建信息：每个生成的SPDX文档都需要一个实例。它为处理工具向过去和未来的兼容性提供了必要的信息（版本号、数据许可证和作者等）。

b) 包信息：SPDX文档中的包可用于描述产品、容器、组件、包上游项目源和tar包的内容等。它是一种将共享某些公共上下文的项目组合在一起的方式，没有必要用一个包来包装一组文件。

c) 文件信息：此处汇总了文件的重要元数据，包括其名称、校验和、许可证和版权。

d) 片段信息：当已知一个文件的某些内容已经在另一个原始源中被包含时，可以选择性地使用片段信息。另外，当文件的一部分可能原本是从不同的文件中复制过来时，片段信息可用于注明这一点。

e) 其他许可信息：SPDX许可证列表9并不展现软件包、文件和片段中的所有许可证，因此本节提供了一种总结其他许可证信息的方法，这些信息可能存在于被描述的软件中，如自定义或专有许可证。

f) 关系：SPDX文档、包、文件和片段可以通过多种不同的方式相互关联。支持43种关系，并可以根据需要进行扩展，以实现有效的系统描述。

g) 注释：注释通常是在有人审阅SPDX文档，并希望从审阅中传递信息的情况下创建的。

然而，如果SPDX文档作者想要存储不属于其他类别的额外信息时，也可以使用注释。

每个文档都能够用完整的数据模型实现和标识符语法表示。这就可使SPDX在数据输出格式（RDF/XML、tag-value、XLSX）之间进行交换，并对SPDX文档的正确性进行正式验证。10在SPDX规范的2.2版中，添加了JSON、YAML和XML的附加输出格式，也增加了对原始SBOM框架文件中确定的“已知的未知”的支持。有关SPDX基础数据模型的更多信息，请参见SPDX规范附录III11和SPDX网站。12

（3）使用案例

a) 描述系统组件和组件之间的细微关系

b) 对软件组件的知识产权（许可、版权）进行高保真跟踪

c) 软件供应链风险评估和组件验证

d) 列出软件分发内容

e) 跟踪可执行文件到单个源文件和源片段

f) 容器内容清单

g) 关联通用平台枚举项（CPEs）、软件遗产持久ID（SWHIDs）、包URLs（purls）与特定软件包，以便于额外安全性分析

h) 识别嵌入文件中的代码行的来源

（4）主要特点

a) 能够使用提供的哈希值检查文档中工件

b) 能够为知识产权和许可信息提供丰富的设施

c) 灵活的模型能够从片段和文件扩展到软件包、容器，甚至是操作系统发行版

d) 能够向其他包参考系统和安全系统添加映射

e) 能够对与复杂系统相关的文档进行逻辑划分和链接

（5）SPDX和SBOM

SPDX可以捕获SBOM数据，因为它们能够代表软件开发和部署中发现的所有组件。SPDX用于表示发行版光盘映像文件、容器、软件包、二进制文件、源文件、补丁，甚至是嵌入在其他文件中的代码片段。SPDX提供了一组丰富的关系，将文档内以及SBOM文档之间的软件元素链接在一起。SPDX SBOM文档能够通过外部参考链接到国家漏洞数据库和其他打包系统元数据。

（6）未来发展方向

a) 需要时，有信息指明创建SPDX时的已知漏洞，以及这些漏洞何时/何地/如何在更新或补丁中被修复，或被确定在交付软件中不可利用。这项工作与新兴的漏洞利用交换工作组方向一致。13

b) 增强谱系和起源信息的表示，以支持监管链讨论。

c) 更丰富的交互间关系集与完整性检查。

d) 识别当前无法由SPDX14表示的用例，并在即将发布的规范中添加元素以支持这些用例。

CycloneDX

CycloneDX是一个轻量级SBOM规范，用于软件安全上下文和供应链组件分析。它可以传达软件组件清单、外部服务及他们之间的关系。CycloneDX是一个开源的OWASP标准。该项目创建于2017年，目标是创建一个完全自动化的、以安全为中心的SBOM标准。核心工作组每年都通过基于风险的标准流程生成不可变的、向后兼容的版本。CycloneDX整合了现有规范，包括Package URL、CPE、SWID和SPDX许可证ID及表达式。CycloneDX SBOM可以表示为XML、JSON和协议缓冲区（protobuf）。

CycloneDX中，可以捕获开源代码组件的动态特性，其源代码易获取、可修改和可再发布。该规范可以表示组件谱系，包括从任何角度描述组件谱系的祖先、后代和变体，以及其提交、补丁和使其具有唯一性的差异。

CycloneDX项目维护了一个受社区支持的列表，该列表包含了所有支持该标准或与该标准交互操作的已知开源和专有工具。15

（1）描述

CycloneDX规范16描述了一个规定性的对象模型，该模型创建了交叉实现的一致性。CycloneDX规范可以通过XML Schema和JSON Schema来验证，也可以使用CycloneDXCLI17验证。其中XML和JSON被提供了注册媒体类型，可允许自动交付和受支持格式的使用。

图3：CycloneDX概述18

（2）CycloneDX SBOM可包含:

a) SBOM元数据：包含的信息包括：用于生成SBOM的工具、供应商、制造商以及SBOM描述的组装软件、组件、固件或设备。

b) 组件：描述第一方和第三方软件组件的完整清单。这包括组件的类型、身份、许可、版权、哈希以及完整的谱系和出处（包括对组件的任何更改）。组件可以被嵌套而形成组件集合，这些组件集合可能具有自己的供应商信息。数字签名可以选择性地应用于组件或组件集合。

c) 服务:描述软件可调用的外部API，可能会包括端点URI、身份验证要求和信任边界遍历。软件和服务之间的数据流也可以描述为包括数据在内的数据分类，以及每种类型的流向。数字签名可以有选择地应用于服务。

d) 依赖关系：描述直接关系和传递关系。它可以表示依赖于其他组件的组件，以及依赖于服务的组件，也可以表示依赖于其他服务的服务。

e) 组合：库存和关系的完整性可以用组合来描述。每个组合的聚合可以描述为完整的、不完整的 、仅第一方不完整、仅第三方不完整或未知的，这可使SBOM作者描述SBOM的完整性，或者SBOM中是否存在完整性未知的组件。

f) 扩展：在整个CycloneDX对象模型中存在多个扩展点，允许快速创建新功能的原型，并支持专门的和未来的用例。

（3）使用案例

a) 软件组件和服务清单的描述

b) 漏洞分析、修复和其他安全用例

c) 软件供应链风险评估和证明

d) 许可证合规性

e) 谱系和出处，包括所有修改的完全可追溯性

f) 签名组件、组件集和SBOM的完整性验证

g) 用于SBOM构建时创建和分发、基于文件的可移植格式，以及高效的机对机二进制格式

（4）主要特点

a) 易于学习和采用的规定性对象模型

b) 开源标准——宽松、商业友好的许可证

c) 高度自动化，跨多个开发生态系统的深度集成

d) 支持多种组件标识标准，包括Package URL、CPE和SWID（标签ID或完整的SWID文档）

e) 基于风险的标准开发方法，可加快向社区交付核心功能

f) 规范是可扩展的，允许快速原型化新功能，以满足组织或行业的特定需求

（5）CycloneDX和SBOM

CycloneDX是一个全栈SBOM标准，可以代表许多不同类型的软件应用程序、组件、服务、固件和设备。该规范目前被广泛应用于各行各业，用于描述软件包、库、框架、应用程序和容器映像。该项目能支持大多数主要的开发生态系统，并可为软件工厂提供实施办法，例如GitHub操作，从而进一步提升组织完全自动化SBOM创建的能力。

（6）未来发展方向

a) 纳入社区和CycloneDX行业工作组的反馈，以帮助指导该标准的未来方向

b) 目前正在开发多个扩展，包括对现有漏洞扩展的审计、制定和增强19

c) 通过每年发布的版本不断完善核心规范。可以使用GitHub里程碑20跟踪进度。

如何生成SBOM

（1）描述

软件识别（SWID）标签旨在为组织提供一种透明的方式来跟踪安装在其托管设备上的软件，2012年由ISO定义，并在2015年被更新为ISO/IEC19770-2:201521。22SWID标签文件包含有关软件产品特定版本的描述性信息。

SWID标准定义了一个生命周期：SWID标签作为软件产品安装过程的一部分，被添加到端点，并在产品卸载过程中被删除。在此生命周期中，给定SWID标签的存在直接对应于该标签描述的软件产品的存在。包括可信计算组（TCG）、互联网工程任务组（IETF）在内的多个标准机构在其标准中都使用了SWID标签。

为了捕捉软件组件的生命周期，SWID规范定义了四种类型的SWID标签：主标签、补丁标签、语料库签和补充标签。（见图4）

1. 主标签：SWID标签，识别和描述软件产品，安装在计算设备上。

2. 补丁标签：SWID标签，识别和描述已安装补丁，该补丁对安装在计算设备上的软件产品进行了增量更改。

3. 语料库标签：SWID标签，识别和描述处于预安装状态的可安装软件产品，可用于表示软件产品、软件更新或补丁的安装包及安装程序的元数据。

4. 补充标签：SWID标签，允许附加信息与任何引用的SWID标签相关联，有助于确保软件供应商提供的SWID主标签和补丁标签不会被软件管理工具修改，同时也可允许这些工具提供自己的软件元数据。

语料库标签、主标签和补丁标签具有相似的功能，是因为它们都描述了不同类型软件（例如，软件安装程序、软件安装、软件补丁）的存在，以及潜在的软件产品的不同状态。相比之下，补充标签则提供了不包含在语料库标签、主标签或补丁标签中的额外信息。

图4:由SWID标签记录在端点上的软件生命周期

来源：NISTIR8060

上图说明了软件生命周期中的步骤，以及四种SWID标签支持的生命周期事件之间的关系。补充标签可以与任何其他标签相关联，以提供可能有用的额外元数据。作为一个主体，SWID标签具有广泛的功能，包括软件发现、配置管理和漏洞管理。

以下是ACME公司一款已编译软件（Roadrunner Detector）23的主要SWID标签示例。该标签定义了产品名称、版本和其他详细信息，比如二进制文件的哈希值。

（2）使用案例

a) 软件组件的SBOM

b) 对已安装软件清单的持续监控

c) 识别端点上易受攻击的软件

d) 确保已安装软件正确修补

e) 防止安装未经授权或已损坏的软件

f) 防止执行已损坏软件

g) 管理软件权限

（3）主要特点

a) 可提供构建时创建的稳定软件标识符

b) 能将软件供应商和消费者之间可交换的软件信息标准化，使其作为软件安装过程的一部分

c) 实现软件相关信息的关联，包括相关补丁或更新、配置设置、安全策略以及漏洞和威胁咨询

（4）SWID标签和SBOM

SWID标签可以作为SBOM使用，这是因为它们为软件组件提供了标识信息、为构成软件组件的工件提供了文件列表和加密哈希值，也提供了SBOM（标签）创建者和软件组件创建者的源信息。标签可以明确地链接到其他标签来表示依赖树。

生成SWID标签的操作模型允许标签作为构建和打包过程中的一部分生成，这就可使基于SWID标签的SBOM能在打包相关软件组件时自动生成。

（5）未来发展方向

尽管SWID标签是一种XML格式，但目前IETF正在对一种更轻量级的表示法CoSWID进行标准化，这是一种基于简明二进制对象表示法（CBOR）的SWID标签信息的二进制表示法，用来支持受限的物联网用例。关于CoSWID的更多信息可以在下面找到。

SPDX、SWID和CycloneDX的专家们参与了三种格式数据字段之间的映射实践。并非所有字段都是均匀地相互映射的，因为这些格式最初是为不同目的而设计的。然而，由于存在足够多字段的相互对应，工作组发现了其具有良好互操作性的潜力。这点在框架组文档中讨论的与基本组件数据相关的字段上尤其得以体现。24

下面，我们列出了与框架组文档中定义的“基线组件信息”类似的基本数据字段。为了说明这一点，我们提供了一个示例，该示例捕获了SPDX、CycloneDX和SWID中基本SBOM的许多特性。

表1：SPDX、CycloneDX和SWID之间的映射，用于基线元素

示例场景

示例如图5所示，它重点介绍了一个名为Acme的组织创建的一个称为“Application”的虚拟软件，并演示了SBOM如何以相当轻量级的方式呈现。Acme的应用程序正好包含两个第三方组件：Bob浏览器和Bingo缓冲区。反过来，Bob的浏览器依赖于第三方组件。我们知道Bob浏览器包含Carol的压缩引擎，但我们并不知道它是否还包含其他组件。Carol的压缩引擎是从头开始编写的，我们知道它不包含第三方组件。然而，对于Acme应用程序的另一个依赖项Bingo缓冲区，我们仍不清楚它是否包含任何第三方依赖项。

图5：演示SBOM外观的软件简单示例。25

当NTIA工作组开始讨论软件物料清单时，也建议考虑采用以下格式来识别软件。工作组与这些项目的创建者合作确定了关键要素，下面是总结，并附有进一步信息的链接。

ConciseSWIDTag（CoSWID）

（1）描述

ConciseSWIDTag（CoSWID）标签规范26是一种使用简明二进制对象表示法（CBOR）表示SWID标签的另一种格式。以XML表示的SWID标签可以相当大，甚至可能会大于在受限设备用例（例如，物联网）中可接受范围。虽然包含与SWID标签相同的信息，但CoSWID标签可以显著减少SWID的大小。方法是通过在CBOR中使用整数标签代替人类可读的数据元素和常用值的字符串来减少。

（2）使用案例

作为SWID标签的另一种表示形式，CoSWID与SWID标签共享相同的用例。由于尺寸减小，CoSWID标签可以更好地支持这些用例在物联网和其他受限设备和网络中的实施。

（3）主要特点

CoSWID与SWID标签具有相同的功能。表达相同的信息的同时，这种格式减少了SWID标签的占用空间。下面是一个基于十六进制二进制格式的CoSWID标签示例：

bf0f65656e2d5553207820636f6d2e61636d652e727264323031332d63652d7370312d76342d312d352d300cc2410101783041434d4520526f616472756e6e6572204465746563746f72203230313320436f796f74652045646974696f6e205350310d65342e312e350e2002bf181f745468652041434d4520436f72706f726174696f6e18206861636d652e636f6d18219f0120ffff04bf18267823687474703a2f2f7777772e676e752e6f72672f6c6963656e7365732f67706c2e7478741828676c6963656e7365ff05bf182d6432303133182f66636f796f7465183473526f616472756e6e6572204465746563746f72183663737031ff06bf11bf18186e72726465746563746f722e657865141a200820e8079f015820a314fc2dc663ae7a6b6bc6787594057396e6b3f569cd50fd5ddb4d1bbafd2b6affffffff

CBOR中的CoSWID大小为317个字节，而XML中的SWID标签为795个字节。这意味着同样是表达了相同的信息，但前者的大小减少了60.1%。

通用平台枚举项（CPE）

（1）描述

还有一种相关的数据格式叫做通用平台枚举项（CPE）。27这种格式是“描述和识别企业计算资产中存在的应用程序、操作系统和硬件设备类别的标准化方法”。CPE可用于各种情境，比如国家漏洞数据库（NVD）。CPE能够识别特定应用程序，（无论其是否带有版本号）但它本身并不能识别子组件。

（2）使用案例

CPE很有用，因为它们可以通过NVD方便组件进行漏洞匹配。NVD搜索工具可以查询SBOM中包含的CPE信息，发现其潜在的相关漏洞。288

（3）主要特点

CPE标识符由11个元素及cpe版本的前缀组成（最新的cpe规格是cpe:2.3）：

wfn[part="o",vendor="microsoft",product="windows_vista",version="6\.0",update="sp1",edition=NA,language=NA,sw_edition="home_premium",target_sw=NA,target_hw="x64",other=NA]

Package URL（purl）

（1）描述

Package URL（purl）试图标准化现有的可靠识别和定位软件包的方法。purl是一个URL字符串，用于在编程语言、包管理器、打包约定、工具、APIs和数据库之间以普遍和统一的方式标识和定位软件包。这样的Package URL对于使用基于熟悉URL约定和简单且富有表现力的语法来可靠地引用相同的软件包很有用。

purl是一个由七个组件组成的URL：scheme:type/namespace/name@version?qualifiers#subpath

组件由特定字符分隔，以进行无歧义的语法分析：

组件被设计成一个层次结构，最重要的组件在左边，最不重要的在右边。purl不能包含URL权限：即它不支持用户名、密码、主机和端口组件。命名空间段有时可能看起来像主机，但它的解释是特定于一个类型的。

（2）例子29

pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessiepkg:docker/http://gcr.io/customer/dockerimage@sha256:244fd47e07d1004f0aed9cpkg:gem/ruby-advisory-db-check@0.12.4pkg:golang/google.golang.org/genproto#googleapis/api/annotationspkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources

（3）链接

SPDX2.2将PURL识别为有效的外部引用30。

SWID：可以使用“link”元素在SWID标记中提供PURL。

CycloneDX：所有版本的CycloneDX都支持将PURL作为组件标识的一部分。

软件遗产持久标识符（SWHID）

（1）描述

软件遗产项目31是一个非盈利性的倡议，32得到了大量组织的大力支持。这些组织包括软件、系统和工具供应商、IT用户、学术和政府机构。它正在构建一个软件源代码的通用存档，并预将其作为一个通用基础设施，满足从工业到科学和文化的各种用例。

（2）使用案例

软件遗产的任务声明中特别列出的一个用例是行业源代码跟踪33:“因为行业不能承担丢失其源代码任何部分的后果，所以我们要跟踪软件的起源、历史和演变。软件遗产项目将提供独特的软件标识符（与软件组件有内在联系）,以确保在未来的开发和组织变化中具有持久的可追溯性"。这些内在标识符基于加密签名，具有精确的正式定义34，并且已经用于存储在软件遗产档案中的100多亿件工件35。它们是确保源代码库完整性的重要组成部分，目前正在被一些主要行业参与者以及Wikidata社区36使用，来完成他们SBOM工作流的一部分，其中涉及到源代码分发义务。

（3）链接

SPDX2.2:正式承认SWHIDs为有效的外部引用类型。37

该文件主要介绍了工作组调查的现有标准、格式和倡议，这些内容适用于识别软件产品构建中使用的外部组件和共享库（专有或开源）。该文件还分析了其他组织在交流这些信息方面（以机器可读的形式）进行的工作。总的来说，基线SBOM数据可以通过文件中描述的任何一种格式来传输，生态系统能够且应该支持下述数据格式之间的互操作性。NTIA方面也正在从现有模板和标准相关项目中汲取经验，努力开发出具有完善实践意义的新一代软件物料清单规范。

注释1：数据元素基线

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

注释2：最小元素文件密切相关

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

注释3：下游用户

https://www.ntia.gov/files/ntia/publications/ntia_sbom_sharing_exchanging_sboms-10feb2021.pdf

注释4：SBOM的生产和供应

https://www.ntia.gov/files/ntia/publications/software_suppliers_sbom_production_and_provision_-_final.pdf

注释5：管理和使用

https://www.ntia.gov/files/ntia/publications/software_consumers_sbom_acquisition_management_and_use_-_final.pdf

注释6：ISO/IEC标准

ISO/IEC5962:2021 https://www.iso.org/standard/81870.html

注释7：开发工具

https://spdx.dev/resources/tools/

注释8：SPDX标准

https://spdx.github.io/spdx-spec/

注释9：SPDX许可证列表

https://spdx.org/licenses

注释10：正式验证

https://tools.spdx.org/app/validate/

注释11：SPDX规范附录III

https://spdx.github.io/spdx-spec/appendix-III-RDF-data-model-implementation-and-identifier-syntax/

注释12：SPDX网站

https://spdx.dev/

注释13：工作组方向一致

https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf

注释14：SPDX

https://github.com/spdx/spdx-spec/issues

注释15：专有工具

https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf

注释16：CycloneDX规范

https://cyclonedx.org/docs/latest

注释17：CycloneDXCLI

https://github.com/CycloneDX/cyclonedx-cli

注释18：CycloneDX概述

https://cyclonedx.org/specification/overview/

注释19：制定和增强

https://cyclonedx.org/ext/vulnerability/

注释20：GitHub里程碑

https://github.com/CycloneDX/specification/milestones

注释21：ISO/IEC19770-2:2015

https://webstore.ansi.org/Standards/ISO/ISOIEC197702015

注释22：SWID标签文件

虽然ISO文件付费，但任何人都可以自由使用ISO标准化的规范。有关详细说明和指南，请参阅NIST内部报告（NISTIR）8060:

GuidelinesfortheCreationofInteroperableSoftwareIdentification（SWID）Tags

注释23：Roadrunner Detector

https://csrc.nist.gov/publications/detail/nistir/8060/final

注释24：体现

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

注释25：软件简单示例

有关此示例的更多详细信息，请参见

https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

注释26：ConciseSWIDTag（CoSWID）标签规范CoSWID格式由

https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/描述。该IETF草案即将作为IETFRFC发布。

注释27：CPE

CPE定义在

https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe/

注释28：相关漏洞

NVDCPE搜索工具

https://nvd.nist.gov/products/cpe/search

注释29：例子

信息来自:https://github.com/package-url/purl-spec

注释30：type

信息来自:https://github.com/package-url/purl-spec

注释31：软件遗产项目

https://cacm.acm.org/magazines/2018/10/231366-building-the-universal-archive-of-source-code/fulltext

注释32：非盈利性的倡议

https://www.softwareheritage.org/support/testimonials/

注释33：行业源代码跟踪

https://www.softwareheritage.org/mission/industry/

注释34：正式定义

https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html#persistent-identifiers

注释35：工件

https://archive.softwareheritage.org

注释36：Wikidata社区

https://www.wikidata.org/wiki/Property:P6138

注释37：外部引用类型

https://spdx.github.io/spdx-spec/3-package-information/#321-external-reference