美国商务部机构建议这样生成软件供应链 “身*份*证”

美国商务部机构建议这样生成软件供应链 “身*份*证”
2022-5-7 18:5:30 Author: www.freebuf.com(查看原文) 阅读量:14 收藏

01 概览

本手册概述了软件物料清单(SBOM)的生成流程，以及软件供应商提供它们的方式。“供应商”的广义定义包括提供商用产品的软件供应商，提供可交付软件并签署合同的软件开发者，以及公开可使用的开源软件(OSS)开发项目。

02 工作流程概述

创建软件的组织多样性，以及跨多个软件和系统创建SBOM的需求，意味着组织将使用多样化工具和过程来生成SBOM。美国政府已经公布了一个要素表，这其中包括数据字段、自动化能力和操作需考虑的因素。不管SBOM如何创建，都需要将这些要素包含在内¹。本文件有助于团队基于其现有工具水平、处理流程和技术成熟度来表述考虑因素和做出决策。

SBOM的生成过程大致可分为以下几个步骤：

1	识别软件交付品中包含的软件组件。
2	获取可交付软件中的组件数据。
3	将组件数据导入结构化的SBOM格式。
4	验证SBOM以确保格式有效且包含“基线”属性。

03 不同工作流程的差异

每个组织对软件的创建和分发都有不同的需求和能力：包括作为工程现代化组成部分的工具和流程水平，对现有工具和流程举一反三的能力。因此组织间甚至同一组织内部，生成SBOM的工作流程也会有所不同。

下面，我们将说明其中一些变化，以及不同条件是如何引导组织有效且高效地创建SBOM的。

3.1当前的最佳实践与非自动化工程过程

源码级SBOM(“构建前”的SBOM)的生成可作为版本控制系统的一部分，也可以通过挖掘产品构建管道输入的工具进行创建。对进入管道的源文件(以及任何二进制文件的哈希)进行有效的哈希处理，有助于确保关键组件的识别，这在创建产品前查找漏洞时是最重要的。一些对保障性和安全性高要求的用例可能需要从构建到成为源文件间整个过程的追溯跟踪；同时，构建中也有必要包含源代码、相关数据和组成工件相关的SBOM。然而, 构建前的SBOM可能会有易受到攻击的源代码，只是它们并不会包含在最终可执行文件中。

3.1.1 自动化的工作流程：作为构建工件生成SBOM

当前工作流程的最佳实践比如Git，它用于软件版本控制和管道持续集成/持续交付(CI/CD)，支持从管道构建(在编译源代码或软件打包过程中生成的“构建时（build-time）”SBOM)中自动整理和生成SBOM。这些自动化过程会生成构建软件所必需的数据，因此生成的SBOM通常不会出现人工输入错误，而且会包含更具权威性的软件组件特征。自动化生成的SBOM还可以实现SBOM的签名自动化，这也为供应商和下游消费者提供了更多的可审计性。

我们可以通过工具来创建SBOM，这个工具会和构建系统、包管理器和CI服务器集成。在构建管道期间创建SBOM具有许多技术和业务优势，但这超出了本手册的范围。“构建时”创建的SBOM通常要调用一个工具，它会和正在使用的构建系统共同本地协作。该工具随后生成组件清单和所有关联元数据，这些元数据可以在之后的构建管道的过程中扩充以及增强，由此产生的SBOM将作为附加工件交付，并具体到所构建的软件版本。另外，在构建的过程中，SBOM的加密签名能够增加其可审计性。

SBOM供应商必须确定构建过程中将生成的SBOM格式。以下的每种SBOM格式都包含了一个映射，从Framing文档（一份NTIA文件）中标识的“基线”属性到已经标识的SBOM特定数据元素，都用来表示这些通用元素。

SPDX(Software Package Data Exchange)

https://github.com/lfscanning

中有一些SBOM常见的开源项目。

CycloneDX：示例见

https://github.com/CycloneDX/

sbom-examples。

软件标识(SWID)：SWID实例请参见

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

如果需要对软件许可证进行审计，则有源代码和二进制代码扫描实用工具收集许可证细节，并生成包含此类信息的SBOM。SBOM内能自动生成许可证数据，满足了那些需要把集成组件公开的开源许可证的条件。

3.1.2 在构建管道和软件工厂中生成SBOM

许多组织在其开发生命周期中自动创建SBOM。这通常是在CI/CD管道中完成的，其中每次构建都会生成一个作为工件的SBOM。大多数开发生态系统都有一种可选方法，那就是通过构建插件来创建SBOM。这些插件与底层构建和依赖关系管理系统集成，生成一种支持的SBOM格式。这种方法很简单，但可能需要额外资源来集成所有构建管道。

针对所有开发生态系统没有一致且通用SBOM的情况，一些组织采用了一种可以帮助他们加速组织间SBOM创建的策略。并非是和每个构建集成，CI/CD软件工厂本身就可以扩展以支持SBOM自动化创建。管道集成和执行SBOM自动化创建的GitHub就是这个功能的具体例子。

3.2容器化过程中SBOM的容器导出

软件可以以应用程序或可执行文件的形式交付，但越来越多的软件以容器镜像的形式交付，例如Docker/Open container Initiative (OCI)格式。容器镜像有分层的概念，它有一个准确完整的组件清单，这些组件来自于容器镜像的所有层。每层可能都会包含各种软件应用程序，包括操作系统(OS)、操作系统包、应用程序及其关联库，还有其他可能已集成到各层的工件。SBOM描述容器镜像时，应该会汇总并标识来自所有层的所有软件。

多个容器镜像可聚合起来形成一个应用程序，如何执行这一操作超出了本文的范围。但是，我们不能忽略容器之间存在的依赖关系。Docker Compose图和Kubernetes Helm图是两种描述容器化资源的常用方法。由于二者都描述了一个或多个容器镜像，因此不管以单独还是聚合的形式，SBOM都能捕获到这些格式描述的所有镜像的软件聚合。此外，如果一些容器向其他容器提供服务，SBOM依赖关系图也能捕获到。更多信息请参阅External Services: Crossing Trust Boundaries。

构建时生成的SBOM应将构建时间作为SBOM的一部分。

客户可能需要SBOM的签名作为保障要素。为了满足这些客户的需求，作为构建过程一部分而生成的SBOM应当作为构建过程一部分进行签名。

3.2.1 构建之后的SBOM

并非所有交付软件的SBOM都能在构建时生成。许多软件功能，尤其是在老旧系统中用的功能，一开始并不是用目前软件版本控制或者持续集成的方法开发的。对于这些系统，供应商用来填充“构建后”SBOM的数据应尽可能获取接近工程过程的组件数据，并明确“已知的未知情况”²，这其中可能包括全局唯一外部标识符。构建后的SBOM可能是来自各种不同供应商、过程以及工具的SBOM集合。通常情况下，填充从上游供应商收到的SBOM组件相关信息需要用到用代码分析工具执行的二进制扫描，否则此类SBOM信息将无法获得。然而尽管代码分析工具可以生成SBOM，其标识商业组件的能力可能还是有限。

对于非自动化的系统和过程，重要的是要清楚SBOM中列出组件的来源，以及它们是如何为SBOM获取这些信息的。一些重要问题包括：

(1) 来源

有没有一种方法可以来验证SBOM中列举的组件是从一个特定的来源进入供应商组织的？（例如，在特定时间点从包管理器统一资源定位器[URL]下载，或者从带有供应商签名的特定分发服务器中获取。)遗留系统通常缺乏托管链，无法为开源组件建立可验证的来源，这些组件是由开发人员引入，或从商业供应商处获得，只是他们并没有在软件上签名。托管链可以通过官方来源采购组件重新建立。

例如，一个组织的软件开发管道可能需要一个依赖项清单，以列出企业组件存储库(或包管理器)中的组件。组件存储库包含SBOM所需的基本元数据(供应商、产品名称和版本)。这个元数据还可能包括组件哈希值和来源(例如，公共包管理器或开源URL)。要获取SBOM组件数据，从包管理器中比从某个描述特点时间点组件组合的文档文件(例如电子表格)中获取更为可取，因为自文档生成，组件组成可能就已经发生了变化。

遗留过程(Legacy Processe)³通常涉及通过现有平台和流程对SBOM数据的手动或半自动化管理，如手工维护的电子表格，或从手工维护数据的系统导出的电子表格。出于遵循语义版本的目的，软件功能中包含的开源组件列表可以被维护保存。如果没有其他可用的数据，可以利用这些OSS或“FLOSS”(free/libreOSS)清单生成SBOM，但是缺少哈希值意味着组件名称和软件功能中的实际组件之间缺少可验证的联系。为了确保软件的完整性，需要进行一些验证过程，但遵从语义版本的电子表格只是个开始。二进制扫描可用来确保软件的完整性。

(2) 软件标识

软件组件是否能通过官方标识(例如公共平台枚举[CPE]、包URL[PURL]、SWID标签)映射到漏洞信息？许多遗留系统在软件引入组织时使用的是人工指定名称来标识组件。这些内部名称可用于单一SBOM，但这个问题最终需要由SBOM开发者或消费者解决，并要引入官方标识，以此来实现漏洞管理。

近来提出的还有包管理中软件的标识或URL，例如公共存储库URL。这种方法适用于(公共)包管理服务覆盖的软件，而私有组件通常不适用这种方法。需要注意的是，包URL规范指定了全局唯一的公共标识符，即公开可访问的包管理器中包的位置，而不是一个企业内部的包管理器，它的命名空间和公共包管理器命名空间相悖。另外，公共标识符不仅仅是内部系统中供应商、包和版本信息的关联。为了遵守PURL规范，当源点是公开可访问的包管理器时，使用PURL作为软件标识符的供应商应使用PURL，它会将组件与公共包管理器位置相关联。源于供应商的专有或第一方包，可以使用内部包存储库限定符。

3.3 构建时未创建的SBOM生成时机

构建后生成的SBOM，应包括生成时间(即创建SBOM的时间)。SBOM自身的版本信息可包含在SBOM的标题或主体中。还可以对构建后SBOM签名，以确保SBOM的完整性和对SBOM作者的核实。

3.4可交付物:盒子里有什么

清楚什么能用SBOM描述，什么不能是很重要的。例如，如果一个应用程序作为源文件或编译后的二进制文件交付，其中的SBOM枚举了集成到应用程序中的软件依赖项，那么该SBOM属于该应用程序。这只是一个相对简单的例子。

如果应用程序安装了运行时依赖项、操作系统、动态链接库(DLL)、更新程序、共享库或其他包含项，SBOM的信息应当以一种明确的方式解决其描述内容的模糊性，使消费者能够了解到应用程序交付的附加组件或实用程序在SBOM中是否列出。例如，一个商业软件产品可能与应用程序的SBOM一起交付，也可能和其安装程序或分发包的单独SBOM交付。这个问题也适用于容器镜像和容器依赖性。类似地，用于创建软件工具链的SBOM也可能被提供。

避免漏报差距是很重要的，即供应商为其应用程序提供了一个SBOM，但安装程序部署的其他软件不在SBOM中，因为即使它们与应用程序一起交付或安装，这些组件也并不在应用程序内。运行时依赖关系也可能是一个重要的漏洞来源，供应商或消费者不应视其为盲点，除非它们被包含在二进制文件中。曾有这样例子，安装程序本身(而非其安装的内容)被恶意软件感染(或其本身就是恶意软件)。因此，“已知的已知情况(即SBOM所描述的外部限制)”的明确性涉及到安全，十分重要。

3.5 外部服务：跨越信任边界

系统确保跨信任边界的外部服务的可见性，例如，从应用程序调用Internet服务以提供应用程序所需的数据。自动更新服务是与安全相关的外部服务。

如果软件能力的执行依赖于对外部服务的调用，则可以使用SBOM来枚举软件交付所需要的外部服务。软件消费者可能会接受外部服务枚举，也可能不会，这这取决于他们自己的安全性和监管要求。这组需求目前还不是SBOM基线的一部分，它还在发展当中。

从供应商的角度来看，外部服务调用枚举可以简化动态测试，解决上门服务相关的网络检测警报问题，从而提高客户保障性、接受度和软件授权的效率。它还可以合理化网络权限建立，这是软件能力运作所需要的。

04 SBOM其他方面的考虑

并不是所有的SBOM决策都与依赖关系图和相关数据的技术创建有关。跟踪和共享软件供应链数据还涉及到运营、业务，甚至法律问题。下面是几个组织可能需要考虑的问题。

4.1SBOM的知识产权/保密条例

供应商可能会将SBOM视为有竞争力的信息，不希望他们的SBOM被公开。SBOM信息一定会通过中间消费者流动到中间商再到他们的最终购买者(即从分包商到承包商再到客户)，因此恰当的保密制度将SBOM视为专有资料，受合约谈判协议约束，而不是利用SBOM的版权来阻止分发。

例如，Creative Commons CC0许可证(SPDX生成和提供的最佳实践)提供的SBOM，也可以在保密协议下被提供。它不要求或允许在谈判达成的保密协议范围之外共享数据，但它的确允许在谈判达成的协议的许可范围内传输数据。

关于NTIA框架小组“SBOM的提供和交换”相关工作的更多资料，请参阅Sharing and Exchanging SBOM。

4.2SBOM格式的验证

有几种工具可以检查SBOM格式是否有效(例如，必要的字段是否存在、文档的结构是否正确)。SBOM验证是对格式正确性和完整性的检查，而非对填充SBOM字段的数据质量或准确性的检查。SBOM验证可在交付SBOM之前进行，以确保SBOM的使用者能够以可预测、无错误、自动化的方式解析SBOM。

SBOM验证工具的例子包括：

用于验证SPDX格式SBOM的SPDX Online Tool：

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

SWID工具：

https://pages.nist.gov/swid-tools/swidval/。

用于验证CycloneDX格式SBOM的CycloneDX CLI Tool和Web Tool：

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

https://cyclonedx.github.io/cyclonedx-web-tool/。

4.3组件的验证

对于SBOM消费者或创建者关心的SBOM信息验证的问题，可借助评估成熟度的架构来进行，其中包括开放式Web应用安全项目(OWASP)软件组件验证标准(SCVS)和ISO 5230。

OWASPSCVS(https://owasp-scvs.gitbook.io/scvs/)是一个基线评估架构，用于评估SBOM基线生成能力和除基线元素以外SBOM的完整性。该标准允许SBOM生成组织评估其技术成熟度和验证级别（放在用于填充SBOM的底层数据当中），因此也是信任级别。

OpenChain(https://www.openchainproject.org)，也被称为ISO/IEC5230:2020，它是一个过程管理标准，旨在明确处理精确标识和软件入站、内部和出站跟踪所需的关键拐点。作为一个过程管理框架，ISO/IEC 5230与SBOM标准并无相关，这允许组织利用预先存在的活动，并采用最适合其需求的特定SBOM格式(如SPDX)和编码(如JSON、XML等)。ISO/IEC 5230的制定确保了任何使用的SBOM都能在生产的每个关键阶段得到充分的验证。同样的，它将显示当前组织过程管理的成熟度和改进路径。

二进制分析也可用于识别或验证SBOM中的二进制组件。软件成分分析(SCA)工具可以实现软件成分的透明性。

注释1：（《软件物料清单(SBOM)最小要素》.

https://www.ntia.gov/files/ntia/publications/sbom_ minimum_elements_report.pdf (2021)）

注释2：名词“已知的未知情况"

(known unknowns)”，在《SBOM最小要素》中通过举例具体描述，如对SBOM中未列举完整依赖关系图的情况，SBOM作者必须显式标识具体情况：需清楚区分没有进一步依赖关系的组件和依赖关系未知且不完整的组件等。

注释3：《SBOM最小要素》中有“遗留软件”的说法，通常指旧版本但仍在使用的软件

NTIA 原文可见：https://www.ntia.gov/files/ntia/publications/software_suppliers_sbom_production_and_provision_-_final.pdf

代码卫士试用地址：https://codesafe.qianxin.com/

开源卫士试用地址：https://oss.qianxin.com

推荐阅读

《软件供应商手册：SBOM的生成和提供》解读

在线阅读版：《2021中国软件供应链安全分析报告》全文