SBOM 建置與工具選擇實務指引

本文的用途
這份文件協助執行團隊瞭解不同法規對 SBOM 的具體要求差異、評估因應方案（人工/委外/工具化）的適用性、以及在需要導入工具時的選型方法。目標是讓團隊能根據自身產品組合與法規需求，做出務實的決策。

一、各法規對 SBOM 的具體要求比較

不同法規對 SBOM 的要求在深度、格式、更新頻率上有差異。以下對照表協助您瞭解各法規的具體需求，以便規劃統一或分線的因應策略。

要求維度	歐盟 CRA	美國 FDA	汽車 UN R155/R156
SBOM 深度	需涵蓋直接與間接依賴；Annex I 要求「識別並記錄產品中的漏洞與元件」	需涵蓋商用、開源、自研元件，包含版本號與已知漏洞；建議至少一層依賴	需識別供應鏈軟體元件及其風險；深度取決於 CSMS 實施範圍
格式要求	機器可讀；ENISA 2025 指引建議 CycloneDX 或 SPDX	FDA 接受 CycloneDX 與 SPDX；需包含 PURL 識別碼	尚無統一強制格式；實務以 SPDX/CycloneDX 為主流
漏洞關聯	Art. 14 通報義務需仰賴 SBOM 判斷漏洞影響範圍；需持續比對	送審時需說明已知漏洞的風險評估與緩解措施	CSMS 要求持續監控元件漏洞並評估風險
更新頻率	產品生命週期內持續維護；每次重大版本更新需更新 SBOM	送審時提交；重大軟體更新時需更新	型式認證時提交；持續維護作為 CSMS 的一部分
VEX 支援	ENISA 建議搭配 VEX 文件標記「不受影響」的漏洞，降低通報雜訊	FDA 接受但未強制；有助於說明已知漏洞的實際風險	尚未明確要求，但有助於漏洞管理效率
授權合規	CRA 不直接要求，但開源授權管理是技術文件的隱含需求	FDA 關注軟體成分的合法使用權	車廠供應鏈通常要求授權合規審查

實務建議：如果您的產品同時涉及多個法規，建議以 CRA 的要求為基準（最嚴格的機器可讀格式 + 持續漏洞比對），這樣同一份 SBOM 基礎可以向下相容 FDA 與 R155 的需求。 

 

二、SBOM 的基本構成：執行團隊需要知道的核心概念

2.1 兩大標準格式

	SPDX (ISO/IEC 5962)	CycloneDX (OWASP)
背景	Linux Foundation 主導；2021 年成為 ISO 標準；偏重授權合規	OWASP 主導；偏重資安應用（漏洞、VEX）；輕量化設計
適用場景	授權合規為主、法律文件需求強的情境（如開源授權審查）	資安合規為主、需要漏洞追蹤與 VEX 整合的情境（如 CRA 通報）
法規接受度	CRA、FDA、NTIA 均接受	CRA、FDA、NTIA 均接受
建議	若主要需求是授權合規與法律追溯，SPDX 更成熟	若主要需求是資安漏洞管理與 CRA 通報支撐，CycloneDX 更實用

 

2.2 SBOM 最低內容要素（NTIA 基準）

美國 NTIA 定義的「最低要素」已成為全球 SBOM 內容的基準參考：

• 供應商名稱（Supplier Name）
• 元件名稱（Component Name）
• 元件版本（Version）
• 唯一識別碼（如 PURL — Package URL）
• 依賴關係（Dependency Relationship）
• SBOM 作者（Author of SBOM）
• 時間戳記（Timestamp） 

CRA 與 FDA 的實務要求在此基礎上更進一步，通常還需要：已知漏洞列表、授權類型、SBOM 涵蓋範圍聲明。
   

三、三種因應方式的詳細比較

面對 SBOM 要求，執行團隊需要根據產品數量、法規需求、組織成熟度選擇合適的因應方式。以下是三種方式的詳細比較：

評估維度	人工盤點	委外服務	工具化（內建）
初期投入	低（人力工時）	中（服務費用）	高（工具授權 + 整合工時）
長期成本	隨產品增加線性成長	按專案計費	邊際成本遞減
完整性	低：難以追蹤間接依賴	高：專業 SCA 掃描	高：自動化掃描
持續更新能力	弱：每次需重新盤點	中：需重新委託	強：CI/CD 自動產出
漏洞即時比對	無	報告交付時點比對	持續比對（NVD/OSV）
法規格式合規	弱：通常是 Excel	強：SPDX/CycloneDX	強：SPDX/CycloneDX
適用情境	產品少、軟體簡單、短期合規需求	尚未有內部能力、需要快速合規	產品多、版本迭代快、長期需求

務實路徑建議：多數廠商的合理起點是「委外取得第一版 SBOM + 學習方法論」→「評估產品規模與更新頻率」→「決定是否導入工具並選型」。不建議在尚未瞭解 SBOM 實務的情況下直接採購工具。
 

四、工具選型：八個評估維度

當您決定導入 SBOM 工具時，以下八個維度可作為評估框架。建議以實際產品程式碼進行概念驗證（PoC），避免僅憑規格表做決策。

	評估維度	評估重點	為什麼重要
1	元件識別準確度	直接依賴 + 間接（transitive）依賴的識別能力；是否支援 binary analysis	CRA/FDA 要求涵蓋完整供應鏈；遺漏的元件 = 漏洞管理缺口
2	語言與建置系統支援	對您實際使用的語言（C/C++、Java、Python 等）和建置工具（Make、CMake、Yocto 等）的支援程度	嵌入式 / IoT 產品常用 C/C++，許多工具對此支援不完整
3	輸出格式	是否支援 CycloneDX 與 SPDX 標準格式；是否包含 PURL 識別碼	不同法規與客戶要求不同格式，工具需有彈性
4	CI/CD 整合能力	是否可嵌入 Jenkins、GitLab CI、GitHub Actions 等流程，自動產出 SBOM	持續更新是 CRA 與 CSMS 的核心要求；手動觸發較難規模化
5	漏洞資料庫比對	是否整合 NVD、OSV、GitHub Advisory 等漏洞資料庫；比對頻率與警示機制	CRA 通報義務需要即時掌握漏洞狀態；FDA 要求已知漏洞的風險評估
6	VEX 支援	是否支援 VEX（Vulnerability Exploitability eXchange）文件的生成與管理	VEX 可過濾「不受影響」的漏洞，降低通報雜訊與工程團隊負擔
7	授權合規檢查	是否能識別開源元件的授權類型（GPL、MIT、Apache 等），並標記授權衝突	開源授權問題在車用與醫療產業尤為敏感
8	報告與追溯能力	是否能產出可供監管機關或客戶審查的報告；是否保留歷史版本 SBOM	面對稽核或客戶審查時需要完整的追溯紀錄

 

五、工具選型：開源與商業工具

以下整理供執行團隊初步認識市場上的主要工具類別。工具選型應以實際 PoC 結果為準，不建議僅憑規格表決策。

5.1 開源工具

工具	特色	適用情境	注意事項
Syft (Anchore)	通用型 SBOM 生成工具；支援容器映像與檔案系統掃描；搭配 Grype 可做漏洞比對	容器化產品、需要快速生成 SBOM 的場景	對 C/C++ 建置系統的支援較弱
cdxgen (OWASP)	OWASP 官方 SBOM 工具；支援多語言（含 C/C++）；CLI 與 API 雙模式	多語言混合專案；需要 CycloneDX 格式輸出	部分語言支援需要建置環境配合
Trivy (Aqua)	綜合型漏洞掃描器；支援 SBOM 生成 + 漏洞比對 + 容器掃描	DevOps/DevSecOps 團隊；已使用容器的環境	SBOM 生成功能為附加能力，深度可能不如專用工具
Dependency-Track (OWASP)	SBOM 管理平台；匯入 SBOM 後持續比對漏洞；支援政策引擎	需要 SBOM 全生命週期管理的企業環境	本身不生成 SBOM，需搭配上述生成工具使用

5.2 商業工具

工具	特色	適用情境	注意事項
Snyk	開發者友善的 SCA 平台；IDE 整合強；自動修補建議	開發團隊導向、注重 shift-left 的組織	部分高階功能需企業版授權
Black Duck (Synopsys)	企業級 SCA 平台；binary analysis 能力強；授權合規功能完整	嵌入式 / C/C++ 產品；需要 binary 掃描的場景	授權費用較高；導入週期較長
Mend.io (原 WhiteSource)	自動化程度高；授權合規 + 漏洞管理一體化	中大型企業；多產品線管理	需評估與現有 CI/CD 的整合複雜度
Sonatype Lifecycle	政策管理導向；與 Nexus Repository 深度整合	已使用 Nexus 的 Java/Maven 團隊	對非 Java 生態的支援需評估

提醒：工具是手段，不是目的。選型前請先釐清：(1) 您需要解決的是「產出 SBOM」還是「持續管理 SBOM」；(2) 您的產品主要使用哪些程式語言與建置系統；(3) 您面對的法規要求哪些格式與深度。基於這三個答案做的選擇，通常比追逐市場熱門工具更務實。
 

六、風險管理視角：SBOM 建置的常見風險與管理措施

	風險面向	潛在影響	建議管理措施
1	SBOM 不完整	遺漏的元件成為漏洞管理缺口；無法準確判斷通報義務是否觸發	以工具掃描為主、人工審查為輔；確認涵蓋間接依賴
2	格式不符法規要求	客戶或監管機關無法接受；需要重新製作	確認輸出支援 SPDX/CycloneDX；建議同時產出兩種格式
3	SBOM 過時	版本更新後 SBOM 與實際產品不一致；漏洞比對結果不可靠	將 SBOM 產出整合至 CI/CD；建立版本追溯機制
4	工具選型不當	工具無法正確掃描產品的程式語言/建置系統；投入效益不佳	以實際產品程式碼做 PoC；不僅憑規格表決策
5	內部缺乏 SBOM 解讀能力	產出了 SBOM 但團隊不知道如何用它來支撐漏洞管理	搭配漏洞比對訓練；先從委外服務學習方法論再內建

 

七、建議導入路徑

階段	時間參考	行動	產出	決策點
Phase 1	第 1–2 個月	選擇 1–2 個主力產品，委外執行 SCA 掃描，取得第一版 SBOM 與漏洞分析報告	SBOM + 漏洞報告	評估內部準備程度
Phase 2	第 2–3 個月	根據產品語言/建置系統，選擇 2–3 個候選工具做 PoC	PoC 比較報告	是否導入工具/選哪個
Phase 3	第 3–5 個月	將選定工具整合至 CI/CD；建立 SBOM 版本管理與漏洞比對流程	CI/CD 自動 SBOM	覆蓋率與準確率驗證
Phase 4	第 5–6 個月	擴展到全產品線；建立 SBOM 管理政策（更新頻率、保存期限、交付流程）	SBOM 管理政策文件	持續優化與擴展

 

八、DEKRA Onward Security 服務對照

以下對照表說明在 SBOM 建置與工具選型的不同階段，DEKRA 可以提供的協助：

您的階段 / 需求	DEKRA 可提供的服務	服務效果
需要第一版 SBOM	SBOM 建置服務：SCA 掃描 + CycloneDX/SPDX 格式產出 + 漏洞比對分析	快速取得法規與客戶要求的 SBOM 文件，同時建立基線
不確定現有能力是否足夠	SBOM 成熟度評估：盤點現有 SBOM 管理方式與法規差距	釐清現況、識別缺口、提供工具選型與導入路徑建議
需要工具選型協助	工具選型顧問：根據您的產品技術棧與法規需求，規劃候選工具清單並協助 PoC	基於實際產品的驗證結果做決策，避免選型失誤
需要持續漏洞監控	漏洞情報監控服務（訂閱制）：基於 SBOM 持續比對 NVD/OSV	在新 CVE 揭露時即時通知，支撐 CRA 通報與 CSMS 監控要求
需要跨法規合規規劃	CRA / FDA / R155 合規差距分析：跨法規盤點 SBOM 與產品安全缺口	一次盤點、統一策略，最大化合規投入效益

DEKRA Onward Security 的優勢：同時具備 CRA（歐盟）、IEC 62443（工控/車用）、FDA 合規經驗的第三方機構。我們不銷售特定 SBOM 工具，而是以法規合規為出發點，協助您選擇最適合的方案——無論是委外服務、工具導入或兩者並行。
  參考資料
1. European Commission, Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I.
2. ENISA, SBOM Landscape Analysis — Towards an Implementation Guide, December 2025.
3. U.S. FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, 2023.
4. UNECE, UN Regulation No. 155 — Cyber Security and Cyber Security Management System.
5. UNECE, UN Regulation No. 156 — Software Update and Software Update Management System.
6. NTIA, The Minimum Elements for a Software Bill of Materials, 2021.
7. OWASP, Advisory on SBOM Implementation for Vulnerability Management, February 2025.
8. OWASP, CycloneDX Specification, https://cyclonedx.org/specification/overview/
9. Linux Foundation, SPDX Specification (ISO/IEC 5962), https://spdx.dev/
───────────────────────────────────────────
CRA 合規系列文章導覽
第一篇至第三篇建立問題意識與產品安全設計方向。從第四篇開始，進入 CRA 合規的具體操作指引。
第一篇：從波蘭能源攻擊事件看台灣製造商的產品安全缺口與 CRA 合規策略
第二篇：從波蘭能源攻擊事件看 OT 資產擁有者的六項優先行動
第三篇：CRA 來了，你的產品規格準備好了嗎？——PM/RD 的安全規格變更清單

▼ 從問題意識到合規操作 ▼
第四篇：CRA 第一階段通報合規準備（高層版 + 執行版）
第五篇(本篇)：SBOM 建置與工具選擇（高層版 + 執行版）
第六篇：弱點管理政策與合規框架（高層版 + 執行版）
第七篇：弱點管理全流程實務指引（高層版 + 執行版）
───────────────────────────────────────────