台灣 ODM 與零組件供應商 CRA 指南：SBOM 與漏洞判定

2026 年 9 月 11 日，EU 品牌的 CRA 漏洞通報義務正式生效。從那一天起，若 EU 品牌知悉產品內有被積極利用的漏洞，就有 24 小時提交早期預警。要做到這一點，他們可能會要求供應商以短於 24 小時的 SLA 提供足夠資訊，常見設計是 12 小時。

這份 12 小時 SLA 不是 CRA 直接寫給 ODM 的硬性時限。它是 EU 品牌為了保留自身通報作業時間，可能寫入代工合約的商業控制項。

台灣五大 ODM 代工廠（和碩聯合科技（Pegatron）、仁寶電腦（Compal）、緯創資通（Wistron）、英業達（Inventec）、廣達電腦（Quanta））是本文的核心讀者。BMC、NIC、網通模組、韌體套件與連網晶片供應商也需要看同一套邏輯：你可能不是 EU 品牌成品的製造商，但你交付的元件證據會直接影響客戶能不能完成 CRA 檔案。

本文說明合約條款的來源邏輯、七項核心條款的實務內容、如何在量產環境建立 SBOM 自動化、以及如何利用既有的 IEC 62443 建置縮短差距。

為什麼 EU 品牌會把 CRA 義務轉嫁給台灣 ODM

CRA 的法律義務落在以自有品牌在 EU 市場銷售產品的「製造商」身上。對台灣 ODM 來說，這表示你的 EU 品牌客戶是法律意義上的製造商，而非你。

但這不代表你置身事外。

EU 品牌必須履行的 CRA 義務，許多直接取決於 ODM 能否提供特定資料與流程支援。以被積極利用漏洞的通報為例：EU 品牌一旦知悉產品內漏洞被積極利用，須於 24 小時內提交早期預警。如果漏洞出現在 ODM 提供的韌體元件中，EU 品牌需要先從 ODM 取得足夠資訊。

這就是短時限 SLA 的來源邏輯：

• EU 品牌的早期預警期限：24 小時
• EU 品牌需要留給自己準備通報的時間
• 因此：ODM 合約可能要求在取得被積極利用漏洞的可信證據後，以 12 小時等短時限通知 EU 品牌

這個邏輯同樣適用於 CRA 技術文件。EU 品牌負責向市場監督機關提交完整技術文件，其中包含 ODM 提供的元件層級資料。EU 品牌無法自己製造這些資料，只能從 ODM 的合約義務中取得。

合約壓力的時間點比多數 ODM 預期的早。CRA 漏洞通報義務從 2026 年 9 月 11 日生效，早於 CRA 全面適用日期約 15 個月。EU 品牌必須在 2026 年 9 月前確認供應鏈能支援 24 小時通報義務，因此短時限 SLA 條款可能提前出現在供應商合約中。

第一波合約修訂預計出現在 2026 年第三季至第四季。等到 2027 年才開始準備，會發現合約條款已經到位而能力尚未就緒。

零組件供應商什麼時候也要自己準備產品檔案？

台灣供應鏈常見的誤解，是把「元件」和「成品」混成同一件事。對 EU 品牌代工時，EU 品牌通常是成品的對外製造商；但如果台灣供應商把連網晶片、BMC 模組、NIC、DPU、網通模組、韌體套件或其他數位元件，以自己的名稱或商標供應到 EU 市場，這個元件本身可能也需要自己的 CRA 檔案。

判斷時先問三件事：

還有一個邊界：同規格替換用的維修備品，不應被寫成每一顆都自動落入 CRA。寫合約或文件時，重點是把「分開銷售的連網元件」和「嵌入成品的供應商料件」分清楚。

五大台灣 ODM 的產品線與 CRA 敏感度

以下五家公司依公開資料（年報、DigiTimes 報導、財務申報）整理其產品線與 CRA 適用性。客戶關係僅引用公開揭露資訊，未公開的合約關係不予引述。

重要提示： CRA 直接義務通常落在以自己名稱銷售成品的 EU 品牌身上，而非純代工 ODM。但較高風險產品清單中的品項，會讓 EU 品牌對 ODM 的合約要求更嚴格。防火牆、入侵偵測／防禦系統等高風險產品，通常會帶來更重的供應商技術文件要求。

EU 品牌合約中可能出現的 7 項 CRA 條款

以下七項條款反映的是 CRA 義務透過供應鏈合約的典型轉移機制，以及 ODM 在每項條款中需要注意的談判空間。這不是特定公司的合約文本，而是基於 CRA 義務結構的合理預期。

條款 1：SBOM 交付（CycloneDX 為主，元件版本層級）

合約要求的實際形態： EU 品牌要求 ODM 在每次韌體版本交付時，同步提供機器可讀格式的軟體物料清單（SBOM），格式可為 CycloneDX 或 SPDX 等常用且機器可讀格式，涵蓋所有第三方元件與開源函式庫，精確至版本號。

若 ODM 無法交付： EU 品牌在 Log4Shell 或 XZ Utils 類型漏洞爆發時，無法在 24 小時內判定影響範圍並透過 SRP 向協調者 CSIRT 與 ENISA 通報。品牌會承擔違規風險，並將合約責任追溯至 ODM。

談判建議： SBOM 格式（CycloneDX vs SPDX）通常可協商。CRA 目前要求常用且機器可讀格式，漏洞管理情境通常優先評估 CycloneDX；授權合規情境則常見 SPDX。元件版本精確度（版本號 vs patch level）應明確寫入合約，避免後續爭議。

重用既有 US EO 14028 SBOM： 已為美國聯邦客戶準備 EO 14028 SBOM 的台灣 ODM 不需從零開始。NIST 認可 SPDX、CycloneDX、SWID 三種為 EO 14028 情境下的標準 SBOM 格式。CRA 目前未強制特定格式，既有 SPDX 或 CycloneDX SBOM 是 CRA 適合性評估的合理起點。但歐盟執委會後續仍可能透過實施法案指定 SBOM 的格式與必要欄位。請將既有 US 格式 SBOM 視為下限（不是上限），持續追蹤歐盟執委會的實施法案，並準備在指定欄位發布時增補。

條款 2：CVD 政策與 security.txt 公開

合約要求的實際形態： 要求 ODM 建立書面的協調漏洞揭露（CVD）政策，並在企業網站 /.well-known/security.txt 路徑依 RFC 9116 格式放置聯絡檔案。

若 ODM 無法交付： 外部安全研究人員發現 ODM 韌體漏洞時，沒有標準通報渠道。漏洞可能先公開揭露或直達 EU 品牌，令 ODM 被動。

談判建議： CVD 政策的回應時限（acknowledgement within X days, patch within Y days）是可協商範疇。ODM 規模較小時，可要求 EU 品牌提供標準政策範本。

條款 3：12 小時通報 SLA（品牌 24 小時義務倒推）

合約要求的實際形態： ODM 一旦發現自家韌體元件存在被積極利用的漏洞，須在 12 小時內以書面通知 EU 品牌指定的資安聯絡人，包含：漏洞描述、CVE 編號（若已有）、受影響版本、已知利用情況、暫時緩解措施。

若 ODM 無法交付： EU 品牌無法在 24 小時內提交早期預警，會面臨市場監督機關調查。

談判建議： 「12 小時」的起算時間點至關重要：是從「發現漏洞」還是從「驗證該漏洞確實被積極利用」？建議 ODM 爭取以「取得可信確認之積極利用證據」為起算點，而非「首次知悉任何漏洞」。兩者在實務上差距可達數日。

條款 4：5 年韌體支援與安全更新承諾

合約要求的實際形態： ODM 須承諾在產品支援期內持續提供安全漏洞修補，包含底層硬體平台與韌體的支援。CRA 對製造商的支援期原則上不得少於 5 年；若產品預期使用年限短於 5 年，可依預期使用年限設定。

若 ODM 無法交付： EU 品牌本身須在產品支援期內提供免費安全更新。若 ODM 平台在 3 年後停止支援，品牌可能無法繼續履行義務，須自行吸收後端支援成本或強制換代。

談判建議： 支援期的起算點需要明確：是從「ODM 出貨日」還是從「EU 品牌首次在 EU 市場上架日」？這兩個日期可能相差 12-18 個月。另外，若 ODM 平台依賴第三方晶片廠商支援，應在合約中加入支援終止情境的處理條款，並要求品牌提前 12 個月通知換代計畫。

條款 5：技術文件元件區段交付

合約要求的實際形態： EU 品牌負責整份 CRA 技術文件，但文件中的「元件層級」部分（安全架構描述、元件風險評估、SBOM、安全測試報告）由 ODM 提供。

若 ODM 無法交付： EU 品牌無法向市場監督機關提交完整技術文件，CE 標章申請受阻，產品無法在 EU 合法上架。

談判建議： 應提前在合約中定義 ODM 負責交付的技術文件清單，以及格式要求與交付時程。模糊的「必要時提供技術文件」條款在審查時往往引發爭議。

條款 6：EU 適合性聲明（EU DoC）協作義務

合約要求的實際形態： EU 品牌在簽署 EU DoC 時，需要 ODM 確認底層韌體與硬體符合 CRA 的基本網路安全要求。合約通常要求 ODM 提供書面確認函，或提供 IEC 62443 / 其他認證佐證。

若 ODM 無法交付： EU 品牌無法簽署完整 EU DoC，CE 標章申請受阻。

談判建議： ODM 應確認書面確認函的具體措辭範圍，避免承擔超出自身設計職責的保證義務。

條款 7：稽核權（Right-to-audit）條款

合約要求的實際形態： EU 品牌保留在事先通知後（通常 30-60 天）對 ODM 的資安開發流程、SBOM 生成管線、漏洞通報記錄進行現場或遠端稽核的權利。

若 ODM 無法交付稽核： EU 品牌在市場監督機關要求提供供應鏈稽核記錄時，無法舉證盡責，可能面臨調查。

談判建議： 稽核範圍、頻率（每年一次或事件觸發）、費用分擔、替代稽核方式（第三方認證報告代替現場稽核）等均可協商。取得 IEC 62443-4-1 認證的 ODM 通常可以認證報告代替部分現場稽核要求。

12 小時通報 SLA 的實務設計

12 小時是一個需要事先建立基礎設施的時限。在漏洞爆發的當下臨時組織通報流程，必然超時。

以下是達成 12 小時 SLA 的幾個關鍵設計決策：

起算時間點的定義

CRA 通報時鐘的起算點，是製造商知悉漏洞被積極利用。但「知悉」的定義在 ODM 情境下需要具體化：

• 外部研究人員透過 CVD 管道通報，並提供可信的積極利用證據：確認證據時起算
• TWCERT/CC 發布公告，且明確指出 ODM 韌體元件已遭利用：公告發布即起算
• ODM 內部監測確認客戶環境或公開攻擊中已有利用證據：首次確認時起算

建議在合約中將 ODM 的 12 小時起算點定義為「取得可信的積極利用證據之時」（例如公開漏洞資料庫標記為已遭利用，或可信情資顯示同一元件已在未授權系統中被惡意利用），而非「任何漏洞首次出現在技術雷達上」。PoC 代碼通常只能證明可利用性，不應單獨等同於 CRA 的「被積極利用」。

內部 PSIRT 工作流程的最低要求

一個能達成 12 小時 SLA 的 PSIRT（產品資安應變小組）流程至少需要：

1. 7x24 值班輪班：漏洞通報和 CVE 狀態更新不會挑時段，週末晚上同樣可能爆發
2. 自動化監控：TWCERT/CC RSS 摘要、NVD CPE 比對、OSV.dev 訂閱，針對 ODM 所用的開源元件持續監控
3. 預先核准的通報範本：12 小時內不夠時間走完完整的法務審閱流程。預先核准的最低資訊範本（漏洞描述、受影響版本、暫時緩解）應在平時就準備好
4. 直達 EU 品牌資安聯絡人的通道：確認每家 EU 品牌客戶的技術安全聯絡窗口，而非走採購或業務

與 TWCERT/CC 流程的銜接

台灣 ODM 通常已與 TWCERT/CC 建立漏洞通報關係。CRA 的 SRP 通報是疊加在 TWCERT/CC 之上的獨立義務，對象不同（歐盟協調者 CSIRT 與 ENISA vs 台灣本地 CSIRT），但資料大多可以共用。

建議將通報流程設計為「單一事件，雙軌輸出」：同一份事件分析報告，同時產出 TWCERT/CC 格式通報和 CRA SRP 早期預警格式通報，減少重工。

SRP 狀態（2026 年 6 月 18 日）

ENISA 表示單一通報平台預計在 2026 年 9 月 11 日通報義務生效時可用，平台註冊、操作手冊與訓練資料會在 2026 年 6 月陸續提供。現階段不要假設可以用 API 自動送件；ENISA 目前說明的是手動或平台內流程，尚未提供 API。ODM 的 12 小時 SLA 應先以「能快速交付給 EU 品牌」為設計目標，而不是承諾直接替品牌完成 SRP 送件。

EUVD（歐洲漏洞資料庫）可以放進監測雷達，用來追蹤漏洞是否遭利用、是否已有緩解措施、是否需要升高優先順序。它不是通報管道，也不會自動啟動 CRA 通報時鐘。若事件已有 EUVD ID，可以作為 SRP 表單中的參考資訊；是否通報，仍要看產品是否受影響、是否有可信的積極利用證據、以及 EU 品牌或製造商何時知悉。

與 24 小時公開揭露規範的差異

許多 ODM 的工程團隊熟悉業界 CVD 的「90 天公開揭露」或「24 小時響應確認」慣例。12 小時 SLA 是完全不同的概念：

• 對象：通知 EU 品牌，而非公開揭露
• 觸發條件：漏洞被積極利用，而非任何漏洞
• 內容：早期預警最低資訊集，不要求完整修補方案

不要把 12 小時 SLA 和漏洞修補期限混為一談。通報的義務是在 12 小時內，修補的時程是另一個合約條款。

SBOM 在量產環境的自動化

台灣大型 ODM 的韌體生產規模，與小型嵌入式裝置廠商有根本差異。仁寶或廣達每天可能在量產線上建置數百個不同 SKU 的韌體映像（image），SBOM 生成不是一次性工作，而是需要整合進持續整合（CI）管線的基礎設施。

工具鏈選擇

目前主流的開源 SBOM 生成工具包含 Syft 和 cdxgen，兩者各有適合的使用情境：

• Syft：擅長從容器映像和檔案系統生成 SBOM，對 Linux 韌體根檔案系統（rootfs）支援良好，可輸出 CycloneDX 或 SPDX 格式
• cdxgen：擅長從程式語言的套件管理器（npm、pip、Maven）掃描依賴關係，適合應用層韌體

量產環境通常需要兩類工具搭配使用：系統層（kernel、busybox、libc）用 Syft，應用層（web UI 後端、管理代理程式）用 cdxgen。

量產環境的特殊挑戰

• SKU 爆炸：同一硬體平台在不同 EU 品牌客戶間有客製化差異（預載語言包、地區設定、功能解鎖），每個 SKU 理論上需要獨立的 SBOM
• 交叉編譯工具鏈：SBOM 必須在建置時（build time）生成，而非事後逆向分析。建置時的元件資訊最準確。
• SBOM 版本管理：每次韌體更新後，SBOM 必須同步更新，並與對應的韌體版本建立明確的關聯關係

建議將 SBOM 生成整合進韌體建置系統（Yocto / OpenWRT / Buildroot）的建置後步驟，在每次成功建置時自動輸出 CycloneDX JSON 格式的 SBOM，並儲存至版本控制系統中。

漏洞判定紀錄

SBOM 只能告訴你「哪個元件可能有 CVE」，不能直接告訴你「這個產品是否受影響」。EU 品牌真正需要的是每個韌體版本的判定紀錄：受影響、未受影響、已修補、調查中。VEX 是常見的機器可讀做法，但 CRA 沒有強制使用 VEX 這個名稱。重點是保留可稽核理由，例如：易受攻擊函式未編譯進映像、服務未啟用、受影響程式碼不可到達、已在某一版韌體修補。

這份判定紀錄應和 SBOM、韌體版本、客戶型號、修補版本、通知狀態連在一起。沒有這層紀錄，EU 品牌在 24 小時內只能看到一串 CVE，卻無法判斷哪些 SKU 真的需要通報或緊急修補。

SBOM 格式選擇

CRA 目前要求 SBOM 採常用且機器可讀格式，並未指定單一格式。建議 ODM 在沒有 EU 品牌特別指定格式的情況下，漏洞管理工作流優先評估 CycloneDX，授權合規工作流同步保留 SPDX；同時追蹤歐盟執委會後續指定格式與欄位的實施規則。

雲端後端與遠端診斷

如果 ODM 同時提供裝置雲端、OTA 後端、fleet portal、遠端診斷、OCPP / 智慧能源後端或資料中心管理服務，而且產品少了這個後端就無法完成其中一項功能，該後端不能被簡單寫成「客戶 IT 系統」。合約要說清楚：哪些後端由 ODM 供應，哪些由 EU 品牌供應，哪些是最終使用者自己的環境。ODM 供應的後端，通常也要納入 SBOM、漏洞處理、更新流程與支援期證據。

IEC 62443-4-1 既有建置的再利用

廣達（Quanta）旗下的 QCT（廣達雲端技術）與緯創資通的部分伺服器產品線，已依 IEC 62443-4-1 標準建置安全開發生命週期（SDL）。若你的 ODM 已取得或正在取得 IEC 62443-4-1 認證，在 CRA 準備上有具體的再利用機會。

flowchart LR
    subgraph IEC["IEC 62443-4-1 已覆蓋（元件層級）"]
        A1["安全需求管理\nSR-1 至 SR-6"]
        A2["安全設計\n威脅模型"]
        A3["安全實作\n程式碼審查"]
        A4["安全驗證\n滲透測試"]
        A5["安全更新管理\n修補流程"]
    end

    subgraph GAP["CRA 額外要求\n（IEC 62443-4-1 未覆蓋）"]
        B1["SBOM\n機器可讀格式\nCycloneDX/SPDX"]
        B2["ENISA SRP\n24h 通報流程\n（元件層級觸發）"]
        B3["security.txt\nRFC 9116 格式"]
        B4["技術文件\n元件區段"]
    end

    IEC --> PARTIAL["IEC 62443-4-1 可重用\n元件層級流程證據"]
    GAP --> MUST["仍須獨立\n建立的能力"]

IEC 62443-4-1 的 SDL 流程記錄（需求追蹤、設計審查、安全測試報告）可以直接用於 CRA 技術文件的元件區段，減少重複工作。但以下四項 CRA 特有要求，IEC 62443-4-1 不涵蓋：

1. 機器可讀 SBOM：IEC 62443 的元件清單要求較鬆散，CRA 要求以常用且機器可讀格式輸出元件清單，實務上常見 CycloneDX/SPDX
2. ENISA SRP 通報流程：IEC 62443 的事件應變聚焦在 OT 環境，CRA 的通報入口是 ENISA 單一通報平台，收件流程涉及協調者 CSIRT 與 ENISA
3. security.txt 公開：IEC 62443 無此要求
4. 技術文件格式轉換：IEC 62443 認證報告須轉換成 CRA 技術文件需要的章節結構

對於尚未建立 IEC 62443 認證的 ODM，以上四項仍是最優先的準備項目，因為它們也是 EU 品牌合約要求最先到位的核心能力。

時程：從現在到 2027 年 12 月

flowchart LR
    NOW["📅 準備期\n2026 年上半年"] --> M1["2026 年 Q2-Q3\n產品線盤點完成\nSBOM 管線建置啟動\nCVD 政策與 security.txt 上線"]
    M1 --> SEP["⚠️ 2026 年 9 月 11 日\nCRA 通報義務生效\nEU 品牌開始要求\n12 小時 SLA"]
    SEP --> M2["2026 年 Q4\n第一波合約修訂到達\nSBOM 交付能力須就位\nIEC 62443 差距分析完成"]
    M2 --> M3["2027 年 H1\n技術文件元件交付\nEU DoC 協作義務生效\n5 年支援條款確認"]
    M3 --> DEC["🔴 2027 年 12 月 11 日\nCRA 全面適用\n全部合約義務應已到位"]

關鍵時間點提醒： 2026 年 9 月 11 日不是「開始準備」的期限，而是「SBOM 交付與 12 小時通報能力必須已在運作」的期限。在那一天之前，EU 品牌的合約修訂請求已經在途中了。

本文內容僅供參考，不構成法律建議。有關 EU 產品法規的具體合規要求，請諮詢熟悉 EU 法規的法律專業人士。