芯耀
与非AI
153
引言
在前两期中，我们已经分别对 CRA 的适用范围、整体影响以及率先生效的漏洞通报义务进行了分析。随着 2026 年 9 月 11 日这一关键时间节点不断临近，企业面对 CRA 的合规准备，已不能停留在对“报告义务”的被动理解上，而必须进一步进入更深层的能力建设阶段，即建立一套能够支撑产品全生命周期的网络安全风险评估与管理机制。根据欧盟委员会公开说明，CRA 已于 2024 年 12 月 10 日生效，主要义务自 2027 年 12 月 11 日起全面适用，其中报告义务则自 2026 年 9 月 11 日提前适用。与此同时，欧盟委员会也明确指出，制造商在产品投放市场前即应先开展网络安全风险评估，并据此确定如何落实 CRA 所要求的基本网络安全要求。
一、为什么网络安全风险评估是 CRA 合规的起点
从 CRA 的制度设计来看，网络安全风险评估并不是企业可自行选择是否开展的内部管理动作，而是整个合规体系的起点。根据 Regulation (EU) 2024/2847 第13条，制造商在将具有数字要素的产品投放欧盟市场时，必须确保该产品依照附件 I 第 I 部分的基本网络安全要求进行设计、开发和生产；而风险评估的作用，正是用来识别产品面临的具体网络安全风险，并据此决定这些要求应如何适用于特定产品、如何具体落地，以及漏洞处理要求应如何纳入企业流程。欧盟委员会在其面向制造商的官方说明中也明确提出，企业在产品上市前的第一步，就是开展风险评估，并据此确定适用的基本网络安全要求，再将相关结论纳入技术文档和合规评估流程。
这意味着，CRA 并不是要求所有企业以完全同一套技术措施应对所有产品，而是要求企业先做出有证据支撑的风险判断，再决定控制措施的深度和方式。换言之，CRA 的核心逻辑不是“机械勾选要求”，而是“基于风险实施安全”。如果企业无法证明其风险识别过程完整、风险判断逻辑合理、控制措施与风险水平匹配，那么即便已经部署了部分安全措施，也可能仍然无法充分证明其满足 CRA 的要求。
二、CRA 所要求的风险评估，企业到底要评估什么
CRA 对风险评估的内容并非空泛表述，而是给出了相对清晰的法定框架。根据第13条第3款，企业的网络安全风险评估至少应当包括：基于产品预期用途和可合理预见用途的网络安全风险分析；结合产品使用条件的分析，例如运行环境、被保护资产以及产品预期使用时长；并进一步说明附件 I 第 I 部分第(2)点列出的安全要求是否适用、如何适用，以及企业准备如何落实附件 I 第 I 部分第(1)点与第 II 部分的漏洞处理要求。与此同时，风险评估结果还必须在产品投放市场时被纳入技术文档，并在支持期内根据情况持续更新。
从附件 I 的具体要求来看，企业评估的对象远不只是传统意义上的“是否会发生数据泄露”。CRA 要求产品在基于风险的前提下达到适当的网络安全水平，并尽量做到无已知可利用漏洞，以“默认安全”的配置投放市场，同时还应保护基本功能的可用性、限制攻击面、降低安全事件影响，并通过记录和监测相关内部活动提供必要的安全信息。对于漏洞处理，CRA 还要求企业识别并记录产品及其组件中的漏洞与组成成分，在风险相关的范围内及时修复漏洞并提供安全更新，定期测试和复核产品安全性，建立协调漏洞披露政策，并提供漏洞接收与沟通渠道。
因此，在 CRA 框架下，企业需要评估的风险至少应覆盖以下几个维度：产品自身设计缺陷所导致的安全风险，默认配置和权限控制不当引发的风险，更新机制失效或被篡改的风险，第三方组件和开源依赖带来的供应链风险，以及产品在不同部署环境和不同生命周期阶段下可能产生的差异化风险。可以说，CRA 所要求的并不是一次性的静态评估，而是覆盖“设计—开发—交付—维护—更新—退役”全过程的动态风险治理。
三、企业应如何建立 CRA 视角下的风险评估方法
从企业实务角度看，满足 CRA 要求的风险评估，首先不是“写一份风险评估报告”，而是要先搭建清晰的方法框架。第一步，应当围绕具体产品建立资产和边界识别机制，明确该产品的核心功能、关键组件、外部接口、依赖的第三方软件或服务、典型使用场景以及涉及保护的关键资产。因为 CRA 明确要求风险分析基于预期用途、可合理预见用途和使用条件展开，企业若连产品边界都无法说清，就很难证明其风险评估是完整的。
第二步，应将威胁、脆弱点和影响分析纳入统一逻辑。企业不仅要识别“产品可能被怎样攻击”，还要分析“为何会被攻击”“一旦被利用会对哪些对象造成什么后果”。在 CRA 语境下，这些后果不仅包括机密性、完整性和可用性的损害，也包括对其他设备、网络和服务产生的连带影响。因此，风险评估不能只由研发或测试团队孤立完成，而需要产品、研发、安全、法务、合规、售后乃至供应链团队共同参与，才能形成兼顾技术事实、业务场景和合规要求的判断。
第三步，应当把风险评估结果直接映射到控制措施，而不是停留在“高、中、低”分级本身。CRA 真正关注的，不是企业是否给风险打了标签，而是企业是否根据风险决定了合理的安全设计、测试、更新、漏洞处理和用户通知措施。欧盟委员会也强调，风险评估之后，制造商需要据此定义如何落实适用的基本网络安全要求，并通过技术文档和合规评估予以证明。也就是说，风险评估的输出应当至少回答三个问题：哪些安全要求适用；企业如何实施这些要求；相关证据存放在哪里。
四、风险管理不应止于产品上市前，而应贯穿整个支持期
CRA 与许多传统产品合规规则最大的不同之一，在于它并不把“上市前合规”作为终点，而是明确要求企业在产品上市后继续处理漏洞并维持安全能力。根据第13条第8款及其后续规定，制造商必须在产品投放市场时以及整个支持期内，确保该产品及其组件的漏洞得到有效处理；支持期应反映产品预期使用时长，原则上不得少于五年，若产品预期使用期限少于五年，则支持期应与预期使用期限一致。企业还必须将确定支持期时所考虑的信息写入技术文档。欧盟委员会对制造商义务的说明同样指出，产品上市后，企业仍需在支持期内持续处理漏洞，并承担相应报告义务。
这意味着，企业的风险管理不能停留在项目立项或上市评审阶段，而必须嵌入持续运营机制中。实践中，至少应建立以下几类持续动作：对内部发现和外部报告漏洞的接收与分流机制；对已部署版本、组件依赖和客户影响面的持续识别机制；对补丁、缓解措施和替代控制的发布机制；以及对新威胁情报、供应链事件和运行环境变化导致的风险变化进行复评的机制。CRA 第13条同时要求企业系统性记录与产品相关的重要网络安全事项，包括企业已知漏洞及第三方提供的相关信息，并在适用时更新网络安全风险评估。由此可见，CRA 所要求的是“持续更新的风险管理闭环”，而不是“上市前一次评估、上市后不再过问”。
尤其值得注意的是，CRA 将支持期与漏洞处理、更新可获得性以及技术文档保存义务紧密绑定。法规要求，安全更新在支持期内提供后，还需至少继续可获取十年或覆盖剩余支持期，以较长期限者为准；同时，技术文档、用户信息和符合性文件也需至少保存十年或覆盖支持期。对企业而言，这意味着风险管理已经从单纯的“技术修复”延伸到生命周期承诺管理、文档治理和客户沟通管理。
五、供应链与第三方组件，将成为风险管理中的重点难点
在 CRA 语境下，企业无法再将第三方组件、开源依赖或外包开发视为外部问题。附件 I 第 II 部分明确要求制造商识别并记录产品中的漏洞和组成成分，包括通过以通用、机器可读格式形成软件物料清单（SBOM），至少覆盖顶层依赖关系。这一要求的本质，不只是文档留痕，而是为了让企业具备对供应链风险进行追踪、定位和快速响应的能力。ENISA 也在与 CRA 实施相关的资料中反复强调，SBOM 有助于增强对软件供应链的理解，帮助制造商和用户跟踪新出现的已知漏洞和网络安全风险。
与此同时，ENISA 关于供应链网络安全良好实践的研究提出，企业应建立覆盖风险评估、供应商关系管理、漏洞管理和产品质量管理的统一第三方风险管理体系，并建议以计划—执行—检查—改进（PDCA）的持续改进方式来管理供应链安全。该报告还指出，供应链风险评估应首先识别并记录供应商和服务提供商类型，明确业务目标与风险准则，再结合业务连续性要求开展风险分析、风险处置及持续监测。虽然这份 ENISA 报告并非 CRA 的直接法律文本，但对于企业如何把 CRA 的供应链风险要求转化为内部治理机制，具有较强参考价值。
因此，对出海企业而言，真正需要建立的不是“采购阶段问供应商要一份安全承诺函”，而是围绕第三方组件和供应商形成可验证的风险管理链条。例如，哪些组件属于核心依赖，哪些供应商提供关键功能，哪些更新路径可能影响产品安全，哪些供应商应接受更高强度的安全审查，哪些第三方漏洞会直接触发本企业的影响分析和通报流程。这些问题如果在平时没有机制化管理，等到漏洞事件发生时，企业很可能既无法快速判断影响范围，也无法在法定期限内形成准确、可提交的结论。
