别把SBOM做成一张应付检查的Excel!CRA出海,制造商真正要搞懂的供应链合规

欧盟CRA（网络弹性法案）落地工作在2026‑09‑11就已开始，不少做软件、IoT、工业硬件出海的厂商，已经听过无数次“要做SBOM。

很多企业第一反应：找个工具导出一份清单，存个Excel，就算搞定CRA合规。 但现实很扎心：CRA要的SBOM，不是一份静态组件清单，是整套漏洞处理流程的“地基”，配套协调漏洞披露CVD、风险评估、VEX漏洞状态管理，才是完整答卷。

今天站在制造厂商视角，把这件事讲透：什么是真正能用的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，prEN40000‑1‑3还要求梳理HBOM硬件组件清单，记录芯片、固件等硬件部件信息，用于硬件层面漏洞处置，这是漏洞处理流程的配套要求。

很多厂商被网上五花八门的解读搞晕：到底要不要全部传递依赖？PDF行不行？开源闭源组件都要写进去吗？

我们拆开prEN40000‑1‑3条款，分成【强制基线要求】和【RE风险增强要求】，RE增强项不是所有产品默认强制，由企业自己的产品风险评估结果来决定是否启用，输出一份《适用性声明SoA》作为审计证据。

✅所有产品都必须做到（强制基线RQ）

1. 格式必须机器可读：JSON / XML，例如CycloneDX、SPDX（ISO/IEC5962）；PDF、Word、Excel不算合规格式，监管工具无法自动解析。

2. 至少记录顶层直接依赖组件，自研、闭源第三方、开源组件全部纳入，不只是开源。

3. 每个组件记录：组件厂商、名称、版本号；组件唯一标识（PURL / CPE / SWHID）、依赖关系。

4. SBOM元数据完整：编制主体、SBOM版本、ISO‑8601标准时间戳。

5. 每次产品版本、补丁、组件升级，都要重新生成新版SBOM，不能一份SBOM用好几年。

6. 所有历史版本长期归档：至少保存10年或者产品支持周期，取时间更长那一个。

⚠️RE风险增强项：仅高风险产品触发（重要/关键类CRA产品）

普通风险产品不强制；高风险产品，必须开启增强要求，并且写进适用性声明。

1. 技术可行前提下，SBOM包含全部传递间接依赖；上游供应商拿不到信息可以例外，但必须书面记录理由。

2. 如果上游供应商提供组件哈希值，哈希必须写入SBOM，用于校验构件完整性。

划重点：不是所有产品必须把成千上万间接依赖全部扒出来。普通风险产品做到顶层依赖就满足最低合规门槛；高风险产品（工业设备、安防、网络设备等）才要求深挖全部传递依赖。

全部判断依据来自企业自己输出的风险评估报告+适用性声明，这两份文档也是审计证据，缺一不可。

两个高频误区澄清

1. ❌误区：CRA要求把SBOM放到官网公开下载。 

   ✅真相：法规没有强制公开SBOM。只需要作为内部技术文档留存，监管机构索取时提供；商业场景下，你可以选择性交付给客户，但不是法律义务。

2. ❌误区：SBOM只需要管开源组件。 

   ✅真相：自研代码、第三方闭源SDK、固件组件，全部要纳入清单。

提醒：没有任何工具可以点一下按钮就实现CRA合规。工具只负责产出SBOM工件；风险评估、适用性声明、证据归档、流程建设，需要人来完成。工具生成SBOM≠自动合规。

🟢开源方案（适合中小企业，预算有限，云原生/软件类产品优先）

适合：软件、容器、云服务，DevSecOps团队有能力维护流水线。

1. Syft（Anchore）：最流行，扫描镜像、文件系统，输出CycloneDX/SPDX；搭配Grype做漏洞匹配。

2. Trivy：全能选手，可以直接生成SBOM，同时做漏洞扫描，支持容器、本地文件。

3. cdxgen OWASP：多语言SBOM生成，主打CycloneDX格式，非常适配CRA。

4. OWASP Dependency‑Track⭐核心平台：接收各个流水线产出SBOM，统一资产管理，漏洞持续监控，支持VEX漏洞可利用性交换文档（CRA非常需要VEX处理假阳性漏洞）。

👉开源典型流水线：CI构建产物 → Syft/Trivy产出JSON格式SBOM → 上传Dependency‑Track做持续漏洞监控，维护VEX文档，归档全部版本。

短板提醒：开源工具对嵌入式固件、闭源二进制分析能力偏弱，IoT硬件厂商只靠开源工具会遇到很大障碍，很多固件组件识别不全。

🔵商业SCA/SBOM平台（适合嵌入式、IoT、工业硬件、大型多供应商供应链）

1. Synopsys Black Duck：行业标杆；强项是二进制固件分析BDBA，不需要源码，非常适合硬件固件产品；完整支持CycloneDX/SPDX、VEX/CSAF，完整审计日志，适配CRA全套证据留存。

2. Finite State：聚焦IoT固件二进制解析，专门面向硬件制造厂商。

3. Snyk：开发者友好，适合互联网软件、云原生；短板固件二进制能力弱。

4. Sonatype Lifecycle、Mend：擅长包管理供应链、许可证合规，适合大量第三方组件引入的软件项目。

5. Anchore Enterprise：Syft企业版，面向容器云原生场景。

📌简单选型建议

• 云原生/纯软件，预算有限：开源组合 Syft+Trivy+Dependency‑Track；

• IoT、嵌入式、固件设备（没有完整源码）：优先商业工具，开源能力不足以完成二进制解析；

• 大型企业，多供应商，需要接收上游供应商提交SBOM，完整审计证据：Black Duck / Mend。

很多企业以为搞定SBOM就万事大吉，prEN40000‑1‑3告诉我们，SBOM只是起点，完整漏洞处理分为六大阶段：

1. 准备PRE：制定漏洞处理策略、CVD协调漏洞披露政策、建立漏洞上报渠道、梳理SBOM/HBOM、制定定期安全测试计划；

   这里提醒：企业需要对外公布漏洞上报联系方式（安全邮箱、web表单等，推荐security.txt），这是硬性要求。

2. 接收RCP：接收内外部漏洞报告，监控漏洞数据库，拿着SBOM快速定位哪些软硬件组件可能受影响。

3. 验证VRF：确认漏洞真实性，做风险评估，划分修复优先级，高危漏洞要加速处置。

4. 修复RMD：制定修复方案，开发补丁，充分测试，验证修复效果。

5. 发布RLS：免费提供安全更新；发布安全公告，高风险产品还要提供机器可读CSAF安全公告。

6. 发布后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跑通，跑通漏洞影响分析流程，再逐步迭代补充传递依赖等增强项，优先保证流程跑通，而不是追求文档100%完美。