SBOM 怎麼驗收？拿到清單先查 5 個欄位

這篇文章回顧的是2026年10月7日，由張饒輝（Lightman Chang）在 APPI News 發表的 SBOM 驗收整理。它本來是寫給企業採購與資安人員看的，不過裡頭「拿到一份長清單，怎麼快速判斷能不能用」的方法，其實和我們平常讀健康資訊、核對檢查報告的思路很像。這次把它翻成白話，順便聊聊核對文件核到眼睛痠的你。

SBOM 是什麼？先給一句白話解釋

SBOM（Software Bill of Materials，軟體物料清單）是一份機器可讀的紀錄，列出軟體產品裡用了哪些元件、誰提供的、彼此怎麼相依。你可以把它想成軟體的「成分表」，就像食品包裝上會寫原料一樣。差別在於這份成分表要能被工具讀取、比對、更新，而不是一張只給人看的 PDF。

來源文章把驗收重點收斂成幾個欄位，以下依該文整理。

先確認清單對應哪個產品版本

第一關是「這份清單能不能對回實際交付物」。產品名稱相同，但版本、建置編號不同，裡面的元件可能完全不同。來源引用 NTIA（美國國家電信與資訊管理局）的 SBOM 最低元素報告，把供應者、元件名稱、元件版本、唯一識別碼、相依關係、SBOM 作者與時間戳記列為基本欄位。

作者建議的最小驗收組合有五項：

一、產品與版本：確認產品名稱、版本、建置或發布識別。缺少時，你不知道清單對應哪個交付物。

二、元件名稱與版本：直接與間接相依元件都要列。漏洞通知來的時候，這是比對的基礎。

三、供應者：元件由誰維護。沒有這欄，出事時不知道修補資訊該找誰。

四、唯一識別碼：例如 PURL、CPE 或雜湊值。同名套件可能被誤認成同一個元件，識別碼能避免這種錯配。

五、相依關係：產品、直接相依、間接相依怎麼連接。只有清單沒有連結關係，漏洞爆發時追不到受影響範圍。

NTIA 是美國商務部下轄機構，這份最低元素報告屬於官方文件層級的參考，不是單一廠商的說法。不過來源也提醒，欄位越多不等於清單一定完整，仍要對照版本與實際部署內容。

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

SPDX 和 CycloneDX 是兩種常見的 SBOM 格式。來源指出，SPDX 目前規格為 3.0，也是 ISO/IEC 5962:2021 國際開放標準；CycloneDX 則把元件、服務、相依關係放進結構化模型。

實務上的驗收底線是：可以接受 JSON、XML 等機器可讀格式，但不宜只收 PDF、圖片或人工整理的試算表。同一家公司用不同工具產出的檔案，也不能只因副檔名相同就視為合格。

相依關係是容易漏掉的地方。來源引 CycloneDX 的使用案例提醒一件事值得記住：沒被放進相依圖的元件，不能直接當成「沒有相依」，它可能只是資料還沒確認。驗收時可以要求供應商說明哪些項目尚未確認、原因為何，讓你知道那是資料缺口還是有意省略。

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

來源整理 SPDX 官方的處理邏輯：產品建置時產生 SBOM，之後若元件出現漏洞，就確認產品影響、整合修補版本、重新發布產品與新版 SBOM；若判定不受影響，也要留下原因。

所以採購方不能只問「有沒有 SBOM」，來源建議還要問四件事：新版產品或元件更新後，多久提供新版 SBOM；清單有錯時怎麼更正、新舊版怎麼區分；漏洞公告出現時由哪個窗口確認受影響版本；以及供應商的後續配合方式。這幾點在來源文章中均有列出，細節可回原文查閱。

讀完這份清單的你，也順便核對一下自己

講完文件，想聊聊核對文件的人。這種逐欄比對的工作，往往一坐下來就是好幾個小時，而且出錯的代價不低，壓力自然跟著來。

如果你今天正好要驗收這類文件，可以給自己幾個小提醒。核對到視線開始飄、字會浮起來的時候，起來倒杯水、看窗外幾分鐘，比硬撐著多看十頁更有效。需要連續比對長清單時，每隔一段時間刻意抬頭看遠處，讓眼睛的對焦肌肉換個姿勢。這些做法和我們在長時間對著試算表工作的眼睛照顧裡聊過的原則是同一套。

另外，判斷「資料缺口」和「有意省略」需要清醒的腦袋。如果你正在趕截止期限熬夜核對，跟熬夜追系統更新的工程師處境類似，我們在追版本與熬夜編譯時的照顧方式裡整理過一些做法可以參考。重點不是不能熬夜，而是知道自己的判斷力會隨疲勞下降，重要結論留到精神好的時候再確認一次。

結語

這篇文章依據的是單一來源的整理，格式與欄位細節建議回到 SPDX、CycloneDX 與 NTIA 的官方文件核對。它的價值在於提供一個可操作的起點：先對產品版本，再查元件、供應者、識別碼與相依關係，最後問清楚更新與更正的責任。文件驗得完整，晚上才睡得安穩，這大概是資安工作和健康生活最實際的交集。