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 条触发条件见 漏洞报告。