软件物料清单（SBOM）之我见|安全芝士局第一期内容回顾

默安科技全新出品的网络安全技术主题节目——安全芝士局，第一期在双十一当天正式与大家见面，来自安全研究院的周贤胜为大家分享了他对于软件物料清单（SBOM）技术的看法和观点。

本期芝士局的分享从SBOM 介绍、SPDX和CycloneDX的差异、SBOM生命周期和SBOM发展方向四个方面进行展开。

SBOM（软件物料清单）来源于BOM（物料清单）的概念。软件工程中的 SBOM 和传统的 BOM有一些区别，传统的BOM只需要记录生产设备时需要的配件，不需要明确配件的组成，而SBOM是一个嵌套的BOM，需要记录软件中每一个层级的关系。

软件开发过程中使用第三方组件，在快速实现业务需求的同时，也带来了许多安全风险。而SBOM能记录组件本身信息、依赖信息、许可证、漏洞信息等。用户通过SBOM能快速了解软件是否包含该组件，快速判断软件是否受到漏洞影响。

SBOM可以帮助用户识别和避免已知漏洞，管理许可证信息以规避合规风险，允许对软件包中固有的风险进行量化管理；同时SBOM其实也是将软件成分分析这一工具的结果进行了标准化，使分析结果可分享、可流转、可管理，辅助建立更加透明的软件供应链体系。

在实际应用中，SPDX和CycloneDX是SBOM的两种主流格式，周贤胜老师分别从格式支持、最小细粒度、安全维度、许可证维度、组件依赖维度这五个维度对这两种SBOM格式进行了对比。

·  格式支持方面，SPDX能够支持多种格式；CycloneDX目前目前只能支持两种。

·  最小细粒度方面，SPDX可以记录代码片段级别的信息；CycloneDX主要记录组件的基本信息。

·  安全维度方面，SPDX的做法是通过记录漏洞外部的URL来记录风险，实际上只是记录了一个URL；而CycloneDX则有一个独立的记录漏洞信息的字段，可以在SBOM中完整记录漏洞信息，没有URL记录失效的风险。

·  许可证维度方面，SPDX定义了许可证的简短标识，同时也支持许可证表达式、文件层级许可证、片段层级许可证等；CycloneDX则是使用了SPDX ID作为许可证ID标识。

·  组件依赖维度方面，SPDX是通过记录两个SPDX元素直接的关系来记录组件依赖关系；而CycloneDX通过dependencies和Compositions描述组件依赖信息的同时，也支持描述组件的断言关系，这个断言关系是SPDX不能提供的。

SBOM是编码阶段的产物，代码编写完成后可以在每次的推送中由工具重新自动化生成SBOM。

·  在编码或测试阶段，代码数据如果出现依赖更新的情况，SBOM也需要同步更新，并且这个行为能够同时被版本管理系统记录。

·  软件发布时，供应商应该同时提供SBOM的下载地址，帮助下游供应商了解软件中包含的组件。

·  SBOM发表后应该进入到资产管理系统，进行对应的软件资产管理，当出现新漏洞时可以通过历史SBOM快速确认影响范围。

·  完整性

SBOM是在开发阶段生成的，理想状态下组件的作者应该在发表组件时同时发布SBOM，用户在使用组件时只需要把该组件的SBOM集成到自身的SBOM中就能保证其完整性。在软件开发过程中必须选择一个值得信赖的软件成分分析工具，然而目前大多数的开源组件并没有提供SBOM，默安科技的雳鉴SCA产品就可以在开发阶段来帮助生成尽可能完整的SBOM。完整度更高的SBOM更能够便于用户掌握组件及相关漏洞对软件的影响情况，当出现安全风险时，SBOM缺失或完整性较低则会大大增加软件风险排查的成本。

·  组件定位

SPDX和CycloneDX两种格式中定位组件的标识符具有不同的使用方法，用户无法准确管理软件中存在的组件。

目前也有一些开源项目正在积极推进组件定位的工作，例如purl项目统一了多种语言的组件标识，但目前并不是权威性的标识。

·  交换和分享

从攻击者角度看，他们能通过SBOM更轻松地识别软件组件。相反，对于防守方来说，SBOM能够以提供额外的透明度以及标准的机器可读的决策⽀持来为防御者提供公平的竞争。

SBOM定位问题会影响SBOM间的交换和分享。组件作者在SBOM发布时应该同时提供一定的安全策略，保证用户在接收到SBOM时能校验SBOM的完整性。

安全芝士局是由默安科技全新出品的一档网络安全技术主题节目，节目将定期邀请行业大佬对近期关注的技术问题或网络安全热点进行分享，每期节目资料都能够在安全芝士局交流群中获取，欢迎各位小伙伴们加入交流群畅所欲言，与从业人员共同交流进步~

扫码进群