終於來到 Day 30。
這 30 天，我試著把自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的理解、疑問與心得整理下來。這不是 CRA 的教科書，也不是法規解釋，更不是唯一的導入方法。
很多內容，其實都是我一邊研究、一邊實際思考：
**「如果企業真的要做，這件事情要怎麼落地？」**之後慢慢形成的個人看法。
最後一天，我不想再介紹新的 Requirement，而是想回到一個最實際的問題：
如果明天，公司才第一次把 CRA 交到我手上，我現在會怎麼開始？
第一次接觸 CRA，很容易想趕快建立制度。
所以開始寫 Policy、Procedure、Checklist，找 Template。
但走到 Day 30，如果重新開始，我反而不會急著寫文件。
我第一件事情會是：先把問題看清楚。
CRA 為什麼跟公司有關？
哪些 Product 可能適用？
哪些時間點最重要？
公司現在已經有哪些能力？
真正缺的是什麼？
因為如果連 Scope 都還不知道，Procedure 很可能寫得很漂亮，卻不知道到底要給誰使用。
如果今天開始，我會先抓住幾個重要時間點。
CRA 已於 2024 年 12 月 10 日生效；Article 14 的相關 Reporting Obligations 自 2026 年 9 月 11 日開始適用；CRA 大部分規定則自 2027 年 12 月 11 日開始適用。
所以如果是現在開始，我不會把所有工作都排到 2027 年。
因為：2026/9/11 已經先到了。
這也是我會先建立的第一個觀念：CRA 不是只有一個 Deadline。
如果所有 Resource 都只盯著 2027/12/11，很可能還沒把完整 Framework 建完，就先碰到 Article 14 的要求。
這件事看起來非常基本，但我現在反而覺得，它可能是整個 CRA Program 最重要的基礎之一。
我會先建立一份：Product Inventory。
至少先掌握 Product Family、Product Name / Model / Part Number、Product Owner、Legal Manufacturer、Software / Firmware、Connectivity、EU Market、Lifecycle Status 等基本資訊。
這時還不用急著把每個欄位做到完美。
第一階段最重要的是先回答：「我們到底有哪些 Product 需要評估？」
因為後面的 Applicability、Classification、Risk Assessment、Technical Documentation、Conformity Assessment，幾乎都會從這張 Inventory 往下展開。
如果連母體都不知道，後面很難知道 CRA 到底做到幾成。
有了 Product Inventory，下一步才是 Scope。
我會逐一去問：
是不是 Product with Digital Elements？
是否符合 CRA 的適用條件？
是否屬於排除範圍？
是否涉及其他特定 EU Legislation？
Product 是否會被 Made Available on the EU Market？
這一步我自己會很重視。
因為：Scope 判錯，後面所有工作都可能跟著偏掉。
所以我寧願前面多花一點時間，把 Applicability 的判斷邏輯、依據與紀錄方式先建立起來，而不是看到 Product 裡面有 Firmware 或 Connectivity，就直接認定答案。
而且我會要求：判斷結果要留下 Basis。
因為幾年之後 Product Feature 改變、Business Model 改變，或 Guidance 更新時，我們才知道當初為什麼這樣判。
確定 Product in Scope，接下來才進入 Classification。
例如判斷 Product 是否屬於一般 Products with Digital Elements、Important Products Class I、Important Products Class II 或 Critical Products。
這不是為了多填一個欄位。因為 Classification 後面會進一步影響 **Conformity Assessment Strategy。**所以我同樣會要求留下 Classification Basis。
不是只寫「Class I。」
而是要回答 「為什麼判斷是 Class I？」
這個「為什麼」，其實就是後面 Technical Documentation、Conformity Assessment，甚至未來重新檢視 Classification 時很重要的 Evidence。
這是如果重新開始，我現在一定會做的調整。
因為 2027/12/11 還有一段時間，但 2026/9/11 已經到了。
所以 Product Inventory、Applicability、Classification、SSDLC 等工作可以依 Roadmap 持續推進，但 Article 14 Readiness，我會另外拉出一條 Fast Track。
先把最實際的問題回答清楚：
Vulnerability 從哪裡進來？
誰判斷 Product Impact？
誰負責判斷是否涉及 Actively Exploited Vulnerability 或 Severe Incident？
內部什麼時間點開始計時？
24 小時與 72 小時相關 Reporting 怎麼完成？
後續 Final Report 誰追？
假日與跨時區怎麼處理？
誰有 Reporting 權限？
這些事情 我不會等完整 CRA Framework 建完才處理。
而且我不會只寫 Procedure。
我會真的跑一次 Scenario。
如果只有第一個 30 天，我不會要求 CRA 全部完成。
我會把目標放在 Scope + Governance + Urgent Readiness。
大概先完成以下幾件事情：
| First 30 Days | 主要目的 |
|---|---|
| CRA Requirement Overview | 先建立共同法規認知與主要要求範圍 |
| Product Inventory 初版 | 掌握可能受 CRA 影響的產品母體 |
| Applicability Assessment Method | 建立 CRA Scope 判定方法 |
| Product Classification Method | 建立產品分類與判斷依據 |
| CRA Governance / RACI | 確認跨部門角色與責任 |
| Current-state Gap Assessment | 了解現有能力與主要 Gap |
| Article 14 Reporting Flow / Readiness | 優先建立已生效通報要求的基本能力 |
| High-level Implementation Roadmap | 排出後續 Workstream 與優先順序 |
所以第一個月，我自己最想得到的不是一堆 Procedure。而是一張 公司 CRA 現況地圖。
我要知道哪些 Product 可能適用、哪些 Team 需要加入、哪些能力已經存在、哪些 Gap 最急，以及哪些事情會卡住後面的工作。
當 Scope 大致清楚，下一步才開始建立真正的 Capability。
我可能拆成幾條 Workstream：
Product Classification
Product Cybersecurity Risk
SSDLC
SBOM
PSIRT / Vulnerability
Supplier Security
Technical Documentation
Conformity Assessment
每一條都用類似的方法往下拆 Current State → Gap → Target State → Owner → Action → Deadline → Evidence
做到這裡，CRA 才會慢慢從 法規研究 變成 Implementation Program。
這也是我現在回頭看，覺得很重要的一個轉折。
前面可以研究很久，但最後一定要有人、流程、時程與 Deliverable 接住。
因為做到後來，我發現很多東西其實都從 Risk 出發。
Security Requirement 從 Risk 來。
Threat Modeling 支援 Risk Analysis。
Testing 驗證 Security Control。
Technical Documentation 又需要相關 Risk Assessment 與 Evidence。
所以 Product Cybersecurity Risk Assessment，我不會放到最後才做。
Product Scope 確認之後，我可能就會挑 Representative Product 先 Pilot。
因為 Risk Assessment 一跑，很快就會發現很多原本只停留在概念上的問題。
例如：
Asset 怎麼定義？
Attack Surface 怎麼盤？
Threat Scenario 誰來判斷？
Risk Owner 是誰？
Residual Risk 誰接受？
這些問題如果等到後面才處理，很多流程可能都要重新設計。
這是如果重新做，我自己很想採取的方法。
我可能先選 1～3 個 Product，而且最好來自不同 Product Family，然後完整跑一次：
Applicability → Classification → Risk Assessment → Threat Modeling → Security Requirement → SSDLC → SBOM → Security Testing → Technical Documentation → Conformity
因為 Template 在會議室裡看起來通常都很好。 真正拿一個 Product 跑一次，才知道哪裡不實際。
可能第一版 Risk Assessment 太複雜，R&D 根本填不完；可能 SBOM Tool 產得出檔案，但跟 Product Release 對不起來；也可能 Technical Documentation 要的 Evidence，其實散在五個不同 System。
這些問題 Pilot Product 會比十場會議更快告訴你答案。
如果公司本來就有 Product Development Process，我會先問：
Security Requirement 能不能加進去？
Threat Modeling 能不能進 Design Review？
SAST / SCA 能不能進 Build？
Security Testing 能不能進 Verification？
SBOM 能不能成為 Release Artifact？
Security Sign-off 能不能進 Release Gate？
如果可以，我會優先 Extend Existing Process。
而不是另外建立一套 「CRA 專用 SSDLC」。
因為我真正希望的是 2028 年之後，即使 CRA Project 已經結束，R&D 還是會繼續做。
這樣 CRA 才真正進入 Product Development Process，而不是在旁邊多長出一套平行流程。
一開始，我不一定會急著建立最豪華的 SBOM Platform。
我會先確認幾件最基本的事情：
能不能產？
Component Identification 是否合理？
Version 對不對？
能不能對應 Product Release？
Vulnerability 發生時能不能查？
然後再逐步 Automation。
因為我現在越來越覺得 SBOM 最大的價值不是「我們有一個 SPDX / CycloneDX File」，而是發現 Vulnerability 時，我們知道哪些 Product 可能受到影響。
如果格式非常漂亮，但 Product Version 對不起來，真正出事的時候仍然很難使用。
我會建立或強化 Vulnerability Intake、Triage、Product Impact Assessment、Severity Assessment、Remediation、Disclosure、CVE Coordination、Customer Communication，再把 CRA Article 14 Assessment 接進來。
這樣 CRA Project 結束後 PSIRT 還是可以繼續運作。
我自己會把 PSIRT 視為 CRA 很值得留下來的 Organizational Capability 之一。
因為即使沒有 CRA，Product Vulnerability 也不會消失。
如果重新做，我可能會更早把 Product Component 跟 Supplier 接起來。
真正需要知道的是：
Supplier 提供什麼 Component？
哪些 Product 在使用？
Vulnerability 怎麼通知？
Security Fix 怎麼提供？
Support 到什麼時候？
EOL 怎麼通知？
Questionnaire 當然可以有。但它不是終點。
真正要建立的是 Supplier → Component → Product 之間的關係。
因為當某個 Supplier 通知一個 Critical Vulnerability 時，我們最需要回答的不是：
「這家 Supplier 去年問卷幾分？」
而是 「我們哪些 Product 受到影響？」
這可能是我現在很想提醒自己的地方。
如果等 Product 全部做完，才開始問：「Technical Documentation 到底需要什麼？」
可能會發現三年前的 Threat Model 找不到、Test Report 不知道是哪個 Version、Risk Decision 沒留紀錄、Supplier Evidence 也不知道誰保存。
所以 Technical Documentation Structure，我會提早定義。
開發過程中 Evidence 就慢慢累積。到了 Conformity Assessment，才不需要開始「考古」。
如果重新開始，我會很早建立這樣的關係：
CRA Requirement → Internal Process → Owner → Evidence → System of Record
例如：
| CRA Requirement / Activity | Internal Process | Owner | Evidence | System of Record |
|---|---|---|---|---|
| CRA Applicability | Product Planning / Compliance | Product / Compliance | Applicability Assessment | Product / Compliance System |
| Product Risk Assessment | Product Security / SSDLC | Product / R&D / Security | Risk Assessment Record | Risk / Product Repository |
| Threat Modeling | Design Review / SSDLC | R&D / Product Security | Threat Model | Engineering Repository |
| SBOM | Build / Release | Engineering | SBOM / Build Record | Build / Release System |
| Vulnerability Handling | PSIRT | PSIRT / Product Team | Case Record / Impact Assessment | PSIRT Case System |
| Supplier Security | Supplier Management | Procurement / Product Team | Supplier / Component Evidence | Supplier System |
| Security Testing | Verification / Release | R&D / QA / Security | Test Report | Engineering / QA Repository |
| Technical Documentation | Product Compliance | Product / Compliance | Technical Documentation | Document Repository |
實際 Owner 與 System of Record 當然還是要依企業組織與既有流程調整。
但這張 Matrix 我現在覺得非常有價值。
因為它同時回答：
誰負責？
怎麼做？
證據在哪？
還缺什麼？
到後面做 Mock Audit 時，也可以直接拿它來 Trace。
這也是 Day 26 談 Evidence Management 後，我自己越來越重視的一件事情 不要只管理文件，要管理 Traceability。
Classification 確認後，其實就應該開始思考 Conformity Assessment Route。
是否可以採用適用的 Internal Control Route？
是否因 Product Classification 或其他條件需要 Third-party Conformity Assessment？
預計使用哪些 Harmonised Standards 或其他 Technical Specifications？
是否可能需要 Notified Body？
因為如果真的需要 External Assessment，Budget、Schedule、Evidence、Testing 都需要提前安排。
所以 CE 雖然看起來在最後，但 Conformity Planning 不能放到最後。
這件事情如果到 Release 前才發現，可能就不只是 Compliance Gap，而會直接變成 Schedule Risk。
這可能是我做完這 30 天後，最大的 Project Management 心得之一。
不是每件事情都要同時開始。
我會先處理 Dependency 高的事情。
| 優先建立的能力 | 為什麼要先做 |
|---|---|
| Product Inventory | 會影響 Scope 與後續產品盤點 |
| Applicability | 決定哪些 Product 需要進入 CRA 後續流程 |
| Classification | 影響 Conformity Assessment Strategy |
| Risk Assessment | 影響 Security Requirement、Threat Modeling 與 Testing |
| SBOM | 支援 Component / Vulnerability Impact Analysis |
| PSIRT | 直接支援 Vulnerability Handling 與 Article 14 |
| Evidence Framework | 支援 Technical Documentation 與後續 Audit / Assessment |
所以 Roadmap 不是單純把所有 CRA Requirement 排上日期。
而是 先看 Dependency，再排 Priority。
有些工作看起來 Deadline 很後面，但如果不先做，後面三、四條 Workstream 都可能一起卡住。
不是每週請 Management 參加 Technical Meeting。
而是一開始就說清楚：
CRA 對哪些 Product 有影響？
重要 Deadline 是什麼？
需要哪些 Function？
需要多少 Resource？
哪些 Decision 可能影響 Business？
例如 Support Period、Product Market Strategy、Supplier Replacement、Product Release Delay、Third-party Assessment Cost。
這些到最後都不是 Security Team 自己能決定的事情。
所以我現在會把 Management Sponsorship 理解成 需要做決策的時候，真的有人可以做決策。
而不是只有 Steering Committee Organization Chart 上面有幾個名字。
這也是我現在很有感的一件事。
第一次 Risk Assessment Template 可能不好用。
第一次 SBOM 可能不完整。
第一次 Article 14 Drill 可能很混亂。
第一次 Mock Audit 可能找出一堆 Gap。
我現在反而覺得 這很正常。
因為 CRA Implementation 本來就會是一個逐步成熟的過程。
所以 Pilot → Review → Improve → Rollout
可能比一開始花半年設計一套「完美制度」，最後才發現現場根本跑不動，更實際。
我寧願第一版只有 70 分但真的有人使用，再透過實際使用慢慢改善。
如果問我 「CRA Ready 長什麼樣子？」
我現在可能會回答：
| 我想看到的狀態 | 代表的能力 |
|---|---|
| Product Scope 知道 | Product Inventory / Applicability 能持續運作 |
| Classification 有依據 | Classification Basis 可追溯 |
| Product Risk 有被管理 | Risk Assessment / Risk Treatment 在運作 |
| SSDLC 真的在跑 | Security 已進入 Product Development |
| SBOM 對得上 Release | Component 與 Product Version 可追溯 |
| Vulnerability 進得了 PSIRT | Product Vulnerability 有正式處理機制 |
| Article 14 Process 跑得動 | Regulatory Reporting Readiness 已建立 |
| Supplier Component Risk 看得到 | Supplier / Component / Product 能建立關聯 |
| Technical Documentation 找得到 Evidence | Evidence 與 Product Version 可追溯 |
| Conformity Assessment Route 清楚 | 上市前的 Compliance Path 已確認 |
| Product Change 會 Trigger Security Review | 上市後仍能維持 Lifecycle Compliance |
| Management 看得到重大 Risk | 重大 Product Security Decision 有治理機制 |
但還有一件我自己更在意的事情 這些事情不是只有 CRA PMO 知道怎麼做。
如果 CRA PMO 一解散，大家就不知道下一個 Product 怎麼評估、下一個 Vulnerability 怎麼處理，那我會覺得我們可能只是把 Project 做完了。
還沒有真的 CRA Ready。
我想，我會告訴自己 先不要急著把 CRA 做成文件，先把 CRA 做成流程。
文件當然重要。但真正需要回答的是：
Product 進來，誰判斷？
Risk 出現，誰處理？
Vulnerability 發現，誰分析？
Supplier 出問題，誰追？
Product Change，誰重新評估？
要上市，誰確認 Conformity？
上市之後，誰繼續維護？
如果這些問題都有答案 文件才真正有意義。
這 30 天一路寫下來，我自己越來越確定 CRA 很難由單一 Function 完成。
它需要 Product、R&D、Product Security、PSIRT、QA、Procurement、Product Compliance、Legal、Customer Support、Management。
Security 當然很重要，但它更像是在提供 Framework、Methodology、Governance，並協助把不同 Function 串起來。
因為 Product Cybersecurity 最後還是發生在 Product Lifecycle 裡。
如果 Product Development、Supplier Management、Release、Maintenance 原本的流程都沒有改，只多出一個 Security Team 在旁邊追 Checklist，我自己會擔心這樣很難長期運作。
這也是 Day 28 談 Operating Model 時，我自己很在意的事情。
如果所有設計都只為了 2027/12/11，那到了 2028 年，可能又要重新開始。
我現在更希望 CRA Implementation 最後留下的是 Product Security Capability。
Project 可以 Close。
但 SSDLC、SBOM、PSIRT、Supplier Security、Product Risk、Evidence、Governance 會繼續運作。
真正理想的狀態可能是 有一天公司不再把這些事情叫做「CRA 工作」。
而是它們原本就是 Product Development 與 Product Lifecycle 的一部分。
Day 1，我比較在意 CRA 是什麼？
接著開始問 哪些 Product 適用？
再來 要做哪些 Requirement？
後來變成 怎麼做？
再往後 誰來做？
最後變成 怎麼讓它一直做下去？
我覺得這個過程，也滿像自己理解 CRA 的一條路：
Regulation → Compliance → Process → Capability
一開始是在讀法規。
後來是在做 Compliance。
再後來是在設計 Process。
最後真正想留下來的 是 Capability。
我現在可能會畫成：
Understand
↓
Scope
↓
Classify
↓
Assess Risk
↓
Build Security into Development
↓
Know Your Components
↓
Handle Vulnerabilities
↓
Manage Suppliers
↓
Collect Evidence
↓
Assess Conformity
↓
Place Product on Market
↓
Monitor & Maintain
↓
Improve
但這條路 不是只走一次。
Product 每一次 Change，可能又會重新走其中一段。新的 Vulnerability 出現，又會走其中一段。
新的 Component 加進來，可能又要重新看 Risk、SBOM、Supplier 與 Testing。
所以寫到最後，我自己越來越覺得 CRA 最後其實是一個 Lifecycle。
寫到最後，我反而不太想只把 CRA 看成一項新的 EU Compliance Burden。
因為從企業角度來說，它確實會帶來成本、人力、文件、Tool、Process、Training。
這些都是真實的負擔。
但換一個角度，如果企業本來就需要面對 Software Supply Chain Risk、Product Vulnerability、Open Source Risk、Security Update、Customer Security Requirement、Product Incident，那 CRA 某種程度也把這些原本可能分散在不同 Team 的事情：
串成了一個 Product Cybersecurity Lifecycle。
這是我自己研究到最後，覺得很值得思考的一件事情。
我反而比較想用 Product Security。
因為法規會改，Standard 會改，Guidance 會更新，Technology 也會改。
但 Product 需要被安全地 Design、Develop、Release、Maintain，這件事情不會因為 CRA Project 結案就消失。
所以如果 CRA 最後真的讓企業建立了一套 Product Risk Management、Secure Development、SBOM、PSIRT、Supplier Security、Evidence Traceability 與 Lifecycle Governance，我自己會覺得：
這可能比單純完成一次 Compliance Project，更有長期價值。
而且這些能力未來面對的，也不會只有 CRA。
這 30 天，我們從 CRA 的基本概念開始，一路走過 Product Scope、Classification、Cybersecurity Risk Assessment、SSDLC、Threat Modeling、SBOM、Vulnerability Management、PSIRT、Article 14、Supplier Security、Support Period、Technical Documentation、Conformity Assessment、EU DoC、CE、Market Surveillance、Governance、KPI / KRI、Evidence、Mock Audit、Operating Model。
但如果問我：「30 天之後，最想留下什麼？」
可能不是 「我已經知道 CRA 所有答案。」
事實上，我還有很多地方正在研究、理解與學習。
我比較希望留下的是 一套看待 CRA 的方式。
看到 Requirement，問它影響哪個 Product？
看到 Product，問它有哪些 Risk？
看到 Risk，問誰負責處理？
看到 Control，問怎麼驗證？
看到 Evidence，問對應哪個 Version？
看到 Vulnerability，問影響哪些 Product？
看到 Supplier，問它提供哪些 Component？
看到 Change，問 Risk 有沒有跟著改？
看到 Compliance，問 這套能力能不能持續？
開始寫這個系列時，我只是想把自己對 CRA 的研究與實務上的思考整理下來。
一路寫到 Day 30，我自己也在這個過程中重新整理了很多原本看似分散的概念。
而我越來越覺得：
CRA 並不是一個靠 Security Team 寫幾份 Procedure 就能完成的題目。
它牽涉 Product、Engineering、Security、Supply Chain、Compliance、Management。
真正困難的，往往不是某一條法規看不懂。
而是 怎麼把這些人、流程、系統與 Evidence 串起來。
這 30 天分享的內容，當然不會是 CRA 的標準答案。
更多的是我自己一路研究、參與、思考後形成的心得與解讀。
有些想法，之後隨著法規 Guidance、Standards 與自己的實務經驗增加，我相信也可能再調整。
但我想 這也是把它寫下來的意義。
不是告訴大家「CRA 就應該這樣做。」
而是把自己目前看到的問題、理解的方法，以及實際導入時遇到的思考，拿出來和大家交流。
如果這 30 天的內容，能讓正在接觸 CRA 的朋友少一點：「這到底要從哪裡開始？」
或者讓原本在做 ISMS、Product Security、R&D、PSIRT、Product Compliance、Supply Chain 的朋友開始發現：
自己原來也是 CRA 這張拼圖的一部分。
那我覺得這 30 天就很值得了。
Day 1，我們從 「CRA 是什麼？」 開始。
到了 Day 30，我自己最後得到的問題卻變成 「我們想建立什麼樣的 Product Security 能力？」
因為 法規要求我們符合 CRA；但真正能讓企業長期走下去的，是把 Cybersecurity 變成 Product Lifecycle 原本就存在的一部分。
這是我目前對 CRA 最深的一個體會。
也用這句話，為這次 30 天 CRA 鐵人賽畫下一個 暫時的句點。
因為真正的 CRA 導入，不會在 Day 30 結束。
對我來說 這 30 天比較像是把問題看清楚。
而接下來真正困難、也真正有意思的事情，才正要開始 把它做進 Product。
— CRA 鐵人賽 30 天，完。
iThome鐵人賽
看影片追技術