宏虹分享|「100天」倒計時!CRA 合規指南(三)企業如何建立網路安全風險評估與全生命週期管理機制

引言:CRA上路「100天」倒計時,你準備好了嗎?

在前兩期文章中,我們已分別說明 CRA 的適用範圍、整體影響,以及率先適用的漏洞通報義務。

隨著 2026 年 9 月 11 日這個關鍵時點逐步接近,企業面對 CRA 的合規準備,已不能只停留在對「通報義務」的被動理解,而必須進一步進入更深層的能力建置階段,也就是建立一套足以支撐產品全生命週期的網路安全風險評估與管理機制。

根據歐盟委員會公開說明,CRA 已於 2024 年 12 月 10 日正式生效,主要義務將自 2027 年 12 月 11 日起全面適用,其中漏洞通報義務則會提前於 2026 年 9 月 11 日開始適用。

歐盟委員會也明確指出,製造商在產品投放市場前,即應先完成網路安全風險評估,並據此判斷應如何落實 CRA 所要求的基本網路安全要求。

這也代表,CRA 合規的核心,並不只是「漏洞通報」,而是企業是否具備持續辨識、評估、管理與回應網路安全風險的能力。

一、為什麼網路安全風險評估是 CRA 合規的起點

從 CRA 的制度設計來看,網路安全風險評估並不是企業可自行決定是否執行的內部管理措施,而是整個合規體系的起點。根據 Regulation (EU) 2024/2847 第 13 條,製造商在將具有數位元素的產品投放歐盟市場時,必須確保產品依附件 I 第 I 部分的基本網路安全要求進行設計、開發與生產。

而風險評估的作用,正是用來辨識產品面臨的具體網路安全風險,並據此決定:

  • 哪些安全要求適用於該產品
  • 應採取哪些控制措施
  • 漏洞處理要求應如何納入企業流程

歐盟委員會在官方說明中也明確指出,企業在產品上市前的第一步,就是進行風險評估,並據此判斷適用的基本網路安全要求,再將相關結論納入技術文件與符合性評估流程。

換句話說,CRA 並不是要求所有企業以完全相同的一套技術措施應對所有產品,而是要求企業先完成有證據支持的風險判斷,再依風險程度決定控制措施的深度與方式。

因此,CRA 的核心邏輯並不是「機械式勾選要求」,而是「依風險落實安全」。

如果企業無法證明其風險辨識過程完整、風險判斷邏輯合理,且控制措施與風險程度相符,即使已部署部分安全措施,仍可能無法充分證明其符合 CRA 要求。

二、CRA 要求的風險評估,企業究竟要評估什麼?

CRA 對風險評估的內容並不是抽象描述,而是提供了相對明確的法定架構。

根據第 13 條第 3 項,企業的網路安全風險評估至少應包括:

  • 依產品預期用途與可合理預見用途進行的風險分析
  • 產品運作環境與使用條件分析
  • 受保護資產與預期使用期間分析
  • 附件 I 基本安全要求的適用性判斷
  • 漏洞處理要求的落實方式

同時,風險評估結果也必須納入技術文件,並在支援期間內持續更新。從附件 I 的具體要求來看,企業評估的對象,遠不只是傳統意義上的「是否會發生資料外洩」。

CRA 要求產品在依風險判斷的前提下,達到適當的網路安全水準,並盡可能避免存在已知可利用漏洞。產品投放市場時,也應採取「預設安全」設定。

除此之外,企業還需要考量:

  • 基本功能的可用性保護
  • 攻擊面的限制
  • 安全事件影響的降低
  • 安全記錄與監測能力
  • 使用者安全資訊提供

在漏洞處理方面,CRA 也要求企業:

  • 識別並記錄產品與元件中的漏洞
  • 建立軟體組成成分管理機制
  • 提供安全更新與漏洞修補
  • 定期測試與檢視產品安全性
  • 建立協調漏洞揭露政策
  • 提供漏洞接收與溝通管道

因此,在 CRA 架構下,企業需要評估的風險至少涵蓋以下幾個面向:

  • 產品本身設計缺陷造成的安全風險
  • 預設設定與權限控管不當風險
  • 更新機制失效或遭竄改風險
  • 第三方元件與開源依賴風險
  • 不同部署環境下的差異化風險
  • 不同生命週期階段產生的風險變化

也就是說,CRA 要求的並不是一次性的靜態評估,而是涵蓋「設計、開發、交付、維護、更新、退役」全流程的動態風險治理。

三、企業應如何建立 CRA 視角下的風險評估方法

從企業實務角度來看,要滿足 CRA 要求,首先不是「寫出一份風險評估報告」,而是建立一套清楚的方法架構。

1. 建立資產與邊界識別機制

企業應先釐清產品的:

  • 核心功能
  • 關鍵元件
  • 外部介面
  • 第三方依賴
  • 典型使用情境
  • 關鍵保護資產

因為 CRA 明確要求風險分析必須依產品用途、可合理預見用途與使用條件進行。

如果企業連產品邊界都無法清楚定義,就很難證明其風險評估是完整且合理的。

2. 建立威脅、弱點與影響分析邏輯

企業不只要辨識:

「產品可能如何遭受攻擊」

更要分析:

  • 為什麼可能遭受攻擊
  • 哪些弱點可能被利用
  • 一旦被利用會造成哪些影響

在 CRA 脈絡下,影響範圍不只包括機密性、完整性與可用性的損害,也包括對其他設備、網路與服務產生的連帶影響。因此,風險評估不能只由研發或測試團隊單獨完成,而需要產品、研發、資安、法務、法遵、售後,甚至供應鏈團隊共同參與

唯有如此,才能形成兼顧技術事實、業務情境與合規要求的完整判斷。

3. 將風險結果直接對應控制措施

CRA 真正關注的,不是企業是否為風險貼上「高、中、低」標籤,而是企業是否依風險決定合理的控制措施。

例如:

  • 安全設計
  • 安全測試
  • 更新機制
  • 漏洞處理流程
  • 使用者通知措施

歐盟委員會也強調,完成風險評估後,製造商需據此定義如何落實適用的基本網路安全要求,並透過技術文件與符合性評估加以證明。

因此,風險評估的輸出至少應回答三個問題:

  • 哪些安全要求適用
  • 企業如何落實這些要求
  • 相關證據保存在哪裡

四、風險管理不應止於產品上市前,而應貫穿整個支援期間

CRA 與許多傳統產品合規規則最大的不同之一,在於它並不把「上市前合規」視為終點。

相反地,CRA 明確要求企業在產品上市後,仍須持續處理漏洞並維持安全能力

根據第 13 條第 8 項及相關規定,製造商必須在產品投放市場時,以及整個支援期間內,確保產品及其元件的漏洞獲得有效處理。

支援期間原則上不得少於五年;若產品預期使用期間少於五年,則支援期間應與產品使用期間一致。企業也必須將支援期間的判斷依據寫入技術文件。

這代表企業的風險管理不能只停留在上市前審查,而必須嵌入持續營運機制

實務上,企業至少應建立以下幾類持續性工作:

  • 漏洞接收與分流機制
  • 已部署版本與影響範圍識別機制
  • 修補程式與緩解措施發布機制
  • 新威脅情資重新評估機制
  • 供應鏈事件風險分析機制

CRA 第 13 條同樣要求企業系統性記錄與產品相關的重要網路安全事項,包括已知漏洞與第三方提供的相關資訊,並在必要時更新風險評估。

由此可見,CRA 要求的是「持續更新的風險管理閉環」,而不是「上市前做一次評估,上市後就不再追蹤」。

尤其值得注意的是,CRA 也將:

  • 支援期間
  • 漏洞處理
  • 安全更新
  • 技術文件保存

彼此緊密連結。

法規要求,安全更新在支援期間內提供後,仍須至少持續可取得十年,或涵蓋剩餘支援期間,並以較長者為準。

同時,技術文件、使用者資訊與符合性文件,也須至少保存十年或涵蓋支援期間。

這代表企業的風險管理,已從單純的「技術修補」,進一步延伸到生命週期承諾管理、文件治理與客戶溝通管理。

五、供應鏈與第三方元件,將成為風險管理中的重點與難點

在 CRA 脈絡下,企業已不能再將第三方元件、開源依賴或委外開發視為外部問題。

附件 I 第 II 部分明確要求製造商識別並記錄產品中的漏洞與組成成分,包括以通用、機器可讀格式建立軟體物料清單(SBOM),且至少涵蓋頂層依賴關係

這項要求的本質,不只是留下文件紀錄,而是要讓企業具備:

  • 追蹤供應鏈風險
  • 快速定位受影響元件
  • 評估漏洞影響範圍
  • 加速事件回應能力

ENISA 也在與 CRA 實施相關的資料中多次強調,SBOM 有助於提升對軟體供應鏈的理解,協助製造商與使用者追蹤新出現的已知漏洞與網路安全風險。

同時,ENISA 關於供應鏈網路安全良好實務的研究也指出,企業應建立涵蓋:

  • 風險評估
  • 供應商關係管理
  • 漏洞管理
  • 產品品質管理

等面向的第三方風險管理體系。

ENISA 也建議企業採取 PDCA(Plan-Do-Check-Act)的持續改善方式來管理供應鏈安全。

雖然 ENISA 報告並不是 CRA 的直接法律文本,但對企業如何將 CRA 的供應鏈要求轉化為內部治理機制,仍具有高度參考價值。

因此,對已進入或準備進入歐盟市場的企業而言,真正需要建立的,並不只是「向供應商索取一份安全承諾書」。更重要的是,建立一套可驗證、可持續運作的供應鏈風險管理鏈條

例如:

  • 哪些元件屬於核心依賴
  • 哪些供應商提供關鍵功能
  • 哪些更新路徑可能影響產品安全
  • 哪些供應商需接受更高強度安全審查
  • 哪些第三方漏洞會觸發影響分析與通報流程

如果這些問題平時沒有機制化管理,當漏洞事件真正發生時,企業很可能既無法快速判斷影響範圍,也無法在法定期限內形成準確且可提交的結論。

結語

隨著 CRA 正式進入實施倒數階段,企業面對的挑戰,已不再只是單純理解法規內容,而是如何真正建立一套可持續運作、可被驗證,且能貫穿產品全生命週期的網路安全治理能力。

從風險評估、漏洞管理、支援期間、安全更新,到 SBOM 與供應鏈風險管理,CRA 所要求的,其實是一種從「產品導向」轉向「生命週期安全治理導向」的思維改變。企業需要的不只是一次性的合規文件,而是能夠持續辨識風險、快速回應漏洞、掌握供應鏈影響範圍,並留下完整證據鏈的管理機制。

尤其對準備進入歐盟市場的企業而言,CRA 已不只是資安或法遵部門的議題,而是牽涉產品設計、研發流程、供應鏈管理、售後支援與企業治理能力的整體性挑戰。

距離 2026 年 9 月 11 日漏洞通報義務正式上路,時間已逐漸逼近。企業若希望在未來面對 CRA 合規要求時,能夠真正具備風險辨識、漏洞追蹤與持續更新能力,現在正是重新檢視內部流程與建立長期治理機制的重要時點。

瞭解ONEKEY韌體安全與合規平台

ONEKEY 自動化韌體安全與 SBOM 管理平台

自動化掃描 × 漏洞合規化,打造穿透式物聯網資安防禦網

宏虹 ONEKEY 平台專為全球智慧製造與 IoT 供應鏈場景打造,透過無須源碼的二進位掃描與雲端自動化分析,協助企業在產品生命週期中即時掌握資安風險,建立可量化、可審核的軟體清單(SBOM),降低合規成本與資安風險。

  • 全自動化二進位掃描: 無須取得原始碼,即可分析韌體並識別已知漏洞(CVE)。

  • 零迷霧 SBOM 管理: 自動生成符合國際標準(SPDX/CycloneDX)的軟體物料清單。

  • 即時漏洞關聯分析: 同步蒐集全球資安威脅情資,精準對應產品受威脅狀態。

  • 合規性與認證支援: 提供符合歐盟 CRA 或美國行政命令的合規檢測報告。

  • 數位孿生資安技術: 以無須設備實體的方式,進行虛擬化的穿透測試與驗證。

  • 多產業應用場景: 適用於工業控制、醫療器材、車用電子與智慧零售設備。

➢ 點擊聯繫諮詢 📩