prEN 40000-1-3

prEN 40000-1-3 是 vulnerability handling 的横向草案标准。它为 Annex I Part II 提供支撑，将漏洞接收、验证、修复、发布及发布后工作转化为结构化的 manufacturer 流程。

草案状态

本地来源是提交给 CEN enquiry 的 draft European Standard。它有助于规划漏洞处理能力，但除非状态已经被核实，否则不应被称为最终 EN 或已被引用的 harmonised standard。

M/606 条目 15 要求为 products with digital elements 制定漏洞处理欧洲标准。该 M/606 条目的期限是 30 August 2026。

Annex I Part II 角色

Annex I Part II 关注 manufacturer 的流程。它覆盖发现和记录漏洞、组件可见性、修复、测试、披露、更新分发，以及安全更新可用后的用户信息。

prEN 40000-1-3 围绕该流程设计。它不判断是否触发 Article 14 报告。Article 14 报告是针对 actively exploited vulnerabilities 和 severe incidents affecting product security 的独立法律义务。

漏洞处理流程

草案使用生命周期模型。流程在报告到达之前就开始，因为 manufacturer 需要先准备政策、联系渠道、组件信息和更新机制。

准备

Before reports

准备政策、披露渠道、安全沟通、产品识别、组件信息、测试计划和更新分发。

接收

Report intake

Manufacturer 接收报告，并监控内部和外部来源，以发现影响产品或组件的漏洞。

验证

Triage

Manufacturer 检查报告是否有效、产品是否受影响，以及漏洞严重程度。

修复或缓解

Fix or mitigation

Manufacturer 决定修复方式，开发修复或缓解措施，并在发布前测试。

发布和发布后

User action

Manufacturer 发布安全更新，发布清晰信息，监控有效性，并改进流程。

构成模块

草案建立在已有漏洞标准之上。它使用 vulnerability disclosure、vulnerability handling 和 multi-party coordinated disclosure 概念，并将这些概念调整到 products with digital elements 和 CRA 支持期限模型中。

Disclosure policy

公开渠道告诉研究人员和用户如何报告潜在漏洞。

Component visibility

软件和硬件组件信息支持在发现漏洞时进行影响分析。

Update release

安全更新分发和清晰的 advisory 信息把修复与用户行动连接起来。

来自风险的额外控制

草案包含 requirement enhancements。它们是在产品风险评估显示需要更高严谨度时适用的额外措施。

安全沟通

SBOM 完整性

组件哈希

机器可读 advisories

与报告义务的边界

漏洞处理是持续性的产品流程。Article 14 报告是在满足法律触发条件时产生的独立通知义务。一个漏洞可能需要在流程中处理，但不属于 Article 14 报告范围；一个可报告漏洞也仍然需要处理流程来修复和沟通。

用 prEN 40000-1-3 的思路处理漏洞处理流程。
用 Article 14 分析 actively exploited vulnerabilities 和 severe incidents affecting product security。
用支持期限页面判断漏洞处理必须持续多久。

Article 14 触发条件见 Vulnerability Reporting。