歐盟 CRA（Cyber Resilience Act）軟體材料清單（SBOM）要求：建立可用的組件清冊

Julian Meroi · 發布日期 2026年11月3日 · 最近校閱 2026年11月3日

依網路韌性法案，每一位製造商都必須識別並記錄其具數位元素的產品所含的組件，包括製作軟體材料清單（SBOM）。SBOM 屬於漏洞處理的一環：當新的漏洞被通報時，您靠它迅速判斷已投放市場的某個產品版本是否受影響。本指南說明法規的要求、如何為特定版本界定並檢查組件清冊，以及在漏洞被通報時如何運用它，並附上一個假設性範例。附件 I 第二部分第 (1) 款。

此項義務自 2027 年 12 月 11 日起適用。在該日期之前投放市場的產品，僅於該日期起經實質修改時，才適用 CRA 的要求。第 14 條的通報義務已經適用，包括這些較早投放市場的產品。第 71 條第 2 項、第 69 條第 2 項至第 3 項、CRA 通報要求指南。

CRA 的要求

CRA 將軟體材料清單定義為「記載具數位元素的產品之軟體元素所含組件之細節及其供應鏈關係之正式紀錄」。這項定義同時涵蓋組件及其關係，因此若只是一份平面清單，看不出產品哪個部分含有哪個組件，就難以符合定義的用意。定義也涵蓋軟體元素中的每一個組件，無論是自行開發、向外購買，或取自開源專案。第 3 條第 (39) 款。

這項要求本身位於漏洞處理要求之中。製造商必須識別並記錄產品所含的漏洞與組件，包括「以通用且機器可讀之格式製作軟體材料清單，至少涵蓋該產品之最上層相依套件」。附件 I 第二部分第 (1) 款。

條文的用語可推導出兩點：

• 最上層相依套件是 SBOM 文件的最低涵蓋範圍。 處理漏洞的義務範圍更廣。第 13 條第 8 項要求產品（含其組件）的漏洞在整個支援期間內獲得有效處理；第 13 條第 5 項要求對整合的第三方組件（包括自由與開源軟體）盡注意義務。下層組件的漏洞仍須由您處理，因此您需要某種方式得知該下層組件的存在。第 13 條第 5 項、第 13 條第 8 項。
• 法規並未指定格式。 它要求的是通用且機器可讀的格式。第 13 條第 24 項授權執委會以實施法令明定 SBOM 的格式與要素。2026 年 11 月 3 日，歐盟執委會的 CRA 實施進度頁面 並未列出此類法令。在確定所採用的格式之前，請先確認最新情況。第 13 條第 24 項。

Recital 77 說明了其目的：識別組件有助於漏洞分析，並協助製造商與使用者追蹤新出現的漏洞。Recital 77 也指出，製造商不應負有公開 SBOM 的義務。Recital 77。

誰會看到 SBOM。 CRA 定有數個各自獨立的途徑：

合約、採購規則及其他法律可能另定 SBOM 的交付條件。請另行檢視；上述 CRA 途徑並不處理這些條件。附件 VII、第 13 條第 25 項、附件 II。我們的 CRA 技術文件指南 說明技術文件的其餘部分。

界定產品與版本的範圍

一份 SBOM 描述的是單一產品的軟體元素，因此請從您投放市場時的產品出發：其韌體、應用程式，以及屬於產品一部分的任何遠端資料處理。遠端服務僅在其軟體由您設計及開發、或於您的責任下設計及開發，且產品缺少它即無法執行其功能之一時，才屬於產品的一部分。我們的 CRA 產品分類指南 說明如何確定產品範圍，CRA 網路安全風險評估指南 也採用相同的範圍。第 3 條第 (1) 款至第 (2) 款。

接著，將每一份清冊與特定版本綁定。技術文件載明影響符合性的軟體版本；唯有知道 SBOM 描述的是哪一個出貨版本，它在漏洞處理中才有用處。國際最低要素與 BSI 的技術指引，都期待每個軟體版本各有一份 SBOM。CRA 本身並未規定命名方式或產生時機。附件 VII 第 1 點第 (b) 目。

在每一個版本中，將軟體分成三組：

• 您自己的程式碼：由您自行建置，因此可以完整識別，包括複製到您專案原始碼中的任何第三方程式碼。
• 您直接整合的組件：例如作業系統、函式庫或供應商的二進位模組。
• 內含於上述組件中的組件：您可能只能透過供應商的 SBOM 或自己的分析得知，也可能完全無從得知。

請記錄您不知道的部分。內容不明的組件，與已經檢查並確認不再內含其他組件的組件並不相同。《2026 Minimum Elements》 建議 SBOM 作者在資訊不明或刻意不提供時明確說明；ENISA 的 SBOM 技術建議也建議記錄這些「已知的未知」（known unknowns）。ENISA 技術建議，第 4.1.2 節。

選擇格式與應記錄的資訊

實務上，「通用且機器可讀」指向兩種廣泛使用的格式：SPDX 與 CycloneDX。請選擇其中一種規格的正式發布版本，並依該版本的 schema 驗證輸出結果。《2026 Minimum Elements》 也建議不要以已淘汰的格式版本為新軟體製作 SBOM。ENISA 技術建議，第 2.1 節。

除格式之外，CRA 並未列出資料欄位。指引文件則有列出；下表說明每一類資訊的用途，以及這項期待的出處。

這是依據《2026 Minimum Elements》、BSI TR-03183-2 第 2.1.0 版第 4 至 6 節及 ENISA SBOM 技術建議的實作範例。除第 3 條第 (39) 款的定義，以及附件 I 第二部分第 (1) 款關於格式與最上層相依套件的要求外，這些欄位並非 CRA 所強制要求。

BSI TR-03183-2。 德國聯邦資訊安全辦公室（BSI）發布了一份技術指引，訂有其自身的 SBOM 規格。第 2.1.0 版要求：採用 JSON 或 XML，並符合 CycloneDX 1.6 以上版本或 SPDX 3.0.1 以上版本；對交付範圍內的每一個組件遞迴解析其相依套件，直到第一個位於交付範圍之外的組件為止；交付組件使用 SHA-512 雜湊值；每個軟體版本各有一份 SBOM。該指引也要求宣稱符合本指引的 SBOM 不得包含漏洞資訊。這些是符合 BSI 指引的條件，客戶或招標有時會要求；它們並非 CRA 的條文。BSI TR-03183-2 第 2.1.0 版，第 3.1、4 及 5 節。

產生並檢查組件清冊

ENISA 的技術建議描述了一種最小可行做法：在建置過程中產生 SBOM，因為此時相依套件最為準確可知；使用您既有的建置基礎設施，並將 SBOM 與建置產出物一併保存。開始時不需要特定工具，也不需要完整的 CI/CD 管線（pipeline）；產生出來的檔案只是下列檢查的起點。ENISA 技術建議，第 4.1 節。

1. 依實際出貨的版本產生。 盡可能使用建置資訊：套件資訊清單（package manifest）、lock file、建置產出物與容器映像。部分嵌入式建置系統已能產生 SBOM，只需啟用該選項。
2. 納入供應商資訊。 合併或引用供應商的 SBOM，並確認每一份都符合您實際整合的版本及您所做的任何修改。供應商的 SBOM 可支援您履行注意義務；整合後產品的責任仍由您承擔。第 13 條第 5 項、歐盟執委會常見問題集，第 4.4.2 節。
3. 補足缺口。 對於僅以二進位形式提供的組件，請詢問供應商或進行二進位分析，並記錄仍然不明的部分。
4. 驗證檔案。 依格式規格檢查語法，並檢查所選規格要求的欄位及組件識別碼。
5. 對照版本檢查涵蓋範圍。 將 SBOM 與技術文件中的系統架構說明相互比對。每一個交付的軟體元素都應出現在其中，無論是作為已描述的組件，或作為已記錄的缺口。附件 VII 第 2 點第 (a) 目。
6. 保護並保存。 ENISA 建議對 SBOM 進行簽署、控管產生流程的存取權限，並將 SBOM 保存於具版本控制並有完整性保護的儲存位置，且與其描述的版本相連結。ENISA 技術建議，第 4.2 節。

這是依據 ENISA SBOM 技術建議第 2.2 節及第 4 節的實作範例。這些流程選擇並非 CRA 所強制要求，ENISA 亦表明其建議不具強制性。

即使 SBOM 通過 schema 驗證，仍可能描述了錯誤的建置版本，或遺漏某個組件。schema 驗證只能顯示檔案符合其格式。漏洞掃描沒有發現問題，所涵蓋的也只是掃描工具能夠識別並比對的組件，且僅限於其所使用的資料庫與設定：識別碼錯誤或缺漏、分析不完整，或嚴重程度篩選條件，都可能導致沒有任何發現。請將失敗或不完整的檢查視為尚未解決。兩種結果都不能證明產品不含有漏洞的組件。ENISA 技術建議，第 2.2.2、3.2 及 4.1.2 節。

漏洞被通報時如何運用 SBOM

當某個組件的漏洞成為已知時，SBOM 最能發揮作用。漏洞列於相關的公開漏洞資料庫時，應視為已知；也可能透過協調式揭露、內部測試或顯著的報導而成為已知。單有通報並不代表該漏洞適用於您的產品：歐盟執委會的指引期待您進行調查並予以確認。歐盟執委會指引，第 233 至 235 段。

我們的 CRA 漏洞處理指南 說明完整流程，從接收通報到發布安全更新並記錄每項決定。

從第一次分流開始，就要將通報義務納入考量。一旦您知悉產品所含的漏洞遭積極利用，第 14 條即要求不無故遲延、且至遲於 24 小時內提出早期預警通報，其後還有後續通報。修補作業不會使這項義務延後。產品的支援期間結束後，第二部分的漏洞處理義務不再適用，但通報義務仍持續適用。我們的 CRA 通報要求指南 說明觸發條件與期限。第 14 條第 1 項至第 2 項、歐盟執委會指引，第 209 至 211 段。

1. 找出受影響的版本。 將安全公告中的組件與版本範圍，與各版本的 SBOM 比對。也要納入支援期間已結束的版本：第二部分已不適用於這些版本，但第 14 條仍然適用。
2. 檢查缺口。 若某版本記錄某個組件內容不明，而該組件可能包含受影響的程式碼，則比對不到並不代表該版本不受影響。請透過供應商或分析來解決缺口。
3. 全程留意遭積極利用的情形。 若您在任何時點知悉該漏洞遭積極利用，第 14 條的通報即自該時點起算，與調查及修補同步進行。
4. 評估適用性。 檢查有漏洞的程式碼是否存在於您的建置版本中，以及依您產品的使用方式，它是否可被觸及或利用。
5. 記錄調查與決定。 第 13 條第 7 項要求您記錄所知悉的漏洞及第三方提供的相關資訊，並於適用時更新風險評估。第 13 條第 7 項。
6. 修補。 就產品所面臨的風險，不遲延地處理並修補漏洞，包括提供安全更新；於技術上可行時，安全更新應與功能性更新分開提供。安全更新可供取得後，分享並公開揭露已修補漏洞的相關資訊。於有正當理由的情形，若您認為公開所生的安全風險大於其效益，得延後公開，直到使用者已有機會套用修補程式為止。附件 I 第二部分第 (2) 款及第 (4) 款。
7. 告知組件的維護者。 第 13 條第 6 項要求您將在整合組件中發現的漏洞，通報製造或維護該組件的個人或實體。歐盟執委會的指引將此限於您所整合的版本，以及組件本身的漏洞。若您能確認維護者已經知悉，或該組件已無維護者，則無須通報。若您開發了修補該組件漏洞的修改，應將相關程式碼或文件分享予維護者。若緩解措施變更的是您系統的其他部分，則無須分享。第 13 條第 6 項、歐盟執委會指引，第 222 至 229 段。
8. 隨修補後的版本發布新的 SBOM。

VEX 與安全公告。 Vulnerability Exploitability eXchange（VEX）與 Common Security Advisory Framework（CSAF）等格式，可讓您告知客戶某個產品是否受特定漏洞影響。它們承載的是會隨時間變化的漏洞狀態，而 SBOM 記錄的是某個版本包含哪些內容。BSI 在其規格中將兩者分置於不同文件。CRA 並未要求提供 VEX 檔案。「不受影響」的聲明記錄的是您的評估，並非獨立的證明。BSI TR-03183-2 第 2.1.0 版，第 1 及 3.1 節。

範例：連網感測器及其儀表板的 SBOM

本範例延續 CRA 網路安全風險評估指南 中假設的「範例感測器 1.0」：一款商業建築用的連網環境感測器，搭配由製造商開發、屬於產品一部分的雲端儀表板。韌體 1.0 與儀表板 1.0 是各自獨立的軟體版本，因此各有一份 SBOM，技術文件則記錄產品由哪個韌體版本與哪個儀表板版本組成。以下所有組件名稱與版本均為虛構。

兩份 SBOM 中的部分項目：

在本範例中，假設團隊已對照部署中的儀表板（包括複製進來的第三方程式碼與下層相依套件）檢查儀表板 1.0 的 SBOM，且未發現缺口。韌體 1.0 的 SBOM 則有一個已記錄的缺口。

漏洞被通報。 一份假設的公開安全公告指出，example-tls 3.1.5 之前的版本存在漏洞。

• 受影響的版本： 韌體 1.0 的 SBOM 列出作業系統中的 example-tls 3.1.4，因此韌體 1.0 可能受影響。儀表板 1.0 的 SBOM 未列出該函式庫，且其涵蓋範圍經檢查並無缺口，因此團隊判斷儀表板 1.0 不受此安全公告影響。
• 遭積極利用的情形： 從第一次分流起，團隊即搜尋該漏洞遭積極利用的資訊；一旦知悉遭利用，便會立即啟動第 14 條的通報。目前尚未發現相關資訊，並在調查期間持續檢查。
• 缺口： Wi-Fi 模組韌體的內容不明。團隊無法斷定其中不含 example-tls，因此向模組供應商詢問，並記錄這個待解問題。
• 適用性： 團隊確認韌體 1.0 在連線至儀表板時會使用受影響的功能，並記錄分析結果及更新後的風險評估。
• 修補： 韌體 1.0.1 透過作業系統供應商的更新，將 example-tls 更新至 3.1.5。安全公告由該函式庫的維護者發布，因此他們已經知悉，無須向上游通報。沒有延後公開的正當理由，因此團隊在 1.0.1 可供取得後，即公開已修補漏洞的相關資訊。
• 證據： 韌體 1.0.1 的 SBOM、調查紀錄、更新後的風險評估，以及 1.0.1 的測試報告。

這是依據 CRA 附件 I 第二部分、第 13 條第 5 項至第 7 項及第 14 條的實作範例。CRA 並未強制要求這些欄位、這套流程或這些涵蓋情形標示。各列僅為部分項目，並非完整或通過 schema 驗證的 SBOM；所列證據為預計提出、尚未完成。

「範例感測器 1.0」的完整 SBOM，將涵蓋兩個版本的每一個軟體元素，記錄其餘缺口，並對照技術文件所描述的架構進行檢查。

分享、更新與保存

更新。 每當某個版本變更其組件時，請產生新的 SBOM；當您發現錯誤或取得某個組件更完整的資訊時，請更正既有的 SBOM。Minimum Elements 與 BSI 都區分同一軟體版本的更正版 SBOM，與新軟體版本的新 SBOM。技術文件（包括 SBOM）應至少於支援期間內視情況持續更新。第 31 條第 2 項。

保存。 技術文件應於產品投放市場後至少 10 年，或於支援期間內（以較長者為準），保存以供市場監督機關查閱。您投放市場之各版本的 SBOM，屬於該技術文件的一部分。對於從未發行的內部建置版本所產生的 SBOM，CRA 並未另訂規則，請於您自己的政策中決定。第 13 條第 13 項。

分享。 是否讓使用者取得 SBOM 由您決定；若您決定提供，使用者資訊須說明取得位置。客戶仍可能依合約要求提供，整合者也可能需要組件資訊以履行其自身義務。ENISA 的技術建議與 Minimum Elements 都描述了受控的分享方式，例如針對特定版本的網址，或透過需身分驗證的方式存取。附件 II 第 8 點第 (f) 目及第 9 點。

指引與標準的定位

• ENISA 的 SBOM 技術建議（2026 年 10 月）就 SBOM 類型、生命週期、建置流程整合與安全提供實務建議。ENISA 表明這份文件不具強制性，並非對 CRA 的法律解釋，且其建議做法可能超出 CRA 的要求。ENISA 技術建議，第 1.1 至 1.2 節。
• 《2026 Minimum Elements》（2026 年 7 月）由美國網路安全暨基礎設施安全局（CISA）與多國合作機關共同發布，其中包括歐盟會員國的主管機關。這份文件訂定基準資料欄位與實務做法，表明其不創設新的要求，並期待涵蓋所有組件，包括間接相依套件（transitive dependencies）。這比 CRA 的最低要求更深入。《2026 Minimum Elements》。
• BSI TR-03183-2 定有更嚴格的規格，如上所述。
• EN 40000-1-3 是正在制定中的漏洞處理協調標準。其公布的範圍，包括在更廣泛的漏洞處理流程中識別組件及 SBOM。2026 年 11 月 3 日，CEN 專案紀錄 顯示其處於核准階段，並預期將於《歐盟官方公報》引用。唯有在其出處於《歐盟官方公報》公布後，才產生符合性推定，且僅限於其所涵蓋的要求。在依賴其詳細要求之前，請先查閱正式公布的文本。我們的 CRA 網路安全風險評估指南 說明 EN 40000 各部分如何相互配合。第 27 條第 1 項。

依賴 SBOM 之前的檢查

• 每一份 SBOM 都載明其描述的產品版本，且版本與技術文件一致。
• 該版本的每一個軟體元素（包括屬於產品一部分的遠端資料處理），都以組件或已記錄缺口的形式出現。
• 依賴關係顯示產品哪個部分含有每一個組件。
• 組件附有您的漏洞資訊來源能夠比對的識別碼。
• 供應商的 SBOM 與您所整合的版本相符。
• 內容不明的部分標示為不明。
• 漏洞處理流程確實運用 SBOM，且有過往的調查紀錄可以說明如何運用。
• SBOM 與該版本一併保存，並可依要求提供。

Meroi Security 如何協助

Meroi Security 可依網路韌性法案檢視您既有的 SBOM，找出涵蓋範圍與版本上的缺口，建立組件清冊與漏洞處理之間的連結，並準備相關的技術文件。歡迎了解我們的 CRA 合規服務。