联系方式
全国免费服务热线
400-7558988
固话：0769-85075888-6618
手机：13925591357
传真：0769-85075898
邮箱：net04@gtggroup.com
地址：广东省东莞市松山湖园区科技八路2号华灿产业园
CRA 供应链合规：SBOM 的正确形态、prEN 40000-1-3 要求与工具选型
CRA供应链合规：SBOM的正确形态、prEN 40000-1-3要求与工具选型
欧盟CRA（网络弹性法案）的报告义务已于2026年9月11日起适用，做软件、IoT、工业硬件出海的厂商对此已不陌生。但CRA要的SBOM不是一份静态组件清单，而是整套漏洞处理流程的基础，需要配套协调漏洞披露（CVD）、风险评估、VEX漏洞状态管理，才算完整。本文从制造商视角回答四件事：真正能用的SBOM长什么样、哪些坑不要踩、开源与商业工具怎么选、怎么落地不做无用功。
先纠正一个普遍误解：找工具导出一份清单、存成Excel，并不等于CRA合规。SBOM如果只是一张静态表格，漏洞爆发时用不上，即使文档齐全，依然会被判定不合规。
为什么CRA盯上SBOM
过去很多硬件、软件厂商的模式是：产品做完、卖出去，事情就基本结束。组件里藏了多少开源、多少第三方闭源包，不少团队自己都说不清。漏洞爆出来、外部报来CVE编号，研发到处翻代码，花几天甚至几周，才搞清楚"这个产品到底受不受影响"。
这正是CRA要解决的痛点：产品上市不等于安全工作结束。在整个支持周期（最低5年）内，制造商需要持续管理漏洞、发布安全更新、接受监管机构抽查文档。
法律依据（CRA，EU 2024/2847，Annex I Part-II）：
- 制造商必须识别并记录产品组件
- 编制机器可读格式的SBOM软件物料清单
- 至少覆盖顶层直接依赖
- 作为技术文档留存，监管机构有权随时调取
- 法律并不强制对外公开发布SBOM
配套协调标准草案prEN 40000-1-3（漏洞处理标准）把法律条文拆解成可落地的流程。SBOM在这个流程里不是独立文档，而是贯穿漏洞全生命周期：准备阶段梳理组件 → 接收漏洞报告快速定位受影响软硬件组件 → 漏洞风险评估 → 修复开发 → 发布安全公告 → 发布后复盘优化。
第一个大坑：把SBOM当成交差材料
错误做法：版本迭代一次，导出一份Excel表格，归档进文件夹，此后再也不打开。等到监管抽查，翻出来交上去。
CRA真正的意图：当漏洞爆出，你能拿着SBOM快速判断——我的产品会不会中招、哪些版本要打补丁、哪些客户需要通知。
如果SBOM只是一张静态表格，漏洞爆发时根本用不了，即使文档齐全，依然判定不合规。
补充：硬件设备厂商不要只盯着软件SBOM。prEN 40000-1-3还要求梳理HBOM硬件组件清单，记录芯片、固件等硬件部件信息，用于硬件层面的漏洞处置，这是漏洞处理流程的配套要求。
条款拆解：强制基线RQ与RE风险增强项
不少厂商被网上各种解读绕晕：到底要不要覆盖全部传递依赖？PDF行不行？开源与闭源组件是否都要写进去？把prEN 40000-1-3的条款拆开看，可以分成"强制基线要求"和"RE风险增强要求"两类。RE增强项并非所有产品默认强制，而由企业自身的产品风险评估结果决定是否启用，并输出一份《适用性声明SoA》作为审计证据。
| 要求项 | 强制基线RQ（所有产品） | RE风险增强项（仅高风险产品） |
|---|---|---|
| 格式 | 机器可读：JSON或XML，例如CycloneDX、SPDX（ISO/IEC 5962）。PDF、Word、Excel不算合规格式，监管工具无法自动解析 | 同左，无额外格式要求 |
| 覆盖范围 | 至少记录顶层直接依赖组件；自研、闭源第三方、开源组件全部纳入，不只是开源 | 技术可行前提下包含全部传递间接依赖；上游供应商拿不到信息可例外，但必须书面记录理由 |
| 组件字段 | 组件厂商、名称、版本号；组件唯一标识（PURL / CPE / SWHID）；依赖关系 | 如上游供应商提供组件哈希值，哈希必须写入SBOM，用于校验构件完整性 |
| 元数据 | 编制主体、SBOM版本、ISO 8601标准时间戳 | 无 |
| 更新频率 | 每次产品版本、补丁、组件升级都要重新生成新版SBOM，不能一份SBOM用好几年 | 无 |
| 归档期限 | 所有历史版本长期归档：至少保存10年或产品支持周期，取时间更长的那一个 | 无 |
| 配套文档 | 技术文档留存，监管索取时提供 | 风险评估报告 + 适用性声明SoA，两份均为审计证据 |
划重点：不是所有产品都必须把成千上万个间接依赖全部梳理出来。普通风险产品做到顶层依赖即满足最低合规门槛；高风险产品（工业设备、安防、网络设备等）才要求梳理全部传递依赖。判断依据来自企业自己输出的风险评估报告与适用性声明，这两份文档也是审计证据，缺一不可。
两个常见误区澄清
误区一：CRA要求把SBOM放到官网公开下载
真相：法规没有强制公开SBOM。只需作为内部技术文档留存，监管机构索取时提供；商业场景下可以选择性交付给客户，但不是法律义务。
误区二：SBOM只需要管开源组件
真相：自研代码、第三方闭源SDK、固件组件，全部要纳入清单。
另需注意：没有任何工具可以点一下按钮就实现CRA合规。工具只负责产出SBOM工件；风险评估、适用性声明、证据归档、流程建设，需要人来完成。工具生成SBOM不等于自动合规。
工具选型：开源与商业各适合谁
开源方案（适合中小企业、预算有限，云原生与软件类产品优先）
- Syft（Anchore）：使用较广，扫描镜像与文件系统，输出CycloneDX/SPDX；搭配Grype做漏洞匹配
- Trivy：功能覆盖较全，可直接生成SBOM，同时做漏洞扫描，支持容器与本地文件
- cdxgen（OWASP）：多语言SBOM生成，主打CycloneDX格式，较适配CRA
- OWASP Dependency-Track（核心平台）：接收各流水线产出的SBOM，统一资产管理、持续漏洞监控，支持VEX漏洞可利用性交换文档（CRA处理假阳性漏洞时需要）
一条典型开源流水线：CI构建产物 → Syft/Trivy产出JSON格式SBOM → 上传Dependency-Track做持续漏洞监控、维护VEX文档、归档全部版本。
短板提醒：开源工具对嵌入式固件、闭源二进制的分析能力偏弱。IoT硬件厂商只靠开源工具会遇到较大障碍，很多固件组件识别不全。
商业SCA/SBOM平台（适合嵌入式、IoT、工业硬件、大型多供应商供应链）
- Synopsys Black Duck：业内应用较广；强项是二进制固件分析（BDBA），不需要源码，适合硬件固件产品；完整支持CycloneDX/SPDX、VEX/CSAF，具备完整审计日志，适配CRA全套证据留存
- Finite State：聚焦IoT固件二进制解析，专门面向硬件制造厂商
- Snyk：开发者友好，适合互联网软件与云原生；短板是固件二进制能力较弱
- Sonatype Lifecycle、Mend：擅长包管理供应链与许可证合规，适合大量引入第三方组件的软件项目
- Anchore Enterprise：Syft企业版，面向容器与云原生场景
简单选型建议
| 产品类型 | 推荐路线 |
|---|---|
| 云原生 / 纯软件，预算有限 | 开源组合：Syft + Trivy + Dependency-Track |
| IoT、嵌入式、固件设备（没有完整源码） | 优先商业工具。开源工具对二进制解析能力不足以完成这类工作 |
| 大型企业、多供应商，需接收上游SBOM、保留完整审计证据 | Black Duck 或 Mend |
SBOM贯穿的六个漏洞处理阶段
不少企业以为搞定SBOM就万事大吉。prEN 40000-1-3说明，SBOM只是起点，完整的漏洞处理分为六个阶段：
准备阶段（PRE）
制定漏洞处理策略、CVD协调漏洞披露政策、建立漏洞上报渠道、梳理SBOM与HBOM、制定定期安全测试计划。
这里需要提醒：企业需对外公布漏洞上报联系方式（安全邮箱、Web表单等，推荐security.txt），这是硬性要求。
接收阶段（RCP）
接收内外部漏洞报告，监控漏洞数据库，拿着SBOM快速定位哪些软硬件组件可能受影响。
验证阶段（VRF）
确认漏洞真实性，做风险评估，划分修复优先级，高危漏洞加速处置。
修复阶段（RMD）
制定修复方案，开发补丁，充分测试，验证修复效果。
发布阶段（RLS）
免费提供安全更新；发布安全公告，高风险产品还需提供机器可读的CSAF安全公告。
发布后复盘（PRA）
跟踪补丁落地效果，复盘流程，优化后续工作。
SBOM贯穿上述全部流程。没有一份可用的SBOM，漏洞来了，你根本不知道自己产品里装了什么组件，整个流程会直接卡住。
另一个容易被忽略的工件：VEX文档
大量扫描会报出一堆CVE，但很多漏洞在你的产品场景下根本不可利用。VEX用于标准化记录"这个漏洞对我的产品是否受影响"，可减少大量无效修复工作量，同时留存审计证据，是CRA合规的重要配套工件。
五条落地建议
第一，先做产品风险评估，输出适用性声明SoA
不要上来就买工具生成SBOM。先评估产品风险等级，确定是否开启RE增强项（传递依赖、哈希），把结论写进适用性声明。这份文档是监管核查的重点。
第二，SBOM融入CI/CD流水线，避免手工Excel维护
手工维护SBOM一定会过时。每一次构建、每一次补丁发布都自动生成SBOM，与构建产物绑定，全部版本归档。
第三，管理上游供应商SBOM，做好供应链尽职调查
很多组件来自第三方供应商，应主动索要SBOM。供应商提供的SBOM质量差、字段缺失的，要记录该风险，在风险评估文档中写清限制条件。CRA明确：制造商对集成进来的第三方组件负有尽职调查责任，包括开源组件。
第四，不孤立看待SBOM，同步补齐配套文档
除SBOM外，还需同步准备：CVD协调漏洞披露政策、漏洞上报渠道、风险评估报告、VEX漏洞处置记录、安全公告、定期安全测试计划。要的是一套完整证据链，而不是单独一份SBOM文件。
第五，中小企业不必追求一步到位
可以从基线要求做起：先把顶层依赖的机器可读SBOM跑通，跑通漏洞影响分析流程，再逐步迭代补充传递依赖等增强项。优先保证流程可用，而不是追求文档完美。
一句话总结：CRA给出海厂商带来的主要变化，是安全从"上市前测试"变成了产品全生命周期的责任。SBOM本质上不是用来应付检查的文档，而是了解自己产品内部究竟装了什么的一张地图。当漏洞爆发的那一刻，这份地图能不能快速帮你定位风险，才是CRA真正想实现的目标。