后“最小要素”时代如何推进软件物料清单(SBOM)的应用落地

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

观点

后“最小要素”时代如何推进软件物料清单(SBOM)的应用落地

2023-08-23 15:57:08

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

软件物料清单(SBOM)是一种为了提升供应链透明度而记录其软件组成等信息的文件，对降低供应链维护和保障的工作量及难度意义重大。近年来，随着软件供应链安全成为关注焦点，特别是美行政令EO 14028发布后，各界对SBOM的追逐也呈现出白热化的态势。

但由于SBOM在使用推广过程中出现了一些困难和抵触，从业者对SBOM的思考也开始回归理性。红帽产品安全副总裁Vincent Danen针对《2022软件材料清单和网络安全报告》的统计数据表示，SBOM只有使用时才有用，仅要求生成并不解决问题，SBOM未来的方向是集中数据，让SBOM数据工作起来才能推动其使用。

本文以《SBOM最小要素》遇到的应用瓶颈为切入点，归纳分析了美网络安全和基础设施安全局(CISA)和开源安全基金会(OpenSSF)等机构组织在推动SBOM“使用”、“实用”、“适用”方面的思路、举措和进展，并结合我国当前的SBOM工作状况提出了对应建议。

一、“最小要素”其实并不“小”

美国家电信与信息管理局(NTIA)发布的《SBOM最小要素》是EO 14028要求的重要指南成果之一，引发了广泛关注。但软件供应链安全服务商Chainguard在2023年1月发布的一份对3000多个SBOM文件检测结果的分析报告中提到，仅1%的SBOM文件满足“最小要素”的要求，大量SBOM文件存在缺少组件供应商数据、无法指定所有组件的名称或版本等问题。由此看来，“最小要素”的要求似乎是SBOM的较高门槛。

此外，白宫管理和预算办公室(OMB)2022年9月发布了《通过安全的软件开发实践增强软件供应链的安全性》(M-22-18)的备忘录，以响应EO 14028 4k的要求。备忘录的附录规定了各机构后期需完成的任务及期限，其中CISA有一项任务是“发布更新的SBOM指南”，但未明确完成期限。这也反映出最小要素可能并非SBOM使用推广的最佳选择。“最小要素”时代必将随着新指南的制定而结束，但NTIA的一系列文件依然是后续工作的重要基础。

二、CISA“SBOM指南更新”工作进展

CISA的背景和职能定位决定了其SBOM工作更加关注落地和漏洞风险等方面，聚焦可操作性、工具、新技术、新用例等内容。CISA意识到SBOM的发展和改进应来自社区，通过促进社区的参与、开发和持续进步来推动SBOM工作。一年多来，CISA通过搭平台、建模型、扩VEX(漏洞可利用性信息交换)等工作完善和推进SBOM指导文件制定。

1、搭平台：推动成立5个工作组

为促进软件和安全社区在更广泛的技术生态系统中理解SBOM的创建、使用和实现，CISA推动成立了5个工作组。

工作组	每周会议时间 (美东部时间)	聚焦方向
VEX	周一10-11点	定义、细化VEX模型，并描述用例和认证等
共享和交换	周一12-13点	跨软件供应链的SBOM移动及相关元数据
入口和采用	周二12-13点	组织提供、请求和使用SBOM以了解风险并确保安全
云和线上应用	周三15-16点	将当前理解集成到线上应用和现代基础设施上下文中
工具和实现	周四15-16点	关注自动化SBOM生态的机遇和挑战

2、建模型：凝练共享和类型模型

SBOM共享生命周期模型

为帮助使用者合理选择共享SBOM的解决方案，2023年4月，《SBOM共享生命周期报告》发布，描述了从SBOM作者到用户共享SBOM的完整过程，包括发现(Discovery)、访问(Access)和传输(Transport)三个阶段，如下图所示。

报告针对发现、访问、传输的一系列具体方法，分别定义了高、中、低三级复杂度，并结合例子进行了详细说明。例如，对于访问来说，低、中、高级复杂度的方法分别包括人工控制、限制的访问控制粒度、授权的身份认证和访问控制等。模型和这些方法均基于NTIA的《共享和交换SBOM》，但NTIA列出的方法较少，且未进行复杂度分级。

SBOM类型模型

2023年4月，CISA的SBOM工具和实现工作组发布了《SBOM类型》，总结了当前工具能够创建的6个常见SBOM类型及各自的优点和局限。具体SBOM类型如下表所示。

SBOM 类型	定义	数据描述
设计	针对准备做的、计划好的软件项目或产品	源于设计规范/RFP/初始概念
源	从开发环境、源文件和用于构建的依赖项中创建	SCA工具生成，手工净化
构建	SBOM作为软件构建过程的一部分	由集成的中间构建和源SBOM组成
分析时	构建后通过分析工件生成的SBOM	由第三方工具分析工件生成
部署	结合配置项分析和部署环境中执行行为检查	结合已安装工件SBOM和配置信息
运行时	通过检测运行软件的系统生成SBOM	记录环境中存在或执行的工件

在RASC2023上，CISA SBOM共享联合负责人、Cybeats战略副总裁Chris Blask报告了《SBOM的世界》的议题，介绍了上述各类型SBOM之间的关系及对电力行业典型供应链参与者改进透明度和效率的帮助，以及在“未来集成商交付的解决方案”、“安装新产品的程序操作”和“管理安全修复的程序”三个典型场景下，各类型SBOM协作应用的例子。

3、扩VEX：补充和制定VEX指南

VEX是一种用于表示软件产品是否受已知漏洞影响的机器可读的安全通知形式，并非SBOM的必要组成，但对SBOM数据的有效使用，特别是在安全领域的使用有很好的支撑作用。VEX最初由NTIA提出，但CISA近一年多来从多个方面进行了扩展和规范。

定义VEX最小元素和应用场景

2022年4月，《VEX用例》发布，推荐了VEX文档最小数据元素，并提供了一系列产品供应商可能会遇到的应用场景示例，可用于指导构造不同复杂度的VEX文档。其最终目标是支持跨漏洞生态系统的更大自动化，包括披露、漏洞追踪和修复等。

VEX文档最小数据元素包括：VEX元数据、产品详情、漏洞详情、产品状态详情(NTIA初始VEX中定义的“不受影响”、“受影响”、“已修复”、“调研中”4种状态)4部分内容。并规定，如产品状态为“受影响”，则必须有一个行为语句来指明用户需要做什么；如产品状态为“不受影响”，则必须有一个影响语句来进一步解释细节。

文件针对“单产品&单漏洞”、“单产品&多漏洞”、“多产品&单漏洞”和“多产品&多漏洞”等四大类9种典型场景，分别给出了具体案例，以及套用了最小数据元素的CSAF和CycloneDX格式的VEX文档。

确定“不受影响”状态解释选项

2022年6月，《VEX状态解释》发布，为“不受影响”的产品状态推荐了5种可能的解释选项，并提供了在VEX文档中适时使用不同选项的示例，以帮助使用者理解产品“不受影响”的结论是在什么情况下做出的。

这5种解释选项包括：组件不存在、易受攻击的代码不存在、易受攻击的代码不会被控制、易受攻击的代码不在执行路径上、内部缓解措施已存在。文件针对每种状态解释选项给出了具体的示例和对应的状态解释图。

例如，“组件不存在”的示例可能包括使用Python编写的产品不会受Java组件Log4j漏洞的影响、自动化导致不正确地将组件标识保存在JAR文件中、其他层删除了基础层容器镜像中包含的未使用的包等；“易受攻击的代码不在执行路径上”的状态解释图如下所示。

规范VEX最低要求及标准格式

2023年4月，《VEX最低要求》发布，以标准格式指定了创建VEX文档所需的最小元素。“最低要求”面向自动化、工具和互操作性，为非强制要求。CSAF、CycloneDX和OpenVEX等格式均可用于生成基于最低要求的VEX文档。

“最低要求”的VEX数据元素如下表所示。一个VEX文档中可包含一个或多个VEX语句。表中数据元素名称后方括号中的内容是元素标识符；圆括号中的内容是对相应元素的解释说明。

所属类别			VEX数据元素
VEX文档	文档元数据		文档ID[doc_id]
			文档版本[doc_version]
			作者[author] (个人/组织，可表现为“名称/URI”等)
			作者角色[author_role] (可定义为“用户/供应商/协调者/……”)
			工具[tooling] (生成VEX相关信息的工具或自动化机制)
			首次发布时间戳[doc_time_first_issued]
			最后更新时间戳[doc_time_last_updated]
	VEX语句	语句元数据	语句ID[statement_id]
			语句版本[statement_version]
			首次发布时间戳[statement_time_first_issued]
			最后更新时间戳[statement_time_last_updated]
		产品详情	产品标识符[product_id]
			子组件标识符[subcomponent_id]
			提供者[supplier]
		漏洞详情	漏洞标识符[vul_id]
			描述[vul_description]
		状态	状态 [status] (从4个状态选项选择)	若选“不受影响”，需增加：	影响语句[impact_statement]
					影响语句时间戳[impact_statement_time]
					解释[justification] (从5个解释选项选择)
				若选“受影响”，需增加：	行为语句[action_statement]
					行为语句时间戳[action_statement_time]
			状态说明[status_notes] (附加信息，如引用的其他VEX信息等)

三、OpenSSF“SBOM无处不在(SBOM Everywhere)”计划进展

在2022年5月的白宫开源软件安全峰会Ⅱ上，OpenSSF发布了《开源软件安全行动计划》，介绍了改善开源软件安全的10个方向。其中方向9为“SBOM无处不在：改进SBOM的工具使用和宣传培训，以尽量促进其应用”，核心思想是“通过无处不在的SBOM改善整个开源生态系统的安全状态。仅发布是不够的，SBOM需要被积极的使用”。

随后，OpenSSF在安全工具工作组下设立了“SBOM无处不在兴趣小组(SIG)”，专注于通过改进工具和培训促进SBOM的可用和易用。成立以来，SIG的主要工作聚焦在探索创建SBOM工具生态全景图、与开源生态和项目合作研发并向其推广成功经验、识别面向安全的SBOM用例等方面。

1、SBOM工具生态全景图构建

(1) SBOM全景图的目标和任务

当前，对SBOM工具跟踪工作的不足带来了搜索工具的困难。SIG从成立之初就计划创建一个类似于CNCF“云原生全景图”的SBOM全景图，用于跟踪所有SBOM工具、企业、数据格式和用例，以便对生态中大量的解决方案进行分类、搜索和跟进。

根据计划，SBOM无处不在项目将为全景图的初始构建、填充和部署提供资金，并与OpenSSF会员、志愿者一起进行后续维护。SIG认为，全景图一旦建立起来并被视为信息的标准来源，开发者将保持对其工具的更新，并且能够帮助所有人驾驭庞大的SBOM世界。SIG为全景图的开发和部署规划了4项任务：

在OpenSSF基础设施上建立SBOM全景图。全景图将托管在OpenSSF的GitHub库中，按OpenSSF要求使用适当的品牌和许可，并实施最新的行业标准；
将OpenSSF工具分类法应用于已知工具列表。NTIA的已知工具文档已长时间未更新，且非机器可读。部署全景图时，SIG将会将其转换为全景图工具可读的YAML文件；
完善现有的NTIA工具分类元数据。NTIA的分类方法已过时。在依靠社区成员提供当前工具、标准和概念的列表后，应尽量从中识别新的分类元数据；
确保全景图是社区可维护的。全景图被部署后，将由社区来推动未来的更新。必须确保所有必要的组件都存储在GitHub库中，且有解释如何更新、添加和删除条目的文档。

(2) 基于工具信息模板的已知工具维护

根据上述第二项任务的要求，SIG正在推进SBOM工具信息模板的编制，并基于模板初稿(2022年9月1日)对140个已知工具进行了整理，包括基于SPDX的29个开源工具和15个专利工具、基于CycloneDX的61个开源工具和12个专利工具、基于SWID的15个开源工具和8个专利工具。此外，SIG还在探索通过设置模板的机器可读版本来自动获取工具数据。工具信息模板初稿及示例如下表所示。

<工具名称>(例如：<Augur>)

工具类型	所属的工具分类[说明：目前仍主要依据NTIA的工具分类法] 例如：生成(分析)
功能	关于工具功能的描述例如：Augur用于开源软件健康使用和可持续性指标及数据收集，可扫描收集项目许可信息并创建SPDX文档。实例演示见http://augur.osshealth.io/
位置	能够获得工具的位置信息例如：网址：http://www.augurlabs.io/；来源：https://github.com/chaoss/augur/
安装说明	关于如何部署工具的说明例如：https://oss-augur.readthedocs.io/en/master/getting-started/installation. html
如何使用	关于如何在生产中使用工具的说明例如：https://oss-augur.readthedocs.io/en/master/getting-started/create-a-metric /overview.html
支持的格式版本	工具支持的规格文件版本，如SPDX 2.2、SPDX 2.3、CycloneDX 1.4等例如：SPDX 2.1
SBOM类型	根据本文第二2(2)节中列举的SBOM类型例如：分析时SBOM
支持的Mime文件类型	工具支持格式的数据类型，如XML、JSON、YAML、RDF、SPDX、XLS
支持来源	专有/商业/开源社区

(3) 改进的SBOM工具分类法

根据上述第三项任务的要求，在NTIA工具分类法的基础上，SIG正在推进和探讨SBOM工具分类元数据的改进和完善。下表是改进的分类法的初稿(2022年9月1日)，斜黑字体标注的是SIG新增内容，其他为NTIA原有分类内容。

分类	种类	描述
生成	构建	SBOM作为构建软件工件的一部分自动创建，包含有关构建的信息。这些信息包括含有的组件、标识及特定的版本标识符
	静态分析	静态分析将通过检查工件和任何关联源来生成SBOM
	动态分析	动态分析/监听执行以生成SBOM。需要一个执行环境，可能会遗漏被监听的执行不需要的依赖项。动静结合的分析被认为是动态分析
	编辑	协助手动输入或编辑SBOM数据的工具
使用	查看	能够理解人类可读形式的内容。用于支持决策制定和业务流程
	分析	可分析SBOM内容，并与其他数据集和策略比较，以支持风险管理决策。包括识别组件已知漏洞，漏洞是否可利用，潜在的许可问题
	监管/报告	对于给定的组织，能够报告哪些产品包含重要的漏洞
	差异对比	可比较多个SBOM并清晰地展现差异(如比较一个软件的两个版本)
	导入	能够发现、检索和导入SBOM到系统中，以便进一步处理和分析
变换	转变	从一种文件类型转变为另一种文件类型，同时保留相同的信息
	合并	可以将多个文档源合并在一起以进行分析和审计
	工具支持	支持通过API、对象模型、库、传输或其他引用源在其他工具中使用

可以看出，修改包括将“生成”大类中的分析进一步划分为静态和动态分析，“使用”大类中增加了针对安全风险、漏洞的分析类和监管类工具，这也说明了这些工具的需求、开发或使用正在不断增加，已引起SIG的注意。

2、与开源生态和项目合作研发

SPDX Python库是一个用于解析、验证和创建SPDX文档的Python库，可帮助用户了解依赖关系，并提高安全性和合规性。但由于缺乏志愿者的技术和资金支持，该库较长时间未更新，不能与较新的SPDX版本保持一致。SBOM无处不在计划确立后的第一项工作就是促成了OpenSSF对SPDX Python库研发的资助，该工作于2022年9月1日启动，在2023年3月27日发布了SPDX Python库的0.7.0版本，提供了对SPDX V2.3的支持。

之所以积极推进该工作，是因为SIG认为无论未来软件安全状态如何，SBOM及相关工具的生态系统都将继续在保持软件生态安全方面发挥重要作用。此外，今年6月底SIG展望未来工作时还提到，下一步将会考虑将目前正在做的事情与一些开源项目合作，例如，SIG了解开源项目成功生成SBOM的条件，可为对此感兴趣的开源项目创建统一的实现手册。

3、面向安全的SBOM用例识别

SIG正在推进的另一项工作是通过识别用例，支持SBOM无处不在计划的执行，因为《行动计划》方向9中提到，消除进一步应用SBOM的重大障碍在于，确保使用SBOM构建用例所需的条件在当前SBOM规范中被清晰的理解、记录和实现；有好用的开源工具来生成满足这些条件的SBOM。对此，SIG总结了用户需求视角的用例信息要求和关键SBOM用户/角色初始集合等内容(截止2023年8月10日)。

用户需求视角的用例信息应突出列出用例的动机、清晰表达用户视角、明确SBOM的用途(即明确软件中非第一方贡献、修改和控制的成分，包括了解依赖项的许可以确保合规、了解依赖项的漏洞以评估安全风险、快速了解软件是否依赖于Log4j之类的组件)；关键SBOM用户/角色的初始集合包括开发者、具有SBOM的产品的下游用户、产品架构师/管理者、开源项目办公室、安全工程、第三方供应商采购，每类用户又细分为若干具体用户种类。

SIG还简要介绍了软件生产者和用户的典型用例。软件生产者的典型用例包括通过构建、分析或编辑生成SBOM等5方面内容，软件用户的典型用例包括SBOM的查看、验证、分析和导入等8方面内容。

四、我国推进SBOM工作的进展及建议

为推进SBOM的落地，我国也已开展了多方面的工作。标准制定方面，国标《软件供应链安全要求(报批稿)》和《软件产品开源代码安全评价方法(征求意见稿)》中有关于SBOM基础字段的定义和对SBOM完备性、可追溯性的要求，全国信安标委7月发布的2023年度第二批网络安全国家标准需求中包括了《软件物料清单数据格式》的需求指南；科研项目方面，SBOM自动生成及应用的项目课题在稳步推进中；行业SBOM能力评估方面，由中国信通院组织开展的“可信软件物料清单SBOM能力评估”和“基于软件物料清单(SBOM)的软件供应链风险管理试点”，已发布相关评估结果。尽管如此，我国的SBOM应用和推广尚处于起步阶段，结合前面章节对已有工作的分析，本文建议：

反向开展SBOM格式和内容规范的制定

SBOM是一项实践性很强的工作，主要难点在于应用推广，而非技术。在制定SBOM格式规范时，建议借鉴CISA从实践中提炼和归纳SBOM共享和类型模型的经验，借助产业界的力量(类比于CISA和OpenSSF依赖的社区)，从已有成功案例中总结格式数据，并通过充分的试点试用进行验证和迭代。采用“理论指导实践”的反向思路制定规范。

构建面向国内使用者的SBOM工具体系

自动化工具是SBOM可用易用的重要保障，让SBOM使用者方便的了解、获取和使用这些工具可大大提升工作效率。建议：组织或资助研发一系列特定功能的工具，如与格式规范配套的SBOM生成、验证工具；及时跟踪OpenSSF SBOM全景图进展，对相关成果选择性利用，并补充国内已有工具的信息，不断完善工具体系图谱，为SBOM使用者服务。

推进基于SBOM的安全风险治理应用落地

建议SBOM格式规范中包含开源许可、漏洞等安全相关字段；软件供应方采用开源安全治理工具监测开源物料并消减其风险，监测所使用物料的安全漏洞等风险并及时为用户提供技术支持，生成SBOM并随产品提供；软件最终用户验证SBOM以确认软件成分和安全风险，在软件日常运行中，基于SBOM持续跟踪软件物料相关的威胁情报，及时采取措施。