技术分享 | 悬镜亮相于2025开放原子开源生态大会软件物料清单（SBOM）分论坛 - 新鲜讯息

由开放原子开源基金会主办，国家工业信息安全发展研究中心、开源风险评估与治理技术实验室联合承办的“2025开放原子开源生态大会软件物料清单（SBOM）分论坛” 日前在北京国家会议中心二期正式召开。工业和信息化部信息技术发展司副司长李丽、中心总工程师张格、北京市经济和信息化局信息化与软件服务业处处长赵祥伟到会致辞。

本次论坛以“深化SBOM行业应用，共筑供应链安全基石”为主题，围绕软件供应链安全发展趋势、企业开源供应链管理与SBOM应用、开源社区SBOM治理、重点行业供应链安全治理的探索与实践等议题展开主题发言，以推动SBOM从理论到实践落地，助力安全防线前移。悬镜安全作为厂商代表积极参与了此次议题，悬镜安全CCO董毅上台发表题为“SBOM在软件供应链安全治理中的实践”的技术演讲。

悬镜安全CCO董毅技术演讲现场

以下是演讲全文：

大家好，本次分享的主题是“SBOM在软件供应链安全治理中的实践”，我将从背景、关于SBOM、数据字段、自动化支持、流程和实践等五个方面来展开阐述。

背景

根据GB/T 43698—2024的定义，软件供应链是指“需方和供方基于供应关系，开展并完成软件采购、开发、交付、获取、运维和废止等供应活动而形成的网链结构。”

软件供应链由传统供应链扩展而来：

1）原始组件：原材料 -> 自研、开源、混源组件

2）集成组件：中间组件 -> 制品模块

3）软件产品：交付产品 -> 软件系统、平台等

4）持续运营：产品运营 -> 运行过程、应急响应

数字时代，越来越多的软件供应链的建立，导致形成一个由相互联系、相互依赖的参与者组成的越来越紧密的网络。这一发展使得软件供应链攻击事件更有可能发生，并持续产生广泛的影响。

比如知名的黎巴嫩BP机爆炸事件就是一次非常典型的软硬件结合的供应链安全攻击事件，由于这类安全事件层出不穷，因此很多公司都做出相应的研究，例如，知名咨询机构Gartner指出，“到2025年，全球45%的组织会受到软件供应链攻击，比2021年增长三倍”；欧盟网络安全局（ENISA）表示，到2030年，软件供应链问题将成为头号网络威胁；Fortress Information Security则对某个安全产品的SBOM进行组件分析的结果发现：在该产品中，共发现了141个脆弱组件，总组件数为699个；最严重的漏洞是最古老的，严重漏洞被发现已有9年半。

关于SBOM

软件物料清单（Software Bill of Materials），指软件产品中所包含的所有组件、相关许可协议的清单，以及所有组件之间依赖关系的描述。

使用SBOM的好处体现在：

提升软件透明度：提高对软件系统组件和功能的全局可见性。

管理安全性：识别已知漏洞并及时应对；方便对漏洞的缓解措施针对性管理。

管理许可证：量化并管理许可证，识别许可证的合规性要求。

建立上下游信任链：建立上下游信任链，提高供应商自身竞争力等。

总体可以归结为：管控风险、降本增效。

由于使用SBOM的好处众多，因此世界各国政府都在推出相应的政府法规来推动软件物料清单的使用。如拜登政府签署的《关于改善国家网络安全（EO14028）的行政命令》，明确提出加强软件物料清单的使用；国内2024年发布的国家标准GB/T 43698中也明确要求了需要对软件物料清单进行使用。

根据美国商务部下属的国家电信和信息管理局早期对软件物料清单的定义，其中包含最主要的元素，即“数据字段、自动化支持以及实践和流程”，这三个元素构成了软件物料清单的基本面，下面我将围绕这三个主要元素进行展开。

SBOM三个最小必需元素

数据字段

美国国家电信和信息管理局明确定义了七个软件物料清单数据字段基本元素，即：

1. 组件供应商：开发组件的个人或组织名

2. 组件名称：供应商给出的组件名称

3. 组件版本：供应商给出的组件版本

4. 组件标识符：标识符，如SWID、PURL等

5.依赖关系：与其他组件的组合关系

6.构建人：生成SBOM的个人或组织名称

7.时间戳：生成SBOM的日期与时间

过去多年，我国有关机构也进行了相应探索，如国家工业信息安全发展研究中心《软件物料清单构成和要求》中在此基础上增加了“组件哈希值、许可证”两个基础字段，进一步完善了数据字段组成。

SBOM数据字段构成

自动化支持

无论是国家工业信息安全发展研究中心还是美国国家电信和信息管理局所定义的软件物料清单中，都明确的描述了软件物料清单必须要求是机器可读，核心原因是要做自动化支持。过去很多早期实践者使用excel表格来存储软件物料清单，这种在当时非常不便于机器进行自动化处理，人工处理方式费时费力。

目前，行业内通用的SBOM标准格式主要包括SPDX、CycloneDX、SWID和DSDX四种。SBOM标准的使用帮助SBOM实现了其自动化支持。

（1）主要SBOM工具格式对比：

四种主要SBOM工具格式对比

上述四种是机器可读的格式，同时也是易于人工可读的格式，其中三款是由国外主导，DSDX SBOM格式是由悬镜安全OpenSCA社区主导发起，汇聚开源中国、电信研究院、中兴通讯等权威研究机构、甲方用户、安全厂商多方力量，共同适配中国企业实战化应用实践场景。无论用户使用上述哪种格式，均可以满足日常使用需求。

（2）SBOM自动化工具的功能

SBOM自动化工具可以大致分为生产型、消费型、转换型工具，通常大家建设的步骤是先做消费类工具建设，再做生产类工具，最后做转换型类工具的建设。但现如今更多的实践者则将消费和生产工具一起做，其原因在于现在拥有一种比较常见的工具叫软件成分分析SCA工具，可以同时实现前两步建设。

SBOM自动化工具的功能

（3）SCA-SBOM生产和消费工具

软件成分分析（SCA）是一种通过识别、分析软件中的开源组件、依赖关系及潜在风险来保障供应链安全的技术‌。它主要应用于漏洞检测、许可证合规审查和软件物料清单（SBOM）生成。

例如，将SBOM DSDX格式与SCA开源威胁管控平台深度联动，可全面提升企业数字供应链安全风险的发现能力、分析能力、处置能力、防护能力以及安全管理水平，能够应用于以下场景：

1. 开源应用组件级资产测绘：DSDX可以生成全面兼容、安全可溯源的软件物料清单，精细化识别开源软件组件及其构成和依赖关系，输出透明化的数字应用组件资产及风险清单。

2. 许可证合规性管理：基于DSDX记录的开源软件许可证信息，进一步实现许可证条款解读、兼容性分析等，帮助企业确保自身遵守许可证相关条款，规避潜在的知识产权等法律问题或处罚，避免后续公司业务自身权益受到损害。

3. 提升软件质量：基于DSDX提供的组件信息，识别出过时或废弃的组件，鼓励开发团队使用最新且安全的库，从而提高整体的软件质量。

4. 安全事件应急响应：DSDX中包含了详尽的软件组成成分，安全团队可以通过DSDX分析软件风险，并进行持续监控；在有供应链安全事件发生时，安全团队也能根据DSDX快速定位第三方组件中已知漏洞的影响范围，并针对性地对修复措施进行优先级排序，加速供应链攻击事件应急响应速度。

当前市面上领先的软件成分分析工具源鉴SCA包含源码组成分析、二进制制品分析、代码同源分析、容器镜像成分扫描、运行时动态追踪、SBOM风险情报预警等六大分析引擎，共同构成了完整的使用场景支持。

SCA-SBOM生产和消费工具-多模态SCA引擎

对于许多中小型实践者而言，可能缺乏足够的财力物力去购买专业商业化SCA 产品。这种情况下，市面上开源SCA工具就成为了重要的选择。

悬镜安全OpenSCA社区是全球首个开源数字供应链安全社区，正式成立于2021.12.31，社区涵盖泛互联网、车联网、金融、能源、信息通信和智能制造等众多行业极客用户，为全球开发者们和广大安全研究人员构筑了专注安全开发与开源治理的技术创新实践社区。

OpenSCA社区的开源项目起源于悬镜安全商业版源鉴SCA，是国内用户量最多、应用场景最广的开源SCA技术（中国信通院《2024中国DevSecOps&BizDevOps现状调查报告》），通过软件码纹分析、依赖分析、特征分析、引用识别与开源许可合规分析等综合算法，深度挖掘开源供应链安全风险，智能梳理数字资产风险清单，结合SaaS云平台和实时供应链安全情报，为社区用户提供灵活弹性、精准有效、稳定易用的开源数字供应链安全解决方案。用户可自行进行下载编译安装在本地使用，也可在线上使用免费SaaS版本。

流程和实践

最基础的软件物料清单实践模型大致分为四个主要步骤，分别为探索如何生成 SBOM；定义 SBOM的消费方式；引入第三方机构以更好地生成 SBOM；将SBOM数据集成到安全工具和数据管理工具。将上述流程进一步提炼，形成软件物料清单生命周期，延展出一个更为精细化的完整化的软件物料清单使用流程，即生成-交付-验证-使用四个环节。

1称成

生成：

谁创建？何时创建？如何创建？何种格式？可执行于开发、构建、运维等阶段。

交付：

与软件一同被交付使用。一般存在于交付、部署、运维阶段。

验证：

验证 SBOM 中依赖信息的完整性和真实性。一般存在于软件交付、运维阶段。

使用：

将 SBOM 纳入资产管理中，监测漏洞变化。一般存在于运维阶段。

在上述生产、交付、使用这三个环节中均会使用到软件物料清单，当然相对应的使用方法和工具也都不一样，生产出的清单质量也不尽相同。因此诸多实践者会通过搭建ASPM数字供应链安全态势感知平台去做综合性管理，通过该平台，可完成所有阶段软件清单综合管理。

ASPM数字供应链安全态势感知平台

针对流程搭建，我们过去积累了大量的实践经验可以与大家分享。

流程要点一

先求有，再求好

在软件物料清单流程搭建环节，要先保证软件物料清单使用起来，由于软件物料清单涉及的环节过多，且使用工具产出质量参差不齐，因此在前期为了顺利推进物料清单的使用，可以在后续增进软件物料清单的完整性和准确性。

流程要点二

闭环SBOM流程

使用软件物料清单时，要注重流程闭环。有很多大型企业实践者在使用软件物料清单过程中，会用SCA工具生成软件物料清单，然后同时监测一些外部漏洞同步进行修复后就算完成流程。但实际上更好的办法是需要将这些漏洞和风险情况同步给研发和测试部分，避免在下一次开发迭代的过程中出现风险因素，形成一个正向循环。

闭环SBOM流程

流程要点三

持续漏洞监控

各SBOM的最大价值来源之一是：不论供应商在管理何种漏洞，终端用户都能够同步监控漏洞。我们称之为SBOM“信任但验证”的能力。

无论当前这个软件产品多么安全可靠，未来任何一天都有可能爆发新的组件漏洞，无数的历史经验告诉我们，持续漏洞监控是每天都要做的事请。

流程要点四

漏洞清零政策不可取

在一个成熟软件产品中，组件漏洞的数量是惊人的。清零政策通常意味着无法上线。因此现在有一个被经常提及的概念叫漏洞可利用性交换（VEX），它是一个信息安全领域的标准。VEX 提供了一种标准化的方式来描述漏洞，包括漏洞的标准详细信息，如严重性、影响软件等。还包括对漏洞的分析，例如漏洞是否可被利用，以及如何减轻或修复漏洞。可以优先针对真的可被利用漏洞，放过并不会造成实质影响的漏洞。

流程要点五

将提供SBOM写入合同

几乎没有供应商愿意主动提供SBOM给用户，除非有法律效力的文件进行约束（如采购合同），否则SBOM的获取将困难重重。

比如供应商不愿意提供SBOM是因为软件供应商生产和分发SBOM都需要额外的成本投入；若SBOM包含过多组件漏洞会让供应商看起来很糟糕；软件供应商会把使用的组件看成商业秘密的一部分；法务部门担心因SBOM不完整或错误带来的潜在风险；SBOM中包含难以修复漏洞会让交付验收面临额外困难等等诸多原因。

但若想软件物料清单使用更加顺畅，则需要提前将软件物料清单添加在采购合同里，否者后续很难从供应商那里获取完整信息。

流程要点六

持续提升真实性和完整性

SBOM信息越完整，能提供的价值就越大。SBOM信息的真实性更是用户和监管部门关注的重点。

比如，SBOM用户可能会考虑验证SBOM数据的来源并确保其未被修改；软件的完整性和真实性通常是通过签名和公钥基础设施来支持的；正在进行的开源工作致力于解决开发环境中遇到的签名元数据优先级的问题；鼓励供应和请求SBOM的用户探索签署SBOM和验证篡改检测；完整性和真实性是很多政府机构的优先考虑事项，尤其是在国家安全领域；在今天，某些SBOM数据用户可能还会坚持要求获取SBOM的数字化签名。

优秀案例实践

在实践案例方面，以某头部新能源车企为例，他们的产品线不仅覆盖国内市场，更是远销海外市场。该厂商生产的汽车搭载了高度集成的车载信息娱乐系统应用，然而，由于这些软件组件来源于多元供应商，存在潜在的开源组件使用及许可风险。具体来说，数字供应链透明度低，难以追踪和管理嵌入式固件以及车端大屏应用中的组件成分；不同的开源组件带有特定的许可证要求，且涉及到海外出口，若未正确遵守，可能导致法律纠纷或商业损失。

某新能源汽车头部厂商案例

为了解决这些问题，该车企建立了车端供应链安全审查制度，针对嵌入式固件及车端应用输出 SBOM 清单，梳理许可证风险，并将车端应用涉及的软件许可，在车端大屏中进行 “开放源代码许可” 声明公示。通过实施这些措施，该车企有效识别了许可风险，规避了版权许可问题，使业务上线前中高危开源漏洞减少了85%。

以上就是全部的分享，谢谢大家。

＋