做過 EN18031 認證，不完全等於已有 SBOM ——在《網路韌性法案》底下不同的義務
從《網路韌性法案》法規原文、prEN 40000 草案到罰則、時程，一次拆解 SBOM 的義務
上一篇文章談的是四步判定法：先確認產品是否落在 CRA 適用範圍內，而這只是起點——真正的功課是接下來一連串具體義務：風險分類、符合性評估、模組選擇、通報義務，以及本文要談的 SBOM。
SBOM 值得單獨拉出來講，是因為它不是一次性的檢查項目，而是貫穿產品整個支援期間、反覆出現在好幾個不同條文與草案標準裡的持續性義務。很多廠商第一次聽到「CRA 要求 SBOM」時，直覺反應是「我們是不是已經做過類似的事」，而這正是最容易出錯的地方。
CRA 的基本要求分為兩部分：Annex I, Part I 談的是「產品本身設計得夠不夠安全」，例如加密、存取控制、預設安全組態這類產品屬性；Part II 談的是「產品上市之後，你有沒有能力持續處理漏洞」。SBOM 屬於 Annex I 的 Part II（漏洞處理要求），而不是 Part I（產品屬性相關的網路安全要求）；SBOM 在這裡扮演的角色，是讓漏洞處理流程有東西可以比對——沒有元件清單，就無從得知某個漏洞是否影響你的產品。
所以，SBOM 是 CRA「漏洞處理義務」的一部分，不是做完就結束，而應該是跟著產品支援期、隨著每次修訂改版持續更新維護；故，已取得 EN 18031 / RED 認證的廠商「已經擁有 SBOM」，僅對應屬於 Annex I, Part I（產品屬性相關的網路安全要求），並未涉及 Annex I, Part II（漏洞處理要求）。
SBOM 的法律依據，寫在 Regulation (EU) 2024/2847 的 Annex I, Part II（漏洞處理要求，Vulnerability handling requirements）第 (1) 項。條文原文（逐字翻譯）是這樣寫的：
「識別並記錄產品內含之漏洞，以及產品的組成元件，包括以常用且機器可讀格式，製作至少涵蓋產品頂層依賴關係之軟體物料清單（SBOM）。」
上述所提 SBOM 是持續性漏洞處理義務外，SBOM 也出現在技術文件的內容範圍裡（Article 31、Annex VII）——技術文件應包含產品說明、風險評估、支援期認定依據、測試報告等，「必要時」也包括 SBOM；技術文件與 SBOM 須依 Article 13 保存至少 10 年或支援期（取較長者）。
CRA 本身的條文只講了原則（「應製作機器可讀的 SBOM，至少涵蓋頂層依賴」），實際怎麼做，要看目前仍在制定中的協調標準草案——prEN 40000 系列。SBOM 目前分別出現在兩份草案裡，扮演不同角色：
prEN 40000-1-2 對應 CRA Annex I Part I（產品屬性要求），談的是產品開發生命週期中的一般性原則。SBOM 在其中出現在兩處：
這一份草案講的比較原則性：SBOM 是安全開發流程的固定動作之一，第三方元件一律要納管。
真正把 SBOM 講清楚、講到可以逐條稽核程度的，是對應 CRA Annex I Part II 的 prEN 40000-1-3，其中 5.3.8 節「[PRE-7] Identification of software components」整段都在規範 SBOM。
重點可歸納為三件事：
PRE-7-RQ-01 至 07 及增強需求摘要，於文章末尾附錄，有興趣進一步研究的讀者可參考下方。
提醒：prEN 40000-1-3 目前仍是 Draft for Public Comment 階段（截至查證時投票已結束但尚未確認進入 Formal Vote，也尚未刊登於歐盟官方公報），條文編號與內容在正式定案前仍可能調整，不能作為最終合規依據；但由於底層法律義務來自 Regulation 本文的 Annex I Part II，草案的變動不影響「SBOM 是不是必要」這個問題的答案——只影響「怎麼做才算做對」的細節。
SBOM 是一項需要持續維護的義務，沒做到的會怎麼樣？—— 違反 Annex I 基本要求（含 Part II 的 SBOM 要求）以及 Article 13、14 義務，行政罰款上限是 1,500 萬歐元，或全球年營業額 2.5%，兩者取高者（Article 64），這是 CRA 罰則架構裡最高的一級。SBOM 雖然聽起來只是一份清單，但在法律定位上，跟加密、存取控制這些產品屬性要求，適用的是同一個罰則等級。
時程上，有兩個日期特別需要留意，而且兩者之間的落差，恰好是多數廠商容易誤判準備時間的地方：
問題在於：Article 14 的 24 小時／72 小時通報時限，實際上要靠 SBOM 才能在時限內回答「我們的產品是否受影響」。也就是說，雖然 SBOM 作為 Annex I 正式要求的生效日是 2027 年 12 月 11 日，但實務上支撐自 2026 年 9 月 11 日起適用的通報義務，需要的正是 SBOM 這份資料——這中間有超過一年的落差，等到 2027 年底才開始準備，會發現通報義務早已經上路一年多，卻沒有支撐通報的基礎資料。
誤解一：「我們已經做過 RED／EN 18031 認證，SBOM 應該已經涵蓋了。」EN 18031 三部曲（網路保護、個資保護、金融交易安全）對應的是 RED 的資安要求，性質上比較接近 CRA Annex I Part I（產品屬性要求），內容完全沒有涵蓋軟體元件識別或 SBOM。SBOM 屬於 Annex I Part II（漏洞處理要求），是兩個不同範疇的義務，既有的 EN 18031 認證投入不會自動涵蓋 SBOM，需要另外規劃。
誤解二：「EN 40000 標準還沒正式公告，所以 SBOM 現在還不用準備。」協調標準只是「如何證明合規」的其中一條路徑（推定合規）；SBOM 的法定義務直接來自 Regulation 本文的 Annex I Part II，標準是否已刊登於官方公報，不影響底層法律義務本身何時生效。更關鍵的是，Article 14 通報義務自 2026 年 9 月 11 日起適用，實務上遠早於標準定案與 2027 年底的全面適用日就需要 SBOM 支援。
誤解三：「SBOM 只要做一次、涵蓋頂層依賴就好。」基本要求（PRE-7-RQ-03）確實只要求涵蓋頂層依賴，但草案已經放入強化要求，要求技術可行時進一步涵蓋傳遞性依賴關係；而且每次新版本、新建置都應該重新產生對應的 SBOM。強化要求是否適用由製造商依自身產品風險決定，不是自動免除，建議及早評估，而不是等到稽核時才發現基本版本不夠用。
標準草案還在變動，不代表可以把 SBOM 往後排。比較務實的排序方式是：
如果你已經確認產品落在 CRA 範圍內，卻還不確定 SBOM 該做到哪個深度、要對應哪一種格式，或想請專業意見協助覆核整體 CRA 準備進度，歡迎與我們聯繫，由顧問協助評估個案狀況。
歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結
prEN40000-1-3 PRE-7 SBOM 逐條要求 (Identification of software components)
| 條號 | 規範重點（白話） |
|---|---|
| PRE-7-RQ-01 | 應識別並文件化產品所含全部軟體元件。 |
| PRE-7-RQ-02 | 每一元件至少記錄：軟體製造者、元件名稱、元件版本。 |
| PRE-7-RQ-03 | 應製作 SBOM，至少涵蓋產品所含之頂層依賴元件（top-level dependencies）——這是基本門檻。 |
| PRE-7-RQ-03-RE（強化要求） | 技術可行時，應將全部軟體元件（不只頂層）納入 SBOM，以偵測傳遞性依賴關係（transitive dependencies）。 |
| PRE-7-RQ-04 | SBOM 應以結構化、機器可讀格式製作（例：SPDX、CycloneDX）。 |
| PRE-7-RQ-05 | 軟體元件有新版本／新建置時，應建立新 SBOM 以反映該新版本。 |
| PRE-7-RC-01（建議） | 發現既有元件新資訊或需更正 SBOM 錯誤時，宜發布修訂版 SBOM。 |
| PRE-7-RQ-06 | SBOM 中繼資料應包含：作者、版本、時間戳記。 |
| PRE-7-RQ-07 | 每一元件除基本資訊外，應包含依賴關係及唯一識別碼（如 CPE、PURL、SWHID）。 |
| PRE-7-RQ-07-RE（強化要求） | 若供應商提供元件之雜湊值及對應演算法，應納入 SBOM。 |
這裡有兩個實務上很重要的細節。第一，標記「RE」（Requirement Enhancement，強化要求）的兩項——涵蓋傳遞性依賴、納入雜湊值——不是自動套用，而是依 [APP-1-RQ-01] 規定：「應依產品風險決定各項強化要求之適用性」，也就是由製造商依自身產品的風險評估結果，自行判斷是否需要做到這個程度。第二，PRE-7 同時也出現在漏洞處理流程的上游——例如 [PRE-1-RQ-04] 要求「為使議題及時解決，須有涵蓋開源在內之上游相依性對應表，以支援協調與通知活動」，說明 SBOM 不只是一份靜態文件，而是支撐整個漏洞應變流程的基礎資料。
補充：CRA 條文與 PRE-7 的強制要求都鎖定在軟體元件，但 prEN 40000-1-3 註記，技術可行時可將硬體元件一併納入 SBOM，讓相依性追溯更完整，這不是法定下限，而屬於加值做法。
Q：CRA 要求的 SBOM 要做到多深？
條文要求以常用且機器可讀格式（如 SPDX、CycloneDX）製作，至少涵蓋產品的頂層依賴；技術可行時可進一步納入傳遞性依賴（此屬強化要求，由廠商依風險決定）。每次新版本、新建置都應重新產生對應 SBOM。
Q：做過 EN 18031 認證，等於已經有 SBOM 嗎？
不等於。EN 18031 對應的是產品屬性要求（Annex I Part I），而 SBOM 是漏洞處理義務（Part II）的一環，兩者分屬 Annex I 的不同部分。既有認證的技術工作可延續，但對 CRA 的 SBOM 還需另行建立。
Q：CRA 的 SBOM 與技術文件要保存多久？
依 Article 13 與 Annex VII，技術文件（必要時含 SBOM）需保存至少 10 年，或產品支援期（取較長者）。
本文所引法規條文與時間點，均以下列文件為準：
文／安合規律 × Applus+ Laboratories 顧問團隊
＊本文為法規解讀性質，非法律意見。prEN 40000 系列標準截至本文撰寫時仍為 Draft for Public Comment，尚未刊登於歐盟官方公報，條文編號與內容在正式公布前可能變動；個案之最終合規認定，仍應以歐盟官方文件與主管機關解釋為準。
