软件供应链安全继续强化：SBOM清单基座规范SBOMit启动制订

作者：Sender Su 来源：原创内容发布日期：2024-01-21 最后修改日期：2024-01-27

开源安全基金会（OpenSSF，Open Source Security Foundation）在2023年12月启动了软件供应链安全规范 SBOMit，为软件物料清单 SBOM 添加了全过程校验的实现。

笔者：国际认证信息系统审计师、软考系统分析师

继上一篇讨论了大供应链安全概念后，回过头来又看看软件供应链安全。话说大供应链安全概念还真是曲高和寡，看来大多数甲方网络安全责任人都难以参与控制大供应链安全，也不想揽上身吧。感觉这个话题以后没必要再写了。

一

前言

软件供应链攻击有个经典故事：

在 1984 年，Unix 操作系统的创始人 Ken Thompson 曾在图灵奖获奖演讲中讨论了“邪恶的编译器”。如果编译器本身带有这么一段代码，这段代码的逻辑是在每次编译都会检查所编译的是否编译器，如果是就对编译得到的编译器运行文件加塞自己这段恶意复制代码，由此反复，这段代码就永远存活，除非有人对运行文件做逆向，否则无人发现......但如果反编译工具甚至除错器都带有这些恶意代码呢？

evil compiler

二

软件供应链

言归正传......实际软件供应链本身也有两层概念。最基本的层次是指软件企业内部的从代码编写、测试、打包到分发的整个过程是由许多个步骤连贯而成，这些步骤使得软件从外源性的软件组件加上内源性的软件源代码转换为最终运行代码，并经过各种验证后形成最后的软件产品。

在此之外的一层，是指软件企业在开发软件产品时所使用的软件组件、开发过程使用到的工具软件、软件发布过程牵涉到的各种要素等所有的这些共同构成和产生了最后的软件产品的过程。

无论是哪一层概念，软件供应链安全已经成为了软件产品整体安全性的关键。攻击者只要能控制整个供应链条的任意一个步骤，就能实现修改最终产品引入后门或引入具有漏洞的代码以便未来利用。

而且，软件供应链攻击一旦得手，影响的会是软件产品的全部最终用户，其收益可谓是一本万利。

软件供应链安全首先要全链条全步骤确保安全，也就是刚才说的两层概念都要安全。传统的安全做法是仅控制软件发布的步骤，但这种做法无法应对已经被嵌入了恶意代码的软件产品，太阳风事件就是典型。

三

SBOM和SBOMit

SBOMit 是新手段的其中一种，要了解 SBOMit，就要先对 SBOM 形成概念。

SBOM Life Cycle

SBOM 软件物料清单笔者之前曾经介绍过。SBOM 的产生是参考了制造业原材料清单的概念，对构成最终软件成品所使用到的软件组件以清单的方式明示，并实现到具体版本的跟踪。

对 SBOM 清单最常见的安全校验方法就是对清单进行签名。这算是可以实现额外的校验，但问题在于这个做法缺失了关键的一件事：没有可靠的方法去确保在创建软件的过程中，所有的过程都已经正确地参与执行了生成最终版本 SBOM。

这因为 SBOM 清单本质是对软件构建过程的输入情况的描述，并不具备过程信息。

为解决该问题，OpenSSF 发起创建 SBOMit 规范，通过通过为软件组件附带上基于 in-toto 证明信息的校验信息，实现对软件供应链完整性（安全性）的证明和可验证。

四

什么是 in-toto

in-toto logo

图片源自 in-toto 项目网站

in-toto 这个古怪的名字......它是一个确保软件供应链完整性的框架规范，在2016年10月份创建，经过多年的发展，在2023年6月释出了 1.0 终版，其网址是：

https://in-toto.io/

按官方介绍，in-toto 是拉丁语“as a whole”即“整体而言”的意思，用这个词的原因是项目组的目的是试图创建一套能保护整个软件供应链的系统。至于in-toto本身，它是一套开放性的元数据标准，可以嵌入到企业自己的软件供应链中。

国内对 in-toto 的介绍和利用较少，但 in-toto 获得了CNCF（Cloud Native Computing Foundation，云原生计算基金会）认可作为托管项目，在 2022 年进入 Incubator。读者如果对此不了解，建议多加关注。

in-toto 的实现目的是确保软件产品从初始阶段到最终用户安装过程的全过程完整性，具体地通过向软件的用户明示软件的构建过程执行了什么步骤、由谁执行以及执行的顺序等信息来实现。

也就说，当软件产品在创建过程中按 in-toto 规范产生了过程信息后，产品的用户就可以汇同软件的开发商共同验证其供应链中的某一个步骤是否会被执行，以及该步骤是否由正确的参与者执行。

目前已经有不少企业和开源项目采用了 in-toto 规范，包括遭受了供应链攻击的太阳风公司就采取了应用 in-toto 到其内部流程以避免继续出现之前被攻击的情况。

五

具体看看 SBOMit

我们回到 SBOMit 上来。

SBOMit Title

图片源自 OpenSSF 博客

SBOMit 规范是开源的，其项目地址为：

https://github.com/SBOMit/specification

SBOMit 规范实质是 SBOM 的下层基础，独立在 SBOM 规范之外。

符合 SBOMit 规范的文档本身就是 SBOM 清单，不同的是附带了在软件供应链过程中产生的验证信息，也就是前面说的基于 in-toto 框架产生的 in-toto 布局信息、证明信息。

当为软件项目创建了 SBOMit 文档后，使用 SBOMit 文档可以用于产生需要的任意一种 SBOM 清单格式，并可从 SBOM 清单回溯到用于创建 SBOM 清单的原始 SBOMit 文档。

对于软件供应链的下游延伸，任何一方在需要获得软件是否具备可靠性时，均可利用这些证明信息对其验证。

支撑 SBOMit 文档能被验证的基础是文档本身的数字签名和构成文档的具体信息。这些信息可以在软件供应链的每个步骤生成，包括关于版本控制系统、构建过程、单元测试、所使用的依赖关系、模糊化、许可证符合性检查、打包等。

软件企业在自己的软件供应链中嵌入使用 in-toto 框架标准生成过程步骤的证明，所以文档内包括了经过数字签名的在软件开发过程中每个步骤的元数据，以及用于概括表达所需过程的策略。

例如，在 SBOM 清单内，可以发现用于编译软件产品的构建系统具有如下的 in-toto 元数据：

从版本控制系统中提取进行编译的源代码文件的名称和安全哈希摘要；
在编译期间产生的中间文件的名称和安全哈希摘要；
关于编译器本身的一系列信息比如版本等；
由编译器控制的私钥进行的签名。

这些加密证明信息可以与 SBOMit 文档中的的 in-toto 布局信息协调使用。文档内的 in-toto 布局信息由项目所有者签名，并描述了项目的有效认证的元数据应该是怎样的。

in-toto 布局信息之所以称为布局，是因为布局信息指定了执行认证的各方的密钥，以及软件供应链的步骤之间如何互连，即形成了供应链各节点在链上的位置布局，所以称为布局信息。

例如：构建系统需要基于版本控制系统比如 GIT 提供的已经签名的 git 版本标签进行操作；构建系统编译的文件必须是已经运行了单元测试且通过了测试的文件。

最重要的是，in-toto 布局信息提供了机器可读的策略，该策略支撑程序化地验证 in-toto 布局信息，以确保以上的所有步骤都已经按照正确的顺序在正确的项目上执行，没有添加、跳过或删除任何。

在 SBOMit 文档中的最后一项是补充的 SBOM 信息。这些信息以及 in-toto 证明信息、布局信息联合起来可以生成导出各种格式的实际 SBOM 清单。补充的 SBOM 信息可能包括公司名称或其他 in-toto 不包含但希望包含在结果 SBOM 中的信息。通过这种方式，从 SBOMit 文档生成的 SBOM 可以包含不属于 in-toto 过程的补充信息。

六

如何利用 SBOMit

虽然 SBOMit 这个项目才刚刚宣布和发布了规范草案、路线图等项目初期材料，尚未产生任何代码级别的实例，但它基于的 in-toto 框架已经相当成熟，且已经有了包括 java、rust、go 等语言的具体实现和 jenkins 的插件。

按规范草案介绍，在设计上，SBOMit 将会包括四个主要组件：

1.in-toto 布局管理工具：规定供应链策略，包括关于每份基于 SBOMit 产生的 SBOM清单，以及该清单在生成过程中所使用到的密钥的详细信息。通过可信的布局密钥对其进行签名。

2.in-toto 元数据收集工具：管理一系列 in-toto 元数据，如子布局、链接元数据和证明，这些数据由适当的各方验证和签名。

3.SBOM 突变工具：创建元数据，以对派生的 SBOM 信息进行强化，以增强其完整性。元数据采用 ISO 或 JSON 补丁格式。

4.附录处理工具：处理附录或修改痕迹，表达为与上一版本文档的差异，并保留历史信息。也使用 JSON 补丁格式。

这些工具以及 SBOMit 的利用流程如下图：

SBOMit workflow

源图来自 SBOMit 项目，已修改

有意全面实施 SBOM 的软件企业需要先在自己的软件供应链环境中做好 in-toto 的落地，然后持续关注 SBOMit 的进展。

七

总结

应用 SBOMit 规范以及执行相应的 in-toto 过程，在软件构建的过程中生成 SBOMit 文档及 in-toto 证明信息而最终产生 SBOM 清单，可以降低意外错误导致的风险和抵御恶意行为。

典型如软件构建过程中为隐蔽恶意行为而跳过了某些步骤的情况，在未应用 SBOMit 和 in-toto 过程时，这种情况导致发现恶意行为的过程非常具备挑战性。

因此，SBOMit 可以增强软件行业企业在被攻陷时的安全恢复能力，并能检测和阻止其他的恶意行为，这远比对代码进行静态扫描产生 SBOM 清单的方法更科学，也比单纯地对 SBOM 清单签名要来得安全。

要说缺点，那就是要应用 SBOMit 以及 in-toto，需要软件企业有良好的软件供应链概念和安全意识，并且有足够的能力对自己的软件供应链进行重构，以将其纳入，否则就只能望洋兴叹了。