√关于软件物料清单（SBOM），你所需要了解的一切

在此前的多篇文章中，我们已经详细地介绍了软件物料清单（SBOM）对于保障软件供应链安全的重要性以及一些注意事项。在本文中，我们将会更深入地介绍SBOM，包括最低要求元素、格式、使用场景以及如何对其进行管理等。

SBOM所包含的元素

2021年年中，NTIA发布了软件物料清单（SBOM）的最少必需元素。这些元素包含以下三类：

• 数据字段：每个软件组件的基本信息
• 自动化支持：能够自动生成机器可读格式的SBOM
• 实践和流程：SBOM 应该如何及何时生成和分发

所需元素的目的是为 SBOM 使用者提供他们所需的信息，以管理漏洞、清点软件组件，并监管许可证合规性。

数据字段

根据NTIA的说法，这一字段是为了“充分识别这些组件以在整个软件供应链中跟踪它们，并将它们映射到其他相关的数据来源，如漏洞数据库或许可证数据库”。

7个必要的数据字段如下：

• 供应商名称： 开发该软件组件的个人或组织
• 组件名称： 给一组软件命名，通常由供应商决定
• 组件版本： 一个标识符，指定软件与以前版本的变化。同样，这是由供应商决定的
• 其他独特标识符： 像Software Identification （SWID）标签、Package Uniform Resource Locators （PURL）、Common Platform Enumeration（CPE）或类似的标识符，可以帮助SBOM 消费者在关键数据库中找到组件
• 依赖项关系： 表示软件组件是如何结合在一起的，如，某个上游组件包含在某个软件中
• SBOM数据的作者： 生成SBOM元数据的实体，可能是软件供应商或其他个人、团体
• 时间戳： SBOM 生成的日期和时间

自动化支持

下一组最低要求元素是指 SBOM 数据在整个软件生态系统内部以及跨组织通信的方式。这一要求的目标是为了确保 SBOM 数据真正可用——不仅仅是机器可读，还能够让人直接阅读，而且它的传输格式是可互操作的。

要达到这一目标，NTIA 认证了3个交付格式来生成和消费 SBOM。至关重要的是，向联邦政府销售软件的组织必须以这三种格式之一传送 SBOM，以符合网络安全行政命令的要求。

这3个格式是：

• Software Package Data Exchange (SPDX)
• Software Identification (SWID) Tags
• CycloneDX

在后面一节，我们将会对这3个格式进行详细介绍。

实践和流程

最后一组SBOM最低要求元素涉及生成和申请SBOM的具体操作。具体而言，实践和流程部分包括以下6个方面的要求：

• 频率（Frequency）： NTIA规定，“如果软件组件随着新的构建或发布而更新”，企业应该生成新的SBOM。此外，供应商在以下情况下也需要生成新的SBOM：
  1）需要纠正原始版本中的错误
  2）了解有关软件组件的新细节
• 深度（Depth）： 合规的SBOM需要包含：
  1）所有顶层组件
  2）所有间接依赖关系。如果SBOM作者不能包含所有间接依赖关系，则需要囊括足够的信息，使消费者可以递归地找到他们。
• 已知的未知因素（Known Unknowns）： 在SBOM作者没有提供完整的依赖关系图的情况下，他们需要说明这是因为：
  1）该组件没有进一步的依赖关系，或者
  2）不知道是否存在其他的依赖关系。
• 分发和交付： 这一部分分为几个环节，都是关于确保SBOM以可消化的格式快速交付。首先，SBOM被要求以“及时”的方式提供（尽管没有设定天数或周数）。其次，他们必须有“适当的”角色和访问权限。最后，SBOM可以与产品的每个实例一起分发或者以其他可访问的方式提供，如公开的网站。
• 访问控制： 如果供应商想将SBOM数据的访问限制在某些客户或用户，他们需要提供这种访问控制的条款。此外，供应商需要提供 “具体的允许和便利”，以便SBOM消费者能够将数据纳入其安全工具。
• 容错程度： 网络安全行政命令和指导SBOM创建的法规目前尚不成熟，因此，各组织被指示要对（无意的）错误或遗漏给予理解。

SBOM交付格式及规范

企业可以通过各种不同的格式创建和发布软件物料清单（SBOM）。对于一个想要在其网站发布 SBOM 的企业来说，HTML 是一个合理的选择。如果 SBOM 中包含了文档或者源代码，那么纯文本也许是更佳选项。此外，还有 Markdown、PDF、CSV等格式可供使用。

除了这些常见的格式外，还有几种专门为交付SBOM而设计的格式，如 SPDX（软件包数据交换），SWID Tags（软件识别）以及Cyclone DX。

SPDX

SPDX是由 Linux 基金会运营的项目，旨在标准化企业共享和使用SBOM中信息的方式。SPDX 捕捉与provenance、许可证和安全相关的数据，下图展示了 SPDX 文档中所包含的数据：

该格式支持以下文件类型：

• YAML
• JSON（你可以在 GitHub 上找到SPDX的JSON schema：https://github.com/spdx/spdx-spec/tree/development/v2.2.1/schemas）
• RDF/XML
• tag:value flat text file
• .xls 电子表格

Seal 软件供应链防火墙可以直接生成SPDX格式的SBOM文件，欢迎访问下方链接申请产品试用：seal.io/trail

SWID Tags

SWID 是一个标准化的 XML 格式，可以识别软件产品的组成部分并将其与上下文结合。4种类型的 SWID Tags 在软件开发生命周期中：

• Corpus Tags： 识别和描述在安装前阶段的软件成分。根据 NIST 给出的定义，corpus tags 是指“软件安装工具和流程的输入”
• Primary Tags： 在软件产品安装后对其进行识别和关联
• Patch Tags： 顾名思义，patch tags 可以识别和描述补丁（而不是核心产品本身）。此外，patch tags 包含了补丁和其他产品或补丁之间的上下文关系信息。
• Supplemental Tags： SWID 格式仅允许 tag 创建者修改 corpus、primary和patch tags。但是 Supplemental Tags 可以让软件用户及软件管理工具在本地添加有益的上下文信息，如许可证密钥以及相关方的联系信息。

在决定将哪些标签和具体的数据元素纳入其产品时，各企业有一定程度的灵活性。在SWID规范中，除了几个必须的字段外，其他的元素和属性都是可选的。

最终，一个最低限度的有效和符合要求的标签只需要描述软件产品（如名称和标签ID）和创建它的实体的少数元素。关于SWID标签数据元素的最全面和最新的信息，建议查看ISO/IEC 19770-2:2015标准全文：
https://www.iso.org/standard/65666.html

Cyclone DX

Cyclone DX 是一个轻量级软件物料清单标准，旨在用于应用安全上下文和供应链组件分析。换言之，它旨在实现与SPDX、SWID以及其他所有SBOM交付格式类似的目标——提供构成一个应用程序的软件组件的关键信息。

Cyclone DX 支持以下4种类型的数据：

• 物料清单元数据： 关于应用/产品本身的信息——供应商、制造商、SBOM所面熟的组件以及用于汇编SBOM的任意工具
• 组件： 完整的专利清单及开源组件清单，包含许可信息
• 服务信息： 软件可能调用的外部API、终端URI、身份认证要求和信任名单
• 依赖项： 包含直接依赖项和间接依赖项

谁是SBOM的目标受众？

历史上，SBOM主要由合规团队用来审计、监控许可证以及遵守行业特定规范，但随着软件供应链攻击的上升，包括 SolarWinds 黑客事件和去年年末的 Log4Shell 漏洞，SBOM 的使用扩展到了安全和开发团队。

安全团队

对于安全团队来说，SBOM扮演着十分重要的角色，特别是需要进行漏洞扫描的时候。因为扫描SBOM库比从头开始扫描整个基础设施更简单也更快，在发生零日事件时，每一分钟都很重要。此外，安全团队也会利用 SBOM 所提供的信息（如风险所在位置）来确定问题修复的优先级，并针对特定组件创建策略，如供应商的选型、可引入的版本或者软件包类型等。

开发团队

开发团队可以使用 SBOM 来跟踪他们所开发、管理和运维的各个软件中的组件，包括开源组件、商业组件和自研组件。并且 SBOM 还能协助开发团队管理依赖项、识别安全问题以减少其重复的工作，还能确保开发人员使用的都是经过审批的代码和可信任的源。

SBOM 的应用场景

显然，有许多令人信服的理由推动企业创建SBOM，并且企业可以为所有产品创建SBOM，每个新版本都可以更新一版SBOM。此外，在一些特定场景中SBOM会最大限度地发挥其作用。

• 融资、并购和IPO： 软件物料清单是收购、IPO或融资过程中技术尽调的重要一环。相关利益方会要求获取文档以更好地了解产品中的软件成分以及许可证合规性、安全性或代码质量风险。
• 客户要求： 由于全球范围内的企业都将防止软件供应链风险的优先级提高了，因此未来会有越来越多的企业要求采购环节中需要提供SBOM。
• 向下兼容： 维护大量旧软件的公司经常需要进行OSS包的更新和升级。当然，如果对这些旧产品中的开放源码软件有一个完整的清单，做起来就容易多了。

全面管理 SBOM 的最佳实践

随着SBOM被迅速接受，行业领导者已经开始开发创建、管理和使用SBOM 的方法。这些实践跨越了软件生命周期的各个关键阶段：

1、在统一的存储库中存储和管理 SBOM
虽然单个开发或应用团队可以将SBOM与他们的代码构件一起存储在存储库中，但安全团队必须在所有应用和开发团队中维护一个统一的SBOM存储库。当新的漏洞或安全事件出现时，安全团队和CISO需要快速查询所有软件的SBOM并即时评估影响，而不是分别从每个团队中获得单独的评估报告，或者不得不浪费事件从头开始查找和重新扫描他们所有的应用程序。此外，满足监管要求或合规标准也需要一个集中的存储库，用于生成报告和其他的合规活动。

2、要求所有进入供应链的软件提供SBOM
企业如果需要对所使用的软件保有可见性，那么收集 SBOM 信息以分析软件成分或应用是十分重要的。如果是第三方商业软件，那么软件供应商应该提供必要的 SBOM，并将其纳入你的 SBOM 资源库。

当使用的是开源组件来构建自定义软件时，在将其引入开发流程前企业应该直接扫描开源构件（如容器镜像）或者开源代码仓库。在某些情况下，开源项目可能会提供一个签名的 SBOM，这可以让企业将他们生成的 SBOM 与社区提供的 SBOM 进行比较来进行验证。

3、为每个开发环节和构建生成SBOM
各行各业的企业正在定制软件以迎合其独特的市场需求。大部分软件都由大量的开源代码组成（根据不同的应用程序，开源代码的占比在50—90%之间）以及内部开发的代码和第三方库。由于在构建阶段开源代码常常会引入额外的依赖项，因此在开发流程中的每一步及每一次构建软件时都扫描您的软件是至关重要的。这可以让您检测出意料之外的SBOM变更，这些变更可能由新依赖项或代码修改导致的。这些 SBOM 需要标记为特殊组件或他们所代表的应用程序。

4、为你所部署或交付的每个软件版本创建综合的SBOM
无论您是将软件交付给客户，还是帮助客户、员工、合作伙伴进行部署，您应该创建一个综合的SBOM，并标记为该版本软件的变更。这提供了一个追踪机制，可以让企业快速评他们生产的应用或组件的安全状况，同时评估新漏洞对此前开发的影响。对于将软件售卖或提供给外部用户的企业，您也可以提供必要的可见性和“信任报告”给软件的下游用户。

5、 将自动化应用于策略执行和告警

借助中心化的SBOM仓库和有效的SBOM管理能力，企业可以利用一个自动的策略引擎来应用策略规则，如同步特殊的监管要求或合规标准。同时，还可以应用任意内部要求。自动告警可以提醒您新漏洞或违反策略的行为，如此，受影响的团队可以快速修正重要问题并阻止受影响的镜像被部署。

借助工具生成SBOM

可以肯定的是，软件物料清单将在业务开展方式中发挥越来越重要的作用。但是，考虑到制作SBOM所需的数据量，仅通过人工将这些碎片组合在一起是相当具有挑战性的。Seal 软件供应链防火墙可以生成SBOM数据，并可以跟踪SBOM的变化以进行漏洞匹配，及时发现软件供应链中的安全风险。