寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

Day 5 談完 Annex I，我遇到下一個問題，Risk 到底怎麼評？
上一篇提到，CRA Annex I 對我來說，不太像一張所有 Product 共用的 Security Checklist。
因為 Router、Software、MCU、Memory 面對的網路安全風險（Cybersecurity Risk），本來就可能完全不同。
所以真正把 CRA 帶進產品開發（Product Development）時，我覺得有一件事很難避開：
網路安全風險評估（Cybersecurity Risk Assessment）。
European Commission 目前也把 Risk Assessment 視為 Manufacturer 在產品上市前的重要步驟。先評估 Product 的 Cybersecurity Risk，再據此決定如何落實適用的基本網路安全要求（Essential Cybersecurity Requirements）。
但問題馬上就來了：到底怎麼做？

一、先回到 CRA Article 13
CRA Article 13(2) 要求 Manufacturer 對 Product with Digital Elements 進行 Cybersecurity Risk Assessment，並將結果納入產品的規劃（Planning）、設計（Design）、開發（Development）、生產（Production）、交付（Delivery）與維護（Maintenance）等生命週期階段。
目的包括降低網路安全風險（Minimising Cybersecurity Risks）、預防事件（Preventing Incidents），以及降低 Incident 可能造成的影響。
Article 13(3) 又進一步提到，Risk Assessment 至少要考慮 預期用途（Intended Purpose）、可合理預見的使用方式（Reasonably Foreseeable Use）、使用條件（Conditions of Use）、運作環境（Operational Environment）、需要保護的資產（Assets to be Protected），以及 Product 預期使用的時間長度。
看到這裡，我自己的第一個心得是：
CRA Risk Assessment 好像不能只從「有哪些 CVE」開始。
因為 Product 可能還沒上市，甚至還在 Design 階段，這時根本還不一定有 CVE 可以拿來評。

二、所以 CVSS 跟 CRA Risk Assessment 不是同一件事
這是我自己一開始很容易混在一起的地方。
看到 Cybersecurity Risk，很自然會想到 Common Vulnerability Scoring System（CVSS），例如 CVSS 9.8 = Critical。
但 CVSS 比較常用來評估已知漏洞（Vulnerability）的嚴重程度（Severity），而 CRA Product Cybersecurity Risk Assessment 的範圍更廣。
它可能要回答 Product 有哪些資產（Asset）、有哪些介面（Interface）、可能面臨什麼威脅（Threat）、攻擊成功會造成什麼影響（Impact），以及 Product Design 應該採取什麼安全措施（Security Measure）。
所以我目前會把兩者分開看：
Product Cybersecurity Risk Assessment 比較偏向 Product Lifecycle 與 Security Design。
CVSS 比較適合用在已知 Vulnerability Assessment，作為其中一項參考資訊。
兩者後面當然可能會互相連結，但我不會直接把 CVSS = CRA Risk Assessment。

三、那 Threat Modeling 呢？
威脅建模（Threat Modeling）又是另一個很容易跟 Risk Assessment 混在一起的概念。
Threat Modeling 可以協助我們找出 資產（Asset）、信任邊界（Trust Boundary）、攻擊面（Attack Surface）、威脅（Threat）與攻擊路徑（Attack Path）。例如 STRIDE 就是常見的方法之一。
所以我自己會覺得：
Threat Modeling 可以是 Cybersecurity Risk Assessment 很重要的 Input。
但我不一定會直接說「做完 STRIDE = CRA Risk Assessment 完成」。
因為 Risk Assessment 通常還需要進一步考慮影響（Impact）、可能性或攻擊可行性（Likelihood / Feasibility）、既有安全措施（Existing Control）、殘餘風險（Residual Risk）與風險處置決策（Treatment Decision）。
如果用我自己比較容易理解的方式來分：
Threat Modeling 在問「可能怎麼被攻擊？」
Risk Assessment 還要再回答「這件事對 Product 到底有多重要，以及我們準備怎麼處理？」
這只是我方便理解兩者關係的方式，不是 CRA 規定一定要這樣切分。

四、如果是 Router，我可能從 Asset 開始
例如一台 Router，我可能先列出管理者帳號憑證（Administrator Credential）、設定資料（Configuration）、韌體（Firmware）、網路流量（Network Traffic）、加密金鑰（Cryptographic Key）等重要 Asset。
接著再看它有哪些 Web 管理介面（Web Management Interface）、遠端管理（Remote Management）、WAN / LAN Interface 與更新機制（Update Mechanism）。
有了這些 Product Context 後，就可以開始問一些比較具體的問題。
Credential 被取得會怎樣？Firmware 被竄改會怎樣？Management Interface 被繞過 Authentication 呢？Update Server 被冒充呢？
這時 Threat 才開始真正跟 產品架構（Product Architecture） 連起來，而不是憑空列出一堆 Security Risk。

五、換成 MCU，Risk Assessment 就會長得不一樣
如果今天是一顆 MCU，關心的東西可能變成 Firmware、開機流程（Boot Process）、除錯介面（Debug Interface）、Cryptographic Key 與安全設定（Security Configuration）。
Threat 可能是未經授權的 Firmware 修改（Unauthorized Firmware Modification）、Debug Interface Abuse、金鑰擷取（Key Extraction）或安全功能繞過（Security Function Bypass）。
接著才開始思考是否需要安全開機（Secure Boot）、Firmware Authentication、Debug Protection、Key Protection，或其他適合的 Security Measure。
但還是要再次提醒，這些只是用來理解的例子，並不是：
所有 MCU 都必須具備以上所有功能才符合 CRA。
真正要做什麼，還是要回到 Product 本身的 Architecture、Intended Purpose 與 Cybersecurity Risk。

六、那 Memory 怎麼辦？
Memory Product 可能沒有 Web Interface，也可能沒有 Account、Network Stack，甚至沒有可更新的 Firmware。
如果直接把 Router 的 Threat Model 拿過來套，大概很多欄位最後都會變成不適用（N/A）。
但這其實沒有關係。
CRA Recital 55 特別提到，如果某些 Essential Cybersecurity Requirements 不適用於特定 Product，Manufacturer 應在 Cybersecurity Risk Assessment / Technical Documentation 中留下清楚的理由。
這個觀念我自己很喜歡，因為它不是：
所有產品每一格都必須填 Yes。
而是：
如果不適用，要能說明為什麼。
對 Semiconductor Product 來說，我覺得這個觀念尤其重要，因為很多 Software 或 Network Product 常見的 Security Control，本來就不一定適用於所有 IC。

七、所以「N/A」其實也需要 Evidence
例如 Product 根本沒有使用者驗證功能（User Authentication Function），那 Authentication-related Requirement 可能不適用。
但我自己不太會只在表格裡面寫一個 N/A。
我可能還會補上 Product Architecture、Intended Purpose，以及為什麼不存在對應的攻擊情境（Attack Scenario）。
這樣未來不管是符合性評估（Conformity Assessment）、Internal Review，甚至幾年後重新 Review Product，才知道當初不是漏掉這一項，而是：
經過分析後判定不適用。
我覺得這跟單純把 Checklist 填完，差異其實滿大的。

八、我目前比較喜歡用一條簡單的 Risk Chain
如果今天要開始設計 CRA Risk Assessment Template，我自己可能會先從一條簡單的風險鏈（Risk Chain）開始：
資產／安全目標（Asset / Security Objective）
↓
威脅情境（Threat Scenario）
↓
既有安全措施（Existing Security Measure）
↓
風險評估（Risk Evaluation）
↓
額外風險處置（Additional Treatment）
↓
殘餘風險（Residual Risk）
↓
佐證（Evidence）
例如 Router 的 Firmware，可以變成：
Firmware
↓
未經授權的修改（Unauthorized Modification）
↓
數位簽章驗證（Signature Verification）
↓
Risk Evaluation
↓
強化更新驗證機制（Strengthen Update Authentication）
↓
Residual Risk
↓
安全測試報告（Security Test Report）
這不是 CRA 官方指定的格式，只是我自己目前覺得比較容易把 Risk 跟 Product Development 接起來的方式。

九、Risk Assessment 最後最好能回到 Requirement
如果做完 100 個 Risk Scenario，最後只是把 Excel 存起來，我會覺得有點可惜。
真正有價值的地方，是把 Risk 轉成 安全需求（Security Requirement）。
例如發現一個 Risk：
未經授權的 Firmware 修改（Unauthorized Firmware Modification）
接著形成 Security Requirement：
Product shall verify firmware authenticity and integrity before installation.
Product 在安裝 Firmware 前，應驗證其真實性（Authenticity）與完整性（Integrity）。
然後才進到 R&D Design，再由 QA / Security Test 進行驗證（Verification），最後留下 Evidence。
所以 Risk Assessment 如果能接到：
Risk → Requirement → Design → Verification → Evidence
它就不再只是一張 Compliance 文件，而開始真正成為安全開發生命週期（Secure Development Lifecycle, SDL / SSDLC）的一部分。

十、這也是 CRA 跟 SSDLC 開始接起來的地方
做到這裡，我開始理解為什麼 CRA 不適合等 Product 開發完成才處理。
因為如果 Risk Assessment 發生在 Release 前一週，結果才發現 Architecture 本身存在重大 Security Risk，這時候才開始改，Cost 可能已經很高。
但如果在 Planning / Design Stage 就開始做，Risk 才比較有機會真正影響 Architecture、Interface、元件選擇（Component Selection）與 Security Requirement。
所以 Article 13 把 Risk Assessment 放進整個產品生命週期（Product Lifecycle），我自己覺得是很合理的設計。
也因為這樣，我現在比較不會把 CRA Risk Assessment 當成產品開發結束後，由 Compliance Team 補上的一份文件。
它應該要有機會真的改變 Product Design。

十一、Risk Assessment 還要更新
另一個很重要的點是，CRA 並不是要求 Risk Assessment 做一次就結束。
Article 13(3) 要求 Cybersecurity Risk Assessment 被文件化（Documented），並在 支援期間（Support Period） 中適當更新。
Article 13(7) 也要求 Manufacturer 依 Product Nature 與 Cybersecurity Risk，以相稱方式持續記錄相關 Cybersecurity Aspects，包括已知 Vulnerabilities 與 Third-party Information，並在適用時更新 Risk Assessment。
所以新的 Vulnerability、新的 Threat、Product Change、Component Change，都可能成為重新檢視 Risk 的 Trigger。
這讓我覺得 Product Cybersecurity Risk Assessment 比較不像一份「Release 前簽核完就封存」的文件，而比較像：
會跟著 Product Lifecycle 持續被 Review 的紀錄。

十二、Risk Assessment 最後還會進 Technical Documentation
這一點對 Compliance 很重要。
CRA Article 13(4) 要求 Manufacturer 將 Cybersecurity Risk Assessment 納入 技術文件（Technical Documentation）。
Annex VII 也要求 Technical Documentation 包含 Product 的 Cybersecurity Risk Assessment，以及 Annex I Part I Requirements 如何適用等相關內容。
所以 Risk Assessment 不是 R&D 內部開會討論完就消失，它後面還可能成為：
符合性佐證（Conformity Evidence）。
這也代表 Risk Assessment 的內容最好能被追溯（Trace）、被 Review，也能說明當初為什麼做出某些 Security Design Decision。

十三、那到底該用哪個 Risk Methodology？
這題我自己現在不會急著說：
「CRA 就一定要用某一套。」
可以參考的方法很多，例如威脅建模（Threat Modeling）、STRIDE、攻擊樹（Attack Tree）、IEC 62443、ISO/IEC 27005，或公司既有的 Product Security Risk Methodology。
European Commission 在 2026 年 7 月發布的第一批 CRA Implementation Guidance，也已進一步說明 Risk Assessment 等企業關注議題。我自己會把這類 Guidance 與後續 Harmonised Standards 一起持續追蹤，而不急著把目前的方法寫死。
所以對我而言，Methodology 的名字不是第一優先。
我反而會先看這套方法能不能合理、可重複地回答幾個問題：
Product Context 有沒有被考慮？
Threat / Risk 有沒有被辨識？
Risk 能不能回到 Security Requirement？
Treatment 後的 Residual Risk 有沒有被確認？
最後能不能留下足夠的 Evidence？
如果這些問題都能回答，我覺得才比較接近 Risk Assessment 真正在 CRA 專案裡的價值。

十四、如果公司本來就在做 IEC 62443 呢？
Industrial / OT Product Company 可能原本就有 IEC 62443-4-1 相關的安全開發生命週期（Secure Development Lifecycle）。
裡面本來就有 Security Requirement、Threat Modeling、Secure Design、Verification、Defect Management 等相關概念。
那我自己不會因為 CRA，就另外重新創造一套完全獨立的 CRA Risk Assessment。
我反而會先做對照分析（Mapping），看看既有 IEC 62443 Process 哪些已經可以支援 CRA、哪些地方還需要補強，以及原本留下的 Evidence 能不能支援 CRA Technical Documentation 與後續 Conformity Assessment。
但還是要提醒：
IEC 62443 ≠ CRA Compliance。
能不能支持 CRA，還是要看實際 Mapping、Evidence，以及未來適用的 Harmonised Standards。
我自己目前比較傾向的方向，一直都是：
能整合既有流程，就不要為 CRA 再創造一套平行流程。
不然最後 R&D 很可能同一件事情，要為不同 Compliance Framework 重複做很多次。

Day 6 小結｜Risk Assessment 對我來說，是 CRA 跟 Product Development 接起來的地方
做到這裡，我自己越來越覺得：
Cybersecurity Risk Assessment 不是 CRA 要多填的一張表。
它真正有價值的地方，是把 Product、Threat、Security Requirement、Design、Test 與 Evidence 串起來。
而且 Router 跟 MCU 不需要長得一樣，Memory 也不用硬套 Router 的 Security Checklist。
真正重要的，可能是能不能回答幾個問題：
這個 Product 有哪些 Cybersecurity Risk？
哪些 Annex I Requirements 適用？
我們怎麼處理這些 Risk？
哪些 Requirement 不適用？為什麼？
最後留下什麼 Evidence？
這些問題，我目前會比「到底要用哪一套 Risk Matrix」更在意。
因為方法可以隨 Product、Industry 與未來 Standard 調整，但如果 Risk Assessment 最後沒有回到 Product Requirement、Design 與 Verification，那它就很容易變成一份只有 Compliance Team 在看的文件。
當然，以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
實際方法還是應持續參考 CRA 正式條文、Commission Guidance、後續 Harmonised Standards，以及 Product 自身特性進行調整。

Day 7 預告｜Risk 找到了，然後呢？CRA 怎麼真正走進 SSDLC？
Day 6 的 Risk Assessment 找出了 Threat、Security Requirement 與 Treatment，但接下來真正困難的是：
怎麼讓這些東西進入 R&D 日常開發流程？
CRA 是不是要另外建立一套 Development Process？還是可以跟既有 SSDLC 整合？
Security Requirement 誰定？Threat Model 什麼時候做？SAST / SCA 做了就夠嗎？Penetration Test 是不是每個 Product 都需要？
到了 Semiconductor，RTL、Firmware、SDK 又該怎麼放進來？
Day 7，我們來聊 CRA 與安全軟體／產品開發生命週期（Secure Software / Product Development Lifecycle）。