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

软件物料清单(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的发展和改进应来自社区，通过促进社区的参与、开发和持续进步来推动SBOM工作。一年多来，CISA通过搭平台、建模型、扩VEX(漏洞可利用性信息交换)等工作完善和推进SBOM指导文件制定。

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

(1) SBOM共享生命周期模型

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

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

(2) SBOM类型模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

随后，OpenSSF在安全工具工作组下设立了“SBOM无处不在兴趣小组(SIG)”，专注于通过改进工具和培训促进SBOM的可用和易用。成立以来，SIG的主要工作聚焦在探索创建SBOM工具生态全景图、与开源生态和项目合作研发并向其推广成功经验、识别面向安全的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还在探索通过设置模板的机器可读版本来自动获取工具数据。工具信息模板初稿及示例如下表所示。

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

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

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

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的条件，可为对此感兴趣的开源项目创建统一的实现手册。

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

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

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

为推进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持续跟踪软件物料相关的威胁情报，及时采取措施。

    觉得不错，就点个 “在看” 或 "赞” 吧~