SBOM 專題 Part 1｜SBOM 是什麼？為什麼客戶突然都在要？

一次搞懂 SBOM 軟體物料清單是什麼

如果你的產品正因為歐盟《網路韌性法案》（CRA）需要準備合規文件，SBOM 只是其中一環；它與 CRA 之間具體的規範關係、規格要求，另有寫專文說明。本篇先幫你釐清 SBOM 這個名詞。

這封信，你是不是也收過

「請提供貴公司產品的 SBOM，作為採購前的資安審查文件之一。」——這句話最近愈來愈常出現在客戶的信箱或稽核表裡。多數工程或業務主管看到時，第一反應往往不是去查該怎麼準備，而是先愣一下：「SBOM？我們是不是漏做了什麼？」

答案通常沒有想像中複雜。SBOM 不是一份需要重新開發才能生出來的東西，而是把「產品裡到底用了哪些軟體元件」這件事，用一份結構化、機器可讀的清單寫清楚。多數廠商其實早已擁有這些資訊——問題只在於有沒有整理成客戶看得懂、系統讀得懂的格式。

SBOM 到底是什麼？

SBOM，全名 Software Bill of Materials（軟體物料清單），概念上很接近食品包裝上的成分標示，或製造業慣用的物料清單（BOM）——只是標示的對象換成了軟體。一份 SBOM 會記錄一項軟體產品裡，用了哪些元件（例如開源函式庫、第三方套件）、各自的版本、來源廠商，以及元件之間的相依關係。

它要解決的問題很具體：當某個被廣泛使用的開源套件被爆出重大漏洞時，廠商能不能在第一時間回答「我的產品裡有沒有用到這個套件？用在哪個版本？」如果答案要靠工程師一個一個翻程式碼、問供應商才能拼湊出來，往往就錯過了黃金應變期。有了 SBOM，這個比對可以在幾分鐘內完成。

為什麼現在幾乎每個客戶都在問？

SBOM 這個詞其實存在多年，但最近一兩年才變成合約裡的常態要求，主要來自三股力量：

• 供應鏈攻擊事件頻傳：近年多起重大資安事件，源頭都不是廠商自己的程式碼出錯，而是深埋在相依鏈底層的一個開源元件出了問題。這類事件讓採購方意識到，光問「你的產品安全嗎」已經不夠，還得問「你的產品裡到底裝了什麼」。
• 法規陸續納入要求：包括美國政府採購體系與歐盟多項數位產品法規，都已經或即將把 SBOM 列為廠商的基本要求之一——這部分我們之後會有專文說明。
• 客戶端稽核流程開始內建這一項：即使不是政府採購，愈來愈多企業買家的供應商資安審查表上，SBOM 已經是必填欄位，而不是加分項目。

一份「用得上」的 SBOM，長什麼樣子？

不是任何一份「軟體清單」都算數。一份能被客戶、稽核單位或掃描工具實際使用的 SBOM，通常需要具備幾個條件：

• 結構化、機器可讀格式：業界最常用的兩種格式是 SPDX（ISO/IEC 5962:2021 國際標準）與 CycloneDX。以 Excel 手動輸入的元件清單，嚴格來說不算 SBOM——重點不是「有沒有列出來」，而是系統能不能自動解析、比對。
• 每個元件至少包含：元件名稱、版本、供應商（或開源專案維護單位），以及與其他元件的相依關係。
• 唯一識別碼：例如 CPE、PURL 或 SWHID，讓每個元件都能被精準對應到漏洞資料庫，而不是靠名稱比對猜測。
• 版本會更新：軟體每次改版、每次新建置，理論上都應該產生對應的新版 SBOM，反映當下實際使用的元件組合。

三個小提醒

一、SBOM 不是簽一次就終身有效的文件。產品只要出新版本、新建置，理論上就該重新產生對應的 SBOM，否則清單很快就會與實際出貨的版本脫節。

二、「有記錄」不等於「有 SBOM」。工程團隊私下維護的相依套件清單，如果不是機器可讀格式、沒有版本與識別碼，離一份合格的 SBOM 還有一段距離。

三、SBOM 需要廠商自己盤點，不能只等上游供應商提供。你的產品用了哪些元件，最終還是由你自己對客戶負責——上游資訊不齊全，正是 SBOM 專案裡最常卡關的地方。

兩個情境，看懂 SBOM 實際能幫上什麼忙

情境一：一封漏洞通知，考驗的是你能不能秒回

某天，資安團隊發出通知：某個被廣泛使用的開源函式庫被爆出重大漏洞。研發主管的第一個念頭是：「我們的產品裡到底有沒有用到這個套件？」沒有 SBOM 的情況下，這個問題往往要靠工程師一個一個翻程式碼、問供應商，可能拖上好幾天才拼湊出答案。手邊有一份結構化的 SBOM，只要跑一次比對，幾分鐘內就能知道哪些產品、哪些版本受影響——應變時間從「以天計」壓縮到「以分鐘計」。

情境二：稽核表上的那一欄，你填不填得出來

海外客戶的資安盡職調查表裡，有一欄問「請提供產品 SBOM」。手上沒有的話，常見的結果是被要求限期補件、拖延整個採購流程，或者直接被記錄為一項風險缺口，影響雙方後續合作的評估分數。反過來，如果能即時附上一份符合 SPDX 或 CycloneDX 格式的 SBOM，稽核往往能順暢許多，也讓客戶對供應鏈治理能力更有信心。

三個常見誤解，一次澄清

誤解一：「SBOM 只是給國防、關鍵基礎設施這種特殊產業用的。」這個印象來自 SBOM 最早被廣泛要求的場景，但現在已經擴散到一般商用產品——只要客戶端有資安採購審查流程，或產品受特定法規約束，就可能被要求提供。

誤解二：「我們的產品沒有用到什麼開源軟體，應該不需要。」SBOM 涵蓋的是「所有」軟體元件，不只是開源套件；自行開發的模組、供應商提供的韌體，只要是產品的一部分，原則上都在盤點範圍內。

誤解三：「做過一次 SBOM，之後就一勞永逸。」SBOM 反映的產品「當下」用了哪些元件？只要產品一改版，舊清單就跟上次版本對不上了。站在客戶端的角度，一份三年前產生、之後從未更新的 SBOM，不但沒啥用處，在資安審查時反而會被視「這家供應商的版本控管有問題」。

準備 SBOM，可以從哪裡開始？

如果目前公司還沒有系統化的 SBOM 產出流程，比較務實的起手式通常是：

• 先盤點：從主力產品線開始，確認目前使用了哪些第三方與開源軟體元件，以及各自的版本。
• 挑工具：依開發語言與生態系選擇合適的 SBOM 產生工具，多數主流語言都已有現成、能輸出 SPDX 或 CycloneDX 格式的工具鏈，不需要從零打造。
• 嵌入流程：把 SBOM 產生步驟接進既有的建置或發版流程，讓每次出新版本時自動更新，而不是等客戶要求才臨時整理。
• 往上游延伸：向核心供應商（尤其是韌體、模組供應商）要求提供元件層級資訊，補齊自己盤點不到的部分。

如果你已經走完前面的盤點，卻不確定該對到哪一種格式、哪一種深度的 SBOM，或是想請專業意見協助覆核，歡迎與我們聯繫，由顧問協助評估個案狀況。

歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結

常見問題

Q：什麼是 SBOM？
SBOM（Software Bill of Materials，軟體物料清單）是記錄軟體產品用了哪些元件、其版本、來源及相互依賴關係的結構化清單。概念上很類似食品包裝上的成分標示。

Q：為什麼現在客戶都在要 SBOM？
三大主要因素：供應鏈攻擊頻傳，讓採購方想知道「產品裡裝了什麼」，法規陸續納入要求、以及企業採購的資訊安全審查表則將 SBOM 列為必填，而非加分項。

Q：SBOM 是否只用於國防及關鍵基礎建設才需要？
不。這種印象來自最早被要求的場景，現在已擴展到一般商業產品，只要顧客有資安採購審查程序，或產品受特定法律規範約束，就可能被要求提供相關資訊。

Q：SBOM 做一次就一勞永逸嗎？
不是。SBOM 反映的是產品「當下」使用的元件，若產品被重新設計，舊版的清單將失準。一份多年未更新的 SBOM，在客戶審查時，可能被視為未妥善版本控制的警訊。

名詞對照

• SBOM｜Software Bill of Materials，軟體物料清單；記錄產品所含軟體元件組成的結構化清冊。
• SPDX｜Software Package Data Exchange，SBOM 常用的結構化資料格式之一（ISO/IEC 5962:2021）。
• CycloneDX｜另一種廣泛使用的 SBOM 資料格式，由 OWASP 社群維護。
• CPE／PURL／SWHID｜三種常見的軟體元件唯一識別碼格式，用來將元件精準對應到漏洞資料庫。
• Top-level dependency｜頂層相依元件，指產品直接引用的軟體元件（尚未往下追溯其相依的相依）。
• Transitive dependency｜傳遞性相依關係，指元件所相依的元件、以及再往下的相依鏈。

參考資料

本文所引概念與規範依據，以下列文件為準：

• ISO/IEC 5962:2021，SPDX 規格國際標準
• CycloneDX 規格文件，OWASP 社群維護：https://cyclonedx.org/
• NTIA／CISA，"Minimum Elements For a Software Bill of Materials (SBOM)"，美國商務部與網路安全暨基礎設施安全局發布之 SBOM 基本要素指引

文／安合規律 × Applus+ Laboratories 顧問團隊

＊本文為法規解讀性質，非法律意見。個案之最終認定，仍應以歐盟官方文件與主管機關解釋為準。