EU Cyber Resilience Act: Overview, Requirements, and Timelines

欧盟网络弹性法案（CRA）：概述 | Docker

欧盟网络弹性法案：概述、要求和时间表

发布于 2026 年 6 月 25 日

Dan Stelzer

和

Monique Altman

欧盟网络弹性法案（CRA）于 2024 年 12 月 10 日正式发布，旨在面对日益增长的网络攻击威胁，保护欧盟的基本价值观。随着针对包含数字元素产品的网络攻击变得越来越频繁和昂贵，该法规为欧洲销售的所有硬件和软件产品建立了首个横向的网络安全基线。紧迫性是真实的，根据 Omdia 在 2026 年的软件供应链安全报告，77% 的组织报告称在过去一年中经历了供应链事件。

该法规将于 2027 年 12 月 11 日全面生效，但强制性的漏洞报告义务将于 2026 年 9 月 11 日生效。对于构建和发布容器化软件的团队而言，CRA 将 SBOM 生成、漏洞披露和镜像加固等实践从自愿的最佳实践转变为法律要求。

本指南涵盖了欧盟 CRA 的要求、适用对象、其 SBOM 命令如何与容器构建工作流程相关联，以及团队在合规截止日期到来之前需要做些什么。

关键要点：CRA 要求所有在欧盟销售的包含数字元素的产品到 2027 年 12 月前满足网络安全标准。制造商必须在每种产品的技术文件中包含一个机器可读的 SBOM。从 2026 年 9 月开始，任何被积极利用的漏洞或对包含数字元素产品的安全造成影响的严重事件，必须在 24 小时内向有关部门报告。商业上分发到欧盟的容器运行时在 CRA 下被视为包含数字元素的产品。

什么是欧盟网络弹性法案（CRA）？

在 CRA 之前，欧盟没有一项跨行业的单一法规来为包含数字元素的产品设定网络安全基线。智能恒温器、企业数据库和容器运行时都受到不同的（或没有）网络安全义务。没有普遍的义务来修补漏洞、披露安全事件或记录在欧盟市场推出的包含数字元素产品的软件。CRA 通过一项适用于多个行业的横向法规填补了这一空白，将主要责任放在制造商身上。

该法规将包含数字元素的产品定义为任何软件或硬件产品，包括其远程数据处理解决方案以及任何单独投放市场的组件。该范围是故意广泛的：它涵盖了从消费者物联网设备到企业软件平台，再到通过注册表分发的容器镜像的一切。制造商必须安全地设计产品，在产品生命周期中处理漏洞，并提供有关软件组成的信息的透明度。

CRA 与 NIS2 的关系

CRA 是更广泛的欧盟网络安全战略的一部分，该战略包括其他监管框架，如 NIS2 和 DORA。由于 CRA 和 NIS2 都涉及网络安全义务，它们很容易被混淆，但它们针对的是不同的对象。CRA 适用于包含数字元素产品的网络安全，而 NIS2 适用于关键和重要实体的网络安全。

CRA 的第 12 条甚至确认 SaaS、PaaS 或 IaaS 解决方案受 NIS2 的约束，原则上将其排除在自身的适用范围之外。然而，对于依赖云基础设施的产品而言，这一界限并不清晰。

欧洲委员会 2026 年 3 月发布的草案指南引入了一个三部分测试，用于确定云组件是否属于 CRA 的适用范围：

• 处理是否在远程进行？

• 如果没有该组件，产品是否会失去核心功能？

• 制造商是否负责设计、开发或控制该远程组件？

如果这三个问题的答案都是“是”，那么该云组件在 CRA 的适用范围内被视为产品的一部分。当该测试将云组件纳入适用范围，并且该组件处理个人数据时，GDPR 将在 CRA 之上适用，而不是取代 CRA，因此你仍然需要指定数据控制者和数据处理者的角色，并确认合法依据。

CRA 适用对象

CRA 根据你在将产品推向市场过程中所扮演的角色来分配义务。

| 角色 | 义务 | |------|------| | 制造商 | 义务最重。<br>制造商在将产品投放市场之前，有评估义务，以确保符合 CRA 中规定的网络安全要求。<br>在此过程之后，制造商可以为其产品加贴 CE 标志并附上符合性声明。投放市场后，制造商需在其产品整个生命周期中处理漏洞，并主动报告被利用的漏洞和严重事件。 | | 进口商和分销商 | 义务较少。<br>两者都必须确保制造商遵守了一套义务，同时保留文件记录，并在得知产品不符合 CRA 或存在漏洞时采取行动。 | | 开源软件维护者 | 一个新的 CRA 类别。<br>主要适用于微型企业、中小型企业（包括初创公司、个人、非营利组织和学术研究组织），这些组织系统性地支持商业活动中使用的开源软件。 | | 义务范围缩小，包括制定网络安全政策和漏洞处理，也包括与市场监督机构合作以及某些报告义务。 |

欧盟 CRA 的关键要求

CRA 将其要求分为两个主要领域，均在法规的附件 I 中定义：产品属性的基本网络安全要求，以及产品生命周期中的漏洞处理义务。

安全设计

产品必须根据风险评估进行设计、开发和生产，以确保适当的网络安全水平。实际上，这意味着默认配置应安全，通过移除不必要的组件来最小化攻击面，保护存储和传输数据的机密性和完整性，并提供安全更新的机制。

对于容器镜像，安全设计的要求直接映射到镜像加固：

• 最小的基础层

• 不包含不必要的 shell 或包管理器

• 出厂时即具备安全的默认设置

基本要求还包括数据最小化：产品应仅处理对实现其预期目的必要且相关、适当的个人或其他数据。

制造商必须在整个产品支持周期内，保持识别、记录和修复漏洞的流程。这包括协调漏洞披露政策、及时的安全更新，以及公开披露已修复的漏洞，并提供足够的细节，使用户能够评估影响并实施修复措施。

在支持周期内，安全更新必须免费提供。公开披露应仅限于用户所需的详细技术信息，不得暴露个人数据，例如举报人的身份或受影响用户的身份。这与CRA对披露内容应避免增加风险的期望一致，并符合GDPR对发布个人数据的限制。

透明度与SBOM

CRA还要求制造商在每款包含数字元素的产品的技术文档中包含软件物料清单（SBOM）。SBOM必须采用通用的、可被机器读取的格式，并至少包括产品的顶层依赖项。然而，法规并未规定特定的格式，但在实践中通常意味着SPDX或CycloneDX。生成的SBOM应限定于包和依赖项的元数据，并确保嵌入的秘密和个人数据不包含在制品中。

重要细节：CRA不要求制造商公开发布SBOM。SBOM必须包含在技术文档中，并在市场监督机构要求时提供。此外，文档在产品投放市场后必须保存十年，或在支持周期内保存，以时间较长者为准。

事件和漏洞报告

制造商必须通过单一的报告平台，将被主动利用的漏洞和严重的安全事件报告给相关的国家计算机安全事件响应团队（CSIRT）和ENISA。报告时间线如下：

报告时间线：

• 24小时：早期预警通知
• 72小时：包含技术细节的完整通知
• 14天：在纠正措施可用后提交最终报告（针对被主动利用的漏洞）
• 1个月：从72小时提交后提交最终报告（针对严重事件）

隐私注意事项：这些报告可能包含个人数据，如举报人的身份或受影响用户的详细信息，因此应将每份报告限制为CSIRT和ENISA实际需要的技术信息，并按照GDPR的规定处理任何个人数据。通知还应避免披露可能增加用户风险的信息。

符合性评估

在将产品投放欧盟市场之前，制造商必须完成符合性评估，以验证是否符合基本的网络安全要求。评估的类型取决于产品在CRA下的分类。

产品类别与符合性评估

CRA根据产品的网络安全风险将其分为三个层级，每个层级需接受日益严格的符合性评估程序。

如果你正在分发容器运行时，你很可能属于重要的 II 类别，需要第三方评估。通过符合性评估的产品将获得 CE 标志，这表明其符合 CRA 并允许其在欧盟市场销售。未能通过评估或在投放市场后被发现不符合要求的产品，可以被国家市场监督机构下令撤回或召回。

CRA 时间线：三个重要的截止日期

CRA 于 2024 年 12 月 10 日生效，但其义务将在三年内逐步实施。每个里程碑都引入了一套独特的要求。

日期

里程碑

生效内容

2026 年 6 月 11 日

符合性评估机构

成员国必须指定通知机构。符合性评估机构开始正式通知并可以开始进行评估。

2026 年 9 月 11 日

报告义务

制造商必须主动向 CSIRT 和 ENISA 报告被利用的漏洞和严重的安全事件。此规定追溯适用于欧盟市场上所有现有产品，而不仅仅是新产品。

2027 年 12 月 11 日

全面实施

所有基本的网络安全要求生效：安全设计、技术文件中的 SBOM、漏洞处理、符合性评估、CE 标志。不合规将触发罚款。

大多数团队容易忽略的关键细节是：2026 年 9 月的报告义务适用于已经在市场上的产品。它追溯适用于欧盟市场上所有现有产品，而不仅仅是新发布的产品。如果你目前向欧盟客户销售容器镜像，你的 24 小时报告倒计时将在几个月内开始，而不是几年后。

不合规的处罚

CRA 第 64 条为不合规设立了三个处罚等级，罚款由成员国设定，但受法规上限限制：

• 未能遵守基本网络安全要求和其他核心义务（第 64 条第 2 款）的罚款上限为 1500 万欧元或全球年度营业额的 2.5%（以较高者为准）

• 未能遵守其他 CRA 义务（第 64 条第 3 款）的罚款上限为 1000 万欧元或全球年度营业额的 2%（以较高者为准）

• 向当局提供错误、不完整或误导信息（第 64 条第 4 款）的罚款上限为 500 万欧元或全球年度营业额的 1%（以较高者为准）

除了罚款，市场监督机构还可以下令产品撤回、召回或直接禁止在欧盟市场销售。对于向欧盟销售软件产品的组织来说，失去市场准入通常比罚款本身更为严重的后果。

微型企业和小型企业通常因未能在漏洞和事件报告上满足 24 小时预警截止日期而免除罚款。开源软件维护者不受 CRA 任何违规行为的罚款限制。

开源软件与 CRA

CRA 对开源软件的处理是立法过程中最具争议的方面之一。最终文本基于商业活动划出了一条清晰的界限。

未在商业活动中直接或通过支持使用免费和开源软件，将不在 CRA 的范围内。只要个人开发者和志愿者维护者不在商业活动中运作，他们就不会被归类为法规中的制造商。CRA 明确不适用于在商业活动范围之外分发的开源软件。

然而，该法规引入了一个新角色：开源软件管理者（open-source software steward）。

“管理者”是指一个法律实体（公司或基金会，而非个人），其系统性地支持用于商业活动的开源软件的开发。CRA 对管理者的监管较为宽松，其义务也相对有限。他们主要需要做到以下几点：

• 保持网络安全政策。
• 主动报告被利用的漏洞。
• 与市场监督机构合作。

关键的是，管理者因违反 CRA 而受到的财务处罚是有限的。

那些以商业模式分发开源软件的组织，无论是通过付费支持还是商业容器镜像仓库，都被归类为制造商，而非管理者。这种区分很重要，因为制造商需要承担 CRA 义务的全部责任，包括符合性评估和 CE 标志。

CRA 对容器团队意味着什么

以上所有内容适用于所有数字产品。现在我们来具体说明。在欧盟商业分发的容器镜像和运行时，根据 CRA 被视为具有数字元素的产品。如果您的组织在某个注册表中发布容器镜像，且欧盟客户可以从中拉取这些镜像，并且这些镜像属于商业产品的一部分，那么 CRA 将适用，您可能被视为制造商。无论您的组织总部设在哪里，这一规则都适用。

实际影响贯穿整个容器生命周期：

• 镜像组成透明度：每个镜像都需要一个机器可读的 SBOM，记录至少顶层依赖项。在构建时生成的镜像层 SBOM，能够记录操作系统包、运行时库和传递依赖项，比 CRA 的最低要求更进一步。

• 漏洞管理：组织必须建立流程，跟踪、修复并报告其镜像中组件的漏洞。从 2026 年 9 月起，第 14 条中列出的所有漏洞和事件报告义务将正式生效。

• 安全设计：镜像应以最小的攻击面、安全的默认配置和没有不必要的组件进行交付。移除了 shell、包管理器和调试工具的加固基础镜像，比标准社区镜像更直接地满足这一要求。

• 来源和完整性：CRA 的基本要求包括保护产品的完整性，并验证组件是否未被篡改。加密签名和来源证明直接解决了这一问题。

• 支持周期：制造商必须定义并传达一个支持周期，在此期间他们将处理漏洞。对于容器镜像，这意味着要承诺为每个支持的镜像标签在其生命周期内提供补丁和重新构建的周期。

合规从镜像层开始

CRA 提高了所有向欧盟交付软件的组织的标准。对于容器团队来说，这些要求直接对应了行业一直在推动的做法：加固镜像、构建时 SBOM、来源证明、漏洞监控和定义的支持生命周期。不同之处在于，这些做法不再是可选的。

幸运的是，Docker 加固镜像附带了 CRA 所要求的各类材料：完整的 SBOM（软件物料清单），具有不可伪造证明的 SLSA 构建级别 3 来源信息，OpenVEX 漏洞利用数据，以及加密签名。这些镜像默认是精简的，会持续根据上游修复进行重建，并且有明确的支持周期。将这些与基于 SBOM 数据的持续漏洞监控相结合，仅限于包和组件元数据，排除个人数据和嵌入的机密信息，CRA 的 24 小时报告时钟将从已知的爆炸半径开始，而不是手动分类。

• [立即开始使用 Docker 加固镜像 →](#)

• [探索使用 Docker Scout 进行漏洞监控 →](#)

常见问题

CRA 是否适用于容器镜像？

是的，通常如此。在欧盟市场商业分发的容器镜像被视为包含数字元素的产品，适用于 CRA。无论这些镜像是作为软件产品的一部分进行分发，作为托管服务出售，还是发布在商业注册表中，都适用这一规定。该法规基于在欧盟市场上的商业可用性，而不是制造商的总部所在地。

CRA 要求使用哪种 SBOM 格式？

CRA 要求使用一种通用的、可被机器读取的格式，但并未指定特定的标准。实际上，这通常意味着使用 SPDX 或 CycloneDX。对于容器工作流程，SPDX 是 BuildKit 生成图像证明时原生支持的格式。无论使用哪种格式，都要将 SBOM 的范围限定在包和依赖项的元数据上，并从生成的制品中排除嵌入的机密信息和个人数据。

我是否必须公开发布我的 SBOM？

不。CRA 要求 SBOM 被包含在技术文档中，并在要求时提供给市场监督机构。没有义务将其公开。然而，那些将 SBOM 作为证明附加到其镜像中的组织，可以更容易地让下游用户验证合规性并评估风险。如果你确实发布 SBOM，首先应清除其中的机密信息、内部主机名和任何个人数据，因为一旦发布，这些制品很难撤回。

开源项目是否豁免？

只要开源软件未在市场上提供，且未用于商业活动中的分发或使用，就超出了 CRA 的适用范围。个人志愿者维护者，只要他们不参与商业活动，就不会被归类为制造商。然而，那些通过付费支持、托管服务或商业注册表商业分发开源软件的组织，可能会被归类为制造商，并需遵守 CRA 的全部义务。

CRA 的 SBOM 要求何时生效？

SBOM 要求是附件 I 中基本网络安全要求的一部分，将于 2027 年 12 月 11 日全面生效。然而，从 2026 年 9 月 11 日开始的漏洞报告义务在没有 SBOM 数据的情况下很难实现，因此在正式截止日期之前，实际迫切需要准备好 SBOM。

来源

Omdia，《Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption》，2026 年 5 月。

概念

[Docker 加固镜像](#)

[Docker Scout](#)

[安全](#)

[软件供应链安全](#)

产品

[目录](#)

相关文章

• 2026年5月12日 Docker AI治理：安全地释放代理自主性 介绍Docker AI治理：集中控制代理的执行方式、它们在网络中可以访问的内容、可以使用的凭证以及可以调用的MCP工具，这样公司中的每一位开发人员都可以在任何工作地点安全地运行AI代理。你的笔记本电脑就是新的生产环境。代理是最大的生产力释放者…… Srini Sekaran 立即阅读

• 2026年6月25日 欧盟网络弹性法案：概述、要求和时间表 了解欧盟网络弹性法案的要求，包括SBOM规定、漏洞报告以及容器团队的合规截止日期。Dan Stelzer 和 Monique Altman 立即阅读

• 2026年6月23日 什么是SBOM（为什么没有它就无法发货）？ 了解软件物料清单（SBOM）是什么，为什么它对供应链安全至关重要，如何生成SBOM，以及应使用哪些格式和标准。Aditya Tripathi 立即阅读

• 2026年6月16日 Docker内容信任：退役和迁移指南 Docker内容信任（DCT）和notary.docker.io上的Notary v1服务将被完全退役（首次在2025年7月宣布）。这篇博客解释了哪些变化正在发生，哪些人会受到影响，以及如何迁移到现代替代方案。Julia Wilson 和 Aditya Tripathi 立即阅读