《网络弹性法案》CRA 合规全指南：禁行与应行

by Canonical on 9 October 2025

Canonical 博客多次撰文探讨欧盟 CRA，而现在正是讨论这项新法规的影响以及它对物联网（IoT）和设备制造商在如何设计和构建具有数字元素的产品（PDE）的实际层面上的意义的最佳时机。

本文将深入剖析 IoT 制造商及 PDE 开发者亟待整改的常见实践，并给出合规改造方案，助您的工作成果和 PDE 在符合 CRA 的前提下持续立足欧盟市场。

《网络弹性法案》（CRA）下的禁行之举及应行之事

根据 CRA 规定，企业可执行与禁止的行为范畴根本上取决于其自身及所涉 PDE 在该新颁布法案中的分级或归类。若您尚未掌握 CRA 的法定措辞、分级机制及合规要求，可通过研读笔者往期专题文章系统掌握细则解读：

• 首席信息安全官针对 CRA 的全面解析：关于欧盟网络弹性法案的全面解析，涵盖法案定义、核心要求以及它将如何广泛影响设备的网络安全设计、文档记录、长期支持和漏洞管理。 
• CRA 对 IoT 制造商而言意味着什么：探究 CRA 将如何影响所有计划在欧盟市场销售设备和产品的 IoT 制造商。
• CRA 将如何影响开源软件：全面了解 CRA 是如何产生的、社区对此法规的反应，以及这对开源的未来意味着什么。

然而，CRA 在特定类别和分类要求之外，引入了极其广泛的变革，这些变革将影响 IoT 和 PDE 的网络安全及漏洞管理领域，无论相关方是否属于 CRA 具体条款的管辖范围。 

让我们深入剖析：

责任推诿到此为止

不再将安全责任转嫁给下游用户，也不应寄希望于上游供应商为漏洞兜底。事实上，构建产品或将其推向市场通常意味着您将被归类为制造商，随之而来的是合规评估层级的提升，以及更严苛的 PDE 合规要求。 

若不愿承担制造商合规的主要压力，您应寻求愿意承接该责任的供应商。 

文档说明不应再成为挡箭牌，更不应视其为可选项

文档说明不应再成为挡箭牌。若 PDE 中存在漏洞、缺陷或瑕疵，或包含特定使用限制说明，您不可理所当然地要求用户通读全部文档，并指望其遵循这些隐蔽的操作说明来实现产品安全使用。 

在实践层面，这意味着制造商不能止步于单纯用文档记录漏洞与风险告知，例如仅告知用户“勿在非安全网络使用设备”、“使用前需修改密码”或“使用前必须手动禁用特定端口或功能”等要求。仅将漏洞记录在案并向用户发出警告已远远不够：制造商必须亲自修复这些漏洞。 

在技术文档层面，CRA 对文档编制方法与可访问性提出了更严苛的强制性要求。总体而言，CRA 意味着制造商必须履行全新文档规范，包括强化文档获取渠道的公开说明，并构建可访问、机器可读的软件供应链及正式软件物料清单 （SBOM）。 

至少，您需要记录以下内容并供公众和欧盟当局访问：

• 关于产品设计、开发及漏洞处理流程的说明
• 网络安全风险评估
• 产品符合的欧盟协调网络安全标准清单
• 经签署的欧盟符合性声明，声明上述基本要求已获满足
• 软件物料清单（SBOM），记录产品所含漏洞及组件

您不应再以 “意图” 为掩护

不应再以文档说明为挡箭牌，主观意图亦不得作为免责事由。

这意味着，产品瑕疵、设计缺陷或安全漏洞均不得辩称为蓄意设计决策。例如，若设备存在可能被合理用于设备访问或网络连接的端口、特性或功能，责任方必须实施风险管控措施，以消除这些要素构成的安全威胁及攻击路径。 

我们将在下一节阐述责任方可采取的一些实操性措施，以强化设备网络安全防护体系。

基础安全要求不再具有可选项性质

 CRA 的诸多要求本质上是将网络安全实践和安全特性规范化，这些内容应视为行业最低标准。此处特指以下情形：交付含已知漏洞的产品；期望用户购买后自行加强设备安全；忽视网络安全基础要求（如未禁用默认管理员凭证）；或借晦涩或不充分的文档说明掩饰缺陷。 

部分网络安全基本要素涵盖： 

• 务必确保所构建的产品在合理范围内达到最高安全等级。产品必须具备最小化攻击面。 
• 对设备或产品实施安全加固。设备的数据必须进行加密或保护，并确保阻止未授权访问。
• 预防系统停机。设备必须能在遭受 DDoS 攻击时持续运行，且即使遭遇漏洞利用攻击，也不得干扰其他设备运行。
• 持续追踪活动踪迹。设备需具备监控能力或记录变更日志功能，以持续提供安全数据。 
• 先制式漏洞修补机制。产品需具备接收安全更新或执行版本回滚的能力。该能力须涵盖直接更新或远程更新功能，包含向用户推送更新通知的机制，并支持版本回退更新或产品恢复至出厂／默认状态。

即便没有 CRA 强制要求满足更高的网络安全标准，也应在 PDE 的安全设计中达到这些基础标准。在 PDE 投放市场前，可采取以下措施确保其安全性与稳健性达到最高标准：

• 应尽可能全面实施零信任架构
• 确保身份认证、授权和访问控制机制完全安全（以及对凭证拥有掌控权）
• 采用“默认安全”配置
• 最大限度减少攻击面 — 若设备、系统或组织当前未使用特定资源（包括端口、组件或软件包），均应默认禁用，待需用时方可启用。
• 确保正确使用加密技术，以保障静态存储数据与传输中数据的安全保护、实现流量加密，并避免使用明文或未加密数据。
• 验证所有输入数据，并妥善处理各类异常
• 确保所有独立组件及其依赖项的安全防护，而不仅限于技术栈整体。
• 最小化应用程序和系统的访问权限，从一开始就设定安全基线，防范服务器端请求伪造攻击
• 使用自动化安全补丁管理软件，确保经过验证及认证的安全更新、CVE 漏洞修复和其他补丁能够及时自动下载。 

简言之，将存在安全隐患的物联网设备推向市场的“淘金热”已告终结：消费者对其所用设备的安全性与隐私性要求显著提升，若产品无法满足这些标准，终将导致灾难性后果。我们深刻理解 CVE 漏洞对用户及企业造成的严重影响，正因如此，Ubuntu Pro 郑重承诺：对关键 CVE 漏洞的修复将在 24 小时内完成。

Ubuntu Pro 为组织提供长达 12 年的免手动的自动化保障，可持续获取核心软件包及安全更新，无论涌现何种新型漏洞或合规要求，皆可确保全面覆盖。 

产品上市绝非终点，持续维护更需重视

您应当优先关注的另一要务是，设备与软件的补丁及漏洞管理。CRA 的核心要求之一是，确保设备具备抵御新漏洞的安全更新能力。您所提供的更新必须是免费的，并在发现漏洞后立即发送，同时向用户提供应采取何种措施的相关说明。

此情形下，您须提供：

• 漏洞详情及其严重程度说明
• 供用户识别受影响数字元素产品的信息
• 漏洞造成的影响
• 帮助用户修复漏洞的信息

此外，此类安全修补与更新工作必须长期持续，并覆盖 PDE 的完整生命周期。必须定期测试产品并即时修复漏洞。漏洞修复后，应依据 CRA 要求的协同公开披露政策，公开披露已修复漏洞的具体信息。 

在最长 5 年（或产品生命周期，以较短者为准）的期限内，您将按照要求召回或撤回未达到 CRA 符合性标准的产品。

不再有隐藏或灰色的依赖关系

无论您是否被归类为制造商，都必须以制造商的责任标准管理软件供应链。这是因为 CRA 引入了新要求：必须建立合规文档体系、透明化软件供应链，并提供软件物料清单，以证明软件组件的安全可溯源。您至少应做到：仅采用可信开源组件，或仅从可信供应商处获取软件包。 

如果您对自己的软件供应链及其能否达到 CRA 的监管标准、文档要求、漏洞披露要求和透明度期望没有把握，则应对您的服务和软件提供商进行评估，选择那些能够帮助您轻松达到 CRA 义务要求的提供商。 

通常，这意味着需选择符合下列任一标准的供应商：

• 具有 CE 标志
• 可以提供供应链认证
• 已决定承担 “制造商” 法律责任身份

我们建议，仅选用已承担 CRA 合规责任的大型可信供应商所提供的软件包或更新。这意味着您应直接采购已决定承担“制造商”法律身份的供应商提供的开源软件版本（或该软件的安全补丁）。

Canonical 深知此举至关重要，因此我们已对旗下多款产品承担制造商责任。Canonical 研发维护的众多工具与产品，包括 Ubuntu、Kubernetes 发行版、MicroCloud、OpenStack 发行版等，均内置安全设计，通过安全维护与漏洞修补提供持续支持，并接受 CRA 的法定监管。除此之外，诸如 Ubuntu Pro for Devices 等服务可以确保您的设备获得长达 12 年的安全维护。 

彻底摒弃 “市场优先” 策略

“快速破局”的时代宣告终结。依据 CRA，企业不得因过度执着市场窗口期或发布日期而交付在安全设计及长期支持方面偷工减料的“最小可行产品”（MVP）。反之，企业必须基于坚实的安全基础和支持体系来构建软件包及软件产品，该体系需在产品发售日期之后持续多年。

您应重新评估操作系统、开发环境及软件供应商的选择策略，以满足此项新规要求。所选系统须同时满足：CRA 要求的强健安全基线与长期安全支持保障，以及最大程度缩减攻击面以降低攻击向量与漏洞数量。 

此举效益远超安全范畴：最小化攻击面、设备优化操作系统或容器化构建，可实现资源占用极致精简，这意味着更高运行效能、更低设备规格要求及更优制造成本。事实上，Ubuntu Core（面向设备的嵌入式 Linux 操作系统）深度践行了这些要求与优势：其作为 Ubuntu 的精简严格封装版本，专为嵌入式设备而设计。Ubuntu Core 具备深度优化的系统架构，完美适配那些硬件规格受限却仍要求强健安全机制、长期维护及高水准性能的设备。 

满足 CRA 合规要求所需的变更要点摘要

综上所述，CRA 的实施意味着诸多方面已发生深刻变革。那些躲在晦涩文档背后、将责任推诿给制造商或用户、推出市场优先的“一锤子买卖”设备（含未知依赖项且无技术支持）的日子，已一去不复返。然而，只要通过强化网络安全基础实践加固 PDE，选用制造商级供应商（具备长期支持计划）提供的可信软件包及安全更新，并构建清晰的软件供应链与依赖清单，您便能从容应对新规要求，持续准入欧盟市场。 

总而言之，若要直面应对 CRA 的新挑战与新要求，您须遵循以下六项明确步骤： 

• 采用 PDE 强化防护与设备安全防护的最佳实践
• 最大限度实施网络安全强化措施
• 立即执行合规评估与测试
• 记录并持续公开所有技术文档，并同步公示包含软件成分及依赖关系的软件物料清单（SBOM） 
• 须恪守用户权益优先原则，严禁最小可行产品（MVP）仓促入市
• 应选择对软件包/软件承担制造商责任的供应商

为了深入了解 Canonical 如何帮助您满足欧盟 CRA 对设备的要求，请访问我们的综合 CRA 网页，或者填写表单联系我们的合规专家团队。

了解更多

要了解如何通过为设备提供长达 12 年的自动化安全补丁服务来设计和支持符合 CRA 要求的 PDE，请访问：www.ubuntu.com/pro

要了解 Ubuntu Core 如何成为您的 PDE、IoT 设备及所有嵌入式系统的理想选择，请访问：www.ubuntu.com/core 

更多阅读

• 【白皮书】了解全球市场的 IoT 安全与 IoT 合规性
• 【博文】首席信息安全官对 CRA 的全面深度解析（中文）
• 【博文】了解 CRA 对开源的影响（中文）
• 【白皮书】CRA ：嵌入式设备采用 Yocto 还是 Ubuntu Core？
• 【博文】SBOM 是什么？ 软件物料清单深度解析指南
• 【博文】CRA 对 IoT 制造商而言意味着什么（中文）