软件物料清单SBOM及其标准格式
date
Sep 24, 2024
slug
2024-SBOM-and-its-standard-format
status
Published
tags
软件工程
type
Post
AI summary
软件物料清单（SBOM）是记录软件组件来源及依赖关系的重要工具，旨在提升软件透明度和供应链管理。SBOM的标准格式包括SPDX、CycloneDX和SWID，分别适用于不同的组织和需求。生成SBOM的理想方式是通过自动化工具，但对于缺乏包管理系统的C/C++项目，生成过程仍需手动整理。使用conan等包管理系统可以提高SBOM生成的效率。
summary
本文对SBOM的概念、由来、主要的作用以及目前主流的SBOM文件格式进行了总结，并提供了一些关于SBOM自动生成的信息。
SBOM的概念和由来
SBOM：Software Bill Of Materials，即软件物料清单。
今天稍微大一点规模的软件开发，已经不是所有的软件组件都依赖自己从头开发这样的形式，否则效率太低速度太慢了。因此这类软件的开发普遍使用到了来自于不同来源的开源软件、第三方软件库、框架库等，如何在软件系统的开发中管理好这些不同来源的软件组件，清楚的了解所有软件组件依赖的安全性漏洞、许可证、授权管理、版本信息等，对于软件的可持续开发与维护非常关键。SBOM由此应运而生。
- 欧盟在2024年3月12日正式批准《网络弹性法案》，要求所有出口到欧洲的数字产品必须提供SBOM等信息，使SBOM成为软件领域国际贸易的通行证。
SBOM主要的作用就是清楚的记录软件系统中各个组件的来源及其依赖关系等方面的信息，可以有效的提升软件组成的透明度和管理软件供应链。这里说的软件组件，主要是软件系统中所包含和依赖的开源软件以及第三方软件。使用SBOM的管理形式，可以对这些软件组件的安全性以及可追溯性提供非常清晰的了解和持续管理。
SBOM的概念最早由美国在2014年提出，2021年由美国国家电信和信息管理局（NITA）发布SBOM的规范，定义SBOM应该是是一份正式的并且可以用机器识别和理解的软件组件及其依赖关系的清单，其中应该详细记录这些软件组件的信息和层次关系等。
从命名上就可以看出来，SBOM明显是由硬件生产体系中的BOM物料清单的概念发展而来。不同的是，硬件生产领域的BOM描述的是硬件产品在生产过程中所需要的各个组件、结构关系以及数量等，而针对软件的SBOM则用于描述一个软件系统中所包含的软件组件清单及其相互的依赖关系。
同硬件领域的BOM文件相同，SBOM本质上也是一个数据文件，其中应该至少包含：供应商的名称、组件的名称、组件版本号、组件之间的依赖关系、SBOM的作者名称、唯一标识符、时间戳等信息。同时如NITA所定义的，SBOM文件的格式和内容必须具备机器可读性和人类可读性。
- 因为具备机器可读性，通过与安全性漏洞管理系统的联动扫描和分析，利用SBOM可以很容易的识别和增强软件系统网络安全事故的分析和响应能力。
SBOM的标准化数据格式：SPDX/CycloneDX/SWID
既然SBOM的信息需要能够支持机器和人类的可读性，方便的实现自动化生成和组织间的共享，定义标准化的SBOM数据文件格式就非常重要。因此，NITA在2021年发布了《软件物料清单（SBOM）最小元素》，在其中定义了三种SBOM文件的标准格式，也就是SPDX、CycloneDX、SWID。
SPDX
SPDX：Software Package Data Exchange。SPDX本身是Linux基金会的一个开源项目，于2021年8月份成为国际公认的SBOM标准。
SPDX是一种重量级的SBOM格式，其突出的特点在于可以支持详细的展示软件组件的许可证信息，适用于大型、复杂组织的软件供应商管理，因此得到了软件领域一些国际领军企业的广泛采用。
SPDX的官方网站是：www.spdx.org
CycloneDX
CycloneDX格式（又称为CDX格式）是由开放式Web应用程序安全项目OWSAP社区创建，是一种轻量级的SBOM标准格式，侧重于网络安全风险管理和供应链的组件分析，更适合用于漏洞管理、安全审计等应用场景，因此比较多在中小型团队和大量使用开源软件的组织中使用。
CycloneDX所支持的输出格式有XML和JSON。
SWID
SWID则直接是由美国国家标准于技术研究所NIST创建，在2015年成为国际标准。SWID采用了标准化的XML格式进行描述，定义了四种标签来标识和描述软件开发生命周期中的不同状态和信息。
所以简单总结起来，无论是SPDX、CycloneDX还是SWID格式的SBOM文件，本质上都是一个类似Json或者XML的文件，在其中定义了一个软件中包含的第三方或者其他开源软件组件的详细信息列表及其相互之间的依赖关系。
例如下图就是一个已经生成的一个SBOM文件的大致格式：
SBOM的生成
对于一个软件项目SBOM的生成，理想的情况下，应该是有一些生成SBOM的工具，这些工具调用后能够对整个软件项目的配置和源代码目录扫描后，自动产生其中所包含的所有软件组件、版本信息及其相互的依赖关系。毕竟SBOM标准是开放的，只要这个扫描的过程能够自动化，生成SBOM文件的整个流程也就可以自动化。如果一个大的软件系统的SBOM需要手动生成并且维护的话，工作量会非常大，而且容易遗漏和出错。
因此目前针对SBOM的生成，无论是商业还是开源的解决方案，都有不少很成熟的方案可供选择。例如参考文档2中所提供的opensca就能够通过一条命令的执行对软件项目进行扫描，生成各种不同格式的SBOM文件：
opensca-cli -path ${project_path} -out output.dsdx这些SBOM生成的解决方案甚至可以嵌入到CI/CD的流水线中，这样的话，以后每次代码提交或者编译流程都可以对代码进行重新扫描并生成更新版本的SBOM文件，确保SBOM始终与最新版本的代码是一致的。这样就可以极大的提升软件开发以及SBOM维护的效率。
但是，无论是开源的还是商业的解决方案，这些SBOM自动生成的工具，基本上都是针对Java、Python、JavaScript、Go等类型的语言，我做了不少搜索始终没有找到针对嵌入式所常用的C/C++语言的SBOM自动生成解决方案。
原因是：这些SBOM生成工具在对软件项目的目录结构以及代码扫描的过程中，需要依赖于项目的软件包管理系统，例如Java的Maven，Python的PiP，Javascript的npm等。因此SBOM生成的过程实际上是对这些包管理系统的配置进行扫描，得到其依赖软件包的SBOM信息并整理成符合规范和要求的SBOM文档结构。
而嵌入式领域所常用的C/C++缺乏一个事实上的包管理系统的标准，项目中所依赖的第三方软件库往往以开发人员规划软件项目架构的思路，散落在项目结构的不同位置，这样就很难通过自动化的扫描来整理出来这个软件项目所依赖的所有第三方软件库的准确信息。
因此，如果没有成熟的包管理系统的话（并且SBOM扫描和生成的工具要能够支持这个包管理系统），对于C/C++软件项目而言，SBOM的生成就只能成为一个依赖开发人员手工整理、填写表格的方式来进行生成和维护，效率低下，短期内仍然缺乏有效的解决方案。
就目前而言，C/C++的一个相对比较流行的包管理系统是conan，如果在项目中使用conan来管理C/C++的第三方软件包，那么可以依赖其插件（‣）来生成SBOM，另外Trivy（Overview - Trivy (aquasecurity.github.io)）能够支持conan包管理系统的SBOM生成：
另外一个SBOM生成的开源软件Syft也能够支持C/C++和conan的组合：
不过前提都是，要在软件项目的规划之初就要使用conan来管理项目的第三方软件包。
参考文档
- 《建设软件物料清单体系的国际经验和自主路径》潘妍 程薇宸 李郁佳