SBOM（软件物料清单）是给定产品的中所有软件组件（专有和开源代码）、开源许可证和依赖项的清单。它提供了对软件供应链以及可能存在的任何许可证的合规性、安全性和质量风险的可见性。

由于当今的应用程序通常由许多单独的组件构建，通常来自各种开源或专有源码包，因此SBOM变得越来越重要和有价值。考虑到这些复杂性，涉及产品的组织和个人很难完全了解软件供应链以及可能存在的任何许可证风险。

而SBOM可以帮助企业快速识别和补救潜在的安全漏洞，满足许可要求，并应用版本控制最佳实践。此外，去年美国政府也就此颁布了一项条款，要求针对联邦政府出售产品的组织必须创建SBOM，以进一步提高安全性。

在本文中，我们将探讨与SBOM相关的所有内容，包括构成要素、优点、用例和工具模板。

一、SBOM的要素

2021年7月12日，美国联邦政府公布了软件材料法案的最低要求，这些指导方针目前只针对与联邦政府有业务往来的企业，但很明显，对于其他社会企业来说，这是迟早的事。

SBOM的最小组成要素分为三个领域：

• 数据字段：每个基于组件的软件工程的基线信息
• 自动化支持：以机器和人类可读格式自动生产SBOM的能力
• 实践和过程：如何以及何时生成和分发SBOM

1.数据字段

数据字段类别包括描述组成软件的组件的基本信息，根据NTIA（美国国家电信和信息管理局）发布的条款，数据字段的组成成分为：

①供应商名称：制造特定基于组件的软件工程的个人和组织

②组件名称：一个软件单元的名称，这是由供应商决定的

③组件版本：一个标识符，指定软件与以前版本相比的更改，同样由供应商决定

④其他的唯一标识符：例如SWID（软件标识符）、PURL（包统一资源定位器）、CPE（公共平台枚举），有助于在数据库中找到组件

⑤依赖关系：表示软件组件如何组合在一起

⑥SBOM数据的作者：生产SBOM元数据的实体，可能是供应商，也可能是个人

⑦时间戳：组装SBOM的日期和时间

2.自动化支持

这个需求的目标是确保SBOM数据实际上是可用的——它不仅是机器可读，而且是人类可读的，并且它是以可互操作的格式传输的。

为了实现这一目标，NTIA确定了SBOM的三种交付格式。

• SPDX（Software package data exchange）

SPDX是一种标准的数据传输格式，它捕获与出处、许可和安全相关的关键信息。由Linux基金会运行的项目SPDX的当前版本2.0支持以下文件类型：

①YAML 1.2

②JSON（你可以在github上找到针对SPDX的JSON Schema）

③RDF/XML（资源描述框架）

④tag文本文件

⑤.xls 电子表格

• SWID（Software identification） tags

SWID tags是标准化的XML格式，用于标识软件产品的组件并将其上下文化。你可以在NIST的SWID Tools页面里找到一些非常实用的SWID工具，例如tag生成器或tag验证工具。

①Corpus Tags: 这些标识和描述处于安装前状态的软件组件。根据 NIST 的规定，语料库标签“用于作为软件安装工具和过程的输入”。

②Primary Tags: 主标记的目的是在安装后识别软件产品并将其置于上下文环境中。

③Patch Tags: 顾名思义，补丁标签标识和描述补丁(与核心产品本身相对应)。此外，补丁标记可以并且确实包含关于补丁和其他产品或补丁之间关系的上下文信息。

④Supplemental Tags: SWID 格式只允许标签创建者修改语料库、主标签和补丁标签。补充标签使软件用户和软件管理工具能够添加本地实用程序的有用上下文信息，例如许可证密钥和相关方的联系信息。

• CycloneDX

根据NTIA制定的标准，CycloneDX可以被描述为“轻量级SBOM标准”，设计用于应用程序安全环境和供应链组件分析。CycloneDX SBOM可以表示为XML文件、JSON文件或协议缓冲。该规范包括以下五个领域：

①材料清单元数据：关于应用程序、产品本身的信息

②组件：专业组件和开源组件的目录

③服务信息：软件可以调用的外部API

④依赖关系：包括直接关系和传递关系

⑤构成：根据CycloneDX的描述，包括组成部分（组件、服务和依赖关系）及其完整性

3.实践和过程

具体来说，该部分包含以下六个方面的要求：

①频率：NTIA要求组织生成SBOM，如果供应商更正原始版本中的错误或增加了新的细节，则应生成新的SBOM。

②深度：SBOM需要包括所有组件和所有依赖，如果一个SBOM作者不能包含所有的传递依赖关系，那么他们必须提供足够的信息，以便使用者可以在哪里递归地找到它们。

③已知和未知：在SBOM作者没有提供完整的依赖关系图的情况下，他们需要指定这是否是因为：a.组件没有进一步的依赖关系或b.是否存在额外的依赖关系时未知的。

④分发与交付：首先，要求及时的提供SBOM。接下来，它们必须具有“合适的”角色和访问权限。最后，SBOM可以是与产品的每个实例一起分发或以另一种可访问的方式提供，例如web。

⑤访问控制：如果供应商希望限制某些客户或用户对SBOM数据的访问，他们必须提供这种访问控制的条款。此外，供应商需要提供特定的API，以便SBOM客户能够将数据集成到他们的安全工具中去。

⑥适应错误:显然，指导SBOM的网络安全行政命令和法规是新的，所以企业必须自行探索以及随时随地进行问题修复。

二、SBOM的优点

作为现代应用程序的一部分，大量不同的软件组件、依赖关系和许可证意味着管理它们可能非常困难。如果SBOM清单，像进行风险评估、围绕 OSS 许可合规进行尽职调查(比如识别版权许可的组件)以及修复漏洞等过程可能会非常耗费时间和痛苦。

当然，这种情况的另一面是，软件材料清单对于管理软件供应链中的风险大有帮助。具体来说，SBOM 有助于:

• 遵守政府规章制度
• 加快识别和补救潜在漏洞的进程
• 使制造商能够满足使用许多开放源码库所带来的属性要求
• 减少由于供应链不明确而可能落在开发团队身上的不必要的工作
• 提供透明度并与消费者建立信任
• 使制造商更容易识别和处理发布后的破损组件
• 在进行审计时避免重大的业务中断

三、SBOM清单用例

显然，有许多令人信服的理由可以解释为什么组织可以创建一个软件材料清单。因此，建议组织始终为所有产品创建 SBOM (并为任何新版本更新它们)。

尽管如此，在一些特定的用例中，软件材料清单可能被证明是特别有价值的。

• 融资、并购和首次公开募股: 软件材料清单是技术尽职调查过程的重要组成部分，伴随着潜在的并购、首次公开募股或融资轮。感兴趣的各方可能要求提供文档，以便更好地理解产品中的软件组件——以及任何许可证遵从性、安全性或代码质量风险。
• 合规性要求: 如前所述，拜登政府关于软件供应链安全的新网络安全行政命令要求向联邦政府出售产品的组织在每个产品上或作为公共网站的一部分发布一个网络清单管理系统。
• 客户要求: 随着防止软件供应链攻击成为全球组织越来越高的优先事项，我们预计越来越多的企业将要求 SBOM 作为采购和/或更新过程的一部分。
• 向下兼容: 维护大量旧软件的公司通常需要对开放源码软件包进行更新和升级。当然，如果对这些遗留产品中的 OSS 进行全面的清点，那么做到这一点要容易得多。

四、用CodeAnt生成SBOM

泛联新安的CodeAnt在帮助企业构建SBOM方面有很大的作用，它可以：

①提供全面和准确的数据

②提供可定制的报告格式

③自动化SBOM创建过程中的关键步骤，节省团队的大量时间，并加强软件供应链的安全性