什麼是 SBOM？

SBOM 是什麼的縮寫？

SBOM 是 software bill of materials（軟體物料清單）的縮寫。這個詞源自製造業，物料清單（bill of materials）列出構成一項產品的所有零件。CISA 將 SBOM 描述為一份巢狀的資產清冊，也就是構成軟體元件的成分清單。

現代應用程式中的大部分程式碼都是別人寫的，而且大多是間接進來的：您新增一個套件，它就會帶進數十個遞移相依套件。SBOM 會把這一切全部記錄下來，讓您不必閱讀任何一個儲存庫，就能回答「我們是否受到影響？」。

SBOM 包含哪些內容？

一份實用的 SBOM 包含兩個部分：關於 SBOM 本身的資料，以及關於每個元件的資料。CISA、NSA 與 FBI 於 2026 年 7 月 29 日與國際夥伴共同發布的2026 Minimum Elements，取代了 2021 年的 NTIA 清單，並訂立了目前多數採購方參考的基準。

部分	欄位
關於 SBOM	作者與作者簽章、時間戳記、資料格式名稱與版本、工具名稱與版本、SBOM 版本，以及產生情境
關於每個元件	名稱、版本、提供者、識別碼（例如 package URL 或 CPE）、雜湊值與演算法、授權，以及相依關係

產生情境比看起來更重要。它說明 SBOM 是何時產生的：建置前、建置期間、從完成的建置產物產生，或在那之後。同一個版本的兩份 SBOM 可能正是因為這個原因而不同。這些欄位在實際檔案中的樣貌，請參閱SBOM 範例；收到檔案時，也可以對照SBOM 品質檢查清單進行檢查。

SBOM 格式

目前使用中的 SBOM 幾乎都採用兩種格式。來自 OWASP 的 CycloneDX 起源於資安領域，也能描述漏洞與服務。來自 Linux Foundation 的 SPDX 起源於授權合規。兩者都能承載最低要素，而且多數工具兩種都能輸出。如何選擇，請參閱CycloneDX 與 SPDX 比較。

為什麼 SBOM 很重要

• 更快的資安事件應變。當 Log4Shell 這類漏洞出現時，問題在於您有哪些產品包含它。有了 SBOM，這只是一次搜尋；沒有 SBOM，這就是一個專案。
• 發布後的漏洞監控。出貨時沒有問題的軟體，明天就可能出現漏洞。將儲存的 SBOM 與新的資安公告重新比對，無需重新建置任何東西就能發現這類情況。
• 授權風險。每個元件宣告的授權，能在 copyleft 或商業條款進入產品之前就讓它們現形。
• 客戶與主管機關的提問。採購方在採購時越來越常要求提供 SBOM，而且多個框架都要求元件資產清冊。

誰需要 SBOM？

任何出貨軟體的人，以及任何必須為軟體內容負責的人。這項要求通常來自以下其中一種情況：

• 醫療器材。FDA section 524B 要求網路裝置（cyber devices）在上市前申請時提交 SBOM。
• 在歐盟銷售的產品。Cyber Resilience Act（CRA）要求製造商提供 SBOM。請參閱CRA 的 SBOM 要求與工具。
• 美國聯邦政府採購。2026 年 1 月的OMB 備忘錄 M-26-05讓各機關自行決定是否要求提供 SBOM，因此請預期會依個案而定。
• 支付軟體。PCI DSS 4.0 要求 6.3.2 要求建立客製軟體及其第三方元件的資產清冊。它並未規定必須使用 SBOM，但 SBOM 能滿足這項需求。

如何產生 SBOM

產生 SBOM 有三種方式，而採用的方法決定了檔案中會有哪些內容。

方法	讀取的內容	常見缺口
掃描原始碼	儲存庫中的 manifest 與 lockfile	建置下載了、但沒有任何 lockfile 列出的內容
掃描產出	完成的容器映像檔或二進位檔	編譯後的程式碼難以判讀，建置工具也不會留下痕跡
記錄建置	建置在執行時實際下載的內容	繞過記錄工具的流量，應予以標示

Syft、Trivy 與 cdxgen 等開源產生工具採用前兩種方法。針對同一個 commit，它們的結果彼此不一致，因為每個工具都有自己的讀取規則。各種選項的並列比較，請參閱最佳 SBOM 工具。

SBOM、SCA 與 VEX 的差異

• SBOM 是一份資產清冊。它說明有哪些內容，而不是這些內容是否安全。
• 軟體組成分析是分析工作。它找出元件並檢查其風險，許多 SCA 工具在過程中也會產生 SBOM。
• VEX 是關於影響的聲明。它說明已知漏洞是否真的影響您的產品，能減少單靠 SBOM 所產生的雜訊。

產生 SBOM 只是簡單的部分

沒有人閱讀的檔案改變不了任何事。真正的價值來自為每個版本保留一份 SBOM、持續監控，並在關鍵時刻能找到它們。這項工作就是SBOM 管理，而SBOM 最佳實務說明了如何執行。

CRACI 如何產生 SBOM

CRACI 是 GitHub Actions 執行器，會記錄每個作業在相依樹各層下載的每個套件，包括從 CI 快取還原的套件。產出的是建置出該版本的那次建置的 SBOM，並帶有完整度狀態，說明作業無法看見的部分。它可匯出為 CycloneDX 或 SPDX，而且 CRACI 會在新漏洞公布時持續重新評估。請參閱建置時 SBOM 產生。

SBOM 常見問題

簡單來說，什麼是 SBOM？

SBOM 是軟體的成分清單。它以機器可讀的格式，列出產品中的每個元件，以及其版本、提供者與授權。

SBOM 是什麼的縮寫？

SBOM 是 software bill of materials（軟體物料清單）的縮寫。

為什麼需要 SBOM？

讓您能迅速判斷新公布的漏洞是否影響您出貨的內容、在發布前看見授權風險，並回答詢問產品內容的客戶與主管機關。

兩種主要的 SBOM 格式是什麼？

CycloneDX 與 SPDX。CycloneDX 來自 OWASP，起源於資安領域。SPDX 來自 Linux Foundation，起源於授權合規。兩者都能承載最低要素。

法律是否要求提供 SBOM？

這取決於產品與市場。FDA section 524B 要求網路裝置提供 SBOM，歐盟 Cyber Resilience Act 也要求製造商提供。在美國聯邦政府採購中，目前由各機關自行決定。對許多其他公司而言，這是客戶的要求，而非法律要求。

SBOM 應該多久更新一次？

每個版本都應產生新的 SBOM，因為每次建置都可能引入不同的版本。版本的 SBOM 之後不會再變更，但您應持續將它與新的漏洞進行比對。

由誰產生 SBOM？

通常是建置軟體的團隊，最好是在 CI 中進行，讓每個版本都能自動取得一份。您採購的軟體應由其供應商隨附 SBOM。