SBOM 品質檢查清單：如何驗證供應商提供的 SBOM

SBOM 品質的三個層面

層面	問題	由什麼檢查	它無法告訴您什麼
有效	檔案能否解析，是否符合其宣告的格式與版本的 schema？	Schema 驗證工具	任何欄位是否填入了有用的內容
可用	您需要的欄位是否存在，工具能否使用它們：能與資安公告比對的識別碼、授權、雜湊值、相依關係？	欄位檢查、合規設定檔與品質分數	檔案中遺漏了什麼
完整	它是否列出您所收到軟體中的所有內容？	與建置比對，或與交付的二進位檔分析結果比對	任何只讀取 SBOM 的工具都無法回答這個問題

大多數接收方團隊只做到第一層。「檔案通過驗證」只是檢查的開始，而不是結果。第三層就是 SBOM 完整性。

一分鐘了解各框架

請在每一次要求與每一則回饋中寫明框架名稱，讓標準來自公開發布的文件，而不是您個人的意見。

• NTIA，The Minimum Elements for a Software Bill of Materials （2021 年 7 月 12 日）。七個資料欄位（供應商名稱、元件名稱、版本、其他唯一識別碼、相依關係、SBOM 資料作者、時間戳記）、以 SPDX、CycloneDX 或 SWID 標籤支援自動化，以及各項實務：頻率、深度、已知的未知、散布與交付、存取控制、錯誤的容許。雜湊值、授權、生命週期階段與簽章則列為建議項目，超出最低要求。
• CISA，2026 Minimum Elements for a Software Bill of Materials （2026 年 7 月 29 日，草案於 2025 年 8 月 22 日發布）。取代 NTIA 要素。由來自 14 個國家的 18 個組織共同撰寫，包括 CISA、NSA、FBI、德國 BSI，以及日本 METI 與 NCO。它有 17 個資料欄位，其中十個是新增的：SBOM 作者簽章、資料格式名稱、資料格式版本、產生情境、工具名稱、工具版本、SBOM 版本、元件雜湊值、元件雜湊演算法與元件授權。「Supplier name」改為「Component Producer」。其實務包括涵蓋範圍、明確標示未知資訊、機器可處理的資料、更新的容許、頻率，以及散布與交付。文件中每項要素都以「should」表述，並表明不會產生新的要求；買方須將其寫入合約才具約束力。
• BSI，TR-03183-2 2.1.0 版（2025 年 8 月 20 日），德國。三者中最嚴格的一份，以 MUST 撰寫：JSON 或 XML、CycloneDX 1.6 以上或 SPDX 3.0.1 以上、每個軟體版本一份 SBOM、遞迴解析相依關係並註明每份相依清單的完整性、每個可部署元件的 SHA-512 雜湊值、元件檔名、以 SPDX 識別碼表示的散布授權，以及「若存在」的 package URL 或 CPE。它也規定 SBOM 不得包含漏洞資訊；這類資訊應放在 VEX 文件或資安公告中。
• 國際協調。 A Shared Vision of SBOM for Cybersecurity （2025 年 9 月 3 日）由來自 15 個國家的 18 個組織簽署。G7 的 SBOM 工作聚焦於 AI 系統（「A shared G7 vision on SBOM for AI」，2025 年；以及「SBOM for AI – Minimum Elements」，2026 年 5 月），並未對嵌入式供應商 SBOM 設定任何要求。
• 汽車產業。Auto-ISAC 於 2025 年 2 月 11 日發布了 SBOM Informational Report。

檢查清單

表格閱讀方式：必要表示文件中規定必須做到。最低要素表示列於該文件的最低清單中（NTIA 的基準，或 CISA 的「should」要素）。建議表示文件將其列於最低要求之外。未提及表示文件並未要求。各項檢查的測試方式與應寄出的回饋文字，請見下一節。

SBOM 層級檢查

檢查項目	為何重要	NTIA 2021	CISA 2026	BSI TR-03183-2
1. 可解析，並通過其宣告 schema 的驗證	您的工具無法讀取的檔案就不算 SBOM	必要：SPDX、CycloneDX 或 SWID 標籤	實務：機器可處理的 SPDX 或 CycloneDX	必要：JSON 或 XML
2. 規格版本符合您的最低要求	舊版本無法承載您需要的欄位	未提及	最低要素：資料格式名稱與版本；避免使用已淘汰的版本	必要：CycloneDX 1.6+ 或 SPDX 3.0.1+
3. SBOM 作者	有人為內容負責	最低要素：「Author of SBOM Data」	最低要素：「SBOM Author」，指組織而非工具	必要：「Creator of the SBOM」，電子郵件或 URL
4. 時間戳記	讓您知道哪一份 SBOM 是最新的	最低要素	最低要素	必要；建議使用 UTC
5. 工具名稱與版本	讓您知道這份 SBOM 可信賴的涵蓋範圍	未提及	最低要素	未提及
6. 產生情境	同一版本的原始碼掃描與建置紀錄並不相同	建議：生命週期階段（「source」、「build」、「post-build」）	最低要素：「before build」、「build」或「after build」	無此欄位；內容必須與建置期間可取得的內容一致
7. SBOM 版本或序號	區分更正版與原始版	未提及	最低要素：「SBOM Version」	格式有此欄位時為必要：「SBOM-URI」
8. 作者簽章	證明檔案來自供應商且未經變更	建議：鼓勵簽署	最低要素：「SBOM Author Signature」	僅供參考：「理想上」應簽署
9. 最上層元件與您收到的內容一致	錯誤版本的 SBOM 比沒有更糟	最低要素：主要元件	最低要素：目標元件	必要：主要元件，即樹狀結構的根

元件層級檢查

檢查項目	為何重要	NTIA 2021	CISA 2026	BSI TR-03183-2
10. 元件名稱	每一次比對最先使用的資訊	最低要素	最低要素	必要；若無名稱則使用檔名
11. 版本：不得為 latest、unknown 或空值	資安公告適用於版本範圍	最低要素	最低要素；若未知須註明	必要；若無版本則使用檔案日期
12. 製作者或供應商	區分同名的兩個元件，並指出由誰負責修正	最低要素：「Supplier Name」	最低要素：「Component Producer」	必要：「Component creator」，電子郵件或 URL
13. 生態系有 package URL 時一律提供，沒有時改用 CPE；兩者格式皆須正確	沒有識別碼（package URL、CPE），就無法與任何漏洞資料庫比對	最低要素：「Other Unique Identifiers」，例如 CPE、SWID 或 PURL（若存在）	最低要素：至少一個識別碼，例如 CPE 或 PURL；應全部列出	若存在則為必要：CPE 或 purl
14. 雜湊值與演算法，且與您收到的檔案一致	證明這份 SBOM 描述的就是這個二進位檔	建議	最低要素：可執行建置產物的雜湊值，使用 NIST 等主管機關核可的演算法	必要：可部署元件的 SHA-512
15. 以 SPDX 識別碼或運算式表示的授權，不得一律填 NOASSERTION	您的授權專家據此判斷 copyleft 及其他義務	建議	最低要素；盡可能使用 SPDX 識別碼	必要：散布授權，優先使用 SPDX 識別碼
16. 相依關係，以及清單是否完整	顯示是什麼拉入了有漏洞的套件，以及缺口是否可信	最低要素；須說明直接相依套件是否已完整列出	最低要素	必要，並須註明每份清單的完整性
17. 檔名	將項目對應到裝置上的檔案	未提及	未提及	必要
18. 可執行檔、封存檔與結構化屬性	說明每個元件屬於哪一類檔案	未提及	未提及	必要

涵蓋範圍檢查

檢查項目	為何重要	NTIA 2021	CISA 2026	BSI TR-03183-2
19. 涵蓋遞移深度，而不只是最上層	大多數有漏洞的程式碼都是間接引入的	最上層為必要；遞移相依套件為建議	涵蓋範圍實務：納入遞移相依套件；未規定最低深度	必要：遞迴解析
20. 註明已知的未知	註明自身缺口的 SBOM，其列出的內容才值得信賴	必要實務	實務：標示未知與保留的資訊	透過完整性聲明列為必要
21. 每個交付的軟體版本一份 SBOM	重要的是您實際執行的版本	必要：每次建置或版本發布都產生新的 SBOM	實務：頻率	必要
22. 以新的 SBOM 送出更正	默默修正的錯誤無法追溯	實務：錯誤的容許	實務：更新的容許	必要：更正錯誤時提供更新的 SBOM
23. 合理性：沒有重複項目、元件數量符合產品規模、Linux 裝置須包含作業系統套件	檢驗完整性最省成本的方法	未提及	涵蓋範圍實務：多個實例須分別列出	多個實例必須分別列出

如何測試各項檢查，以及該告訴供應商什麼

檢查項目	如何自動測試	給供應商的回饋文字
1、2. Schema 與規格版本	使用適用於所宣告格式與版本的 schema 驗證工具；接著將 specVersion（CycloneDX）或 SPDX 版本與您的最低要求比對	「此檔案在所列路徑上未通過 CycloneDX 1.6 的 schema 驗證。請使用產生工具重新產生，並在寄送前完成驗證。」
3 至 7. 作者、時間戳記、工具、情境、版本	必要的中繼資料皆存在：CycloneDX 中的 metadata.authors、metadata.timestamp、metadata.tools、metadata.lifecycles、serialNumber 與 version；SPDX 中的建立資訊	「此 SBOM 未註明產生它的工具，也未註明產生情境。兩者皆為 CISA 2026 Minimum Elements。」
8. 簽章	簽章存在，且能以供應商公布的金鑰驗證	「請依 CISA 2026 要素 SBOM Author Signature 的說明簽署 SBOM，或另附分離式簽章。」
9. 最上層元件	metadata.component（CycloneDX）或所描述的根元素（SPDX）的名稱與版本，與您收到的料號及軟體版本一致	「此 SBOM 描述的是 5.2.0 版；我們收到的是 5.3.0 版。請提供 5.3.0 版的 SBOM。」
10、11. 名稱與版本	沒有空白名稱；除非宣告為未知，否則版本不得為空值、latest 或 unknown	「有 14 個元件沒有版本。請提供確切版本，或將其標示為未知。」
12. 製作者	每個元件都有供應商、製造商或作者	「元件缺少製作者資訊，而這是 CISA 2026 要素 Component Producer 所要求的。」
13. 識別碼	每個 purl 都能以符合 ECMA-427 的 package URL 函式庫解析；每個 CPE 都符合 CPE 2.3 語法，且存在於 NVD CPE 字典中	「沒有任何元件具備 package URL 或 CPE，因此無法與漏洞資料庫比對。請為每個來自套件管理工具的套件加上 purl。」
14. 雜湊值	每個可部署元件都有 SHA-512 項目；對您收到的檔案計算 sha512sum 並比對	「此 SBOM 沒有雜湊值。BSI TR-03183-2 要求提供每個可部署元件的 SHA-512。」
15. 授權	授權 ID 或運算式能對應到 SPDX 授權清單；統計 NOASSERTION 與空值的數量	「92% 的元件授權為 NOASSERTION。請提供 SPDX 授權識別碼。」
16. 相依關係	dependencies 圖（CycloneDX）或相依關係（SPDX）；完整性聲明，例如 CycloneDX 的 compositions 並附上 aggregate 值	「此 SBOM 是扁平清單。請納入相依關係，並註明每份清單是否完整。」
17、18. 檔名與檔案屬性	BSI TR-03183-2 為各格式定義的屬性皆存在	「請依 BSI TR-03183-2 v2.1.0 的要求，加入檔名以及可執行檔、封存檔與結構化屬性。」
19 至 23. 涵蓋範圍	相依關係圖的深度、重複項目偵測、與同類產品比較元件數量、依產品類型檢查預期元件	「這份 Linux 顯示器的 SBOM 未列出 kernel、bootloader 或基礎系統套件。請提供完整映像檔的 SBOM。」

回饋文字中的百分比與數量僅為範例。請填入實際數字，並每次都寫明框架名稱與版本。

即使分數及格，仍會漏掉什麼

一個檔案可能通過驗證、拿到 10 分中的 9 分，卻仍然漏掉半個產品。品質分數讀取的是存在的欄位，看不到不存在的元件。

實例說明。某供應商寄來一台 Linux 顯示器的 SBOM。它是有效的 CycloneDX 1.6，每個元件都有版本、package URL、授權與 SHA-512 雜湊值，相依關係圖的格式也正確。它列出了顯示器應用程式與 40 個函式庫，卻沒有列出 Linux kernel、bootloader 或任何基礎系統套件。每一項欄位檢查都通過了。但由於 kernel 不在其中，這份 SBOM 對 kernel CVE 毫無用處，而 Linux 裝置正必須監控這些 CVE。

接收方團隊可以這樣檢驗完整性：

• 與交付韌體的二進位分析結果比對。有些 OEM 會在供應商的 SBOM 品質達標之前，先以二進位分析作為替代 SBOM，之後再用它交叉比對。
• 依產品類型檢查預期應有的元件。Linux 映像檔會有 kernel、C 函式庫與 init 系統；工業控制器則有其通訊協定堆疊。
• 詢問產生情境與工具。原始碼掃描看不到建置擷取了什麼。
• 詢問 SBOM 是否來自產出您所收到軟體的那次建置。這正是決定第三層的關鍵問題。

SBOM 規模小也可能是合理的。一個採用專有韌體與廠商校準資料的 bare-metal ECU，確實可能只有兩個元件。只要 SBOM 如實說明並註明其已知的未知，就應接受，而不是因為規模小而扣分。

可自動執行檢查的工具

於 2026 年 11 月 11 日在 GitHub 上確認。這些儲存庫皆未封存。

工具	檢查內容	不檢查的內容	狀態
CycloneDX CLI	CycloneDX 1.0 至 1.7（JSON 或 XML）的 schema 驗證；--fail-on-errors 適用於 CI	SPDX、欄位品質、框架設定檔	v0.33.1，2026 年 7 月
sbom-utility	CycloneDX 1.2 至 1.7 與 SPDX 2.1 至 2.3 JSON 的 schema 驗證，支援自訂 schema 變體	SPDX 3、XML、框架設定檔	v0.19.2，2026 年 6 月
SPDX tools-java	適用於 SPDX 2.0 至 2.3 與 3.0.1 的 Verify	CycloneDX、框架設定檔	v2.0.7，2026 年 6 月
SPDX tools-python	pyspdxtools -i：SPDX 2.2 與 2.3 的完整驗證	讀取 SPDX 3（相關支援仍屬實驗性質）	v0.8.5，2026 年 3 月
SPDX NTIA Conformance Checker	依 NTIA 2021、CISA FSCT3 與 BSI TR-03183-2 v2.1.0 檢查 SPDX 2.2、2.3 與 3.0；另有網頁版	CycloneDX；CISA 2026 仍為待處理的功能需求	v6.0.0，2026 年 10 月
sbomqs	涵蓋識別、來源、完整性（integrity）、完整度、授權、漏洞與結構的 0 至 10 分 score；適用於 CISA 2026、NTIA 2021、BSI TR-03183-2 v1.1 至 v2.1.0、FSCT v3 與 OpenChain Telco 的 compliance 設定檔	看出遺漏的元件	v2.1.3，2026 年 10 月；CISA 2026 設定檔自 v2.1.0 起提供，於 v2.1.2 修正
sbom-scorecard	針對規格符合度、產生資訊，以及套件識別碼、版本與授權的加權分數	框架設定檔	0.0.7，2023 年 4 月，最後一個版本

目前只有 sbomqs 能檢查 CISA 2026 Minimum Elements。仰賴某個設定檔之前，請先查看各工具的版本說明：在 sbomqs 2.1.1 中，CISA 2026 旗標誤執行了 2021 年的檢查。在 sbomqs 中檢查 BSI TR-03183-2 v2.1.0 時，請使用 --bsi-v21 或 --bsi；--bsi-v2 檢查的是 v2.0.0。

針對供應商 CycloneDX SBOM 的最簡接收步驟：

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

若為 SPDX，請使用 NTIA Conformance Checker 的 sbomcheck -s spdx3 -c bsi supplier-sbom.json。閱讀合規報告，凡未通過您要求中列為強制之檢查的檔案即予退回，並附上前述回饋文字交還供應商。

寫入供應商要求

供應商從未看過的檢查清單不算要求。請將它放進合約附件：

• 框架與版本：例如「BSI TR-03183-2 v2.1.0」或「CISA 2026 Minimum Elements」。請指定其中一個，不要寫「業界標準」。
• 格式與最低規格版本：例如 CycloneDX 1.6 以上或 SPDX 3.0.1 以上，JSON 格式。
• 您額外要求的欄位，例如每個套件的 SHA-512 雜湊值或 package URL。
• 交付：每個交付的軟體版本一份 SBOM，在軟體交付之前或同時提供。
• 供應商寄送前須執行的驗證，寫明工具與設定檔名稱。
• 回饋流程：由誰接收回饋，以及更正後的 SBOM 須在多久內提供。

同一份協議中供應商那一方的內容，請參閱供應商 SBOM 指南。若您是回應單次要求的軟體廠商，請參閱客戶 SBOM 要求。

修正未通過的 SBOM（供應商適用）

• 手寫的檔案。請使用產生工具或 SBOM 函式庫，絕不要用文字編輯器。
• 缺少 package URL。請從套件管理工具或建置產生，而不是手動填寫。手動輸入的 purl 就是猜測的 purl。
• 缺少授權。從套件中繼資料取得宣告的授權，並以 SPDX 識別碼表示。
• 沒有雜湊值。在建置結束時，針對您實際交付的檔案計算雜湊值。
• 版本錯誤。在發布建置中產生 SBOM，並以版本命名。
• 只有最上層。使用能解析遞移相依套件的方法。

要同時解決完整性與識別碼問題，最可靠的方式是從產出交付軟體的那次建置產生 SBOM。請參閱建置時 SBOM與 SBOM 最佳實務。

好的 SBOM 從哪裡來，以及 CRACI 的定位

對於在 GitHub Actions 上建置的供應商，CRACI 取代 GitHub 託管執行器，並在建置期間記錄 SBOM，因此它列出的是建置實際拉入的內容。

• 每個套件都附有 package URL，每個元件都附有其宣告的授權。
• 遞移相依套件，涵蓋建置所觸及的每一層深度。
• 每個作業都有完整性狀態，逐次建置回答已知的未知問題：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。
• 以 CycloneDX 或 SPDX 匯出；SBOM API 會回傳 CycloneDX 1.7 JSON。

若是整個工程組織，請參閱標準化 SBOM 產生；若是嵌入式 Linux，請參閱為什麼掃描器會漏掉 Yocto 建置中的內容。

對 OEM 而言，第三方 SBOM 可以加入 CRACI，讓您採購的元件與您自己的建置一起接受新漏洞監控。比較方式請參閱SBOM 管理工具。

CRACI 不適用的情況

• 驗證您收到的 SBOM 並評分。CRACI 不提供 SBOM 驗證工具或品質分數。請使用上述工具。
• 沒有 CI 的供應商，或程式碼由模型式工具產生、不擷取任何套件的供應商。建置紀錄工具的幫助有限；由產生工具函式庫產出並經驗證的 SBOM 才是務實的解法。
• 只以二進位檔形式收到的韌體。這要靠二進位分析來解決。
• 已簽署的 SBOM，也就是 CISA 2026 的作者簽章。CRACI 不會簽署 SBOM。

SBOM 品質與驗證：常見問題

如何檢查供應商寄來的 SBOM 品質？

測試三個層面。依 schema 驗證檔案，依 BSI TR-03183-2 或 CISA 2026 Minimum Elements 等指定框架檢查欄位，再檢驗完整性：將它與您所收到內容的二進位分析結果比對，並檢查該產品類型必須包含的元件。

SBOM 必須包含哪些欄位？

這取決於您指定的框架。CISA 2026 Minimum Elements 列出 17 個欄位，包括作者、時間戳記、工具、產生情境，以及每個元件的名稱、版本、製作者、識別碼、雜湊值與授權。BSI TR-03183-2 另外加入 SHA-512 雜湊值、檔名與檔案屬性，並將其列為必要。

NTIA 最低要素與 CISA 2026 Minimum Elements 之間有什麼變化？

CISA 2026 清單將 NTIA 的七個欄位擴充為 17 個。新增的有作者簽章、資料格式名稱與版本、產生情境、工具名稱與版本、SBOM 版本、元件雜湊值與演算法，以及元件授權。Supplier name 改為 Component Producer，深度則改為涵蓋範圍。

BSI TR-03183-2 對 SBOM 有哪些要求？

2.1.0 版要求使用 JSON 或 XML 格式的 CycloneDX 1.6+ 或 SPDX 3.0.1+、每個軟體版本一份 SBOM、遞迴相依關係並註明其完整性，以及每個元件的建立者、名稱、版本、檔名、授權、SHA-512 雜湊值與檔案屬性，若存在 package URL 或 CPE 也須提供。

SBOM 需要雜湊值嗎？該用哪種演算法？

NTIA 將其列為建議；CISA 2026 將雜湊值列為最低要素，並要求使用 NIST 等主管機關核可的演算法；BSI TR-03183-2 要求每個可部署元件的 SHA-512。請要求提供 SHA-512，並與您收到的檔案比對。

CPE 與 PURL 都需要嗎？

不一定。生態系有 package URL 時一律要求提供，沒有時（例如許多商用或嵌入式元件）則要求 CPE。CISA 2026 要求至少一個識別碼，並列出所有已知的識別碼；BSI 則要求存在的每一種都須提供。

如何驗證 CycloneDX 或 SPDX 檔案？

CycloneDX 可使用搭配 --fail-on-errors 的 cyclonedx-cli validate，或 sbom-utility。SPDX 可使用 SPDX tools-java 的 Verify 指令，SPDX 2.2 與 2.3 則可使用 pyspdxtools。接著再以 sbomqs 或 SPDX NTIA Conformance Checker 執行框架設定檔。

怎樣才算好的 SBOM 品質分數？

沒有標準門檻，也沒有我們願意引用的基準。分數衡量的是存在的欄位，而不是完整性：一個檔案可能拿到 10 分中的 9 分，卻漏掉半個產品。請改在供應商要求中為每項檢查設定通過標準，並將分數當作趨勢追蹤。