產生一份符合規定的 SBOM
软件物料清单是附件 I 第 II 部分第 (1) 点规定的一项强制性法律要求。本部分涵盖强制性的范围与格式、根据产品构建方式所应使用的工具，以及完整的生命周期指南。
1 · 法律依據
附件 I 第 II 部分（「漏洞處理要求」）第 (1) 點要求製造商須 「識別並記錄漏洞與元件……包括以常用且機器可讀的格式編製涵蓋產品至少頂層相依項目的軟體物料清單（SBOM）。」
不同於某些容許解讀彈性的 CRA 條文，產生一份至少涵蓋頂層相依項目之機器可讀 SBOM 的義務並不容許採用替代做法。
2 · 強制適用範圍與格式
元件涵蓋範圍。 SBOM 必須記錄所有頂層相依項目，這是法律下限而非建議達成的目標。請於可行之處對應遞移（間接）相依項目；一份淺層的 SBOM 雖能滿足法律文字，但往往不足以進行有效的漏洞管理。
格式。 CRA 規定須採用「常用、機器可讀的格式」。可被接受的格式包括：
- SPDX （ISO/IEC 5962:2021）：廣泛採用、以授權為重點，適合用於合規文件。
- CycloneDX：以安全為核心，非常適合漏洞管理的工作流程。
- 來自公認工具的其他結構化格式（JSON、XML），在基準要求下一般可被接受。
請勿將 SBOM 儲存為 PDF。市場監督主管機關可能質疑 PDF 並非機器可讀。請儲存您工具鏈所輸出的原生 JSON、XML 或標籤值（tag-value）格式。
必填的中繼資料欄位
| 欄位 | 說明 |
|---|---|
| 元件名稱 | 該函式庫、套件或模組的唯一識別碼 |
| 版本 | 確切的版本字串；版本範圍並不足夠 |
| 供應商／來源 | 發行者、供應商或開源專案名稱 |
| 相依項目之間的關係 | 直接相依與遞移相依之別；於可行時建立相依項目圖譜 |
| 密碼學雜湊值 | 每個元件採用 SHA-256 或更強的完整性檢查 |
| 授權識別碼 | SPDX 授權運算式（例如 Apache-2.0、MIT） |
3 · 生成您的 SBOM：选择合适的工具
大多数平台都能在构建时自动生成 SBOM，且无需额外费用。合适的工具取决于您产品的构建方式。
应用程序与软件包生态系统
- GitHub／Actions： Dependency graph → Export SBOM（Settings → Code security）。输出 SPDX JSON。
- GitLab： CycloneDX 報告由相依項目掃描的 CI/CD 工作原生產生。
- Syft （Anchore）：開源 CLI 工具，可為容器映像檔、檔案系統及套件清單產生 SPDX 與 CycloneDX。
- cdxgen： 可為 npm、Maven、pip、Go、Rust 等產生 CycloneDX SBOM。
嵌入式 C/C++ 固件
syft 和 cdxgen 等软件包清单扫描器假定存在依赖清单，而固件并不具备这一点：组件在芯片供应商的 SDK 内部被静态链接或重命名。对于这种情况：
- Gangmu (github.com/GANGMU-SBOM/gangmu ↗）：一款为嵌入式 C/C++ 打造的开源（Apache-2.0）构建时生成器。它读取您的源代码树、 compile_commands.json、链接器映射和固件二进制文件，识别供应商 SDK 重命名或静态链接的开源组件，并输出 CycloneDX 1.6 和 SPDX 3.0.1，可直接送入步骤 2 中的 Analyzer。它完全在您的本地计算机上运行，不含任何遥测。由 Suzhou Qilijie Technology 维护。
当您拥有源代码树时，Gangmu 最为强大；仅针对二进制文件的分析是不完整的，尤其是跨 CPU 架构时。它无法识别的预构建供应商库仍会被列出，并附带其路径和 SHA-256 哈希值，且标记为未识别，以便您自行处理。
其 SBOM 会嵌入您代码树中的相对目录路径和文件哈希值，因此在将其上传到此处或共享之前请先进行审查。Gangmu 只是此处列出的若干 SBOM 生成器之一，与本网站没有关联；我们审查了该工具及其规则库，并基于其自身价值予以推荐，它并非赞助商。
漏洞篩查。 在完成任何 SBOM 之前，先將每個元件對照已知漏洞資料庫進行篩查。GitHub 的掃描器與 Syft 皆可整合下列服務： Grype 用於此目的。納入一個帶有已知且已修補漏洞的元件，即屬直接違反附件 I，且不容任何解讀彈性。
若某元件已有修補過的版本，您就必須採用它。對於已解決的漏洞，CRA 並沒有「已接受風險」這一類別。在將產品投放市場前，務必針對每一項發現採取行動。
4 · 生命週期維護與保存
SBOM 是一份持續演進的文件，會在產品受支援的生命週期內持續更新，以反映已修補的元件、新增的相依項目、已移除的生命週期終止元件，以及供應鏈的變動。包括 SBOM 在內的所有版本技術文件，自首次投放市場起須至少保存 10 年……
第 4–9 節：生命週期、罰則、BSI TR-03183-2 與就緒度查核清單
本指南其餘部分涵蓋 10 年保存義務、機密性與供應鏈揭露、與第 14 條漏洞通報的整合、監控頻率、德國較嚴格的 BSI 規範、罰鍰（最高 €15,000,000 或營業額 2.5%），以及一份可立即使用的就緒度查核清單。
今日评估您的 SBOM 并修复未修复的漏洞
在将产品投放市场之前，请将您刚生成的 SBOM 与实时漏洞数据进行比对，找出任何已存在的未修复漏洞并予以修复。免费的 Vulnerability Analyzer 正是完成这项工作。
CRA 漏洞分析器
Analyzer 会将每个组件与 National Vulnerability Database（NVD）和 EU Vulnerability Database（EUVD）进行交叉比对，标记 End-of-Life 组件，并生成一份可附入技术文档的合规报告。
在产品投放市场之前，每一项未修复的发现都必须得到解决：对于已有补丁的漏洞，不存在“风险接受”这一类别。请使用该报告记录您所发现的内容以及所采取的措施。随后进入步骤 3 以持续监测，因为 SBOM 是一项持续演进的产物，而非一次性的检查。
设置自动化监测流水线
今日 SBOM 洁净，并不代表明日亦然。您必须持续监测其组件，使新披露的漏洞能够在第 14 条规定的 24 小时窗口内被发现。下面介绍如何设置 GitHub 的原生跟踪功能，以及为何仅凭通知摘要无法满足法律要求。
启用标准的 GitHub 通知摘要并不能满足您在 EU 市场法下的法律义务。第 14 条要求制造商在漏洞被实际利用时遵守严格的 24 小时早期通知窗口。摘要汇总只是一项提升开发者认知的功能，无法替代实时的监管事件传递。
第 1 部分 · 仓库设置（维护者）
为使 GitHub 构建依赖关系图并对照 GitHub Advisory Database 标记已知漏洞：
- 打开仓库 → Settings.
- 在侧边栏中，于 Security下，选择 Advanced Security.
- 找到 Dependabot alerts 并点击 Enable.
第 2 部分 · 个人安全警报摘要
Watch 该仓库。 在项目的主页面，打开 Watch 菜单 → All Activity，或 Custom ，勾选 Security alerts 。
设置您的摘要频率。 Profile → Settings → Notifications → Dependabot alerts，然后调整电子邮件摘要：
- 每日摘要： 将未修复的警报每 24 小时合并为一个数据包。
- 每周摘要： 将未修复的警报每周合并为一个数据包。
第 3 部分 · 运营实际情况与 CRA 对齐
在面向 EU 市场部署时，依赖批量摘要会使您面临合规缺口。GitHub 各项配置与 CRA 预期的对应关系如下：
| 配置 | 行为 | CRA 状态 |
|---|---|---|
| 每周摘要 | 每周一次的汇总概要 | ✕ 不合规；完全错过 24 小时窗口。 |
| 每日摘要 | 每 24 小时一次的汇总概要 | ⚠ 高风险；在摘要发出后不久出现的零日漏洞，会在下一次摘要到达之前就超过期限。 |
| 实时 Webhook | 在披露时立即发送 JSON 负载 | ● 合规推动因素；即时提供的机器可读详情可让分类处理团队记录可利用性，并及时联系 ENISA。 |
实时信号是必要的，但并不充分；您仍然必须评估每个组件并生成证据。请将每一项变更重新送入 Vulnerability Analyzer ↗ ，将您的 SBOM 和漏洞数据转化为符合 CRA 要求的报告，然后按照 24h / 72h / 14-day 的时间表向 ENISA 和 CSIRT 报告被实际利用的漏洞。