CRA：prEN 40000-1-3 漏洞處理草案
Sytance · 更新於
prEN 40000-1-3 是關於漏洞處理的橫向標準草案。它對應附件 I 第二部分，説明製造商如何安排漏洞接收、驗證、修復、安全更新發布及發佈後的跟蹤工作。
草案狀態
本文依據的文本是提交 CEN 徵求意見的歐洲標準草案，可供規劃漏洞處理工作。該草案本身不產生 CRA 下的符合性推定。
M/606 條目 15 要求為含數字要素的產品制定漏洞處理歐洲標準。該 M/606 條目的期限是 2026 年 8 月 30 日。
與附件 I 第二部分的關係
附件 I 第二部分規定製造商的漏洞處理流程，包括髮現和記錄漏洞、掌握組件信息、修復、測試、披露、分發更新，以及在安全更新發布後向用戶提供相關信息。
prEN 40000-1-3 圍繞該流程設計。它不判斷是否觸發第 14 條報告。第 14 條報告是針對正在被積極利用的漏洞和影響產品安全的嚴重事件的獨立法律義務。
漏洞處理流程
草案使用生命週期模型。流程在報告到達之前就開始，因為製造商需要先準備政策、聯繫渠道、組件信息和更新機制。
制定政策和測試計劃，建立漏洞披露及安全溝通渠道，準備產品與組件信息，並安排更新分發。
製造商接收報告，並監控內部和外部來源，以發現影響產品或組件的漏洞。
製造商檢查報告是否有效、產品是否受影響，以及漏洞嚴重程度。
製造商決定修復方式，開發修復或緩解措施，並在發佈前測試。
製造商發佈安全更新及使用説明，跟蹤更新是否有效，並據此改進處理流程。
構成模塊
草案沿用現有標準中的漏洞披露、漏洞處理和多方協調機制，並結合含數字要素產品及 CRA 支持期的要求加以規定。
漏洞披露政策
公開渠道告訴研究人員和用戶如何報告潛在漏洞。
組件信息
軟件和硬件組件信息支持在發現漏洞時進行影響分析。
更新發布
安全地分發更新，並在安全公告中説明操作方法，幫助用戶完成修復。
按產品風險採用增強措施
草案包含增強要求。風險評估表明常規措施不足時，需要採用這些額外措施。
較高風險產品可能需要更強控制，用於與報告人、協調者、上游供應商或受影響用戶交換漏洞信息。
如果產品風險要求更快或更準確地分析漏洞影響，可進一步細化組件記錄。
當名稱和版本字符串不足以識別組件時，哈希可以幫助確認實際存在的軟件組件版本。
結構化安全公告可以幫助客户和下游運營者批量處理漏洞信息。
與報告義務的區別
漏洞處理是持續性的產品流程。第 14 條報告是在滿足法律觸發條件時產生的獨立通知義務。一個漏洞可能需要在流程中處理，但不屬於第 14 條報告範圍；需要報告的漏洞，仍須按流程完成修復並向相關方説明情況。
- prEN 40000-1-3 説明如何組織漏洞處理流程。
- 第 14 條規定正在被積極利用的漏洞和嚴重產品安全事件的報告條件。
- 支持期決定漏洞處理工作需要持續多久。
第 14 條觸發條件見 漏洞報告。