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

做完 Risk Assessment，真正困難的事情才開始
Day 6 談到產品網路安全風險評估（Product Cybersecurity Risk Assessment）。
假設我們已經找出資產（Asset）、威脅（Threat）、風險（Risk），甚至進一步形成安全需求（Security Requirement），下一題就是：
然後呢？
如果 Risk Assessment 做得很漂亮，但 R&D 還是按照原來的方式開發，那這份 Risk Assessment 最後可能只是一份 Compliance Document。
所以我自己開始思考：
CRA 到底要怎麼真正進入 Product Development？
這時安全軟體開發生命週期（Secure Software Development Lifecycle, SSDLC）的概念就出現了。

一、CRA 有規定一定要建立一套叫「SSDLC」的制度嗎？
我自己目前不會這樣理解。
CRA 不一定要求公司建立一份名稱就叫 CRA SSDLC Procedure 的文件，但從 CRA Article 13 與 Annex I 的要求來看，Manufacturer 需要把 Cybersecurity Risk 與相關要求納入 Product 的規劃（Planning）、設計（Design）、開發（Development）、生產（Production）、交付（Delivery）與維護（Maintenance）等階段。
所以：
不一定要叫 SSDLC，但 Product Development Lifecycle 需要能承接 CRA 的 Cybersecurity Requirements。
我覺得這兩件事情要稍微分開。
真正重要的不是公司有沒有一份文件叫 SSDLC，而是 Security 能不能真的進入原本的 Product Development Process。

二、如果公司本來就有 Development Process
很多 ICT Company 本來就有軟體開發生命週期（Software Development Lifecycle, SDLC），可能已經包含 Requirement、Design Review、Coding、Code Review、Testing、Release 與 Maintenance。
有些公司甚至已經建立 SSDLC 或 DevSecOps。
那我自己的第一個想法不會是再創造一條 CRA Development Process，而是先問：
現有流程有哪些地方已經 Cover CRA？哪些地方還缺？
例如原本已經有靜態應用程式安全測試（Static Application Security Testing, SAST），不一定需要另外再做一套「CRA SAST」。
原本已經有開源軟體掃描或軟體成分分析（Software Composition Analysis, SCA），那就看看能不能進一步支援 Component Inventory、SBOM 與後續 Vulnerability Management。
我目前比較傾向：
Reuse → Mapping → Gap → Improve
也就是能沿用的先沿用，先做 Mapping，再找 Gap，最後補強，而不是全部重來。

三、但 SSDLC 也不能只等於 SAST + SCA
這是我自己覺得很容易發生的情況。
一談到 Secure Development，馬上就想到 SAST、SCA、動態應用程式安全測試（Dynamic Application Security Testing, DAST）與滲透測試（Penetration Test）。
這些當然都很重要，但如果 Security 只在 Code 寫完之後才進場，其實很多問題已經很難改。
例如 Authentication Architecture、信任邊界（Trust Boundary）、更新機制（Update Mechanism）、金鑰管理（Key Management）、權限設計（Privilege Design），很多都不是最後跑一次掃描工具就能解決的問題。
所以我現在比較傾向把 Secure Development 往前移。
Security 不應該只是一個 Product Development 最後面的 Testing Activity。

四、第一個可以往前移的，是 Security Requirement
Day 6 提到 Risk Assessment 最好不要做完就結束。
例如我們找出一個 Risk：
未經授權的 Firmware 修改（Unauthorized Firmware Modification）
那可能進一步轉成 Security Requirement：
Product shall verify the authenticity and integrity of firmware before installation.
Product 在安裝 Firmware 前，應驗證其真實性（Authenticity）與完整性（Integrity）。
接下來 Architecture / Design 才知道要處理什麼，最後再透過驗證（Verification）確認這項 Requirement 是否真的被實現。
所以我自己現在很喜歡一條很簡單的線：
Risk
↓
Security Requirement
↓
Design
↓
Implementation
↓
Verification
↓
Evidence
如果這條線可以被追溯（Trace），後面的 CRA Technical Documentation 也會比較有基礎。

五、以 Router 為例
假設 Product 是一台 Router。
Risk Assessment 發現遠端管理介面（Remote Management Interface）可能被未經授權的使用者（Unauthorized User）取得控制權。
接下來形成的 Security Requirement，可能涉及強式驗證（Strong Authentication）、存取控制（Access Control）、Session Protection 或 Interface Restriction。
R&D 依 Requirement 進行 Design 與 Development，Testing 階段再執行 Authentication Test、Authorization Test 或其他適合的 Security Testing。
最後留下 Requirement、Design Record 與 Test Result。
這時 Security 才真正走進 Development Lifecycle，而不是等產品快 Release 時才找 Security Team 來掃一次。

六、Semiconductor 也可以用同樣的邏輯，只是 Evidence 不一樣
假設今天是一顆 MCU。
Risk 是未經授權的程式碼（Unauthorized Code）在開機流程（Boot Process）中執行。
Security Requirement 可能是：
Boot Process 應驗證 Firmware Authenticity。
接下來由 Hardware / Firmware Architecture 決定如何實作，可能涉及 ROM Code、密碼功能（Cryptographic Function）、金鑰儲存（Key Storage）與 Boot Sequence。
Verification 階段再依不同 Attack Scenario 確認相關 Security Mechanism 是否有效。
所以 Semiconductor 的 Secure Development 不一定只是在談 Software Source Code，它可能同時碰到 Hardware Design、Firmware、SDK、Driver，甚至 Security-related RTL / IP。
這也是我覺得 CRA 對 Semiconductor Company 很有意思的地方。
同樣一個 Product Security Lifecycle，到了 Semiconductor，Evidence 可能跟一般 Software Product 長得完全不一樣。

七、那 Hardware Development 還叫 SSDLC 嗎？
嚴格來說，SSDLC 的第一個 S 通常指的是 Software。
如果公司做的是 Semiconductor 或 Hardware Product，我自己反而比較喜歡用：
安全產品開發生命週期（Secure Product Development Lifecycle）
因為 CRA 管的是 Product with Digital Elements，不是只有 Software。
所以企業真正建立的可能是一套 Product Security Development Process，底下再依 Hardware、Firmware、Software、SDK 等不同 Product Element，安排不同的 Security Activity。
名稱我覺得反而不是最重要的。
重點是 Security Activity 有沒有真的進入 Product Lifecycle。

八、Secure Coding 還是重要，但它只是其中一段
如果 Product 有 Software / Firmware，安全程式設計（Secure Coding）當然還是重要。
例如 Coding Standard、Code Review、記憶體安全（Memory Safety）、輸入驗證（Input Validation）、錯誤處理（Error Handling）、Credential Handling 等。
但 CRA Annex I 關注的範圍比 Coding 本身更廣，還包括攻擊面（Attack Surface）、Access Control、Confidentiality / Integrity、Secure Update 與 Vulnerability Handling 等。
所以：
「我們有 Secure Coding Standard」不等於「SSDLC 已經完整 Cover CRA」。
還是需要回到 CRA Requirements 做 Mapping。

九、SAST / SCA 可以幫忙，但也不是答案本身
SAST 可以協助找出與 Coding 有關的弱點（Weakness），SCA 則可以協助識別 Open Source Component 及 Known Vulnerability。
這些工具都很實用，尤其 SCA 後面還可能跟軟體物料清單（Software Bill of Materials, SBOM）接起來。
但我自己會把這些工具理解成：
Detection / Verification / Evidence Mechanism。
真正的 Secure Development 還包括前面的 Risk、Requirement、Architecture，以及後面的 Remediation、Release Decision 與 Vulnerability Handling。
所以：
Tool 很重要，但 Tool ≠ Process。
買了 SAST / SCA Tool，也不代表 SSDLC 就自然建立起來了。

十、Penetration Test 也是一樣
另一個很常見的問題是：
「CRA 是不是規定每個 Product 都要做 Penetration Test？」
我自己不會這樣直接下結論。
CRA Annex I Part II 要求 Manufacturer 對 Product Security 進行有效且定期的測試與檢視（Effective and Regular Tests and Reviews）。
但實際需要哪些 Verification Activity，我認為還是應該依 Product Risk、Architecture 與 Attack Surface 等因素決定。
對 Internet-facing ICT Product，Penetration Test 可能很有價值。
但對某些 Semiconductor Component，Verification 可能需要完全不同的方法，例如針對 Hardware / Firmware Security Mechanism 設計特定 Test Scenario。
所以我不太會把 Pen Test 當成：
所有 CRA Product 的單一答案。
真正重要的還是 Verification Activity 能不能合理驗證前面識別出的 Security Requirement 與 Risk Treatment。

十一、Open Source / Third-party Component 要更早進 Development
CRA 做到後面，很容易發現 Product Security 不只是自己寫的 Code。
Product 可能使用 OpenSSL、Linux、Third-party Library、Commercial SDK、Security IP 或 Third-party Firmware。
如果這些 Component 到 Release 前才第一次被盤點，後面的 SBOM 與 Vulnerability Monitoring 可能會很辛苦。
所以我自己會希望從元件選擇（Component Selection）階段，就開始考慮 Security、Support、Vulnerability History、Update Availability，以及 Lifecycle / End of Life（EOL）。
也就是說，問題不只是：
「這個 Component 能不能用？」
還要開始問：
「如果未來它出現 Vulnerability，我們有沒有能力處理？」
這也會一路連到後面的 Supplier Security。

十二、Release Gate 我會希望多一點 Security 意味
傳統 Product Release 可能比較關心 Function、Quality、Performance 與 Schedule。
CRA 之後，我自己會希望在既有產品發布關卡（Release Gate）裡，再加入一些 Security Criteria。
例如 Critical Security Finding 是否已處理？Cybersecurity Risk Assessment 是否更新？SBOM 是否完成？Known Vulnerability 是否完成影響分析（Impact Assessment）？Security Requirement 是否完成 Verification？Technical Evidence 是否齊備？
這不一定要另外成立一個很大的 Security Committee。
也可能只是：
把 Security Criteria 放進既有 Release Gate。
我自己比較喜歡這種整合方式。
因為對 R&D 來說，它仍然是原本的 Product Development Process，只是 Release Criteria 多了 Product Security 的要求，而不是突然多出另一套 CRA Process。

十三、Development 完成後，事情還沒結束
這又回到 CRA 很重要的 Lifecycle 概念。
Product Release 並不是 Security Process 結束，後面還有 Vulnerability Monitoring、Security Update、Incident Handling、Article 14 Reporting 與 Support Period。
所以我現在會希望 Development Team 在 Product Release 時，不只是把 Code / Design 交出去，還要有一些資訊能被產品資安事件應變團隊（Product Security Incident Response Team, PSIRT）或 Product Security Team 接手。
例如 Product Version、Component Information、SBOM、Security Contact、Known Issue 與 Support Information。
這樣 Development 跟後面的 Vulnerability Handling 才真正接得起來。
我覺得這個「交接點」其實很容易被忽略。

十四、IEC 62443-4-1 在這裡就很值得參考
如果是 Industrial / OT / Embedded Product，IEC 62443-4-1 我覺得很值得一起看。
它本來就聚焦在 Secure Product Development Lifecycle，涵蓋 Security Requirements、Secure Design、Secure Implementation、Verification / Validation、Defect Management、Security Update 等生命週期活動。
所以公司如果已經在做 IEC 62443-4-1，我自己會先做 CRA Mapping，而不是再創造另一套 CRA Development Lifecycle。
但還是同一句：
IEC 62443-4-1 ≠ CRA Compliance。
既有 IEC 62443-4-1 Process 能 Cover 多少 CRA Requirements，還是需要逐項確認。
我自己會比較希望最後形成的是：
一套 Product Development Process，支援多個 Security / Compliance Requirement。
而不是 CRA 一套、IEC 62443 一套，其他 Customer Requirement 又再一套。

十五、未來 Harmonised Standards 也會影響這件事
CRA 的調和標準（Harmonised Standards）還在持續發展。
European Commission 已透過 Standardisation Request M/606 推動相關 Horizontal 與 Product-specific Standards，希望進一步把 CRA Essential Cybersecurity Requirements 轉成更具體的 Technical Specifications。
所以我目前不太想把 SSDLC 寫死成一個永遠不變的版本。
比較實際的方式可能是先利用既有 Secure Development Practice 建立 Baseline，之後隨著 Harmonised Standards、Guidance 與實務逐步成熟，再持續進行：
Mapping → Adjust → Improve
我覺得這樣比現在就試圖一次設計出「最終版 CRA SSDLC」更實際。

十六、如果讓我畫一個最簡單的 Secure Product Development Flow
如果把前面談的內容放在一起，我目前大概會把安全產品開發流程（Secure Product Development Flow）畫成：
產品規劃（Product Planning）
↓
網路安全風險評估（Cybersecurity Risk Assessment）
↓
安全需求（Security Requirements）
↓
威脅建模／安全設計（Threat Modeling / Secure Design）
↓
安全實作（Secure Implementation）
↓
安全驗證（Security Verification）
↓
漏洞／元件檢視（Vulnerability / Component Review）
↓
安全發布審查（Security Release Review）
↓
上市後漏洞處理（Post-market Vulnerability Handling）
這不是 CRA 官方指定的流程，只是我目前把 CRA Requirements 放進 Product Lifecycle 後，比較容易理解的方式。
而且這條線也剛好把前幾天談的東西慢慢串起來：
Risk → Requirement → Development → Verification → Release → Vulnerability Handling

Day 7 小結｜我現在比較不想建立「CRA 專用 SSDLC」
研究到這裡，我自己最大的心得反而是：
不要為 CRA 再建立一個孤立的 Development World。
如果公司已經有 SDLC，就看怎麼把 Security 放進去；已經有 SSDLC，就做 CRA Mapping；已經有 IEC 62443-4-1，就看看哪些 Process 與 Evidence 可以 Reuse。
真正重要的不是 Process 叫什麼名字，而是：
Cybersecurity Risk 能不能一路走進 Requirement、Design、Implementation、Verification 與 Release。
而且 Product Release 後，還要能接到 Vulnerability Handling。
對 ICT Product，可能比較偏 Software / Firmware；對 Semiconductor Product，則可能同時涉及 Hardware、Firmware、SDK、Driver 與 Third-party IP。
所以同一套 CRA Requirements，最後在不同產業可能長出不同的 Secure Development Practice。
我自己現在反而覺得這是比較合理的結果。CRA 提供的是 Product Cybersecurity 的要求，但企業真正要做的，是把這些要求放進自己原本就存在的 Product Development Lifecycle，而不是為了 Compliance 再建立一個平行世界。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
未來隨著 CRA Harmonised Standards 與相關實務逐步成熟，現在建立的方法與流程，我相信也還有很多持續 Mapping、調整與改善的空間。

Day 8 預告｜Product 裡到底有什麼？CRA 為什麼讓 SBOM 變得這麼重要？
Secure Development 做下去，很快就會遇到另一題：
「我們的 Product 到底用了哪些 Component？」
OpenSSL 出現 Vulnerability，哪些產品有用？
Linux Kernel 出問題，哪些 Version 受影響？
Supplier SDK 出 CVE，哪些 Product 要查？
到了 Semiconductor Product，Firmware、SDK、Third-party IP 又該怎麼盤？
這時軟體物料清單（Software Bill of Materials, SBOM）就不再只是一份 Component List。
真正的問題開始變成：
「當某個 Component 明天出現重大 Vulnerability，我們能不能快速知道哪些 Product 受到影響？」
Day 8，我們來聊 CRA、SBOM，以及我為什麼慢慢覺得「有 SBOM」跟「SBOM 能用」是兩件不同的事。