CRA 不只是合规清单，而是一套产品安全体系

欧盟《网络弹性法案》（Cyber Resilience Act，CRA）已于 2024 年 12 月正式生效。对于希望持续进入欧盟市场的带有数字元素的产品（Products with Digital Elements, PDE）制造商而言，下一重要合规节点为 2026 年 9 月 11 日。届时，针对主动利用漏洞（actively exploited vulnerabilities）和严重安全事件的报告义务将开始适用。企业需建立覆盖漏洞发现、风险评估、事件报告、漏洞修复和安全更新在内的全生命周期网络安全管理能力。面对 CRA，很多制造商首先想到的是：

• 需要准备哪些文档？
• 需要完成哪些测试？
• 需要满足哪些条款？

但如果仅仅将 CRA 拆解为一份检查清单，企业很容易陷入“逐项满足要求”的误区。其根本原因在于，CRA 关注的并不仅是产品上市前的合规要求，而是贯穿产品全生命周期的安全管理，包括产品设计、软件开发、生产制造、产品部署、漏洞管理、安全更新以及生命周期维护等阶段。

同时，它还涉及芯片供应商、软件供应商、OEM、ODM、EMS 和最终用户之间的协作。因此，真正有效的 CRA 合规，并不是完成一批孤立任务，而是建立一套持续运行的产品安全体系。从企业实施角度来看，CRA 的要求可以提炼为四个关键安全原则：

• 基于风险的方法（Risk-Based Approach）
• 安全设计（Security by Design）
• 默认安全（Security by Default）
• 透明性（Transparency）

简单来说，不同安全原则解决不同层面的问题：

• 基于风险的方法回答：产品需要做到什么程度的安全？
• 安全设计回答：安全能力应该如何构建到产品中？
• 默认安全回答：产品交付时是否已经处于安全状态？
• 透明性回答：如何让相关方理解和验证产品安全状态？

原则一：基于风险的方法——决定“做多少”

网络安全不是投入越多越好，而是需要根据实际风险决定安全措施。基于风险的方法要求制造商理解：

• 产品运行环境；
• 可能面对的威胁；
• 安全事件可能造成的影响；
• 哪些风险需要优先处理。

简单来说，风险并不等同于“是否存在漏洞”，而取决于漏洞被利用的可能性以及可能造成的影响。

例如，一个智能门锁存在本地访问权限配置不当的问题，与一个可被远程利用并控制大量设备的漏洞，虽然都属于安全风险，但由于其发生可能性和潜在影响不同，需要采取不同的风险处置措施。

基于风险的方法帮助企业决定：

• 安全资源投入方向；
• 风险降低措施；
• 剩余风险是否可接受；
• 如何记录安全决策。

它是整个安全体系的起点。

原则二：安全设计——决定“怎么做”

安全设计（Security by Design）的核心思想是：安全不是产品完成后的补充功能，而应该从产品概念、架构设计和开发阶段开始融入。

对于 IoT 产品而言，安全设计并不是简单增加某一个安全功能，而是在产品架构、开发流程和运行机制中系统性融入安全原则。

最小权限（Least Privilege）

确保设备、服务和用户只拥有完成其功能所需的最低权限。简单来说，一个组件能做什么，不应该超过它真正需要做的事情。

例如，智能摄像头可以将视频上传到云端，但不应默认具备访问家庭网络中其他设备的权限。

即使某个组件受到攻击，限制权限也可以降低攻击影响范围。

攻击面最小化（Attack Surface Reduction）

减少攻击者可能利用的攻击面。简单来说，产品暴露的入口越少，潜在风险越低。

例如，IoT 网关可能包含网络接口、调试接口、Web 管理服务、USB 接口等潜在攻击入口。

对于不必要的接口和服务，应当：

• 默认关闭；
• 限制访问；
• 删除不必要功能。

纵深防御（Defense in Depth）

通过多层安全控制共同保护产品。简单来说，不要把安全能力建立在单一道防线上。

例如，智能门锁可以集成多种安全机制，包括：身份认证、加密通信、安全启动（Secure Boot）以及固件完整性校验。

即使某一层受到攻击，其他机制仍可以提供保护。

安全编码实践（Secure Coding Practices）

安全性需求需要集成到软件开发流程中。许多漏洞源于软件缺陷、不安全的编码实践，或未受管理的第三方组件。示例如下：

• 避免硬编码密码；
• 使用安全编程方法；
• 进行代码分析；
• 检测常见安全缺陷；
• 管理第三方软件组件风险。

这也是为什么 SBOM 和漏洞管理成为 CRA 生命周期安全的重要组成部分。

不依赖隐晦式安全（Security by Obscurity）

安全不应该依赖隐藏设计细节。简单来说，“攻击者不知道系统怎么实现”不能成为安全保障。

例如，不能认为 “攻击者不知道设备协议，所以设备就是安全的。”

真正的安全应该依靠安全机制、身份认证、加密保护与权限控制。即使系统设计被了解，产品仍然应该保持安全。

以用户为中心的设计（User-Centered Design）

安全设计需要考虑真实用户如何使用产品。简单来说，不能假设用户永远按照预期方式操作，而应该设计能够降低用户错误影响的产品。

例如，如果设备要求用户完成复杂的安全配置，可能导致用户采取不安全行为，例如使用弱密码、关闭安全功能或忽略安全更新。因此，产品设计应降低用户的安全操作负担，通过提供安全默认配置、简化安全操作流程，并在用户误操作时提供保护机制等方式提升整体安全性。

生命周期管理（Lifecycle Management）

安全设计不能仅关注产品上市前阶段，而应贯穿产品全生命周期，包括开发、生产、部署、运营、更新和退役阶段。例如，设备上线后仍需要持续开展漏洞管理、维护 SBOM、发布安全更新、管理设备身份，以及安全处置退役设备。

简单来说，产品安全不是出厂那一天结束，而是伴随产品整个生命周期。

原则三：默认安全——决定“怎么交付”

如果安全设计解决产品如何被构建，默认安全则解决产品交付时是什么状态。

默认安全要求：用户拿到产品时，产品默认已经具备合理安全配置。

例如，不应该：

• 使用默认弱密码；
• 默认开放不必要接口；
• 要求用户主动开启安全能力。

而应该：

• 提供安全默认配置；
• 默认启用必要保护；
• 支持安全更新。

安全设计负责构建安全能力，默认安全确保这些安全能力在产品交付时即可有效发挥作用。

原则四：透明性——决定“怎么说清楚”

前三个原则解决如何把产品做好安全。透明性解决的是如何让相关方理解、验证产品安全状态的问题。透明性不是公开所有技术细节，而是让正确的信息提供给正确的人。

不同利益相关方对信息披露的需求有所不同：

• 用户需要获取安全使用指南、产品更新信息等，以保障产品的安全使用；
• 供应链伙伴需要了解软件组件信息、安全边界及相关依赖，以支持供应链安全管理；
• 企业需要留存风险分析、漏洞处置记录、更新维护记录等，以满足安全管理和合规要求。

透明性让整个生态能够基于共同信息协作。

四大原则如何协同？

四个原则形成完整闭环：

• 基于风险的方法决定产品需要达到什么安全水平
• 安全设计决定如何将安全能力融入产品
• 默认安全确保产品交付后安全能力能够有效运行
• 透明性帮助相关方理解、验证和维护安全状态

简单来说，风险方法决定方向；安全设计负责实现；默认安全保障交付；透明性负责沟通与证明。

从原则到落地：理念、活动和证据

原则最终需要转化为实际活动，并形成可验证证据。

简单来说，原则解释为什么做，活动说明怎么做，证据证明做过。

结语

CRA 看起来是一部复杂法规，但其底层逻辑并不复杂：基于风险的方法确定安全方向，安全设计和默认安全构建并交付安全能力，透明性帮助整个生态理解和维护安全状态。

四大原则共同构成 CRA 合规的基础。对于 IoT 制造商而言，CRA 不只是一次性的合规任务，而是推动企业建立贯穿产品生命周期的安全管理能力。