一、背景：从 SolarWinds 到 Log4j，供应链安全危机催生新规则
2020 年末的 SolarWinds 攻击事件至今令人记忆犹新——攻击者通过在 Orion 软件更新包中植入后门，渗透了包括美国财政部、国土安全部在内的数百家机构。一年后的 2021 年 12 月，Log4j 漏洞（CVE-2021-44228）将软件供应链风险推至顶点：一个广泛使用的开源日志组件中的远程代码执行漏洞，影响了全球数以百万计的应用系统。
这两起事件揭示了一个核心问题：如果制造商连产品软件里"装了什么"都不清楚，安全就无从谈起。
正是基于这一教训，欧盟《网络弹性法案》（Cyber Resilience Act，简称 CRA，法规编号 EU 2024/2847）将软件组成信息的识别和维护列为制造商的核心义务之一。CRA 于 2024 年 10 月 23 日正式通过，2024 年 12 月 10 日生效，主要合规义务将于 2027 年 12 月 11 日起全面适用。SBOM——Software Bill of Materials，即软件物料清单——正是满足这一义务的核心工具。
二、SBOM 是什么，CRA 为何需要它
（一）SBOM 的定义
SBOM 是一份结构化清单，记录了一个软件产品中包含的全部组件、库、依赖项及其版本信息。可以将其理解为软件的"配料表"——正如食品包装上的成分表让消费者了解食品中有什么，SBOM 让制造商和监管机构了解一个数字产品里到底"装了什么"。
一份标准的 SBOM 通常包含以下字段：组件名称与版本号、供应商信息、依赖关系图谱、许可证信息，以及与已知漏洞（CVE）的关联映射。目前国际通行的两种标准格式分别为 Linux 基金会主导的 SPDX（已成为 ISO/IEC 5962:2021 国际标准，最新版本 3.0.1）和 OWASP 主导的 CycloneDX，两者均被业界广泛接受。
（二）CRA 对软件组成信息的要求
CRA 要求制造商在产品上市前识别并记录产品包含的全部软件组件（涵盖开源组件、商业第三方组件及其间接依赖），并建立持续的风险管理和漏洞管理机制。制造商应在监管要求或风险管理需要时提供相关软件组成信息，而非无条件向所有用户公开完整 SBOM。
对于被积极利用的漏洞（actively exploited vulnerabilities）或重大网络安全事件，CRA 规定了分级报告机制：知悉后 24 小时内提交早期预警（Early Warning），72 小时内提交详细通知（Detailed Notification），一个月内提交最终报告（Final Report）。并非所有 CVE 都需要触发报告义务——仅有那些正在被实际利用的漏洞或严重事件才适用此机制。
在分类方面，CRA 将产品分为"默认类"和"重要/关键类"两个层级。大多数普通消费类产品目前属于默认评估路径，可走制造商自我声明。部分重要产品（Important Class I/II，如防火墙、路由器等）和关键产品（Critical Products，如智能卡操作系统等）则须接受第三方公告机构（Notified Body）的合规评估，其软件组成信息的完整性和准确性将受到更严格的审查。
三、制造商如何建立 SBOM 管理能力
（一）第一步：全面梳理软件资产
对产品中使用的所有软件组件进行盘点。这不仅包括自主研发的代码，更关键的是识别全部引入的外部组件：开源库和框架（如 OpenSSL、Linux 内核模块）、商业授权组件（如 RTOS、协议栈），以及间接依赖——即"依赖的依赖"。间接依赖是最容易被遗漏的环节。
在工具选择上，Syft（Anchore 开源）和 Trivy（Aqua Security 开源）是目前最常用的 SBOM 生成工具，可直接扫描代码仓库和二进制固件镜像，输出 SPDX 或 CycloneDX 格式文档。Tern 适用于容器镜像层级分析，FOSSology 侧重许可证合规审查。Dependency-Check 则更适用于组件漏洞识别与关联分析，可作为 SBOM 生成后的补充验证工具。
（二）第二步：建立持续跟踪与更新机制
SBOM 不是一次性交付物。当软件组成发生变化时，SBOM 应同步更新；当某个组件出现被积极利用的漏洞时，制造商须能够快速完成"漏洞→组件→受影响产品"的追溯定位。建议建立以下流程：将 SBOM 生成纳入 CI/CD 流水线，每次构建自动更新；订阅 NVD（美国国家漏洞数据库）、GitHub Advisory Database 等漏洞源，实现自动化告警；建立从漏洞到受影响产品的追溯映射数据库；在产品维护周期内保存全部历史 SBOM 版本。
四、SBOM 的行业价值与前瞻
SBOM 的推行不仅是为了应对 CRA 监管。从行业趋势看，它正在推动整个软件供应链走向透明化与可审计化。对于制造商而言，SBOM 帮助避免了因未知组件漏洞引发的突发安全事件；对于下游用户而言，SBOM提升了软件组成信息的透明度。；对于监管机构和行业应急组织（如 CERT-EU）而言，SBOM 为大规模漏洞应急响应提供了基础数据支撑。
如果说 EN 18031 系列标准解决了"设备应该具备哪些安全能力"的问题，那么 CRA 和 SBOM 解决的就是"如何在产品全生命周期中证明和持续维护这些能力"的问题。前者是设计阶段的合规基准，后者是上市后持续保障的机制支撑。两者叠加，构成了欧盟面向数字时代的完整产品安全治理框架。
对于正在布局欧盟市场的中国物联网企业而言，CRA 的主要合规义务将于 2027 年 12 月正式适用，看似仍有两年多的准备窗口，但 SBOM 体系的建立——从选型工具、搭建 CI/CD 集成流程到团队培训——并非短期内可突击完成。建议从现在起将 SBOM 纳入研发管理流程，在合规大限到来之前建立充分的能力储备。
更多文章：
实力认证！领世达实验室顺利通过 EN 18031-1 能力验证，软件安全测试技术获国家级认可！
高效开案！PSTI测试开案全流程指南
高效开案！EN 18031测试开案全流程指南
欧盟CRA漏洞披露，2026年强制生效
公司简介
深圳市领世达检测技术有限公司专注第三方检测认证与技术咨询，主营各国的产品网络安全、国际市场准入及产品可靠性测试服务。核心覆盖 EN 18031、PSTI、CRA、CE、FCC、UKCA 、JC-Star、CSA 2024、SB-327、NIST 8259A等认证，提供网络安全测试、无线产品RF测试、以及环境可靠性检测等一站式解决方案。公司依托集团技术实力，遵循 ISO/IEC 17025 体系，为消费电子、物联网、通讯电子等企业提供专业高效的合规入市服务，助力客户突破全球贸易技术壁垒。
···
探索 · 专注 · 领先工匠精神 从始至终 探索之途 一往无前