收到 SBOM 別急著歸檔：五個欄位對得上，漏洞來時才派得上用場

SBOM 是軟體的成分表，但成分表要對得回交付物的版本、元件、供應者、識別碼與相依關係，漏洞公告出現的那一天，它才接得上影響判斷與修補責任。

供應商交貨那天，郵件附件多了一個 JSON 檔，信件主旨寫著「SBOM 如附」。多數組織的處理方式差不多：確認檔案在，歸檔，結案。真正的考題要等幾個月後才會出現。某個開源元件爆出重大漏洞，資安團隊得在一天之內回答三個問題：公司哪些產品用了它、中獎的是哪些版本、修補資訊該找誰。到那個時候，歸檔的 JSON 只有兩種命運：查得出答案，或者淪為當初結案的裝飾品。

先把名詞講清楚。SBOM，Software Bill of Materials，軟體物料清單，把一個軟體產品用了哪些元件、每個元件由誰提供、彼此怎麼連接，寫成機器可讀的紀錄。功能接近食品包裝上的成分表。

成分表要是只寫「食物」，等於沒寫

食品成分表的價值在過敏原警示。某批花生原料出了問題，廠商靠成分表回頭清查哪些產品中標；成分表如果只寫「食物」兩個字，這套機制就整組失效。

軟體的處境相同。現代軟體極少從零寫起，作業系統套件、開源框架、第三方函式庫、容器映像層層疊上來。拿開源管理框架當底、再包一層自家前端的組裝方式，在企業系統裡早已是常態，開發者為若依後端配上現代化前端就是同一種組裝邏輯的產物：產品最終的組成，和任何單一專案首頁寫的內容都對不上。也因為這樣，當某個被廣泛使用的元件爆出漏洞，影響會沿著相依關係往外擴，「我們有沒有中獎」這個問題，靠的就是一份經得起對照的成分表。

美國國家電信與資訊管理局（NTIA）的 SBOM 最低元素報告，把資料欄位、自動化支援，以及產製、交付、更新的流程列成三大類，是目前企業建立驗收表時最常被引用的底線。

五個欄位，先對再說

拿到清單的第一個問題，是這份檔案對應哪一個實際交付物。產品名稱相同，版本、建置編號、作業系統套件或容器映像不同，內含的元件就可能不同。實務上可以把五個欄位視為最小驗收組合：

• 產品與版本：產品名稱、版本、建置或發布識別。少了它，你不知道清單對應哪個交付物。
• 元件名稱與版本：直接相依與間接相依的名稱和版本都要在場，漏洞通知來的時候，比對全靠這一欄。
• 供應者：元件由誰維護或提供。修補資訊該找誰，答案在這裡。
• 唯一識別碼：PURL、CPE、雜湊值，或格式支援的其他識別。網路上同名的開源專案不只一個，少了唯一識別碼，兩個同名的套件會被誤認成同一個東西。
• 相依關係：產品本身、直接相依、間接相依之間怎麼連接。只有名冊、沒有連線圖，追不出受影響範圍。

NTIA 的最低元素把供應者、元件名稱、元件版本、唯一識別碼、相依關係、SBOM 作者與時間戳記列為基本資料欄位，並要求清單支援自動產製、採機器可讀格式。欄位數量與完整性是兩回事：欄位開得再細，沒有對照實際部署的版本，清單照樣可能在空轉。

機器讀得動，後面的事才成立

格式上，SPDX 與 CycloneDX 是兩大主流的可交換格式。SPDX 官方規格目前列到 3.0，並標示為 ISO/IEC 5962:2021 國際開放標準；CycloneDX 把元件、服務、相依關係與供應鏈資訊放進結構化模型。兩者的規格文件都提供工具可處理的格式定義。

對驗收方的實務意義可以講得直白：收 JSON、XML 這類機器可讀格式，PDF、圖片、人工整理的試算表都不宜當成合格交付物。同一間公司用不同工具產出的檔案也可能長得不同，副檔名相同不代表內容合格。格式選擇、必要欄位、交付位置與驗證方式，都該在需求書裡寫清楚，別等收到檔案再來補。

相依關係是另一個常被輕輕放過的欄位。CycloneDX 的軟體相依使用案例給了幾個具體檢查點：bom-ref 要在同一份清單內保持唯一，PURL 是理想的識別方式，dependsOn 用來連出直接與間接相依。文件裡有一個提醒值得抄進驗收表：沒被放進相依圖的元件，不能直接當成「沒有相依」，它可能只是資料還沒被確認。

驗收時可以要求供應商交出一個簡單的對應結果：產品本身連到哪些直接相依，每個直接相依再連到哪些間接相依，哪些項目尚未確認。清單上出現「未知」，或只列到第一層時，供應商應說明範圍與原因，讓採購方分得清楚那是資料缺口，還是有意省略。

漏洞來的那天，問題才真正開始

SBOM 記錄的是產品在建置或發布當下的組成，漏洞資訊則在之後才變動。SPDX 官方說明給出的順序是：建置時產生 SBOM；之後元件出現漏洞，先確認產品影響；接著整合修補版本，重新發布產品與新版 SBOM；若判定不受影響，也要留下原因。SPDX 3.0 進一步把其中的漏洞處理分成產品元件資料、漏洞資料，以及兩者之間的評估關係。

這條順序在現實裡的樣貌，可以對照近期案例：蘋果修補已遭利用的 CoreGraphics 漏洞時，使用者與企業面對的第一件事，就是確認手上的版本在不在修補範圍。SBOM 的價值，在於把這種版本對帳從人工翻查變成可查詢的資料。

所以採購方不能只問「有沒有 SBOM」。有幾個問題該問在簽約之前：

• 新版產品或元件更新後，多久提供新版 SBOM？
• 發現清單錯誤時怎麼更正，新舊版怎麼區分？
• 漏洞公告出現時，由哪個窗口確認受影響版本？
• 修補版本發布後，新版清單會不會跟著交付？

這些問題指向同一件事：清單的壽命要跟產品一樣長。建置那天產生的檔案，如果產品更新三次之後就沒人再產，它很快就會從成分表退化成過期的歷史文件。

驗收的判準：能不能縮短回答問題的時間

回到開頭那個場景。收到附件當天就下結論，等於把驗收簡化成檔案存在檢查。把五個欄位對一遍、確認格式能被工具讀取、把更新與更正責任寫進合約，這些動作平常看不出差別，差別出現在漏洞公告刷屏的那一天：有準備的團隊對著名單回答範圍與窗口，沒準備的團隊還在會議室裡猜產品裝了什麼。

對多數組織來說，下一步可以很具體：拿 NTIA 最低元素開一張驗收表，把五欄當第一關；格式與交付位置寫進需求書；更新節奏與更正方式寫進合約。清單最後會不會發揮作用，取決於這幾份文件，而非信箱裡那個 JSON 檔本身。

資料來源：本站編輯參考 APPI News〈SBOM 怎麼驗收？拿到清單先查 5 個欄位〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。