漏洞分析與 SBOM
CRA 將您的軟體物料清單轉化為一項持續性的義務：掌握您產品中含有哪些元件、持續監看這些元件是否出現新漏洞，並在第 14 條的期限內加以修補與通報。本頁帶您走過此循環，以及運行該循環的免費工具。
CRA 漏洞分析器
上傳您的 SBOM 與有效漏洞清單。分析器會將每個元件對照國家漏洞資料庫（NVD）與 EU 漏洞資料庫（EUVD）進行交叉比對、標示出生命週期終止的元件，並產生一份您可附加於技術檔案的合規報告。
操作指南
產生一份符合規定的 SBOM
依附件 I 第 II 部分第 (1) 點，軟體物料清單（SBOM）是一項硬性的法律要求。本指南涵蓋其強制適用範圍與格式、如何產生，以及它如何銜接至監控循環。
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： 相依項目圖譜 → 匯出 SBOM（設定 → 程式碼安全）。輸出為 SPDX JSON。
- GitLab： CycloneDX 報告由相依項目掃描的 CI/CD 工作原生產生。
- Syft （Anchore）：開源 CLI 工具，可為容器映像檔、檔案系統及套件清單產生 SPDX 與 CycloneDX。
- cdxgen： 可為 npm、Maven、pip、Go、Rust 等產生 CycloneDX 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%），以及一份可立即使用的就緒度查核清單。