拿到 SBOM 後，先核對它對應哪一個產品版本，再查元件名稱與版本、供應者、唯一識別碼、相依關係，以及產製時間和更新責任。缺少這些資料，企業很難在漏洞揭露後確認哪個產品受到影響，也無法把修補工作交給正確的供應商。

SBOM 是軟體元件與供應鏈關係的機器可讀紀錄，功能接近軟體的成分表。先前的 SBOM 原理與台灣政策整理已說明產製、SPDX、CycloneDX 和漏洞比對；這一篇把焦點往後移，處理企業收到檔案後怎麼驗收。NTIA 的 SBOM 最低元素報告則把資料欄位、自動化支援與產製、交付、更新流程列成三大類。

先確認這份檔案對應哪個產品

SBOM 驗收第一關是「能不能對回實際交付物」。產品名稱相同，版本、建置編號、作業系統套件或容器映像不同，裡面的元件也可能不同；NTIA 的最低元素報告把供應者、元件名稱、版本、其他唯一識別碼、相依關係、SBOM 作者與時間戳記列為基本資料欄位。

螢幕顯示軟體元件名稱、版本與相依關係圖
SBOM 的第一個驗收問題，是這份清單是否真的對應交付的產品版本（示意圖）。

我會把下面五欄視為最小驗收組合：

先查的欄位要確認什麼缺少時的實務問題
產品與版本產品名稱、版本、建置或發布識別無法知道清單對應哪個交付物
元件名稱與版本直接、間接相依元件的名稱和版本漏洞通知來時難以比對
供應者元件由誰維護或提供不知道修補資訊該找誰
唯一識別碼PURL、CPE、雜湊或格式可用的其他識別同名套件可能被誤認成同一個元件
相依關係產品、直接相依、間接相依如何連接只能看到清單，追不到受影響範圍

NTIA 報告把供應者、元件名稱、元件版本、唯一識別碼、相依關係、SBOM 作者與時間戳記列為資料欄位，也要求支援自動產製與機器可讀格式。NTIA 最低元素報告可用來建立企業驗收表；欄位越多不等於清單一定完整，仍要對照版本與實際部署內容。

格式要能被工具讀取，相依關係要能追

SPDX 和 CycloneDX 都是可交換的 SBOM 格式。SPDX 官方規格頁目前列出 3.0，並標示 SPDX 為 ISO/IEC 5962:2021 國際開放標準；CycloneDX 官方則把元件、服務、相依關係與供應鏈資訊放進結構化模型。SPDX 規格頁與 CycloneDX 規格總覽都提供可供工具處理的格式資訊。

因此，企業驗收時可以接受 JSON、XML 或其他規格允許的機器可讀格式，但不宜只收 PDF、圖片或人工整理的試算表。格式選擇要寫入需求書，還要同時寫明版本、必要欄位、交付位置與驗證方式；同一家公司用不同工具產出的檔案，也不能只因副檔名相同就視為合格。

電腦螢幕顯示機器可讀的軟體清單資料與程式碼
企業要驗收的是能被工具讀取、比對與更新的資料，不是只適合人工閱讀的附件（示意圖）。

相依關係是第二個常被忽略的地方。CycloneDX 的軟體相依使用案例指出，bom-ref 要在同一份 BOM 內保持唯一，PURL 是理想的識別方式；dependsOn 則用來連出直接與間接相依元件。CycloneDX 相依關係說明也提醒，沒有被放進相依圖的元件不能直接當成「沒有相依」，它可能只是資料尚未確認。

驗收時可要求供應商提供一個簡單的對應結果：產品本身連到哪些直接相依元件、每個直接相依再連到哪些間接相依元件、哪些項目尚未確認。若清單寫著「未知」或只列到第一層，供應商應說明範圍與原因，讓採購方知道這是資料缺口還是有意省略。

有漏洞時，SBOM 要接得上修補判斷

SBOM 是產品在建置或發布時的組成紀錄，漏洞資訊會在後續變動。SPDX 官方說明的處理邏輯是：產品在建置時產生 SBOM，之後若元件出現漏洞，就確認產品影響、整合修補版本、重新發布產品與新版 SBOM；若判定不受影響，也要留下原因。SPDX 3.0 的漏洞資料說明把這條鏈拆成產品元件資料、漏洞資料與兩者的評估關係。

軟體維運團隊核對漏洞通知、產品版本與修補狀態
驗收完成後，清單要能對應漏洞通知、產品影響判斷與修補版本（示意圖）。

所以，採購方不能只問「有沒有 SBOM」，還要問四件事：

  1. 新版產品或元件更新後，多久提供新版 SBOM？
  2. 發現清單錯誤時，供應商怎麼更正，舊版和新版如何區分？
  3. 漏洞公告出現時，由哪個窗口確認受影響版本？
  4. 供應商會提供 VEX 或同等的產品影響聲明嗎？

NTIA 報告把 SBOM 產製頻率、已知未知、交付方式、存取控制與錯誤處理列為實務流程；NTIA 原文可轉成企業的交付與修補條款。這些條件決定清單是一次性交件，還是能在漏洞揭露後持續使用的資料。

台灣現在到哪裡，企業先看契約

台灣目前是政策引導、採購要求與業者實作並行。資通安全署在 2026 年 4 月 29 日表示，已與國家資通安全研究院辦理 SBOM 工作坊，邀請 8 家具產製經驗的資通訊業者交流，並預定在 2026 年下半年發布 SBOM 實務參考指引。資安署新聞稿同時提到，工作坊討論清單元素、流程安排、產品發布後追蹤、漏洞應變與契約合規。

這個政策時程不等於每家台灣企業現在都要交同一種 SBOM。企業真正要先看的文件是採購需求、維運合約、供應商安全條款與目標市場規範；若合約已要求 SPDX、CycloneDX、版本更新或漏洞回應，就依契約逐項驗收，沒有寫清楚的部分則在下一次採購修約時補上。資安署公開資訊目前提供的是推動方向與實務交流，不能拿來代替個案契約的法律判斷。

若驗收對象是聯網醫材，可延伸閱讀台灣醫療器材資安規範與上市要求；那篇處理醫材合規邊界，本文聚焦一般企業軟體的 SBOM 資料驗收。

台灣企業資安人員檢視供應商交付的軟體物料清單與採購條款
台灣企業先把 SBOM 格式、更新期限與漏洞回應窗口寫進採購條件（示意圖）。

對一般使用者來說，最實用的問題是向軟體或設備供應商詢問：目前版本是否有元件清單、漏洞公告去哪裡看、支援期限到哪一天、停止支援後是否仍會提供修補。家庭使用者不一定拿得到完整 SBOM，但可以透過這些問題判斷廠商是否有持續維護的能力；企業採購則應要求可查驗的機器可讀檔案與更新窗口。

我會這樣寫 SBOM 驗收條款

如果要把驗收條件寫成一頁清單，我會分成五組：

  1. 對應版本：寫明產品名稱、版本、建置編號、發布日期，並要求 SBOM 與交付物一對一對應。
  2. 基本欄位：要求元件名稱、版本、供應者、唯一識別碼、相依關係、產製者與時間戳記。
  3. 完整度聲明：要求列出直接和間接相依元件，並分開標示未知、未掃描或刻意省略的部分。
  4. 格式與驗證：指定 SPDX 或 CycloneDX 版本，要求 JSON、XML 或規格支援的機器可讀格式，並約定驗證工具或驗證報告。
  5. 後續責任：寫明產品更新、元件變更、漏洞揭露、錯誤更正、新版 SBOM 交付期限與聯絡窗口。

這五組條款分別對應 NTIA 的資料欄位、涵蓋範圍、已知未知、交付和更新流程，也對應 SPDX 對產品、漏洞與評估關係的拆分方式。NTIA 最低元素報告與 SPDX 漏洞資料說明可作為企業撰寫內規的來源。實務上，先要求供應商交一份可解析的樣本，再把它放進驗收流程，比等到漏洞發生才發現欄位不足更省時間。

常見退件訊號

以下情況出現時，我會先退回補件：

  • 檔案沒有產品版本、建置編號或產製時間，無法確認對應哪一批交付物。
  • 只提供 PDF 或圖片，沒有可被工具解析的格式，也沒有說明如何取得原始 SBOM。
  • 元件只有名稱，沒有版本、供應者或唯一識別碼，無法穩定對應漏洞資料。
  • 只列直接相依元件，沒有說明間接相依的涵蓋範圍或已知未知。
  • 沒有更新頻率、錯誤更正方式和漏洞回應窗口，交付後找不到責任人。

這些退件理由都有對應的規格依據。NTIA 最低元素報告要求基本識別、版本、關係、作者與時間資訊，也說明交付和更新流程；CycloneDX 的相依關係文件要求關係中的識別碼可交叉引用。

SBOM 驗收的結論很明確：先驗證它能不能對應產品，再驗證它能不能追相依關係，最後確認漏洞揭露後誰更新、誰回覆、誰交新版。企業今天可以先從既有供應商合約補上這三層，等台灣實務指引發布後再對照修正，不必把一份只可人工閱讀的附件直接當成完成。

常見問題

SBOM 驗收一定要用 SPDX 或 CycloneDX 嗎？
不一定，應依採購契約、產品需求和工具鏈決定。SPDX 與 CycloneDX 都有公開規格與機器可讀格式，對企業來說，先寫清楚格式版本、必要欄位與驗證方式，比只寫「提供 SBOM」更容易驗收。

SBOM 只有 PDF 可以驗收嗎？
PDF 可以作為人員閱讀的輔助文件，但不宜作為唯一交付物。企業還需要能被工具讀取的原始格式，才能把元件版本、唯一識別碼和相依關係拿去比對漏洞與產品版本。

SBOM 列出有漏洞的套件，產品就一定中標嗎？
不一定。SBOM 先證明產品含有哪些元件，還要由供應商或產品團隊判斷漏洞是否影響實際配置與功能，再決定修補、升級或提出不受影響的說明；SPDX 3.0 將軟體元件資料和漏洞評估關係分開處理。