134 lines
12 KiB
Markdown
134 lines
12 KiB
Markdown
---
|
||
page-title: "《软件供应商手册：SBOM的生成和提供》解读 - FreeBuf网络安全行业门户"
|
||
url: https://m.freebuf.com/articles/neopoints/331333.html
|
||
date: "2023-03-07 09:30:14"
|
||
---
|
||
## 专栏·供应链安全
|
||
|
||
数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。
|
||
|
||
随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。
|
||
|
||
为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。
|
||
|
||
注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。
|
||
|
||
## **摘要**
|
||
|
||
本手册由美国国家电信和信息管理局(NTIA)格式化与工具工作组于2021年11月27日发布，旨在为软件供应商提供软件物料清单(SBOM)生成和交付方面的指导。手册以SBOM生成的四步骤流程为主线，重点说明了在软件构建(Build)前、构建中和构建后等各阶段构造SBOM时的特点或应注意事项，以及目前常用的SBOM验证方法。整体流程的完整性和对各阶段应重点关注问题的讨论是本手册的主要亮点。手册可为我国软件生产企业或个人在SBOM生成和构造等方面提供一定的指导和借鉴。
|
||
|
||
## **背景解读**
|
||
|
||
近年来，全球软件供应链安全攻击事件持续高发，且危害越来越大，特别是2020年底爆发的太阳风(SolarWinds)攻击事件，使得美国更加重视自身的供应链安全防护。2021年5月12日，美总统拜登签署了“关于改善国家网络安全(EO 14028)”的行政命令，其中的第4节针对“加强软件供应链安全”提出了一系列具体要求，旨在迅速改善美国软件供应链的安全性和完整性，而其第(f)条要求，NTIA于同年7月11日前发布SBOM的最低要求。
|
||
|
||
对此，NTIA于2021年7月12日发布了《SBOM最小要素》，规定了最小要素应包括数据字段、自动化支持、实践和过程等三个方面，其中的实践和过程指为了将SBOM集成到安全开发生命周期操作中而需定义其请求的操作、生成和使用等内容，包含频率、深度、已知的未知情况(known unknowns)、分发和交付、访问控制和容错等。可以看出，SBOM的生成是将其集成到安全开发生命周期的重要一环。
|
||
|
||
11月27日发布的《软件供应商手册：SBOM生成和提供》是对最小要素中SBOM生成的进一步细致讨论和在实施层面的补充，给出了SBOM生成的一般性流程及每一步中应关注的重点。手册中关于SBOM三种数据格式(SPDX、CycloneDX、SWID)和特定名词(如“已知的未知情况”)的规定均与最小要素一脉相承。另外，根据手册中的说明，这里的软件供应商指的是商用软件、开源软件、外包软件等广义的供应商。
|
||
|
||
## **正文解读**
|
||
|
||
通过对手册内容进行分析，作者归纳出其参考价值和指导作用主要体现在4个方面。
|
||
|
||
### **01** **以有效性为最终目标，总结了SBOM生成的工作流程**
|
||
|
||
尽管各类组织用来生成SBOM的工具和过程多种多样，但手册归纳出了这一过程的一般性工作流程模型，即通过“识别组件-获取数据-构造SBOM-验证SBOM”4个步骤，最终得到格式有效、属性合规的SBOM文件。
|
||
|
||
在上述过程中，每个步骤均有相应的技术、自动化工具、标准等进行辅助和支持，手册介绍了它们中的代表性内容，例如软件组成分析(SCA)工具、代码分析工具、SBOM格式验证工具、软件包数据交换(SPDX)标准、OWASP CycloneDX和软件组件验证(SCVS)标准等。
|
||
|
||
总体而言，本手册对于SBOM的构造和生成具有一定的指导作用，可基于其描述的流程、标准和工具等开展相关的研究工作，以增强软件产品透明度，便于进行安全分析和保障。
|
||
|
||
### **02** **以构建为阶段划分点，讨论了SBOM构造的主要方法**
|
||
|
||
手册描述了在软件构建(Build)之前、构建时和构建以后的不同时间阶段，构造SBOM时可使用的方法工具、应考虑的信息类型、相应的特点和注意事项等内容，如表1所示。
|
||
|
||
表1 不同阶段SBOM生成的对比
|
||
|
||
**生成阶段**
|
||
|
||
**生成方法**
|
||
|
||
**特点/注意事项**
|
||
|
||
构建前
|
||
|
||
作为版本控制系统一部分，或由挖掘产品构建管道输入的工具创建源码级SBOM
|
||
|
||
有助于关键组件的识别及在创建产品之前查找漏洞；便于构建到源文件的追溯；可能会呈现并不包含在最终可执行文件中的脆弱源码
|
||
|
||
构建时
|
||
|
||
作为构建工件自动化生成SBOM
|
||
|
||
包含更权威的组件特征、无人工输入错误、自动化SBOM签名；必须确定构建过程中生成的SBOM的格式(列举了SPDX等3种)
|
||
|
||
在构建管道或软件工厂中生成SBOM
|
||
|
||
构建管道方法容易使用，但可能需要额外的资源集成管道；软件工厂方法可解决多个开发生态系统没有一致SBOM支持的问题
|
||
|
||
从容器化过程中导出容器镜像SBOM
|
||
|
||
应汇总并识别来自所有层的所有软件的信息；应包括容器间依赖关系、构建时间、签名等
|
||
|
||
构建以后
|
||
|
||
(SBOM应包括生成时间、SBOM版本、签名等)
|
||
|
||
旧系统中使用功能；来自不同的供应商、过程和工具等的SBOM信息的生成
|
||
|
||
应补充接近工程过程的组件数据、已知的未知情况等；代码分析工具可扫描上游供应商组件的SBOM，但识别商业组件方面能力不足
|
||
|
||
非自动化系统和过程的SBOM生成
|
||
|
||
应理解SBOM中列出的组件的来源和软件标识，以及如何获取这些信息
|
||
|
||
手册对每个阶段中SBOM生成的特点或应注意方面进行了一些点上的描述，包括举例等方式，多以说明性为主，缺少统一的描述逻辑。尽管如此，通过对表中内容的分析依然可以发现：
|
||
|
||
- **收集信息的全面性是SBOM构造的基础。**识别和收集软件组件信息的全面性是首先要考虑的。手册明确了，在构建过程中生成SBOM的，需提前确定格式，即使用标准来规范待收集的内容，并且在构建后还要补充必要的信息(例如无法通过自动化手段得到的)。
|
||
|
||
|
||
- **三个阶段的SBOM生成工作各有侧重。**构建时的自动化信息收集是SBOM生成的主要方式；源码级SBOM可以作为辅助；构建之后阶段对SBOM的构造以信息(特别是来源信息)的补充和集成(多供应商SBOM)为主。
|
||
|
||
|
||
- **自动化工具提高了SBOM构造的效率和可操作性。**手册提到的工具包括：构建前使用的版本控制系统，挖掘构建管道输入的工具；构建时使用的Git，与构建系统、包管理器和持续集成(CI)服务器集成的工具，构建管道和软件工厂；构建后使用的代码分析工具等
|
||
|
||
|
||
### **03** **以安全性为出发点，分析了SBOM应包含的内外依赖**
|
||
|
||
为了使运行时依赖关系等引入漏洞的情况不成为消费者和供应商的盲点，手册强调SBOM应避免缺失对应用程序所安装的运行时依赖项、操作系统、动态链接库(DLL)、升级程序、共享库或其他包含项的描述，且描述时应避免存在歧义；另外，为了提高供应商解决相关安全问题的效率，手册明确当软件功能执行依赖于对外部服务调用时，可使用SBOM列出软件交付所需的外部服务。
|
||
|
||
内外部依赖关系是应用程序引入安全问题的重要来源之一，手册将应用的内部依赖项和外部依赖的服务作为SBOM的重要组成部分，能够帮助消费者和供应商更全面的了解应用程序，进而掌握可能引入安全问题的途径，及时采取相应缓解措施，这有利于提高软件安全防护的效率和准确性。
|
||
|
||
### **04** **以可操作性为目的，列举了SBOM验证的工具和标准**
|
||
|
||
针对SPDX、CycloneDX和SWID三种SBOM的格式正确性和完整性的检验，手册列出了相应自动化工具的链接；针对SBOM信息中声明的相关组件的识别、验证和评估等，手册提到了标准OWASP SCVS、OpenChain和软件组成分析(SCA)工具。
|
||
|
||
目前SCA工具在识别软件组成、分析软件成分、统计软件资产等方面功能明显，可有效辅助SBOM中声明组件和依赖信息的验证。但SBOM文件自身验证的工具还比较初级，并且都与特定的SBOM格式相绑定。例如手册中提到的SBOM格式验证工具，仅能够对格式的正确性和完整性进行检查，而不能检查填充SBOM字段的数据质量或准确性。相信随着SBOM相关技术的不断发展，未来此类工具的功能也会有较大的提升。
|
||
|
||
## **影响及趋势预判**
|
||
|
||
美行政令EO 14028虽然对《SBOM最小要素》的制定进行了要求，但并未对它的使用进行强制规定。最小要素和本手册可更多的被看作是对SBOM相关方，特别是美国软件供应商的规范建议。
|
||
|
||
但另一方面，随着全球网络信息领域对软件供应链安全、SBOM重要性认知的不断提升，以及SPDX成为国际标准、《SBOM最小要素》的出台等，软件供应企业(如商用软件、外包软件)和个人(如开源软件)会越来越多主动或被动的构造并提供SBOM，本手册可以在这一方面提供流程的规范和指导，具有积极的促进作用。无论美国厂商还是全球厂商都可以从中得到启示，但手册介绍的粒度较粗，供应商应根据自身状况进一步细化后使用。
|
||
|
||
SBOM生成的自动化是构造SBOM的最终目标和提高效率的有效手段，但从手册中可以看出，目前一些类型信息的收集还难以做到，例如“已知的未知情况”、遗留系统的相关信息等，并且手册也缺少对这些的详细方法介绍；此外，依赖项漏洞是软件供应链安全风险的主要成因之一，手册中列举了几类需在SBOM中重点关注的内外部依赖关系，但并未展开系统阐述。未来应对这些问题进行进一步的研究，进而为软件供应商提供更加明确的指导。
|
||
|
||
## **总结及对策建议**
|
||
|
||
手册归纳了SBOM生成的一般工作流程，包括“识别组件-获取数据-构造SBOM-验证SBOM”4个步骤，并以构建为阶段划分点，讨论了SBOM构造的主要方法，还重点分析了SBOM应包含的内外部依赖关系、列举了针对SBOM的验证工具和标准。基于上述情况，本文对我国的SBOM构造工作建议如下：
|
||
|
||
- 建议国家或行业监管部门指导制定软件SBOM格式、生成和使用等方面的标准和指南，以规范该项工作；并建立有效的机制推动标准的落地、使用，引导相关自动化辅助工具的研发。
|
||
|
||
|
||
- 建议软件供应商提高安全责任意识，根据已有的SBOM要素、生成、使用等参考资料制定满足自身和使用者需求的SBOM规范，包括但不限于组件供应者、组件名称、组件版本、依赖关系等信息内容，并在软件研发和供应过程中严格执行。
|
||
|
||
|
||
- 建议软件使用者将SBOM列为供应商必须提供的内容，并对其提交的软件产品和SBOM进行验证，以确保两者的对应关系，从而提升软件产品的透明度，提高软件安全维护的效率和使用的安全性。
|
||
|
||
|
||
手册原文可参考：https://www.ntia.gov/files/ntia/publications/software\_suppliers\_sbom\_production\_and\_provision\_-\_final.pdf
|
||
|
||
SBOM系列政策文件研究由中国信通院、中国联通联合牵头，筹建单位奇安信、会员单位悬镜安全、绿盟、高伟达、比瓴、盈高科技、亚信、北银金科、孝道科技、南阳理工大学、华为支持开展，包含13篇政策文件的翻译、解读，涵盖了SBOM整体内容概述，SBOM的生成、获取、交换、共享、管理、使用等全生命周期过程，回答了关于SBOM的常见问题，以期助力社区的安全研究研讨，加速推进提升国内供应链的安全管理水平。
|
||
|
||
|
||
|