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

做 CRA 做到這裡，開始發現：「有做」跟「能證明有做」可能是兩回事
前面幾天我們談了很多，包括資安風險評估（Risk Assessment）、安全開發（Secure Development）、軟體物料清單（SBOM）、漏洞處理（Vulnerability Handling）、支援期間（Support Period），以及供應鏈資安（Supplier Security）。
做到這裡，很自然會產生一個問題：如果公司這些事情真的都有做，是不是就代表 CRA 的準備已經差不多了？
我自己慢慢覺得，可能還差一件很重要的事情：證據（Evidence）。
因為未來如果進入符合性評估（Conformity Assessment），可能不能只是告訴評估人員：「我們研發單位都有做資安審查（Security Review）。」而是要能進一步回答：做了什麼？為什麼這樣做？哪些要求（Requirement）適用？怎麼驗證？最後，相關證據在哪裡？
也就是在這個時候，我開始真正理解 技術文件（Technical Documentation） 為什麼會這麼重要。

一、技術文件不是單純一本「CRA 報告」
我一開始看到 Technical Documentation，其實很自然地把它想像成：CRA 專案做到最後，大家把資料整理起來，產出一份很厚的 Word 或 PDF。
但後來我覺得，可能不需要把它理解得這麼狹隘。
CRA Article 31（第 31 條）要求製造商（Manufacturer）在產品上市前準備技術文件，並完成適用的符合性評估程序（Conformity Assessment Procedure）。技術文件應該能夠用來證明產品符合 CRA Annex I（附件一）的基本資安要求（Essential Cybersecurity Requirements）。
所以我現在比較喜歡把 Technical Documentation 理解成：
一套能夠說明並證明產品符合 CRA 要求的技術證據集合。
至於實務上到底要做成一份主文件（Master Document），還是一份主文件搭配許多參照文件（Reference Documents），我自己覺得可以依企業既有的文件架構來設計，不一定需要把所有東西重新複製成一份巨大的 CRA 文件。

二、Annex VII 其實把前面談過的事情全部串起來了
CRA Annex VII（附件七）是理解 Technical Documentation 很重要的依據，其中涵蓋產品一般說明（General Description）、設計／開發／生產資訊、漏洞處理流程（Vulnerability Handling Processes）、資安風險評估（Cybersecurity Risk Assessment）、適用的基本資安要求、標準／技術規格（Standards / Technical Specifications）、驗證與確認證據（Verification / Validation Evidence）、EU 符合性聲明（EU Declaration of Conformity），以及 SBOM 等相關資訊。
看到這裡，我自己的第一個感覺其實是：
Technical Documentation 並不是 CRA 裡另外多出來的一項工作，而是把前面十幾天談過的事情全部串起來。
風險評估做過了，證據要留下來；SBOM 建好了，要知道對應哪一個產品版本；資安測試做完了，要能找到測試報告；Annex I 的要求做過適用性判斷，也要留下「適用（Applicable）」或「不適用（N/A）」的理由。
換句話說，前面的工作如果是一塊一塊的拼圖，Technical Documentation 比較像是最後把這些拼圖組成一張完整的圖。

三、第一個問題其實很基本：產品到底是什麼？
Annex VII 首先要求產品的一般說明，可能包括產品名稱／類型（Product Name / Type）、預期用途（Intended Purpose）、版本（Version）、硬體／軟體版本、使用者資訊，以及產品如何運作等基本資訊。
這些內容乍看之下很簡單，但我自己覺得，它其實是後面所有資安分析的起點。
因為如果連**產品邊界（Product Boundary）**都沒有定義清楚，後面的風險評估、SBOM、漏洞處理，甚至資安測試，都可能不知道範圍（Scope）到底應該畫在哪裡。
這個問題放到半導體公司，可能會更加明顯。
例如公司賣的是一顆 MCU（微控制器），但除了晶片本身，同時可能提供 ROM 程式碼、韌體（Firmware）、軟體開發套件（SDK）、驅動程式（Driver）、參考程式碼（Reference Code），甚至開發工具（Development Tool）。那麼 CRA 所認定的產品邊界到底包括哪些？
這件事情我自己不會等到最後準備 Technical Documentation 時才處理，因為 Product Boundary 會直接影響風險評估範圍、SBOM 範圍、資安測試範圍、支援期間，甚至符合性評估範圍。
所以，產品定義（Product Definition）看起來像是文件問題，實際上很可能是一個前期就必須處理的治理決策（Governance Decision）。

四、架構與設計資訊到底要多細？
Annex VII 也要求設計／開發相關資訊，例如系統架構（System Architecture）、元件（Components）、介面（Interfaces）、資料流（Data Flow），以及與資安相關的設計（Security-relevant Design）等。
看到這裡，半導體公司可能很自然會開始擔心：是不是 RTL、電路設計（Circuit Design）、關鍵架構（Key Architecture）、專有智慧財產（Proprietary IP），全部都要放進同一份 CRA Technical Documentation？
我自己目前不會這樣理解。
我比較在意的是 證據充分性（Evidence Sufficiency），也就是現有文件是否已經足以讓符合性評估人員理解：產品是怎麼設計的、資安風險如何被處理，以及相關要求又是怎麼實現的。
這跟把所有設計細節（Design Detail）毫無區別地複製到一個 CRA 資料夾，其實是兩件不同的事情。
例如主要技術文件可以描述資安架構（Security Architecture），但更敏感的詳細設計（Detailed Design）、RTL 證據或資安測試紀錄（Security Test Record），則透過**受控參照（Controlled Reference）**指向既有的工程資料庫（Engineering Repository）。
對半導體公司來說，我自己目前比較喜歡這樣的文件架構，因為既能建立證據鏈，也比較不需要為了 CRA 再複製大量敏感的工程資訊。

五、風險評估不是做完就收起來
Day 6 談過資安風險評估，到了 Technical Documentation，它又重新出現了。
CRA Article 13（第 13 條）要求製造商進行資安風險評估，並依適當情況持續更新，而相關 Risk Assessment 也需要納入 Technical Documentation。
所以風險評估並不是專案團隊分析完、開完會、存檔之後就結束了，它其實也是後續**符合性證據（Conformity Evidence）**的重要一部分。
而且我現在越來越在意一件事情，就是 Risk Assessment 最好能一路接到 Annex I Requirement。
例如今天識別出一個風險：
未授權韌體遭修改（Unauthorized Firmware Modification）
接下來可能對應 Annex I 中與完整性（Integrity）或安全更新（Security Update）相關的要求，再往下形成資安需求（Security Requirement），例如「韌體真實性驗證（Firmware Authenticity Verification）」；設計上採用數位簽章驗證（Signature Verification），測試時確認遭修改的韌體是否會被拒絕，最後留下資安測試報告（Security Test Report）作為證據。
這樣評估人員才比較容易理解：為什麼產品需要這個 Security Control？這個控制措施又是怎麼被實作及驗證的？
所以我現在越來越喜歡一個概念：可追溯性（Traceability）。

六、嘗試建立一張 CRA 可追溯性矩陣
如果讓我自己設計，我可能會建立一張 CRA 可追溯性矩陣（CRA Traceability Matrix），把幾個重要元素串起來：
CRA 要求（Requirement）→ 適用性（Applicability）→ 風險（Risk）→ 實作（Implementation）→ 驗證（Verification）→ 證據（Evidence）
例如 Annex I Requirement A 判定為「適用（Applicable）」，對應風險 R-001，再對應設計 D-01、測試 T-01，最後指向報告 E-01。
如果 Requirement B 判定為「不適用（N/A）」，也不是只填一個 N/A，而是留下不適用理由（N/A Rationale）。
這並不是 CRA 官方規定的固定範本（Template），只是我自己覺得這種方式很好用，因為一張表就可以把：
要求 → 風險 → 設計 → 驗證 → 證據
之間的關係看清楚。
而且我覺得 N/A 的理由其實也很重要。不是每一個 Annex I Requirement 都一定適用每一種產品，例如某個產品架構根本沒有使用者身分驗證功能（User Authentication），那麼某些要求經過分析後可能確實不適用。
但如果 Technical Documentation 裡面只寫「N/A」，評估人員很難知道到底是經過分析後判定不適用，還是單純漏掉了。
所以我自己會比較希望看到的是 N/A + 理由（Rationale）。例如說明產品架構不包含該功能，因此相對應的威脅情境（Threat Scenario）不存在。
這樣留下來的才比較像是 Evidence，而不是單純填表。

七、標準與技術規格也是證據鏈的一部分
Technical Documentation 也需要說明製造商採用了哪些協調標準（Harmonised Standards）、歐洲標準（European Standards）、技術規格（Technical Specifications），或其他技術方法（Technical Means），來證明產品符合 Annex I 的要求。
未來 CRA Harmonised Standards 應該會變得越來越重要，因為當相關協調標準被歐盟官方公報（Official Journal）引用後，在其涵蓋的範圍內，可能產生**符合性推定（Presumption of Conformity）**的效果。
所以我現在會希望 Technical Documentation 裡面保留一份適用標準清單（Applicable Standards List），清楚知道每個產品或產品系列採用了哪些標準、哪些版本，以及它們分別支援哪些 CRA Requirements。
這樣 Standards 就不只是「我們有參考某個 EN Standard」，而是證據鏈裡面可以被追蹤的一環。

八、有資安功能，還要證明它真的有效
寫一句「我們有安全開機（Secure Boot）」是一件事，但證明 Secure Boot 真的能阻止未授權韌體，又是另外一件事。
所以驗證與確認證據（Verification / Validation Evidence），我自己覺得會是 Technical Documentation 裡非常重要的一塊。
依產品風險與設計不同，可能會包含資安功能測試（Security Functional Test）、負向測試（Negative Test）、弱點掃描（Vulnerability Scan）、靜態程式碼分析（SAST）、軟體組成分析（SCA）、滲透測試（Penetration Test）、模糊測試（Fuzzing），甚至硬體安全驗證（Hardware Security Verification）等。
但這並不代表每一種產品都必須把所有 Security Test 全部做一遍。
我自己仍然會希望測試方法（Test Method）回到 Product Risk：產品有哪些重要的威脅情境？用了哪些資安控制措施？我們需要什麼驗證，才能合理證明這些控制措施達成預期效果？
這樣 Testing 才不會變成單純「為了 CRA 多跑幾個工具」，而是真正成為符合性證據的一部分。

九、證據很多，不代表全部都要塞進主文件
這也是我覺得企業實務上很重要的一點。
一份滲透測試報告可能有幾百頁，SAST 結果可能有幾千筆，SBOM 更可能有幾萬筆資料。如果全部貼進 Technical Documentation 主文件，不但文件會變得非常巨大，而且可能根本沒有人看得完，後續版本控制（Version Control）也會很麻煩。
所以我目前比較傾向採用：
主文件＋證據參照（Master Document + Evidence Reference）
例如 CRA-TD-001 Technical Documentation 裡面註明：
資安驗證證據（Security Verification Evidence）→ SEC-TEST-2027-003
詳細證據（Detailed Evidence）則繼續保留在受控資料庫（Controlled Repository）。
這樣 Technical Documentation 負責告訴評估人員「證據在哪裡、對應什麼 Requirement、哪一個產品版本」，而不是把所有 Evidence 全部複製進主文件。
對我來說，這種方式也比較符合大型企業原本就已經存在產品生命週期管理系統（PLM）、應用生命週期管理系統（ALM）、原始碼儲存庫（Source Code Repository）、測試管理系統（Test Management System）或文件管理系統（Document Management System）的實際情況。

十、SBOM 也是 Technical Documentation 的一部分
CRA Annex VII 也明確把 **軟體物料清單（SBOM, Software Bill of Materials）**放進 Technical Documentation 的要求裡。
但我自己不會因此把完整 SBOM 直接貼進 Word。
比較可能的方式，是在 Technical Documentation 中記錄 SBOM 識別碼（Identifier）、產品版本、SBOM 版本、儲存位置（Repository Location）、產生方式（Generation Method）等資訊，再參照到實際的 SBOM。
因為 SBOM 本身會隨著產品版本、韌體版本或元件異動持續更新，如果每一次更新都要重新複製進一份巨大文件，長期下來反而可能增加版本控制的困難。
所以對我來說，重點還是那條 Evidence Chain：
這一版產品，到底對應哪一版 SBOM？

十一、Technical Documentation 不是產品發布後就不用管
這一點我自己覺得也很重要。
產品可能會有韌體更新（Firmware Update），元件可能更換，風險可能改變，SBOM 可能更新，資安測試也可能需要重新執行。既然產品本身會變，Technical Documentation 自然也可能需要跟著更新。
所以我現在比較不把 Technical Documentation 當成符合性評估前最後兩週，大家開始到處找資料、整理資料，最後趕出來的一份文件。
我反而比較喜歡把它理解成：
在產品生命週期（Product Lifecycle）中逐步累積的證據。
如果前面的安全開發生命週期（Secure Development Lifecycle）已經能夠在適當的管制關卡（Gate）產生需要的 Evidence，那麼到了 Conformity Assessment 時，Technical Documentation 比較像是在整理及串接已經存在的證據，而不是從零開始追資料。

十二、Evidence 還有一個很現實的問題：要保存多久？
CRA Article 13 對 Technical Documentation 與 EU Declaration of Conformity 的保存也有要求。製造商在產品上市後，需要至少保存 10 年或支援期間（Support Period），兩者取較長者。
這件事情對文件管理的影響其實不小，尤其半導體產品的生命週期本來就可能很長。
如果產品上市多年之後才發生漏洞，市場監督機關（Market Surveillance Authority）要求提供資料，或需要重新確認當年的符合性依據（Conformity Basis），這時 Evidence 如果只存在某位工程師電腦裡的一個資料夾，問題就會很大。
所以 Technical Documentation 做到最後，其實也會碰到文件保存（Document Retention）、版本控制（Version Control）、存取控制（Access Control）、資料庫治理（Repository Governance），以及人員離職後 Evidence 如何持續保存等問題。

十三、那 Technical Documentation 到底誰負責？
這也是我做到這裡開始思考的一個問題。
研發單位（R&D）手上有系統架構與技術證據，Product Security 有 Risk Assessment、Threat Model 與 Vulnerability Handling 資訊，QA / Verification 有測試結果，Product Team 有產品資訊，Compliance 則可能負責 CRA Mapping、Standards 與 Conformity Documentation。
如果把所有事情都交給一個人，要求他「負責寫完 Technical Documentation」，我覺得可能會非常辛苦，而且那個人也不太可能真正掌握所有 Engineering Evidence。
所以我自己反而比較喜歡：
分散式證據責任＋集中式文件協調（Distributed Evidence Ownership + Central Documentation Coordination）。
也就是各項 Evidence 分別有自己的 Owner，但有一個角色負責確認整體 Technical Documentation 是否完整、證據是否找得到，以及各項 Requirement 之間能不能追溯。
如果放到半導體公司，我可能會大致拆成：產品／PM 負責產品說明、預期用途、版本與支援期間；R&D 負責架構、資安設計與技術規格；Product Security 負責風險評估、威脅模型與漏洞處理；QA / Verification 負責資安測試與驗證證據；Supply Chain / Procurement 負責第三方元件證據；Compliance 則負責 Annex I Mapping、適用標準與符合性文件。
這當然不是 CRA 指定的組織架構，只是我目前覺得比較符合企業實際運作的方式。

Day 14 小結｜CRA Technical Documentation 對我來說，是一條「證據鏈」
研究到這裡，我自己已經不太把 Technical Documentation 看成 一份為了 CE 標示（CE Marking）最後才寫的文件。
我反而比較喜歡把它想成一條 證據鏈（Evidence Chain）：
產品定義（Product Definition）
→ 風險評估（Risk Assessment）
→ Annex I 要求（Requirement）
→ 資安需求（Security Requirement）
→ 設計（Design）
→ 實作（Implementation）
→ 驗證（Verification）
→ 證據（Evidence）
最後，再由 Technical Documentation 把這些東西串起來。
對半導體公司來說，我覺得這個概念尤其重要。因為設計資訊可能非常敏感，而 Evidence 又可能分散在不同的工程系統，所以實務上不一定要把所有 IP 複製到一份超大的 CRA 文件裡。
比較重要的，可能是建立清楚的可追溯性（Traceability）、版本控制（Version Control）、存取控制（Access Control）與證據參照（Evidence Reference），讓未來需要證明產品符合 CRA 時，可以清楚回答：為什麼這樣設計？對應哪一項 CRA Requirement？做過什麼 Verification？Evidence 又在哪裡？
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
Technical Documentation 到底要多細、Evidence 到什麼程度才算充分，還是需要依產品、符合性評估方式（Conformity Assessment Route）、適用標準，以及後續主管機關與產業實務持續調整。

Day 15 預告｜文件準備好了，就可以貼 CE 嗎？CRA 的符合性評估到底怎麼選？
做到這裡，產品有風險評估，Annex I 有要求對照（Mapping），測試證據有了，Technical Documentation 也開始完整。
接下來真正會遇到的問題就是：
誰來判斷產品符合 CRA？
是不是所有 CRA 產品都要送第三方驗證？什麼是內部控制（Internal Control）？什麼情況需要公告機構（Notified Body）？一般產品（Default Category）跟重要產品（Important Product）、關鍵產品（Critical Product）又有什麼差別？協調標準（Harmonised Standard）怎麼影響符合性評估？最後，EU 符合性聲明（EU Declaration of Conformity）跟 CE 標示（CE Marking）又是怎麼接起來的？
Day 15，我們就來聊 CRA 符合性評估（Conformity Assessment），以及「是不是每個產品都要找 NB？」這個很常見的問題。