目录隐藏

前言

SBOM（软件物料清单）是近年来在软件供应链领域频繁提到的概念，Linux基金会在2021年Q3调研了全球412 家机构发现已经有82%的人熟悉SBOM、78%的组织预计在今年使用SBOM。本文将介绍SBOM基本概念、实现方式、应用场景，帮助读者通过SBOM更高效地实现安全治理目标。

什么是SBOM

根据NTIA(美国国家电信和信息化管理局)的定义，SBOM(Software Bill of Materials，软件物料清单)是一份关于软件组件和依赖，包含它们的信息和层级关系的形式化、机器可读清单。

NTIA认为SBOM应该满足以下要求：

这份清单应该是全面，或者是明确识别范围的
应包含开源和闭源软件
能被广泛使用或者限制访问

还定义了SBOM中应该包含的最小化的软件组件信息（基线软件组件信息），包括：供应商名称、组件名称、唯一标识符、版本字符串、组件哈希、组件之间的关系、SBOM作者姓名。

在展现方式上，SBOM的信息可以通过图、表格等方式进行展现。

（左图为SBOM最小化信息示例，右图为依赖关系图示例）

（树状表格展示的SBOM信息示例）

SPDX (ISO/IEC 5962:2021) 是目前SBOM格式的事实标准，常见的格式还有SWID和CycloneDX，都能满足最小化的使用需求。

SBOM的用途

根据Linux基金会的调研报告，人们普遍认为SBOM有三大收益：

51%的人表示，开发人员更容易理解应用程序中组件之间的依赖关系
49%的用户表示更容易监控组件的漏洞
44%的人指出，管理许可证合规变得更容易

依赖治理

当今软件开发的过程，如同开发人员使用一个个组件作为积木搭出高楼，随着软件变得越来越复杂，开发人员可能并不清楚用到了哪些组件、这些组件之间又存在什么样的依赖关系，一个个的积木如同黑箱般存在，维护起来只能小心翼翼，随时可能陷入下图中的依赖地狱。

对于企业的工程团队而言，对于一些管理需求，例如规范某类组件的使用、避免重复开发以提升研发效率，首先需要了解企业内各种项目中使用到的组件，梳理对应的依存关系，才能做出有效的管理动作，这也迎合了当前比较火热的可见性需求。

一个组件版本碎片化的go语言项目可能会像下图这样，依赖了大量不同版本的同一组件。基于SBOM可以将碎片化的组件版本固定至一个或多个长期维护的稳定版本，避免版本无人维护导致产生bug无法解决。

漏洞管理

企业安全团队在面对新的漏洞、安全事件出现时，需要评估企业内有哪些资产受到影响，可以通过将漏洞的影响软件、版本范围等信息与已有SBOM进行关联，得到受影响资产列表，从而指导进一步的风险处置动作。

例如当出现新的类似log4j的漏洞时，可以通过SBOM以图的形式查找哪些内部项目中用到了log4j，通知这些项目的维护者进行漏洞修复。

除了应急响应，在日常的风险管理中，可以基于SBOM计算每个项目存在依赖的漏洞风险，作为安全评价维度进行管理。

开源许可证合规

2021年罗盒公司的案件是中国法院首次认可了GPL许可证的效力，违反开源许可证也已经被越来越多的国家法律认定为侵权行为。为了降低软件侵权风险，企业需要识别软件中涉及的许可证，有效管理项目中涉及的许可证风险。

而由于许多开源许可证具有传递性，如果不能全面识别所涉及到的组件及对应的开源许可证信息，则可能忽略所开发软件需要遵循相应的开源许可证约束，比如需要提供源代码、需要对开源许可证进行标识。

如图中项目A引用了组件A，组件A使用了AGPL许可证，则项目A应该按照AGPL许可证的要求，不论修改或使用都应该开源。这样的场景对企业使用会有较多限制，应基于SBOM及时进行治理。

如何生成SBOM

可以看到包括墨菲安全的客户端在内有不少的开源工具都可以生成SBOM，而有效的SBOM依赖软件成分分析能力和大量知识数据的储备。

SCA（软件成分分析）

SBOM的生成依赖SCA技术，识别组件和版本，并输出对应的层级依赖关系。其复杂性在于

1）要适配不同的编程语言，而像java和c/c++这样不同语言的包管理机制会有较大差异；

2）要从源码、制品、二进制等不同形态的软件产物中解析提取特征，这些特征的提取策略依赖于对各类产物的理解。

知识库数据

除了SBOM中的基线字段信息外，漏洞、开源许可证也可以作为SBOM的附加信息，而这样的数据则强依赖于云端知识库的积累。

知识库需要实时跟踪当前的各种漏洞情报，并由人工运营加工；需要采集大量的代码、制品信息，分析依赖、计算哈希、提取特征等等，加工形成能和SCA工具结果匹配的特征数据。

如何发挥SBOM的作用

对于企业而言，要想充分发挥SBOM的作用，至少应该关注以下几点。

SBOM及时更新

老旧的SBOM数据可能产生反作用，做无用功的同时让研发团队产生抱怨，因此SBOM应该是跟随代码、制品动态变化的「实时」数据。

可以通过将SBOM更新的逻辑嵌入到每一次代码的变更，例如通过IDE插件识别对应的代码变更、与代码仓库集成在代码提交或合并时重新生成；对于没有代码或者项目中存在二进制依赖的情况，CI/CD环节则更为关键，通过与jenkins等软件的集成可以实现代码发布前的审查。

通过知识库关联风险数据

SBOM只是一个开始，要想用于风险的治理，只有基线数据字段的SBOM难以发挥它的价值，背后需要有强大的知识库作为支撑。

SBOM要和知识库进行联动，当SBOM发生变化或者知识库中的数据发生变化时，都应该触发风险识别逻辑。例如，当SBOM中引入了一个新的组件，需要通过知识库评估这个组件是否存在开源许可证约束、是否适合商业使用；当出现一个新漏洞，知识库收录后应该联动SBOM判断有哪些项目受到影响。

构建管理平台

对于企业的内部治理而言，单点的工具是不够的，还需要有管理平台输出全局的风险视图，提供管理和控制能力。

例如，管理平台需要记录每一次的SBOM变化情况，从而能够展现不同时间点的风险指标情况；要能够基于项目、资产等不同维度对结果进行聚合，便于对总体风险进行梳理。

基本的管理平台可以如下图所示，以SBOM和知识库作为核心数据，控制模块通过和制品库、代码库等的联动，进行数据收集和策略下发，出现问题时帮助企业及时止损。决策模块对黑白名单进行维护、对阻断等策略进行管理，管理模块提供SBOM查询和相关管理指标看板的能力。

要求供应商提供SBOM

企业难以避免会使用到各类供应商提供的软件产品，这些产品通常以二进制的形式交付，相比源码识别的效果覆盖率会更低，存在的风险更难识别。此时SBOM应该作为供应商准入的要求，在采购环节要求提供SBOM，并对SBOM进行审查和统一管理。

总结

对于企业而言，SBOM是软件供应链治理中很重要的基础数据，能够帮助企业实现依赖治理、漏洞管理和开源许可证合规。SBOM背后靠的是SCA和知识库数据的支撑，想要充分发挥SBOM的作用，应该将生成工具和尽可能多的研发流程打通，做到实时更新，和全面的知识库数据进行动态关联，通过管理平台支撑全局的风险呈现与管理，同时还应要求供应商提供SBOM信息。