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

Day 8 談完 SBOM，我馬上想到下一個問題
上一篇談到，SBOM 的價值不只是「我有一份 Component List」。真正發生 Vulnerability 時，能不能快速知道哪些 Product、哪些 Version 受到影響，可能才是它真正開始發揮價值的地方。
但接下來問題就來了：誰來看這些 Vulnerability？
假設今天 Security Researcher 寄了一封信，或者 Supplier 通知某個 Component 有 Vulnerability，又或者 CVE / Security Advisory 出現新的資訊，公司裡到底誰接？誰判斷？誰找 R&D？誰決定修不修？誰跟 Customer 溝通？如果又碰到 CRA Article 14，誰判斷要不要通報？
這時，**PSIRT（Product Security Incident Response Team，產品資安事件應變團隊）**就開始進入我的 CRA 學習地圖。

一、PSIRT 跟傳統 CSIRT / SOC，我自己會稍微分開看
做 Corporate Security，我們比較熟悉的通常是 SOC、CSIRT 或 Incident Response Team。例如公司 Endpoint 中 Malware、AD 被攻擊、Server 被入侵，或 Employee Account 被盜，主要處理的是公司自己的 Information Environment。
但 PSIRT 比較聚焦的是公司提供給 Customer 的 Product。
例如 Router 出現 Authentication Bypass、Firmware 發現 Vulnerability、SDK 使用的 Library 出現 CVE，或 MCU 的 Security Function 被研究者發現可能遭 Bypass。這時處理的對象不再是公司內部的 Server，而是已經交到 Customer 手上的 Product。
所以我自己會覺得，CSIRT 與 PSIRT 的能力其實有不少重疊，例如 Incident Triage、Impact Analysis、Escalation、Communication，但兩者面對的 Context 不完全一樣。一個主要保護企業本身的資訊環境，另一個則把焦點放在產品及其生命週期。

二、CRA 並沒有要求一定成立一個叫「PSIRT」的部門
這點我覺得也要先說清楚。CRA 真正要求的，是 Manufacturer 建立並執行相應的 Vulnerability Handling 能力。
例如 CRA Annex I Part II 涵蓋 Identify and Document Vulnerabilities、Address and Remediate Vulnerabilities without Delay、Effective and Regular Security Tests / Reviews、Public Disclosure of Fixed Vulnerabilities、Secure Distribution of Updates 等要求。
CRA Annex II 也要求 Product 提供 Single Point of Contact，讓外部可以 Report / Receive Product Vulnerability Information，並取得 Manufacturer 的 Coordinated Vulnerability Disclosure Policy。
所以法規真正關心的是 Capability 有沒有建立、流程能不能運作。至於企業把負責這些工作的組織叫做 PSIRT、Product Security Team、Vulnerability Response Team，或直接由既有 CSIRT 延伸，我自己覺得還是可以依企業組織與產品特性設計，不一定非得成立一個名稱叫做「PSIRT」的新部門。

三、但不管叫什麼，第一件事可能是「讓別人找得到你」
假設 Security Researcher 發現 Product Vulnerability，想通知 Manufacturer，結果官網找不到 Security Contact，只好先寄給 Customer Service；Customer Service 不知道轉給誰，再轉給 Sales，Sales 又開始找 R&D，幾天可能就這樣過去了。
所以我自己覺得，Vulnerability Disclosure 的第一步其實很基本：建立一個清楚、可被外部找到的 Vulnerability Reporting Channel。
它可以是 Security Email、Web Form 或 Vulnerability Disclosure Page。重點不是 Channel 做得多漂亮，而是收到之後真的有人處理，而且知道下一步該找誰。

四、收到 Vulnerability 之後，我會先做 Triage
假設今天收到一則通報：「Product A 存在 Remote Code Execution。」
第一時間，我自己不會直接宣布這是 Critical Incident，也不會看到 CVSS 9.8 就直接進 Article 14。可能還是要先確認是哪個 Product、哪個 Version，Vulnerability 是否可以 Reproduce、Attack Preconditions 是什麼、是否需要 Authentication、哪些 Configuration 受影響，以及是否已經存在實際 Exploitation。
這就是 Triage（初步分析與分流）。
因為外部報告的 Severity，跟 Manufacturer 最後評估出來的 Product Impact 不一定完全一樣。CVSS 可以是很重要的參考，但真正進入產品情境後，還是需要結合產品架構、使用方式、攻擊條件及實際暴露面一起判斷。

五、接著 SBOM 就派上用場了
假設問題不是自己的 Code，而是 Third-party Library X，這時前一天談的 SBOM 就開始真正接到 Vulnerability Response。
PSIRT 先確認有問題的 Component，再透過 SBOM 找出可能受到影響的 Product A、B、C，接著由 R&D 確認實際使用方式，再由 Product Security 進一步分析 Exploitability。
這時我才真正感受到，SBOM 並不是為了「做一份清單」而存在，而是為了建立 Component Traceability。如果沒有這樣的追溯能力，PSIRT 可能只能寄信問：「請問哪個 Team 有使用 Library X？」然後等各單位慢慢回覆。
當 CRA Article 14 開始有明確的時間要求後，這種靠人工問一圈的方式，壓力可能就會變得非常大。

六、Semiconductor 的 Vulnerability Triage 可能更複雜
假設某顆 MCU 被 Security Researcher 發現，在特定條件下可能 Bypass 某個 Security Mechanism，這時不一定能像一般 Software 一樣走 Download Patch → Test → Deploy。
可能需要 R&D、Product Security、FA / Engineering 一起分析：哪些 Silicon Revision 受到影響？哪些 Configuration 才會出現？哪些 Use Case 有風險？是否需要 Physical Access？Firmware 能不能 Mitigate？Customer Integration 的方式是否會影響 Exploitability？
所以對 Semiconductor PSIRT 而言，我自己覺得很重要的一件事，是跟 R&D / Product Team 建立固定的 Technical Escalation Path。否則 Product Security 或 PSIRT 單靠自己，很可能無法在有限時間內完成真正有意義的 Impact Analysis。

七、Third-party Component 出問題，也不能只等 Supplier
CRA Article 13 對 Third-party Component 也有相關要求。Manufacturer 在整合 Third-party Component 時應採取適當的 Due Diligence，避免該 Component 損害 Product Cybersecurity。
如果 Manufacturer 發現整合進 Product 的 Component，包括 Open Source Component，存在 Vulnerability，CRA 也涉及通知該 Component 的 Manufacturer / Maintainer，以及依 Annex I Part II 進行相應 Vulnerability Handling 的要求。
所以「這不是我們寫的 Code」，我自己現在不會把它理解成「那就不是我們的 Product Security 問題」。
對 Customer 而言，這個 Vulnerability 仍然可能存在於我們提供的 Product 裡。至於後續責任如何分配、誰負責修正 Component、Manufacturer 又要做到什麼程度，仍需要回到實際供應鏈關係、產品整合方式與 CRA 要求進一步判斷。

八、PSIRT 跟 R&D 的分工，我會盡量分清楚
如果什麼事情全部丟給 PSIRT，我覺得可能也不太實際。
我自己目前會比較傾向讓 PSIRT / Product Security 負責 Intake、Triage、Coordination、Vulnerability Tracking、Disclosure 及 Regulatory Escalation；R&D 則負責 Root Cause Analysis、Technical Impact、Fix / Mitigation 與 Verification。
Product / Business 可以協助確認 Affected Product、Customer Context 與 Support Status；Legal / Compliance 則協助釐清 Regulatory Requirement，以及提供 Reporting Decision Support。
當然，每家公司組織都不同，這不是 CRA 規定的 RACI，只是我自己目前在思考實際導入時，覺得比較容易運作的一種分工方式。真正重要的不是職稱怎麼分，而是當 Vulnerability 真的進來時，大家知不知道誰負責下一步。

九、然後 Article 14 就進來了
這大概是 2026 年現在最需要注意的一段。
從 2026 年 9 月 11 日開始，CRA Article 14 的特定 Reporting Obligations 開始適用。Manufacturer 對符合條件的 Actively Exploited Vulnerability，以及 Severe Incident having an impact on the security of the Product，需要依規定進行通報。
而且時間很短。
以 Actively Exploited Vulnerability 為例，第一階段的 Early Warning 是 24 小時，後續 Vulnerability Notification 則有 72 小時的時間要求。
所以我現在會覺得，企業內部的 PSIRT Flow 跟 CRA Reporting Flow 最好能夠接起來。否則 Product Security 在處理 Vulnerability，Compliance 在另外研究 CRA，兩邊流程沒有接點，真正發生事件時就很容易卡住。

十、但「有 Vulnerability」不等於「一定 Article 14 通報」
這點我覺得非常重要。
CRA Article 14 並不是要求 Manufacturer 把所有 CVE 都在 24 小時內通報 EU。針對 Vulnerability，法規關注的是 Actively Exploited Vulnerability。
所以收到 Vulnerability 後，除了進行一般的 Vulnerability Triage，還需要再判斷：這件事情是否符合 Article 14 的 Reporting Criteria？
這跟一般 Vulnerability Management 並不是完全同一件事。因此我自己會把 Vulnerability Triage 與 Regulatory Reporting Assessment 分成兩個 Decision。前者是在判斷漏洞本身及產品影響，後者則是在判斷它是否已經觸發法規通報義務。

十一、24 小時不是要你把所有事情都查完
這點我自己一開始也會緊張。尤其 Semiconductor Vulnerability 很複雜，24 小時內可能連 Root Cause 都還沒有完全確認，更不用說完成 Fix。
但 Article 14 本來就是採分階段通報。以 Actively Exploited Vulnerability 為例，先有 24 小時的 Early Warning，再於 72 小時內提交進一步的 Vulnerability Notification；後續再依規定提交 Final Report。
所以我目前的理解是：24 小時的重點不是完成完整的 Forensic、Root Cause Analysis 或 Remediation，而是在有限資訊下先完成法規要求的 Early Warning。
這也代表企業真正需要建立的能力，不只是「24 小時內把漏洞修完」，而是能不能在 24 小時內把已知資訊整理出來、找到正確決策者，並啟動應有的 Reporting Process。

十二、這也是為什麼 PSIRT 平常就要準備 Product Information
如果 Article 14 事件發生後，才開始找 Product Owner 是誰、Product 在哪些 EU Member States、哪些 Version 受到影響、誰能登入 Reporting Platform，那 24 小時可能很快就過去了。
所以我現在會覺得，Article 14 Readiness 很大一部分，其實是在 Incident 發生前完成的。
例如 Product Inventory、EU Market Information、Contact Tree、Reporting Role、Escalation Rule，這些資訊平常就可以先準備。真正出事時，再把時間留給最需要 Technical Analysis 與 Decision Making 的地方，而不是花在找人、找資料或確認誰有帳號。

十三、而且 Reporting 不只適用 2027 年後的新產品
這一點對很多企業可能更需要注意。
依 European Commission 目前對 CRA 過渡期間的相關說明，Article 14 的 Reporting Obligations 並不是單純等到 2027 年 12 月 11 日全面適用後才開始準備。對已經 Made Available on the Union Market 的 Products with Digital Elements，也需要留意 2026 年 9 月 11 日開始適用的 Reporting Obligations。
所以我自己不會把 2026/09/11 理解成只需要看「新 Product」。
既有 Product 也可能需要納入 Reporting Readiness。這也是我會建議 Product Inventory 不要只盤 2027 年後的新開發案，而是要把既有產品的 EU Market 狀態、Support 狀態及可能的 Vulnerability Handling 責任一起納入考量。

十四、PSIRT 還要一路處理到 Remediation
通報不是 Vulnerability Handling 的終點。
CRA Annex I Part II 還涉及 Manufacturer 依 Product Risk 處理及 Remediate Vulnerabilities，包括在適用情況下提供 Security Updates。
所以 PSIRT 不能只負責「收到 → 判斷 → 通知主管機關」，後面還需要跟 R&D、Product、QA、Customer Support 等角色協調 Fix、Mitigation、Verification、Release 與 Customer Communication。
對我來說，這才比較接近完整的 Vulnerability Lifecycle。Reporting 只是其中一段，而不是整個 Vulnerability Handling 的終點。

十五、如果是 Hardware Vulnerability，Remediation 可能不是 Patch
這對 Semiconductor 特別重要。
例如發生 Silicon Security Issue 時，可能根本沒有一個 Software Patch 可以直接解決。這時 Corrective / Mitigating Measure 可能是 Firmware Workaround、Configuration Guidance、Disable Certain Function、Customer Integration Guidance，甚至最後需要 New Silicon Revision。
所以 CRA 講的是 Address / Remediate Vulnerability，我自己不會把它全部直接翻譯成「打 Patch」。
不同 Product 的技術特性差異很大，Software、Firmware、Hardware，甚至 Cloud-connected Product，最後能採取的 Remediation Strategy 都可能不一樣。

十六、我現在會把 PSIRT Flow 想得很簡單
如果要先畫一個最基本的流程，我目前可能會整理成：
Vulnerability Intake → Triage → Affected Product / Version Identification → Technical Impact / Exploitability Analysis → CRA Article 14 Reporting Assessment → Fix / Mitigation → Verification → Disclosure / Customer Communication → Closure / Lessons Learned
這不是 CRA 官方指定流程，而是我目前把 Product Vulnerability Handling 跟 CRA 接起來後，覺得比較容易理解的一種方式。
實際導入時，每一個箭頭後面可能都還會再展開很多事情，但至少先把整條路接起來，會比各單位分別建立自己的流程，更容易看出中間有哪些 Gap。

Day 9 小結｜PSIRT 對我來說，不只是「處理 CVE 的 Team」
研究到這裡，我自己對 PSIRT 最大的理解變化是：它其實是 Product 上市後，很多 Product Security Capability 的交會點。
前面 Day 6 談 Risk Assessment、Day 7 談 Secure Development、Day 8 談 SBOM，到了 Day 9，這些東西開始在 Vulnerability 真正發生時接在一起。
SBOM 幫忙找出可能受影響的 Product，R&D 分析 Technical Impact，PSIRT 協調 Vulnerability Response，Compliance 協助判斷 Reporting Requirement，Product / Sales 則提供 Market 與 Customer Information。
所以 CRA Vulnerability Handling 對我而言，越來越不像是單一 Security Team 可以獨立完成的工作，而比較像是一套橫跨 Product Lifecycle 的協作機制。
而 2026 年 9 月 11 日，Article 14 Reporting Obligations 就開始適用。這也是為什麼我目前會把 PSIRT / Reporting Readiness 放在 CRA Program 很前面的位置：不是因為成立一個 PSIRT 就等於 CRA Compliance，而是因為當真正的 Product Vulnerability 發生時，很多原本分散在 R&D、Product、Security、Compliance、Sales 的能力，都必須在很短的時間內接起來。
以上仍然只是**我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。**實際 Reporting Criteria、流程與責任，還是應依 CRA Article 14、European Commission 最新 Guidance，以及企業實際產品與組織情境進一步確認。

Day 10 預告｜24 小時、72 小時到底怎麼跑？CRA Article 14 通報，我會怎麼準備？
Day 9 我們把 PSIRT Flow 接到了 Article 14，下一篇就把 Article 14 再拉近一點。
如果星期五下午 5 點收到 Vulnerability，24 小時從什麼時候算？誰決定它是不是 Actively Exploited？72 小時要提供到什麼程度？Single Reporting Platform 又是什麼？對歐洲以外的 Manufacturer，到底要向哪一個 CSIRT 通報？
另外，很多非 EU Manufacturer 可能也會特別關心：如果 Manufacturer 不在 EU，Authorised Representative（AR）在 Article 14 Reporting 裡到底扮演什麼角色？
Day 10，我們就專門來聊：CRA Article 14 Reporting。