台灣 ODM 代工廠的 CRA 合約生存指南：EU 品牌要求的 SBOM、CVD 政策與 12 小時通報義務
歐盟品牌在 2026-2027 年將把 CRA 合規義務透過合約條款轉嫁給台灣 ODM 代工廠。和碩、仁寶、緯創、英業達、廣達需要提前準備 SBOM、CVD 政策、12 小時通報 SLA 與 5 年韌體支援。本文整理 7 項常見合約條款與實務準備清單。
本文內容
2026 年 9 月 11 日，EU 品牌的 CRA 漏洞通報義務正式生效。從那一天起，EU 品牌有 24 小時向 ENISA 提交早期預警的法律義務。要做到這一點，他們需要在 12 小時內從你這裡拿到通報。
這份 12 小時 SLA 不會出現在 CRA 條文中。它會出現在你明年收到的代工合約修訂版裡。
台灣五大 ODM 代工廠（和碩聯合科技（Pegatron）、仁寶電腦（Compal）、緯創資通（Wistron）、英業達（Inventec）、廣達電腦（Quanta））目前在整個部落格語料庫中都未被直接點名討論。這篇文章的讀者，就是這五家公司的工程、法務、採購主管。
本文說明合約條款的來源邏輯、七項核心條款的實務內容、如何在量產環境建立 SBOM 自動化、以及如何利用既有的 IEC 62443 建置縮短差距。
摘要
- CRA 第 14 條要求 EU 品牌在 24 小時內向 ENISA 通報被積極利用的漏洞，這迫使 EU 品牌在合約中要求 ODM 12 小時內通知
- 合約壓力比法規期限提前到來：第一波合約修訂預計出現在 2026 年第四季，早於 2027 年 12 月的全面適用日
- 台灣五大 ODM（和碩、仁寶、緯創、英業達、廣達）的網通、伺服器、IoT 產品線均落入 CRA 規範範圍
- EU 品牌合約將包含七項核心 CRA 條款：SBOM 交付、CVD 政策、12 小時通報、5 年韌體支援、附件 VII 技術文件、EU DoC 協作、稽核權
- 量產環境的 SBOM 自動化需要不同於小型韌體廠商的工具鏈規劃
- 已取得 IEC 62443-4-1 認證的 ODM 可再利用約 60-70% 的 CRA 附件 I 證據，但 SBOM 格式與 ENISA 通報流程仍須獨立補齊
- 5 年安全更新承諾是合約談判中 ODM 最需要明確界定範圍的條款
為什麼 EU 品牌會把 CRA 義務轉嫁給台灣 ODM
CRA 的法律義務落在以自有品牌在 EU 市場銷售產品的「製造商」身上。對台灣 ODM 來說，這表示你的 EU 品牌客戶是法律意義上的製造商，而非你。
但這不代表你置身事外。
EU 品牌必須履行的 CRA 義務，許多直接取決於 ODM 能否提供特定資料與流程支援。以 CRA 第 14 條的漏洞通報為例：EU 品牌在收到漏洞情資後須於 24 小時內向 ENISA 提交早期預警。如果漏洞出現在 ODM 提供的韌體元件中，EU 品牌需要先從 ODM 取得足夠資訊。
這就是 12 小時 SLA 的來源邏輯：
- EU 品牌的 ENISA 通報期限：24 小時
- EU 品牌需要留給自己準備通報的時間：約 12 小時
- 因此：ODM 必須在發現漏洞後 12 小時內通知 EU 品牌
這個邏輯同樣適用於 CRA 附件 VII 技術文件。EU 品牌負責向市場監督機關提交完整技術文件，其中包含 ODM 提供的元件層級資料。EU 品牌無法自己製造這些資料，只能從 ODM 的合約義務中取得。
合約壓力的時間點比多數 ODM 預期的早。CRA 第 14 條漏洞通報義務從 2026 年 9 月 11 日生效，早於 CRA 全面適用日期約 15 個月。EU 品牌必須在 2026 年 9 月之前將 12 小時 SLA 要求寫入供應商合約，因為在那一天，他們自己就必須開始履行 24 小時通報義務。
第一波合約修訂預計出現在 2026 年第三季至第四季。等到 2027 年才開始準備，會發現合約條款已經到位而能力尚未就緒。
五大台灣 ODM 的產品線與 CRA 敏感度
以下五家公司依公開資料（年報、DigiTimes 報導、財務申報）整理其產品線與 CRA 適用性。客戶關係僅引用公開揭露資訊，未公開的合約關係不予引述。
| 公司 | 英文名 | CRA 相關產品線 | CRA 適用性說明 |
|---|---|---|---|
| 和碩聯合科技 | Pegatron | 筆記型電腦、智慧型手機、IoT 設備、網通模組 | 網通模組與 IoT 設備若含網路功能，落入 CRA 附件 III 重要產品範圍；公開資料顯示和碩為多家歐美品牌組裝多種消費電子產品 |
| 仁寶電腦 | Compal | 筆記型電腦、智慧顯示器、IoT 裝置 | 仁寶為全球最大筆記型電腦 ODM 之一，公開資料顯示其客戶涵蓋多家全球前五大 PC 品牌；筆記型電腦若含網路連線功能屬 CRA 一般產品 |
| 緯創資通 | Wistron | 伺服器、筆記型電腦、網通設備、顯示器 | 伺服器與網通設備若為 EU 品牌客戶的 CRA 義務產品線，則屬於附件 VII 技術文件協作範疇；公開資料顯示緯創為多家美國雲端服務商提供伺服器代工 |
| 英業達 | Inventec | 伺服器、筆記型電腦、智慧裝置 | 公開資料顯示英業達為多家雲端服務商及品牌廠提供伺服器代工；伺服器產品若為受管基礎設施使用，CRA 合規義務透過合約下移至英業達 |
| 廣達電腦 | Quanta | 筆記型電腦、伺服器、雲端資料中心硬體 | 廣達為全球最大筆記型電腦 ODM（公開資料）；旗下廣達雲端技術（QCT）子公司為歐洲資料中心提供基礎設施硬體，是 CRA 合約義務最直接的涉及方 |
重要提示： CRA 直接義務落在 EU 品牌（製造商）身上，而非台灣 ODM。但附件 III 「重要產品」品項的分類敏感度，決定了 EU 品牌對 ODM 合約要求的嚴格程度。Class II 產品（防火牆、IDS/IPS）須第三方認證，帶來更嚴格的供應商技術文件要求。
EU 品牌合約中可能出現的 7 項 CRA 條款
以下七項條款反映的是 CRA 法律義務透過供應鏈合約的典型轉移機制，以及 ODM 在每項條款中需要注意的談判空間。這不是特定公司的合約文本，而是基於 CRA 條文邏輯的合理預期。
第 1 條：SBOM 交付（CycloneDX 為主，元件版本層級）
合約要求的實際形態： EU 品牌要求 ODM 在每次韌體版本交付時，同步提供機器可讀格式的軟體物料清單（SBOM），格式為 CycloneDX 1.4 或以上版本，涵蓋所有第三方元件與開源函式庫，精確至版本號。
若 ODM 無法交付： EU 品牌在 Log4Shell 或 XZ Utils 類型漏洞爆發時，無法在 24 小時內判定影響範圍並向 ENISA 通報。品牌會承擔違規風險，並將合約責任追溯至 ODM。
談判建議： SBOM 格式（CycloneDX vs SPDX）通常可協商，但 ENISA 偏好 CycloneDX。元件版本精確度（版本號 vs patch level）則應明確寫入合約，避免後續爭議。
第 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（品牌向 ENISA 24 小時義務倒推）
合約要求的實際形態： ODM 一旦發現自家韌體元件存在被積極利用的漏洞，須在 12 小時內以書面通知 EU 品牌指定的資安聯絡人，包含：漏洞描述、CVE 編號（若已有）、受影響版本、已知利用情況、暫時緩解措施。
若 ODM 無法交付： EU 品牌無法在 24 小時內向 ENISA 提交早期預警，違反 CRA 第 14 條，面臨市場監督機關調查。
談判建議： 「12 小時」的起算時間點至關重要：是從「發現漏洞」還是從「驗證該漏洞確實被積極利用」？建議 ODM 爭取以「取得可信確認之積極利用證據」為起算點，而非「首次知悉任何漏洞」。兩者在實務上差距可達數日。
第 4 條：5 年韌體支援與安全更新承諾
合約要求的實際形態： ODM 須承諾在產品上市後至少 5 年內，持續提供安全漏洞修補，包含底層硬體平台與韌體的支援。
若 ODM 無法交付： EU 品牌本身對 CRA 第 13 條有 5 年免費安全更新義務，若 ODM 平台在 3 年後停止支援，品牌無法繼續履行義務，須自行吸收後端支援成本或強制換代。
談判建議： 「5 年」的起算點需要明確：是從「ODM 出貨日」還是從「EU 品牌首次在 EU 市場上架日」？這兩個日期可能相差 12-18 個月。另外，若 ODM 平台依賴第三方晶片廠商支援，應在合約中加入「不可抗力免責條款」並要求品牌提前 12 個月通知換代計畫。
第 5 條：附件 VII 技術文件區段交付
合約要求的實際形態： EU 品牌負責整份 CRA 附件 VII 技術文件，但文件中的「元件層級」部分（安全架構描述、元件風險評估、SBOM、安全測試報告）由 ODM 提供。
若 ODM 無法交付： EU 品牌無法向市場監督機關提交完整技術文件，CE 標章申請受阻，產品無法在 EU 合法上架。
談判建議： 應提前在合約中定義 ODM 負責交付的技術文件清單，以及格式要求與交付時程。模糊的「必要時提供技術文件」條款在審查時往往引發爭議。
第 6 條：EU 適合性聲明（EU DoC）協作義務
合約要求的實際形態： EU 品牌在簽署 EU DoC 時，需要 ODM 確認底層韌體與硬體符合 CRA 附件 I 的基本網路安全要求。合約通常要求 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 第 14 條的起算點是「製造商知悉（aware）」被積極利用的漏洞。但「知悉」的定義在 ODM 情境下需要具體化：
- 外部研究人員透過 CVD 管道通報：收到報告即起算
- TWCERT/CC 發布公告中包含 ODM 韌體元件：公告發布即起算
- ODM 內部測試發現可利用漏洞：首次確認時即起算
建議在合約中將 ODM 的 12 小時起算點定義為「取得可信的積極利用證據之時」（例如公開 CVE 狀態標記為 actively exploited，或收到 PoC 代碼），而非「任何漏洞首次出現在技術雷達上」。
內部 PSIRT 工作流程的最低要求
一個能達成 12 小時 SLA 的 PSIRT（產品資安應變小組）流程至少需要：
- 7x24 值班輪班：漏洞通報和 CVE 狀態更新不會挑時段，週末晚上同樣可能爆發
- 自動化監控：TWCERT/CC RSS 摘要、NVD CPE 比對、OSV.dev 訂閱，針對 ODM 所用的開源元件持續監控
- 預先核准的通報範本：12 小時內不夠時間走完完整的法務審閱流程。預先核准的最低資訊範本（漏洞描述、受影響版本、暫時緩解）應在平時就準備好
- 直達 EU 品牌資安聯絡人的通道：確認每家 EU 品牌客戶的技術安全聯絡窗口，而非走採購或業務
與 TWCERT/CC 流程的銜接
台灣 ODM 通常已與 TWCERT/CC 建立漏洞通報關係。CRA 的 ENISA SRP 通報是疊加在 TWCERT/CC 之上的獨立義務，對象不同（EU 市場監督機關 vs 台灣本地 CSIRT），但資料大多可以共用。
建議將通報流程設計為「單一事件，雙軌輸出」：同一份事件分析報告，同時產出 TWCERT/CC 格式通報和 ENISA SRP 早期預警格式通報，減少重工。
與 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，並儲存至版本控制系統中。
ENISA 的格式偏好
ENISA 在 2024 年發布的 SBOM 指引（ENISA SBOM Landscape）中，明確表達對 CycloneDX 格式的偏好，認為其在漏洞資料關聯方面表現較佳。建議 ODM 在沒有 EU 品牌特別指定格式的情況下，預設採用 CycloneDX 1.4 或以上版本。
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 附件 I 額外要求\n（IEC 62443-4-1 未覆蓋）"]
B1["SBOM\n機器可讀格式\nCycloneDX/SPDX"]
B2["ENISA SRP\n24h 通報流程\n（元件層級觸發）"]
B3["security.txt\nRFC 9116 格式"]
B4["附件 VII\n元件區段文件"]
end
IEC --> PARTIAL["IEC 62443-4-1 覆蓋\nCRA 附件 I\n元件層級約 60-70%"]
GAP --> MUST["仍須獨立\n建立的能力"]
IEC 62443-4-1 的 SDL 流程記錄（需求追蹤、設計審查、安全測試報告）可以直接用於 CRA 附件 VII 的技術文件元件區段，減少重複工作。但以下四項 CRA 特有要求，IEC 62443-4-1 不涵蓋：
- 機器可讀 SBOM：IEC 62443 的元件清單要求較鬆散，CRA 要求精確到版本號、以 CycloneDX/SPDX 格式輸出
- ENISA SRP 通報流程：IEC 62443 的事件應變聚焦在 OT 環境，CRA 的通報對象是 EU 市場監督機關
- security.txt 公開：IEC 62443 無此要求
- 附件 VII 格式合規：IEC 62443 認證報告須轉換成 CRA 附件 VII 的特定章節結構
對於尚未建立 IEC 62443 認證的 ODM，以上四項仍是最優先的準備項目，因為它們也是 EU 品牌合約要求最先到位的核心能力。
時程：從現在到 2027 年 12 月
flowchart LR
NOW["📅 現在\n2026 年 4 月"] --> M1["2026 年 Q2-Q3\n產品線盤點完成\nSBOM 管線建置啟動\nCVD 政策與 security.txt 上線"]
M1 --> SEP["⚠️ 2026 年 9 月 11 日\nENISA 通報義務生效\nEU 品牌開始要求\n12 小時 SLA"]
SEP --> M2["2026 年 Q4\n第一波合約修訂到達\nSBOM 交付能力須就位\nIEC 62443 差距分析完成"]
M2 --> M3["2027 年 H1\n附件 VII 元件文件交付\nEU DoC 協作義務生效\n5 年支援條款確認"]
M3 --> DEC["🔴 2027 年 12 月 11 日\nCRA 全面適用\n全部合約義務應已到位"]
關鍵時間點提醒： 2026 年 9 月 11 日不是「開始準備」的期限，而是「SBOM 交付與 12 小時通報能力必須已在運作」的期限。在那一天之前，EU 品牌的合約修訂請求已經在途中了。
常見問題
EU 品牌在什麼時候會開始把 CRA 條款加入代工合約?
預計在 2026 年第三季至第四季出現第一波合約修訂，原因是 CRA 第 14 條的 ENISA 漏洞通報義務從 2026 年 9 月 11 日生效。EU 品牌必須在那天之前確保其供應鏈能夠支援 24 小時通報義務，因此 12 小時 SLA 條款會最早到位。附件 VII 技術文件的合約要求通常在 2027 年上半年才全面到位。詳見台灣網通/IoT 品牌廠的 CRA 實戰指南的時程說明。
我是純 ODM（不以自有品牌在 EU 銷售），是否仍需自行向 ENISA 通報?
純 ODM 不在 EU 市場以自有品牌銷售產品，不具備 CRA 定義的「製造商」地位，因此 ENISA 通報義務不直接落在 ODM 身上（CRA 第 13 條）。然而，若你同時在 EU 市場以自有品牌直銷任何含網路功能的產品，那部分的義務是你自己的。更多關於 CRA 適用性的判定邏輯，請參閱CRA 適用性確認工具。
如果我們已取得 IEC 62443-4-1 認證，EU 品牌還會要求額外的 CRA 證據嗎?
會。IEC 62443-4-1 認證可覆蓋 CRA 附件 I 元件層級要求的約 60-70%，包含安全開發流程、威脅模型、安全驗證。但 SBOM 機器可讀格式、ENISA SRP 通報流程、security.txt 公開、附件 VII 特定章節格式，均不在 IEC 62443-4-1 範疇內，須獨立準備。EU 品牌的合約通常會要求 ODM 在 IEC 62443 認證基礎上，補充說明上述缺口的填補方式。
12 小時通報 SLA 的起算時間點是什麼? 從發現漏洞還是從驗證可利用性?
CRA 第 14 條的觸發條件是製造商「知悉（aware）」漏洞被積極利用，而非「首次發現任何漏洞」。這對 ODM 的合約談判有實際意義: 應爭取將 12 小時 SLA 起算點定義為「取得可信的積極利用確認證據」，例如 NVD 將 CVE 標記為 actively exploited、或收到包含 PoC 的通報，而非任何漏洞消息的首次出現。這個定義在合約文字中應明確寫入，避免後續爭議。更多台灣製造商 CRA 義務概論，請參閱台灣製造業者 EU CRA 完全指南。
5 年安全更新承諾，如果產品提前停產（EOL），合約責任如何處理?
這是目前 ODM 在合約談判中最需要主動界定的條款。CRA 第 13 條第 8 項要求製造商確保安全更新可用的期間不少於 5 年（或產品預期使用年限，以較長者為準）。若 ODM 的底層硬體平台依賴第三方晶片廠商支援（例如某款 SoC 的官方支援期為 4 年），應在合約中: (一) 明確約定 5 年起算基準日，(二) 加入晶片廠商支援終止時的免責條款，(三) 要求品牌至少提前 12 個月通知是否要求換代方案。
台灣 ODM 常見 7 大合約條款中，哪些可以協商、哪些是硬性要求?
硬性要求（法律義務直接下移，無協商空間）: 12 小時通報 SLA 的存在本身、SBOM 交付的存在本身、5 年支援承諾的期限。可協商的範疇: SBOM 格式（CycloneDX vs SPDX）、12 小時的起算點定義、SBOM 精確度層級、附件 VII 元件區段的具體格式、稽核的方式（現場稽核 vs 第三方認證報告替代）。建議透過免費評估取得針對貴公司合約現況的書面差距分析報告，明確列出每項條款的協商空間與優先順序。
後續步驟
下一階段的工作是把合約壓力的預期落實到 SBOM 管線、CVD 政策、12 小時通報 SOP、IEC 62443 差距分析、附件 VII 範本與合約審查機制六個必要組件。
本文內容僅供參考，不構成法律建議。有關 EU 產品法規的具體合規要求，請諮詢熟悉 EU 法規的法律專業人士。
相關文章
CRA 是否適用於你的產品？
回答6個簡單問題，了解你的產品是否屬於 EU 網路韌性法的適用範圍。2分鐘內即可獲得結果。