客戶要求提供 SBOM 時怎麼辦：給元件與軟體供應商的指南

本指南適用於製造業供應鏈中的供應商：ECU、顯示器、控制器、閘道器、驅動器、嵌入式 Linux 堆疊與韌體模組。如果您銷售的是軟體，而客戶寄來的是一次性的請求，請先閱讀涵蓋該情況的如何回應客戶的 SBOM 請求。

OEM 為何現在提出要求

OEM 的 SBOM 請求，通常是 OEM 自身的法規透過合約來到您面前。是哪一項法規，決定了 OEM 必須具備什麼，以及其中有多少會轉嫁給您。

Cyber Resilience Act

依據 Cyber Resilience Act（CRA），Regulation (EU) 2024/2847，具數位元素的產品包括「單獨投放市場的軟體或硬體元件」（第 3(1) 條）。您單獨銷售到歐盟的元件本身就是一項產品，而您是它的製造商，負有自己的 SBOM 義務：附件 I 第 II 部分第 (1) 點要求 SBOM「採用常用且機器可讀的格式，至少涵蓋產品的頂層相依套件」。如果該元件是為了整合到其他產品中而設計，您的說明文件也必須提供「整合者為符合」基本要求「所需的資訊」（附件 II 第 8(f) 點）。

OEM 也有會影響到您的義務。它必須「在整合來自第三方的元件時善盡審查義務」（第 13(5) 條），而當它在所整合的元件中發現漏洞時，必須通報給製造或維護該元件的個人或實體（第 13(6) 條）。歐盟執委會 2026 年 7 月的 CRA 指引指出，審查義務的佐證資料「可以包括從元件製造商取得的文件」，但並未提及 SBOM；實務上，SBOM 往往就是 OEM 要求的文件。通報義務自 2026 年 9 月 11 日起適用，本法規自 2027 年 12 月 11 日起全面適用。依照與所替換元件相同規格製造的備品不在適用範圍內（第 2(6) 條）。關於本法規的其他內容，請參閱 CRA 是什麼與 CRA 指南。

車輛

CRA 不適用於車輛型式認證法規 Regulation (EU) 2019/2144 所涵蓋的產品（第 2(2)(c) 條）。型式認證車輛的元件改依車輛法規進入市場，而這些法規從未提及 SBOM。

UN Regulation No. 155（網路安全）要求製造商蒐集並驗證資訊，「透過供應鏈證明與供應商相關的風險已被識別並受到管理」（5.1.1(a)），說明其網路安全管理系統「將如何管理與受委託的供應商、服務供應商或製造商下屬組織之間可能存在的相依關係」（7.2.2.5），並「針對申請認證的車型，識別並管理與供應商相關的風險」（7.3.2）。
UN Regulation No. 156（軟體更新）要求所有初始與更新後的軟體版本皆可被唯一識別（7.1.1.2），並針對每個 RX Software Identification Number（RXSWIN）提供「描述與該 RXSWIN 相關之所有軟體的可稽核登錄冊」（7.1.2.3）。
ISO/SAE 21434 將 OEM 與供應商之間的網路安全工作組織為分散式活動，分工方式則在網路安全介面協議中約定。
Auto-ISAC SBOM Informational Report（2025 年 2 月）提供了產業本身的指引。

在汽車產業，SBOM 是以合約要求而非法律要求的形式出現。

工業自動化

IEC 62443-4-1 適用於工業自動化與控制系統產品的供應商。它並未明確提到 SBOM，但在實務 6「安全相關問題的管理」（DM-1 至 DM-6）與實務 7「安全性更新管理」（SUM-1 至 SUM-5，包括 SUM-3「Dependent component or operating system security update documentation」）中，SBOM 可作為佐證資料。

機械

機械法規 Machinery Regulation (EU) 2023/1230 自 2027 年 1 月 20 日起適用，並未提及 SBOM。其關於防止遭竄改的基本要求（附件 III，1.1.9）要求識別並保護對合規至關重要的軟體，要求機械能夠「識別其上安裝、安全運作所需的軟體」，並要求蒐集對該軟體進行干預的證據。與型式認證車輛不同，具數位元素的機械也適用 CRA，這就是機械 OEM 現在向供應商索取 SBOM 的原因。請參閱適用於機械製造商的 CRACI與工業物聯網。

NIS2 與取得認證的客戶

如果您供貨給基礎實體或重要實體（例如半導體產業），NIS2 第 21(2)(d) 條要求您的客戶處理供應鏈安全。它並未明確提到 SBOM。客戶會將其轉化為問卷，而在 ISO/IEC 27001 附錄 A 控制措施 5.21 與 8.8 中，SBOM 可作為佐證資料。請參閱作為 ISO 27001、SOC 2 與 NIS2 佐證資料的 SBOM。

各項法規並排比較

法規	適用對象	是否明確提到 SBOM？	如何影響供應商
Cyber Resilience Act	在歐盟市場上具數位元素的產品，包括單獨銷售的元件	是，附件 I 第 II 部分 (1)	若您將元件投放市場則直接適用；透過 OEM 的審查義務（第 13(5) 條）與漏洞通報（第 13(6) 條）
UN R155 與 R156	申請型式認證的車輛製造商	否	透過合約，要求供應商風險管理（R155 7.2.2.5、7.3.2）與軟體識別（R156）
ISO/SAE 21434	道路車輛網路安全工程，涵蓋 OEM 與供應商	其公開說明中未提及	分散式活動與網路安全介面協議
IEC 62443-4-1	工業自動化與控制系統產品的供應商	否	若您是產品供應商則直接適用；SBOM 可作為 DM 與 SUM 的佐證資料
Machinery Regulation	在歐盟市場上的機械及相關產品	否	軟體識別與保護（附件 III 1.1.9）；CRA 同時適用
NIS2	基礎實體與重要實體	否	供應鏈安全問卷與合約條款（第 21(2)(d) 條、第 21(3) 條）

無論是哪一條途徑，客戶需要的都是同一樣東西：您交付的每個軟體版本都有一份正確的 SBOM。

OEM 通常會要求什麼

各家 OEM 的要求不同，但最後都會歸納成同一份清單。請在第一次交付前，依此清單檢查您的 SBOM。

要求	常見期望
格式	CycloneDX 或 SPDX，JSON 或 XML，並有最低規格版本。BSI TR-03183-2 規定為 CycloneDX 1.6 或更新版本，或 SPDX 3.0.1 或更新版本。
欄位	符合 CISA 2026 Minimum Elements 或 BSI TR-03183-2：作者、時間戳記，以及每個元件的名稱、版本、製作者與識別碼
識別碼	生態系有 package URL 時就使用它，沒有時則使用 CPE，以便將元件與漏洞資料庫比對
授權	SPDX 授權識別碼。OEM 的授權專家會據此判斷 copyleft 與其他授權風險。
雜湊值	每個交付二進位檔的雜湊值，讓 OEM 能確認 SBOM 描述的就是它收到的檔案。BSI 要求使用 SHA-512。
深度	包含遞移相依套件，而不只是頂層
粒度	每個交付的軟體版本或料號各一份 SBOM
交付與回應	交付管道，以及漏洞相關問題的回應時間

許多 OEM 會在收到時自動檢查這些項目。關於客戶會檢查什麼以及他們使用的工具，請參閱 SBOM 品質檢查清單；關於這些欄位在檔案中的樣貌，請參閱 SBOM 範例。

開源元件很少或沒有時的 SBOM

一個以模型式程式碼產生、搭載專有韌體的裸機 ECU 或控制器，其誠實的 SBOM 可能很短：專有應用程式、您的 bootloader、晶片供應商的函式庫或校正資料，以及任何開源元件（例如密碼學函式庫）。這是有效的答案。規則如下：

以您自己的識別碼列出專有元件：名稱、版本，並以您為製作者。
說明已知的未知項目，例如您無法得知內容的廠商函式庫。
絕不為了看起來完整而灌水 SBOM，也絕不因為開源函式庫很小就將其省略。

以 Linux 為基礎的顯示器與閘道器則恰恰相反：元件多達數百或數千個，包括核心、bootloader 與基礎系統套件（請參閱連網裝置）。只列出您的應用程式與少數函式庫的 SBOM，正是接收團隊第一個會標示出來的問題。如果您使用 Yocto 建置，請參閱為何掃描工具會漏掉 Yocto 建置中的內容。

合約：第一次交付前應約定的事項

條款	為何重要
涵蓋的產品與軟體版本	避免日後爭論某個變體或服務版本是否需要 SBOM
格式與規格版本	對方的接收流程可能會拒收其他格式
欄位及其依循的框架	「BSI TR-03183-2 v2.1.0」或「CISA 2026 Minimum Elements」可以驗證；「一份完整的 SBOM」則無法驗證
交付時機	每次版本發布、每個出貨給 OEM 的軟體版本，以及每次更正
交付管道	OEM 的供應商入口網站、安全檔案交換，或在 NDA 下以電子郵件傳送
保密	以 NDA 或既有的供貨協議，將 SBOM 列為機密資訊
使用限制	僅限用於漏洞管理與法規遵循，未經同意不得再分享
雙向漏洞通知	OEM 通報它在您元件中發現的漏洞（CRA 第 13(6) 條）；您也通知它您發現的漏洞
VEX 期望	採用哪種格式，以及您多快評估新的 CVE
保存期限	每個版本的 SBOM 保存多久，並與產品的支援期間一致
正確性與已知的未知項目	誠實說明 SBOM 能涵蓋與不能涵蓋什麼的條款，能保護雙方

CISA 的 SBOM Sharing Primer 對汽車業情況的描述也相同：SBOM 請求「會納入標準的資訊交換協議（例如保密協議、網路安全介面協議、開發介面協議）」。

分享而不洩漏智慧財產

SBOM 不是您的原始碼。它列出的是元件名稱、版本、製作者、授權、雜湊值與彼此的關係，不包含您的程式碼、演算法、校正資料或設計。

CRA 並未要求製造商公開 SBOM（前言第 77 點）。SBOM 是在市場監督機關提出附理由的要求時提供給該機關（附件 VII 第 8 點）。
CISA 的分享指引描述了專有軟體常用的管道：在 NDA 下以電子郵件傳送、客戶的供應商入口網站或安全文件交換，或您自己設有存取控管的入口網站，並以合約規範保密與存取。
實務做法：依合約為每家 OEM 提供一份完整的 SBOM；為專有部分使用不會透露內部專案名稱的識別碼；並另外提供 VEX 文件，讓您不必重新寄送 SBOM 就能更新漏洞狀態。

多久提供一次，以及交付之後會發生什麼

您交付的每個軟體版本都提供新的 SBOM，並使用 OEM 燒錄或登錄時的同一個識別碼。以車輛而言，這與 R156 的軟體識別相連結。
更正後的 SBOM：當您發現已寄出的 SBOM 有錯誤時提供。
VEX 聲明或資安公告：當您已評估某個漏洞時提供。

後續的問題「您是否受 CVE-X 影響？」會隨著下一個重大漏洞而來。請準備好針對每個已交付版本回答，而這只有在您保存了每個版本的 SBOM 時才做得到。

VEX：客戶接下來會期待的東西

VEX 文件說明產品是否受某個漏洞影響。CISA 的 Minimum Requirements for VEX（2023 年 4 月）定義了四種狀態：not_affected、affected、 fixed 與 under_investigation。not_affected 聲明應提供以下五種理由之一，否則須提供影響說明：

component_not_present
vulnerable_code_not_present
vulnerable_code_not_in_execute_path
vulnerable_code_cannot_be_controlled_by_adversary
inline_mitigations_already_exist

affected 聲明需要附上行動說明：客戶應該怎麼做。VEX 有三種格式： CSAF 2.0 VEX 設定檔、CycloneDX VEX 與 OpenVEX。Yocto 的 SPDX 3.0 輸出預設包含 VEX 資料（SPDX_INCLUDE_VEX 變數）。

實例說明。一款以 Linux 為基礎的顯示器搭載 OpenSSL 3.0.8。CVE-2023-0464 描述的是在驗證包含政策限制的 X.509 憑證鏈時，會過度耗用資源。政策處理預設為停用，而該顯示器的軟體從未啟用它。供應商寄出一份示意用的 OpenVEX 聲明：

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

以可重複的方式產生 SBOM

您的建置方式	產生 SBOM 的實際做法
在 CI 中建置的軟體	在產出交付軟體的建置中產生 SBOM，並與版本一起保存
以 Yocto 為基礎的嵌入式 Linux	Yocto 本身的 SPDX 輸出（`create-spdx`），並檢查其遺漏的內容，或記錄 Yocto 建置
以模型式工具產生的裸機韌體	使用產生器函式庫或工具（絕不使用文字編輯器），隨每次版本發布維護，並在寄出前驗證
您整合的第三方二進位檔	向您自己的供應商索取其 SBOM；在收到之前，以二進位分析暫代

無論採用哪種途徑，都請在寄出前驗證檔案。SBOM 品質檢查清單列出了客戶可能會執行的驗證工具，CycloneDX 與 SPDX 比較可協助您選擇格式，而標準化 SBOM 產生則說明如何讓各團隊的做法一致。

CRACI 的定位

對於在 GitHub Actions 上建置的供應商，CRACI 會取代 GitHub 託管執行器，並從每次建置記錄 SBOM，因此每個交付的版本都已經有一份 SBOM。

SBOM 列出建置實際取用的內容，包括遞移相依套件，每個套件都有 package URL，並列出每個元件宣告的授權。
每個作業的 SBOM 都附有完整性狀態，讓您在寄出前就知道自己寄出的是什麼。
SBOM 可匯出為 CycloneDX 或 SPDX，且 CRACI 支援 VEX。
受監控的 SBOM 會在新漏洞公布時重新評估，建置歷史也會顯示在您的保留期限內，哪些建置含有存在漏洞的相依套件。
Yocto 建置可在 CRACI 執行器上執行，並有文件說明。
可加入第三方 SBOM，讓您外購的元件與您自己的建置一起受到監控。

CRACI 不適合的情況

您沒有 CI，或您在 GitLab、Jenkins 或建置伺服器上建置。CRACI 目前僅支援 GitHub Actions；其他 CI 系統已列入產品藍圖。
您的韌體是由模型式工具產生，不會取用任何套件。在這種情況下，建置紀錄器的幫助不大。
您需要在分享入口網站中為多家 OEM 託管 SBOM，或需要對 SBOM 簽署。CRACI 兩者都不提供。
您的建置必須在自己的基礎設施上執行。客戶自行託管的執行器已列入產品藍圖。
您的客戶要求證明貴組織的資安管理，例如 ISO 27001 證書或 NIS2 問卷的回答。SBOM 只是其中一部分的佐證資料，而不是認證。CRACI 本身的 ISO 27001 證書涵蓋的是 CRACI 的服務，而不是您的服務。

供應商的 SBOM：常見問題

我的客戶（一家 OEM）要求我提供 SBOM。我有義務提供嗎？

通常是合約而非法律要求您提供。如果您自己將具數位元素的元件投放到歐盟市場，Cyber Resilience Act（CRA）會要求您提供自己的 SBOM。否則，這項義務屬於 OEM，再由 OEM 透過審查義務與供貨協議轉嫁給您。

CRA 是否適用於我銷售給製造商的元件？

如果您將元件單獨投放到歐盟市場，是的：第 3(1) 條涵蓋單獨投放市場的軟體或硬體元件。如果它只以 OEM 產品的一部分進入市場，則 OEM 是製造商，必須對您的元件善盡審查義務（第 13(5) 條）。型式認證車輛的元件不在 CRA 的範圍內（第 2(2)(c) 條）。

UN R155 或 ISO/SAE 21434 是否要求 SBOM？

否。R155 從未提及 SBOM；它要求車輛製造商管理與供應商相關的風險。ISO/SAE 21434 透過介面協議來組織與供應商之間的網路安全工作。在汽車產業，SBOM 是以合約要求的形式出現。

OEM 會期望什麼格式與欄位？

通常是 JSON 或 XML 格式的 CycloneDX 或 SPDX，並符合 CISA 2026 Minimum Elements 或 BSI TR-03183-2：作者與時間戳記，以及每個元件的名稱、版本、製作者、package URL 或 CPE、授權與雜湊值，並包含遞移相依套件。

我多久需要寄送一次更新的 SBOM？

您交付的每個軟體版本都要寄送，每次更正錯誤時也要寄送，並在評估漏洞後附上 VEX 聲明或資安公告。請在合約中約定寄送時機。

分享 SBOM 會暴露我們的智慧財產嗎？

不會。SBOM 列出的是元件名稱、版本、製作者、授權、雜湊值與彼此的關係，而不是原始碼、演算法或校正資料。請在 NDA 或供貨協議下分享，並將用途限制於漏洞管理與法規遵循。CRA 並未要求公開 SBOM。

VEX 是什麼？客戶會要求它嗎？

VEX 說明產品是否受某個漏洞影響：not_affected、affected、fixed 或 under_investigation，not_affected 需附上理由。當您出貨的元件下一次出現廣受報導的漏洞時，預期客戶會向您索取。

我們的 ECU 韌體沒有開源元件。我們的 SBOM 會是什麼樣子？

簡短而誠實：專有應用程式、bootloader、任何晶片供應商的函式庫或校正資料，以及任何開源元件（例如密碼學函式庫），每一項都使用您自己的識別碼，再加上已知的未知項目。不要灌水。

客戶要求提供 SBOM：給元件與軟體供應商的指南