3.4 风险评估
3.4.1 方法论
漏洞和产品的风险评估 (Risk Assessment) 基于既定标准：
- CVSS v3.1/v4.0 —— 通用漏洞评分系统 (Common Vulnerability Scoring System)，用于单个 CVE 的评分
- SSVC —— 利益相关者特定漏洞分类 (Stakeholder-Specific Vulnerability Categorization)，用于优先级排序
- CRA Annex I —— 要求目录作为评估框架
法律依据
Art. 13(3) CRA: "制造商应对含有数字元素的产品进行网络安全风险评估，并在产品的规划、设计、开发、生产、交付和维护过程中考虑该评估结果。"
3.4.2 CVE 风险评估（单个漏洞）
基于 CVSS 的初始评估
| CVSS 评分 | 严重程度 | CRA 优先级 |
|---|---|---|
| 9.0 -- 10.0 | Critical（严重） | P0/P1 |
| 7.0 -- 8.9 | High（高危） | P2 |
| 4.0 -- 6.9 | Medium（中等） | P3 |
| 0.1 -- 3.9 | Low（低危） | P4 |
上下文评估
CVSS 评分需通过上下文分析进行补充：
| 因素 | 评估内容 | 权重 |
|---|---|---|
| 可利用性 | 正在被积极利用 / PoC 可用 / 理论上可能 | 高 |
| 可达性 | 网络 / 本地 / 物理 | 高 |
| 数据暴露 | 个人数据 / 业务数据 / 无 | 中 |
| 影响范围 | 受影响的产品/客户数量 | 中 |
| 可缓解性 | 修复可用 / 临时方案 / 无 | 中 |
决策矩阵
可利用性
积极利用 PoC 理论上
严重程度 +----------------------------------+
Critical | P0 P1 P1 |
High | P1 P2 P2 |
Medium | P2 P3 P3 |
Low | P3 P4 P4 |
+----------------------------------+3.4.3 产品风险评估 (CRA Art. 13(3))
对每个 CRA 相关产品进行网络安全风险评估。使用风险评估模板。
评估类别
1. 威胁分析
- 潜在的攻击者是谁？（脚本小子、有组织犯罪、国家行为者）
- 存在哪些攻击向量？（网络、物理、供应链）
- 哪些资产面临风险？（数据、功能、可用性）
2. 影响分析
- 机密性 (Confidentiality)：哪些数据可能被泄露？
- 完整性 (Integrity)：哪些数据/功能可能被篡改？
- 可用性 (Availability)：可接受的停机时间是多少？
- 安全性 (Safety)：是否可能造成物理损害？（与固件/IoT 相关）
3. 可能性评估
- 攻击复杂度
- 所需权限
- 是否需要用户交互
- 攻击向量暴露程度
风险矩阵
可能性
高 中等 低
影响 +----------------------------------+
严重 | CRITICAL HIGH MEDIUM |
重大 | HIGH HIGH MEDIUM |
中等 | HIGH MEDIUM LOW |
轻微 | MEDIUM LOW LOW |
+----------------------------------+3.4.4 CRA 下的剩余风险不取决于风险偏好
在组织风险管理中，风险以组织自身目标或风险偏好所导出的接受准则来衡量。CRA 并非如此运作。
基准是产品，而非组织
在 CRA 下，剩余网络安全风险的衡量标准是：投放市场的产品是否基于风险确保了适当的网络安全水平——同时考虑其预期用途与合理可预见用途。
制造商的内部风险容忍度、商业战略或单纯的成本考量，与风险是否已被处理无关。
剩余风险是风险评估与风险处理的固有结果——网络安全风险在实践中无法被完全消除。但剩余风险的存在并不意味着可以由制造商自行裁量接受任何风险。只有当采取适当措施后的剩余风险已通过落实附件 I 第一部分的基本要求而得到充分处理时，产品方可投放市场；判断须结合：
- 预期用途，
- 合理可预见用途与使用条件，在相关情形下包括运行环境（例如预期用户）与需保护的资产，以及
- 产品预计被使用的时长。
处理已识别风险的方式 (Art. 13(3))
| 措施 | 示例 |
|---|---|
| 缩减攻击面 | 移除未使用的服务与接口 |
| 落实技术保护措施 | 认证、加密、完整性保护 |
| 限制或调整功能 | 默认禁用某项高风险能力 |
| 更精确地界定预期用途 | 将产品限定于可信环境 |
| 引导合理可预见的使用方式 | 风险沟通、用户指引、引导安全使用模式的界面设计 |
风险不得转移给用户
CRA 不允许将网络安全风险或责任转移给用户或第三方，以弥补产品设计上的缺陷或为不处理风险开脱。将安全产品投放市场并证明其合规的义务，始终由制造商承担。
面向用户的信息与说明可以支持安全部署与运行——包括在制造商已将预期用途限定于可信环境的情形下——并可告知剩余风险。但它们不能替代风险处理。
示例（正当地限定预期用途）： 某制造商开发的工业传感器出于功能原因无法防护针对传感器本身的物理攻击。为缓解风险评估中识别的该风险，制造商将传感器的预期用途限定于可防止未授权物理接触的可信环境，并在面向用户的信息与说明中清晰载明这些限制。
示例（正当地依赖平台安全能力）： 某处理本地存储敏感数据的专业应用的制造商，识别出明文数据被未授权访问的风险。它没有自建加密机制，而是依赖操作系统原生提供的加密与密钥管理功能——其加密服务成熟且获得持续维护。
若风险评估识别出通过适当措施无法充分处理的风险，遵守 CRA 可能要求变更产品的设计、功能或预期用途。当不处理会导致产品无法满足基本要求时，仅以成本或商业可行性为由，不构成不予处理的充分理由。
与附件 I 第一部分第 1 项的关系
附件 I 第一部分第 1 项要求，产品的设计、开发与生产应确保基于风险的适当网络安全水平。这是一项兜底条款，与 Art. 13(2) 项下进行风险评估的法定义务相区别。
| 情形 | 对第 1 项的影响 |
|---|---|
| 所有相关风险均已通过落实第一部分其他适用的基本要求而得到处理 | 第 1 项视为已满足。多数情况下，满足其他要求即可满足第 1 项。 |
| 风险评估识别出这些措施未完全处理的额外风险 | 制造商必须在产品上落实进一步的适当措施，以满足第 1 项。 |
3.4.5 源自产品之外的风险
风险评估涵盖可能影响产品的相关风险，包括源自产品之外的风险——外部网络、环境因素、外部基础设施、其他系统或产品所依赖的服务。
CRA 要求什么、不要求什么
CRA 不要求制造商控制或治理外部环境。它要求识别此类风险，并通过产品自身的设计与开发加以缓解——落实相应的基本要求，并在必要时向用户提供关于集成或部署风险的信息与说明。
| 外部风险 | 产品层面的缓解 |
|---|---|
| 未授权人员访问产品之外的后端系统，并向产品下发恶意指令 | 对远程指令进行加密认证；校验配置变更的完整性；在异常行为时生成安全相关日志或告警 |
| 某外部服务不可用（断电、基础设施故障） | 确保该中断不会使产品进入不安全状态 |
CRA 规制的是产品如何响应这些外部风险。它不对后端基础设施如何组织、配备人员或运营提出要求，也不将其视为产品的一部分 → 1.15 远程数据处理。
因此，对任何含远程要素的产品，必须覆盖三类风险：
- 属于产品一部分的远程数据处理解决方案的风险；
- 依赖第三方远程方案的风险——按第三方组件处理；
- 产品环境的风险（例如底层硬件）。
3.4.6 跨产品族的复用
制造商常将相似产品投放市场——同一产品族的不同变体、型号或配置。CRA 并不要求将每个变体视为完全独立的产品来进行风险评估与合规评估。
何时允许复用
若这些产品共享相同的架构、安全相关设计与预期用途，且面临相同的网络安全风险，制造商可以依托：
- 一份依 Art. 13(2) 作出的单一网络安全风险评估；
- 一套单一的技术文档；以及
- 一次单一的合规评估程序。
据此也可为该组产品出具单一的 EU 符合性声明——前提是其中明确标明所适用的产品变体。
决定性因素：差异是否与网络安全相关？
| 差异 | 是否需要单独评估？ |
|---|---|
| 颜色、外形、内存容量及其他与安全无关的特征 | 否 |
| 不同的通信接口 | 是 —— 须在风险评估中体现，必要时也在合规评估与技术文档中体现 |
| 不同的软件栈 | 是 |
| 不同的更新机制 | 是 |
| 不同的远程连接方式 | 是 |
复用是有条件的，且须持续维护
制造商仍须确保风险评估及相关文档准确反映实际投放市场的产品。若新变体引入新的网络安全风险，或改变了基本要求的落实方式，则现有风险评估与合规文档必须更新。仅在产品之间不存在网络安全属性差异的范围内，才能依托单一合规评估。
同样适用于旧产品族
对于在 CRA 适用前设计的产品，若多个变体共享相同设计与网络安全风险特征，制造商可依托覆盖该产品族的代表性证据，而无需逐一测试 → 1.1 适用范围。
3.4.7 文档记录义务
每次风险评估必须记录：
- 评估日期
- 被评估的产品/版本 —— 若采用产品族评估，须列明所覆盖变体的确切清单
- 已识别的风险及评估结果，包括源自产品之外的风险
- 在产品层面为风险缓解采取的措施
- 剩余残余风险及其对照基本要求的理由 —— 而非对照内部风险偏好
- 任何无法完全满足的基本要求、造成该情形的约束，以及所落实的补偿性措施
- 负责评估人
- 下次审查日期
风险评估是技术文档 (Annex VII) 的一部分，必须保持准确、完整且持续更新（Art. 13(7)、Art. 31(2)）——在产品发生重大变更、出现新变体或出现新的威胁态势时均须更新。
3.4.4 至 3.4.6 节解释的来源与法律地位：欧盟委员会 CRA 指南。