歐盟《網路韌性法》初探（八之八）

EU Cyber Resilience Act（CRA）

Regulation (EU) 2024/2847 + Corrigendum B / C1 / C2 / C3

（續前篇）

適合產業界、驗證業、資訊安全、網路安全及軟/硬/韌體工程師、企業管理者或法規政策研究人員，具備大學教育背景但對歐盟法規未盡熟悉的亞洲讀者閱讀。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。法規內容可能隨時間修訂，具體符合決策宜諮詢歐盟專業法律及資安顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算，實際數值可能隨時變動。參考法規資訊截至2026年3月，後續修訂請查閱歐盟CRA官方網站和EUR-Lex資料庫。 © All Rights reserved。 版權聲明。CC BY-SA 4。0。

第十八章　風險評估、陷阱、改善建議與實際案例

18.1　已知漏洞、新興風險與主要陷阱

（一）技術層面的常見陷阱

●     預設密碼未更改：最簡單卻最常見的違規，直接觸犯 CRA 附錄I Part I 要求。2021年 Mirai 殭屍網路攻擊即源於此

●     未追蹤的開源元件：Log4Shell（CVE-2021-44228）漏洞影響數以千計使用 Log4j 函式庫的產品，許多製造商甚至不知道自己的產品含有此元件

●     SBOM 不完整：採購的商業 SDK 或硬體模組供應商未提供 SBOM，導致整合後的 SBOM 出現空白。

●     OTA 更新無法驗證簽章：更新機制未做程式碼簽章驗證，使產品易受惡意更新攻擊。

●     支援期間計算錯誤：製造商宣稱「5 年支援」，但從首次販售日起計算，而非最後一次市場投入，導致期間被低估。

●     完全豁免的限制條款：在2027年11月11日之前已經最終交付給終端使用者的PDE產品，豁免CRA符合性要求，但排除以下情況之一 （即使已經生產好放在倉庫的產品，如果在該日期後才放入歐盟市場，還是需要完全符合CRA）：

a.    任何在該日期之後繼續販賣的產品，不論當初生產的日期；

b.    任何在該日期之後推送的任何軟體更新；

c.     任何在該日期之後新啟用的功能。

●     搭便車迷思：「軟體漏洞是從第三方程式庫取得的，所以不是製造商的責任」；當製造商將外來程式放到自己的產品裡面，製造商就負全部的產品責任，原始開發者並不是產品安全責任的首要承受對象。

●     時間段迷思：「該項軟體漏洞在當年出貨的時候還沒有人發現，既然當時已經出貨，客戶也收下來，所以製造商沒有責任做後續的更新或發出補丁」。CRA條例的立法原則係嚴格責任制，不論製造商當時是否知道漏洞的存在，只要PDE產品仍在生命周期內，製造商負起後續的更新或做出矯正措施的責任。

（二）法規合規陷阱

●     「通過 ISO 27001 認證就夠了」的誤解：ISO 27001 認證是組織層級的管理系統，尚無法取代產品層級的 CRA 符合性評鑑的管理制度及技術文件要求。

●     進口商不知自身法律責任：亞洲製造商在歐盟無設立據點時，其歐盟進口商承擔大部分法律責任，但多數進口商對此認識不足。

●     重大修改觸發重新評估：產品韌體版本更新(Patching)若引入新的網路功能，或涉及核心架構，可能被認定為「重大修改」，需重新執行符合性評鑑。

●     EU DoC 內容不正確：EU 符合性聲明若引用錯誤的調和標準或遺漏必要資訊，構成直接違規。

●     證書迷思：「誤以為「基本級 (Basic)」PDE產品的自我聲明在所有應用場景都有同等效力」。實務上，在 B2B 場景或企業招標公告中，業主通常要求「重要」或「關鍵」等級的PDE產品。

●     供應商迷思：「身為零組件供應商，僅負責供貨，下游製造商才需要負責符合性問題」；條例第11條亦規定零組件供應商負連帶責任，主管機關可以越過下游製造商追溯到上游供應商而直接課處罰鍰。

●     大盤商迷思：「身為大盤商，將產品只賣給企業級客戶，所以不適用CRA條例」；大盤商雖然不是直接面對消費者，但放入歐盟市場的PDE產品，便適用CRA條例，而且商業和工業產品適用比消費型產品更嚴格的要求。

●     結束營業迷思：「本企業已經結束該項PDE產品業務，永久離開該產業，所以不用繼續提供軟體更新或補丁」。CRA條例的立法原則係嚴格責任制，製造商的支援義務不會因為停止營業或者停產PDE產品而終止。

18.2　風險評估方法論

CRA 要求製造商對PDE產品進行「網路資訊安全風險評鑑」，以下是建議的操作架構：

l   資產識別（Asset Identification）：列出產品中所有值得保護的資產，包含資料、功能、通訊介面；

l   威脅建模（Threat Modeling）：採用 STRIDE（Spoofing/ Tampering/ Repudiation/ Information Disclosure/DoS/Elevation）或 PASTA 方法論，系統化識別潛在威脅；

l   漏洞分析（Vulnerability Analysis）：結合 SBOM 比對 NVD（National Vulnerability Database），識別已知 CVE；

l   風險評分（Risk Scoring）：採用 CVSS（Common Vulnerability Scoring System）量化漏洞嚴重性；

l   風險減緩（Risk Mitigation）：針對高風險項目制定具體緩解措施或接受風險的理由；

l   殘餘風險評估（Residual Risk Assessment）：確認採取措施後殘餘風險可被接受。

 

18.3　附錄I 的改善行動建議

Part I — 設計及開發要求的具體落實

●     建立安全開發生命週期（SDL）：採用 OWASP SAMM 或 BSIMM 架構衡量現有成熟度，再制定改善路線圖

●     採用「零信任架構」（Zero Trust Architecture）：假設內部網路同樣不安全，所有存取均需驗證

●     強化身份驗證：禁用預設密碼，要求初次使用時設定強密碼或採用無密碼認證（FIDO2）

●     實施最小化資料收集：只收集產品功能所需最少量的個人資料（與 GDPR §5 協同）

●     定期進行第三方滲透測試：至少每年一次，覆蓋新版本發布前後

Part II — 漏洞處理改善

●     建立安全資訊中心（Security Advisory Page）：在官方網站發布 CVE 公告及對應更新連結

●     採用自動化掃描工具：將 SAST/DAST/SCA 整合進 CI/CD 管道，確保每次程式碼提交都經過安全掃描

●     設定 SLA 處理時程：依 CVSS 評分設定漏洞修補期限（如 CVSS 9.0+ 在 7 天內發布修補） 

18.4　真實案例研究

案例一：Log4j事件 2021

事件概述：Log4j(Log4Shell) 是由 Apache 軟體基金會開發的 Java 日誌架構，廣泛應用於全球數百萬個應用程式中。屬於「遠端代碼執行 (RCE)」漏洞（CVE-2021-44228）。攻擊者只需向受影響的伺服器發送一串特殊的字串（如透過 Header 或登入欄位），利用 Java 命名和目錄介面 (JNDI) 缺陷，即可誘使伺服器下載並執行惡意程式碼。CVSS 評分達到最高分 10.0，屬於致命性風險等級。谷歌公司Google 估計超過 35,000 個 Java 套件受到衝擊，佔當時 Maven Central 套件庫的 8% 以上。全球頂尖雲端商（AWS, Microsoft, iCloud）、企業軟體及工業控制系統無一倖免。雖然具體的經濟損失難以精確量化，但數以萬計的企業需緊急停機維護。美國網路資訊安全審查委員會 (CSRB) 指出，Log4j 將是一個「長達十年的問題」，因為它深埋在許多遺留系統（Legacy Systems）中，其修補的人力成本估計達數十億美元。

CRA 啟示：在CRA架構下，每一個把Log4j包含在PDE產品裡面的製造商都會負起連帶責任。Apache基金會本身則係符合開源豁免的條款，而免遭CRA處罰。依照CRA條例，軟體開發商或將受影響軟體整合進PDE產品的廠商（包括大型商業開發者）必須履行下列義務：

措施	行動事項
24小時早期預警	製造商一旦察覺漏洞被「積極利用」(Actively Exploited)，必須在 24 小時內向 ENISA 與該國 CSIRT 提交初步通報
72小時強制通報	在 72 小時內提供詳細的技術分析、風險評估與緩解建議
軟體材料清單 (SBOM) 的強制調閱	CRA 要求製造商必須維護 SBOM。企業必須清楚知道其產品中使用了哪些開源組件（如 Log4j） 在 2021 年，許多企業甚至不知道自己使用了 Log4j，但在 CRA 架構下，這已構成違犯CRA條例的必要條件
立即修補與安全性更新	製造商必須在漏洞發現後立即開發補丁，並透過自動更新機制推播給用戶。 如果無法修補，必須提供明確的停用建議

相對地，CRA條例要求歐盟執行委員會與各成員國監管機構採取的干預措施：

措施	行動事項
建立單一通報平台 (SRP)	由 ENISA 運行的平台將彙整所有 Log4j 的攻擊數據，並即時向全歐盟的關鍵基礎設施（如電力、醫療）發布預警
市場監督與產品召回	若某廠商未能及時提供 Log4j 的修補程式，或隱瞞漏洞不報，國家監管機構有權要求該產品從歐盟市場撤回 (Withdrawal) 或 召回 (Recall)
高額罰鍰 (fines)	對於未履行漏洞處理義務的廠商，CRA 規定了最高 1,500 萬歐元 或 全球年營業額 2.5% 的行政罰鍰（以較高者為準）

案例二：SolarWinds 供應鏈攻擊（2020-2021）

事件概述：俄羅斯 APT 組織在 SolarWinds Orion 的合法動態連結庫建置流程中植入惡意程式碼（SUNBURST）後門程式，由於該檔案擁有 SolarWinds 的官方數位簽章，因此能避開幾乎所有傳統安全軟體的偵測。透過合法的軟體更新機制散布至全球 18,000 個組織，包括美國多個聯邦政府機構（財政部、商務部、國土安全部、國務院、能源部及國家核安全管理局）以及財富 500 強中的多間科技巨頭（如 Microsoft, Intel, Cisco）。軟體攻擊雖然早在 2019 年就開始佈署，歷經約一年的潛伏期，從2020 年 3 月起透過正常的軟體更新管道分發，直到 2020 年 12 月才由資安公司 FireEye 揭發。駭客長期潛伏在受害機構的電子郵件系統與內部網路中，竊取了海量高度機敏數據。調查與修復成本估計達 數十億美元。SolarWinds 自身的股價一度跌掉 40% 以上，並面臨多起集體訴訟。此次攻擊暴露了軟體供應鏈的系統性漏洞。

CRA 啟示：此案例直接推動了 SBOM 及安全開發生命週期的立法強制化。CRA 的 SBOM 要求、建置環境安全要求（附錄I Part I 第 3 點）及 OTA 更新完整性要求，正是針對此類攻擊的具體回應。該類網路管理軟體 (Network Management Systems) 會被列為 「重要產品 (Important Products) - 第 II 類」 或 「關鍵產品 (Critical Products)」，不能僅靠廠商自我評估。CRA條例要求必須由第三方驗證及公告機構 (Notified Body) 進行強制性的符合性評鑑，審查其開發流程是否具備防篡改機制。CRA條例進一步 規定製造商必須確保「產品生命週期的安全性」。這意味著 SolarWinds 有法律義務證明其建置系統 (Build System) 的完整性。當SolarWinds現其產品被植入後門且正被積極利用，必須以24小時/72小時的限定期間內通報歐盟主管機關，若在 CRA條例管制下，一旦證明廠商因管理疏忽導致未能察覺大規模攻擊，將面臨最高 1,500 萬歐元或全球營收 2.5% 的罰款，配合及時發行補丁程式、追蹤修復進度，甚至嚴重時停止銷售、召回。

案例三：Hikvision 攝影機漏洞（CVE-2021-36260）

事件概述：中國監控攝影機製造商 Hikvision 的網頁伺服器元件存在嚴重的命令注入漏洞（CVSS 9.8），允許未授權的遠端完全控制。此漏洞在 2021 年被公開後被廣泛利用，多國政府（含美國、英國）將 Hikvision 設備列為安全隱患並實施限制。

CRA 啟示：若 CRA 已生效，此漏洞的通報義務（24h）、修補義務及技術文件不足的問題，將可能導致 Hikvision 在歐盟遭受高額罰款，並被市場監督機關限制銷售。此案亦說明連網監控設備（IPC）在 CRA 下屬於需特別關注的高風險類別。

案例四：ASUS 路由器漏洞事件（2023）

事件概述：2023 年，ASUS 多款路由器被發現存在多個高危漏洞（含 CVE-2023-28702、CVE-2023-28703 等），允許未經授權的遠端執行程式碼。ASUS 雖最終發布修補程式，但因通報及修補時程問題受到多國資安機構關注。美國 CISA 發出公告，荷蘭 NCSC 亦發出建議停用特定版本的警告。

CRA 啟示：若 CRA 已生效，ASUS 將面臨：(1) 漏洞通報義務——24h 向 ENISA 通報；(2) 技術文件不足導致的合規風險；(3) 若被認定為 Class I 路由器，可能觸發更嚴格的符合性評鑑要求。此案例凸顯 SBOM 追蹤及主動漏洞監控的重要性。

案例五：特斯拉自動駕駛召回 2024

這個案例確認了CRA條例一個非常重要的原則：【軟體更新】措施，本身就屬於新的PDE產品放入市場的行為。也就是說即使PDE產品已經出貨很多年，只要企業（經濟營運者）推送新的軟體更新，就要重新確認整個PDE產品符合所有適用CRA條例的要求。(見附圖)

附錄　文獻參考（Literature References）

A. 主要法規文本

●     Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 20.11.2024. EUR-Lex: http://data.europa.eu/eli/reg/2024/2847/oj

●     Corrigendum to Regulation (EU) 2024/2847 (C3). OJ L, 2025/90555, 2.7.2025. EUR-Lex: http://data.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj

●     Commission Implementing Regulation (EU) 2025/2392 — Technical Description of Important and Critical Products. OJ L, 1.12.2025.

●     Commission Delegated Regulation (EU) 2025/1535 — Exclusion for Certain Products under Regulation 168/2013. OJ L, 29.7.2025.

●     Regulation (EU) 2019/881 — Cybersecurity Act (ENISA Regulation). EUR-Lex.

●     Directive (EU) 2022/2555 — NIS2 Directive. EUR-Lex.

●     Regulation (EU) 2016/679 — GDPR. EUR-Lex.

●     Regulation (EU) 2024/1689 — AI Act. EUR-Lex.

B. 官方指引與技術文件

●     European Commission. (2024). Cyber Resilience Act — Summary of the Legislative Text. https://digital-strategy.ec.europa.eu

●     European Commission. (2024, December 3). CRA Frequently Asked Questions (Technical FAQs). 66 pages.

●     BSI (Bundesamt für Sicherheit in der Informationstechnik). (2024). Technical Guideline TR-03183 — Cyber Resilience Requirements for Manufacturers and Products.

●     ENISA. (2024). ENISA Foresight Cybersecurity Threats for 2030.

●     CEN/CENELEC/ETSI Mandate M/606 — Standardisation Request for CRA. (3 February 2025).

C. 調和標準（已發布或預期）

●     ETSI EN 303 645 v2.1.1. (2020). Cyber Security for Consumer Internet of Things: Baseline Requirements. Sophia Antipolis: ETSI.

●     ISO/IEC 27001:2022. Information Security Management Systems — Requirements. ISO.

●     ISO/IEC 27002:2022. Information Security, Cybersecurity and Privacy Protection — Information Security Controls. ISO.

●     EN ISO/IEC 29147:2020. Information Technology — Security Techniques — Vulnerability Disclosure. ISO.

●     EN ISO/IEC 30111:2020. Information Technology — Security Techniques — Vulnerability Handling Processes. ISO.

●     ISO/IEC 27404:2025. Internet of Things (IoT) Security — Baseline Security Requirements. ISO.

●     IEC 62443 Series. Industrial Communication Networks — IT Security for Networks and Systems. IEC.

D. 市場研究

●     Mordor Intelligence. (2026, January). Cybersecurity Market Size & Growth Trends Report 2031. https://www.mordorintelligence.com

●     ISC2. (2024). ISC2 Cybersecurity Workforce Study. https://www.isc2.org

●     CBI (Centre for the Promotion of Imports). (2024). The European Market Potential for Cybersecurity Products and Services. https://www.cbi.eu

●     ENISA. (2024). ENISA Threat Landscape 2024. European Union Agency for Cybersecurity.

●     ENISA. (2026). ENISA Threat Landscape 2025. European Union Agency for Cybersecurity.

E. 學術文獻

●     Bradford, A. (2020). The Brussels Effect: How the European Union Rules the World. Oxford University Press.

●     Timmers, P. (2022). 'Cybersecurity in the European Union: Regulatory Challenges and the Path Forward.' Journal of Cybersecurity and Privacy, 2(3), 451-468.

●     OECD. (2024). Building a Skilled Cyber Security Workforce in Europe. OECD Publishing. https://doi.org/10.1787/3673cd60-en

F. 重要網路資源

●     EUR-Lex（歐盟法律資料庫）：https://eur-lex.europa.eu

●     ENISA 官方網站：https://www.enisa.europa.eu

●     歐盟數位策略官方頁面：https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

●     BSI TR-03183 技術指引：https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html

●     歐盟網路韌性法追蹤網站：https://www.european-cyber-resilience-act.com

●     Secure by Design Handbook：https://www.securebydesignhandbook.com

（本篇完）