CRA報告：先分清漏洞與嚴重事件
一條客戶報告了某款聯網裝置異常，安全團隊還沒有確認攻擊範圍。待相關修復完成後再處理，還是立即走歐盟《網路韌性法案》（CRA）的報告程序？答案取決於產品是否在適用範圍、製造商是否已知悉“被主動利用的漏洞”或影響產品安全的嚴重事件。兩種情形都可能啟動24小時預警與72小時通知，但最終報告的期限不同。先判斷觸發條件，再保留產品版本與時間證據。
截至2026年10月4日，依據 Regulation (EU) 2024/2847 第14、16、71條及歐盟委員會CRA報告說明核對。第14條製造商報告義務自2026年9月11日起適用；CRA其他一般義務的適用時間另行區分。
誰來報告，報告什麼
第14條的強制報告主體是製造商，針對已在歐盟市場提供的帶數字元素產品。是否屬於這類產品，要按法規關於軟體、硬體及其遠端資料處理方案的定義和預期或可合理預見連線關係判斷；“有數字元件”並不自動足夠。開放原始碼軟體管理者另有第24條第3款及較晚的適用時間，也不能直接套用製造商口徑。
製造商以自己的名稱或商標將產品投放市場，通常不能把對外報告義務全部轉交給代工廠。進口商、分銷商也有各自的CRA義務，但不應在本文中被一概寫成第14條報告主體。合同可約定上游發現線索後如何通知品牌方，卻不能代替品牌方判斷本產品、版本和事件是否觸發報告。
先判兩條觸發路徑
第一條是製造商知悉產品中“被主動利用的漏洞”。僅有理論漏洞、尚無主動利用證據，不能直接等同於這一強制報告觸發點；但應繼續調查並履行適用的漏洞處理義務。第二條是製造商知悉“影響產品安全的嚴重事件”。嚴重程度需要對照第14條第5款的定義判斷，不能把任何客服投訴或普通故障都叫作嚴重安全事件。
初始工單時間值得儲存，但並非每一條模糊線索都自動成為法定知悉時點。記錄收到什麼、何時核驗、何時形成被主動利用或嚴重事件的判斷及其理由，才能解釋24小時和72小時從哪一刻計算。不要因證據尚不完整而把可能觸發的事項一直留在普通工單裡。
同樣的前兩段時限，不同的最終報告
第14條要求在知悉後無不當遲延、最遲24小時提交早期預警；隨後無不當遲延、最遲72小時提交漏洞或事件通知。72小時是從知悉起算，並非在24小時預警之後重新起算。初報與後報的資訊範圍不同，後者需補充已有的產品、性質、影響及措施資訊；不能把“尚未查清全部細節”當作無限延遲初報的理由。
最終報告要分開排期：被主動利用漏洞，在糾正或緩解措施可用後最遲14天；嚴重事件，在72小時事件通知提交後一個月內。兩種時鐘不能合併成一個“後續再報”的模糊節點。若已有資訊此前已經提供，法規也允許避免重複提供相應內容。
把報告接回具體產品版本
設想安全公告只寫“某元件存在漏洞”，卻沒有說明哪一韌體版本、哪批在歐盟提供的產品受到影響。即使平台提交成功，客服、補丁發布與客戶通知仍可能指向不同範圍。製造商應將產品型號、軟體或韌體版本、市場範圍、首個可信線索、判斷依據、每次平台提交回執以及糾正措施版本關聯起來；這是便於複核的實務記錄方式，並非第14條另設的一張固定表。
CRA單一報告平台（SRP）是提交渠道。報告指向製造商主要營業地對應的協調CSIRT，並依規則向ENISA提供；不應寫成向所有成員國主管機關逐一手工提交。提交記錄也不能代替必要的安全修復、使用者溝通或其他適用法律下的義務。
現在可以做的一次核對
選一款在歐盟銷售的聯網產品，沿“品牌主體—受影響版本—首次可信線索—觸發判斷—24小時預警—72小時通知—分支最終報告—修復版本”走一遍。若任一環節無法指向責任人或原始證據，先補齊內部升級路徑，並按歐盟委員會與ENISA的現行SRP指引核對實際提交欄位。本文是法規條文與官方說明的適用解讀，不替代具體事件的法律和技術判斷。
綠色方舟（深圳）認證有限公司｜郵箱：sui@greenark-sz.com｜官網：www.greenark-sz.com｜電話：18407559004
