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

前面談了很多流程，現在終於要碰 Product Security 本身了
前四天，我們一路從 CRA 是什麼，談到產品適用範圍（Product Scope）、產品分類（Product Classification），再到符合性評估（Conformity Assessment）。但如果真的開始做 CRA 差距分析（Gap Analysis），遲早會碰到一個最基本的問題：「所以 CRA 到底要求產品做到什麼？」
第一次看到 CRA Annex I，我很自然會想把它整理成一張 Security Checklist，例如 Encryption 有沒有？MFA 有沒有？Secure Boot 有沒有？Penetration Test 做了沒有？這種想法其實很直覺，因為過去做很多 Compliance Assessment 時，我們習慣先把 Requirement 拆成 Control，再逐項確認產品到底有沒有做到。
但後來我慢慢覺得，如果只用 Checklist 的方式讀 Annex I，可能會把 CRA 看得太扁平。因為 Annex I 真正讓我開始改變思考方式的地方，不是哪一項 Security Function，而是它背後一直存在的一個核心概念：網路安全風險（Cybersecurity Risk）。

一、我先把 Annex I 看成兩件事情
CRA Annex I 是基本網路安全要求（Essential Cybersecurity Requirements），大致可以分成兩個部分。Part I 是 Cybersecurity requirements relating to the properties of products with digital elements，比較偏向數位元素產品（Product with Digital Elements）本身應具備哪些 Cybersecurity Properties；Part II 則是弱點處理要求（Vulnerability Handling Requirements），比較偏向產品上市後，Manufacturer 要如何持續識別、處理及修復 Vulnerability。
如果先不管法規文字的細節，我自己會把它簡單理解成兩件事：Part I 是「產品本身怎麼做得比較安全」，Part II 是「產品出了漏洞之後怎麼持續處理」。 這個區分對我後來理解 CRA 很有幫助，因為它提醒我 Product Security 不是只發生在產品 Release 以前，產品上市後的 Vulnerability Handling 同樣是 CRA 很重要的一部分。

二、Annex I 第一個讓我注意的，其實不是 Encryption
一開始看 Annex I，我原本以為會先看到很多具體的 Security Control，但真正讓我開始重新思考的是網路安全風險評估（Cybersecurity Risk Assessment）。CRA 把產品的 Design、Development、Production 與 Cybersecurity Risk 連在一起，而 Article 13 也要求 Manufacturer 對 Product with Digital Elements 進行 Cybersecurity Risk Assessment，並將評估結果納入產品的 Planning、Design、Development、Production、Delivery 與 Maintenance 等階段。
看到這裡，我開始覺得 CRA 真正要問的可能不是：「每一個 Product 是不是都要裝一樣的 Security Control？」而比較像是：「這個 Product 有什麼 Cybersecurity Risk，而我們怎麼處理這些 Risk？」
這兩個問題看起來很像，但做法其實差很多。前者很容易變成 Checklist，後者則會迫使我們先了解 Product 本身。

三、所以不是每一個 Product 都一定要 MFA
假設今天是一台 Enterprise Gateway，而且提供遠端管理（Remote Administration），如果 Administrator Account 被拿走，可能連帶影響整個 Network，那麼強式身分驗證（Strong Authentication）甚至多因素驗證（Multi-Factor Authentication, MFA）就可能非常重要。但如果今天換成一個完全不同功能的 Hardware Component，本身沒有 User Login，也沒有 Administrative Interface，這時直接問它「有沒有 MFA」，可能就不是一個很合理的問題。
所以我現在如果做 CRA Gap，比較不會一開始拿著 Checklist 問「MFA 有沒有？Encryption 有沒有？Logging 有沒有？」，而是會先問：「這個 Product 有哪些資安相關功能（Security-relevant Function）、資產（Asset）、介面（Interface）與威脅（Threat）？」了解這些之後，再往下決定需要哪些安全措施（Security Measures），我覺得會比較接近 Risk-based 的思考方式。

四、Encryption 也是一樣
CRA Annex I 的確談到 Data 的機密性（Confidentiality）、完整性（Integrity）等 Cybersecurity Properties，但我自己不會直接把它簡化成「CRA 規定所有 Data 都要 Encryption」。我會先看 Product 到底處理什麼 Data，例如 Credential、Cryptographic Key、Personal Data、Configuration、Firmware 或 Business Data，再進一步看這些資料是靜態資料（Data at Rest）還是傳輸中資料（Data in Transit），可能面臨什麼 Threat，以及一旦遭到未授權存取、修改或破壞後會造成什麼 Impact。
這些事情釐清之後，才比較能判斷到底需要加密（Encryption）、完整性保護（Integrity Protection）、存取控制（Access Control），還是其他 Security Measures。也就是說，同一個 Annex I Requirement，放到不同 Product Architecture 上，最後形成的 Security Design 可能完全不同。

五、換成 ICT Product，Risk 比較容易想像
假設是一台 Router，它可能有 Web Administration Interface、Firmware Update、Remote Management、Authentication、Network Service 與 Configuration File。這時很自然就會想到一些 Risk，例如預設密碼（Default Password）、身分驗證繞過（Authentication Bypass）、管理介面暴露（Management Interface Exposure）、韌體竄改（Firmware Tampering）、未授權設定變更（Unauthorized Configuration Change），或存在弱點的 Third-party Library。
接著就可以沿著這些 Risk 往下思考需要哪些 Security Control，例如 Authentication、Access Control、Secure Update、Integrity Protection、Attack Surface Reduction 等。做到這裡，我開始覺得 Annex I 不再只是一張 Compliance Checklist，而是慢慢跟產品架構（Product Architecture）、Threat 以及 Security Design 串在一起。

六、但換成 Semiconductor，整張圖可能完全不一樣
假設今天是一顆微控制器（Microcontroller Unit, MCU），它可能沒有 Web UI、沒有 User Account，也沒有一般 ICT Product 常見的 Network Service，但它可能有開機流程（Boot Process）、除錯介面（Debug Interface）、Firmware、密碼學功能（Cryptographic Function）、金鑰儲存（Key Storage）與外部介面（External Interface）。
這時 Cybersecurity Risk 可能變成未授權韌體修改（Unauthorized Firmware Modification）、除錯介面濫用（Debug Interface Abuse）、金鑰擷取（Key Extraction）、開機流程竄改（Boot Process Tampering）或安全功能繞過（Security Function Bypass），而可能對應的 Security Measure 則是 Secure Boot、Firmware Authentication、Debug Protection、Key Protection 或其他 Hardware Security Mechanism。
不過這些都只是我用來理解 Risk-based Approach 的例子，並不是說 CRA 要求每一顆 MCU 都必須實作上述所有功能。對我來說，重點反而是：先知道 Risk 是什麼，再談 Control。

七、Memory Product 又可能完全是另一種 Risk Profile
如果今天換成一顆 Memory Product，本身沒有 Firmware、沒有 User Authentication，也沒有 Network Stack，它的網路安全風險輪廓（Cybersecurity Risk Profile）自然可能跟 Router 或 MCU 差很多。如果直接拿 Router 的 Security Checklist 要求 Memory Product 全部照做，最後雖然可能得到一張填得很完整的 Checklist，卻不一定真正反映這顆產品的 Cybersecurity Risk。
這也是我在看 Semiconductor CRA 時越來越有感的一件事：不同 IC 的 Security Capability、Attack Surface、Architecture 與 Intended Purpose 差異可能非常大。 因此 CRA 在 Semiconductor Company 落地時，如果只做一份全公司共用的 Security Checklist，我自己會覺得還不夠，前面可能還需要一層 Product Cybersecurity Risk Assessment，才能知道哪些 Requirement 對這個 Product 真正 relevant，以及後續要留下什麼 Evidence。

八、「沒有已知可被利用的漏洞」這句也讓我想了很久
CRA Annex I Part I 有一個很容易引起注意的要求，就是 Product 在 Made Available on the Market 時，應為 without known exploitable vulnerabilities，也就是沒有已知可被利用的漏洞。
第一次看到這句，我也很自然想到：「那 Product 只要有 CVE，是不是就不能上市？」
但後來我自己不會直接把常見弱點與漏洞編號（Common Vulnerabilities and Exposures, CVE）跟可被利用的漏洞（Exploitable Vulnerability）畫上等號。因為知道某個 Component 有 CVE，跟這個 Vulnerability 在特定 Product 中到底能不能被 Exploit，中間其實還有一段 Technical Analysis 要做。

九、這也是 SBOM 跟 VEX 開始串起來的地方
假設軟體物料清單（Software Bill of Materials, SBOM）發現 Product 使用的某個 Open Source Component 有 CVE，但 Product 並沒有啟用 Vulnerable Function，或實際 Attack Path 不存在，又或者 Product Configuration 使該 Vulnerability 無法被利用，這時我覺得就需要進一步進行弱點影響分析（Vulnerability Impact Analysis）或可利用性分析（Exploitability Analysis），而不是看到 CVE Number 就直接判定 Product 不符合 CRA。
這也是弱點可利用性交換（Vulnerability Exploitability eXchange, VEX）後來開始對我有意義的地方。我自己會先很簡單地理解成：SBOM 告訴我「Component 在不在」，VEX 則進一步協助說明「這個 Product 到底受不受這個 Vulnerability 影響」。 當然，實際判定還是需要 Technical Analysis 支持，不能只是把狀態填成 Not Affected 就結束。

十、Attack Surface 有時候不是「加東西」，而是「少開東西」
CRA Annex I 也要求 Product 應在 Risk 基礎上限制攻擊面（Limit Attack Surfaces），包括 External Interfaces。這個概念我自己很有感，因為做 Security 很容易直覺想到「還要再加什麼 Control」，但 Attack Surface Reduction 有時候剛好相反：不需要的 Port 不開、不需要的 Service 不啟用、Production 環境不需要使用的 Debug Interface 關閉或適當保護、不必要的 Administrative Function 不對外暴露。
所以安全設計（Security by Design）有時候不是「再加一層 Security Control」，而是一開始就不要留下不必要的入口。 對 Semiconductor 來說，這個觀念尤其值得思考，因為有些 Interface 或 Function 一旦進入 Silicon Design，後面再修改可能就不像 Software 那麼容易。

十一、Secure by Default 也不只是設定問題
CRA Annex I 也談到預設安全（Secure by Default）。這讓我想到很多 Product Security 問題，其實不是 Product 完全沒有 Security Capability，而是 Default Configuration 太寬鬆，例如 Default Credential、Unnecessary Service Enabled、Remote Management Enabled by Default，或其他 Weak Security Setting。
如果 User 買回去什麼都不改，Product 就已經處於比較高風險的狀態，後面再期待 User 自己把所有 Security Setting 調整好，可能不是最好的 Product Security Design。因此對我來說，Secure by Default 真正值得帶回 Product Development 的問題是：「產品交到客戶手上時，它一開始是不是就處在相對安全的狀態？」

十二、Security Update 也不一定等於 Software Patch
Annex I 也涉及弱點修復（Vulnerability Remediation）與安全更新（Security Update）。一開始看到 Security Update，我很容易直接想到 Software Patch，但放到不同 Product 上，實際情況可能完全不一樣。ICT Product 可能透過 Firmware Update，Software 可能透過 Version Update，MCU 相關問題可能透過 Firmware、SDK 或 Library 處理；到了 Semiconductor，有些問題甚至可能只能透過 Mitigation Guidance、Configuration、Customer Integration，或後續 Product Revision 處理。
所以我現在比較不會把 Vulnerability Remediation 直接等同於「一定要 Patch」。Patch 可能只是 Vulnerability Remediation 的其中一種方式。 尤其對 Hardware Product，這個差異我覺得很重要。

十三、Hardware Vulnerability 讓 Security by Design 變得更現實
Software Vulnerability 發生時，改 Code、Release Patch 相對容易想像，但如果 Vulnerability 發生在 Silicon，Product 已經大量出貨，甚至已經焊在 Customer PCB 上，Fix 就沒有那麼單純。這也是為什麼我自己會覺得 Semiconductor Product Security 更需要在設計階段（Design Stage）就把 Threat、Security Requirement 與 Mitigation 想得比較完整。
因為 Hardware 後期修正的 Cost，可能比 Software 高很多。 這時 Security by Design 就不再只是一句口號，而會直接連到 Product Lifecycle、Engineering Change、Product Revision，甚至後續 Customer Communication。

十四、Annex I Part II 讓我意識到：產品上市後，事情還沒結束
前面談的比較偏 Annex I Part I，但 CRA 很重要的另一半是弱點處理（Vulnerability Handling）。Annex I Part II 涉及識別並記錄 Vulnerabilities 與 Components、維護 SBOM、處理及修復 Vulnerabilities、執行有效且定期的 Tests and Reviews、公開揭露已修復漏洞的相關資訊，以及提供 Security Updates 等能力。
這時我才慢慢理解，CRA 的 Product Security 不是 Release 前安全一次，而是上市之後還要繼續維護。 對我來說，這也是 CRA 跟過去比較容易想到的「產品上市前做一次 Security Test」很不一樣的地方。

十五、所以 SBOM 的價值，不只是「我有一份清單」
CRA Annex I Part II 把 SBOM 放在 Vulnerability Handling Requirements 裡，這個位置我自己覺得很有意思，因為它讓我不再把 SBOM 當成單純的 Documentation Requirement。SBOM 真正要支援的，可能是 Vulnerability Identification、Product Impact Analysis 與 Remediation。
假設某個 Third-party Library 明天出現 Critical Vulnerability，公司能不能很快回答：「哪些 Product 用到了？」 我覺得這可能比「我們有一份 SBOM PDF」更有實際意義。所以真正的問題可能不是 Have SBOM?，而是 Can we use the SBOM?

十六、Risk Assessment 也不是 Release 前做完就封存
CRA Article 13 要求 Cybersecurity Risk Assessment 被 Documented，並在支援期間（Support Period）中適當更新。這一點我自己覺得很重要，因為 Product 上市幾年之後，威脅情勢（Threat Landscape）可能已經不同，新的 Attack Technique、Vulnerability 與 Component Risk 都可能陸續出現。
所以 Product Risk Assessment 如果只是在 Release Gate 前簽一次，之後就永遠不再看，可能很難真正反映 Product Lifecycle 中持續變化的 Risk。我自己會比較傾向把它理解成一份會跟著 Product Lifecycle 持續 Review 的文件，而不是 Release 前完成一次就結束的表單。

十七、那 Product Cybersecurity Risk Assessment 到底怎麼做？
這題我自己覺得值得獨立一篇，因為 CRA 並沒有直接給 Manufacturer 一張「Likelihood × Impact = Risk」的表格，然後要求所有產品使用完全相同的方法。那企業到底要怎麼建立自己的 Product Cybersecurity Risk Assessment？可以用威脅建模（Threat Modeling）、Attack Tree、STRIDE、CVSS、IEC 62443、ISO/IEC 27005，還是建立自己的 Product Risk Methodology？
這些方法都可能跟 Risk 有關，但我覺得實務上第一件事反而是先分清楚：它們各自在解決什麼問題？ 尤其通用弱點評分系統（Common Vulnerability Scoring System, CVSS）跟 Product Cybersecurity Risk Assessment，其實不是完全相同的東西，這個我自己覺得很容易在實務上混在一起。

十八、「CRA Checklist」?
Checklist 當然有用，尤其做 Gap Assessment 時，可以協助確認 CRA Requirement 有沒有漏掉。但如果最後變成 Encryption？Yes。Authentication？Yes。Logging？Yes。Update？Yes。全部打完勾之後就宣布 CRA Ready，我自己反而會有點不放心。
因為 Product A 的 Encryption 跟 Product B 的 Encryption，可能是在解決完全不同的 Risk。所以我現在比較希望 Checklist 前面先有一層 Product Cybersecurity Risk Assessment，再讓每一項 Control 跟 Product Risk 連起來。這樣 Checklist 回答的就不只是「有沒有做」，而是開始回答：「為什麼要做？」

十九、如果是我現在做 CRA Gap，我會想把 Evidence 一路串起來
如果是我現在做 CRA Gap，我會希望 Product Security 的證據鏈（Evidence Chain）大概可以一路串成：
產品功能／資產（Product Function / Asset） → 威脅／弱點（Threat / Vulnerability） → 網路安全風險（Cybersecurity Risk） → 安全需求（Security Requirement） → 安全控制／設計（Security Control / Design） → 驗證／測試（Verification / Test） → 剩餘風險（Residual Risk） → 證據（Evidence）
這不是 CRA 官方指定的格式，只是我自己目前覺得比較容易管理的方式。因為到了最後 Conformity Assessment，我們需要的不只是說「有做 Security」，而是最好能回答：「為什麼這樣做，以及怎麼知道它有效？」 我覺得這兩個問題，才比較接近 Product Security Evidence 真正需要證明的事情。

二十、同樣是 Annex I，Router、MCU、Memory 可能會走出完全不同的路
例如 Router 的 Asset 可能是 Credential、Configuration、Traffic，Threat 可能來自 Remote Attacker，對應的 Control 可能是 Authentication、Secure Update、Interface Protection；換成 MCU，Asset 可能變成 Firmware、Key、Security Function，Threat 可能是 Firmware Tampering、Debug Abuse、Key Extraction，對應的 Control 可能變成 Secure Boot、Debug Protection、Key Protection；到了 Memory Product，又可能需要重新從它的 Intended Purpose、Architecture、Interface 與 Security Capability 去辨識真正 relevant 的 Risk。
同樣都是 CRA Annex I，但 Product Architecture 不同，最後形成的 Security Design 可以完全不一樣。這也是做到這裡之後，我越來越能理解 CRA 所強調的風險導向方法（Risk-based Approach）。

Day 5 小結｜Annex I 對我來說，不是一張所有產品共用的 Security Shopping List
做到這裡，我自己對 CRA Annex I 最大的理解變化，其實不是又多記住了多少 Security Control，而是開始把問題的順序倒過來。以前可能會先問：「CRA 要哪些 Security Control？」現在我會比較想先問：「這個 Product 有什麼 Cybersecurity Risk？」
因為 Router 跟 Memory 不同，MCU 跟 Cloud-connected Device 也不同。CRA Annex I 提供的是 Essential Cybersecurity Requirements，但 Manufacturer 還是需要把 Requirement 轉成自己 Product 的 Security Design，而中間很重要的一座橋，我覺得就是 Cybersecurity Risk Assessment。
Product 上市後，事情也沒有結束。SBOM 要能支援 Vulnerability Handling，Security Update 要能持續提供，Risk Assessment 也需要隨著 Product Lifecycle 適當更新。所以如果要我現在用兩句話理解 Annex I，我會寫成：
上市前，把 Cybersecurity Risk 放進 Product Design；上市後，持續處理 Product Vulnerability。
這只是我目前方便理解 CRA 的方式，不是對 Annex I 的正式法律解釋。以上也仍然是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。不同 Product 適用的 Security Measures，仍應依其 Intended Purpose、Cybersecurity Risk、Architecture、Threat Landscape 與 CRA 正式要求個別評估。

Day 6 預告｜CRA 說要做 Cybersecurity Risk Assessment，那到底怎麼做？
Day 5 一直談 Risk-based，但真正坐下來開始做，問題馬上就來了：Risk Assessment 到底要評什麼？Threat 從哪裡來？CVSS 可以直接拿來當 Product Risk 嗎？Threat Modeling 跟 Risk Assessment 是同一件事嗎？Router 怎麼做？MCU / Memory 又怎麼做？
更重要的是，做完 Risk Assessment 之後，要留下什麼 Evidence，才能真的回到 Product Development？
Day 6，我想從實務角度聊聊 CRA 產品網路安全風險評估（Product Cybersecurity Risk Assessment）。