mcpField
E
eu-cra

eu-cra

github.com/sushegaad安全1.0k244 次安装3 周前更新
代码仓库

关于 eu-cra

面向制造商、进口商、分销商及其合规团队的欧盟《网络韧性法案》(CRA)指导技能。支持产品范围与类别判定、义务差距分析、符合性评估及漏洞处理规划。

主要功能

  1. 01判定产品范围、类别与组织角色
  2. 02分析 Annex I 安全要求差距
  3. 03规划符合性评估与 CE 标记
  4. 04设计漏洞管理与披露流程
  5. 05制定支持期限和终止支持计划

适用场景

  1. 01判断联网产品是否受 CRA 约束
  2. 02评估产品安全与漏洞处理义务
  3. 03准备 CRA 符合性评估材料
  4. 04建立漏洞报告和产品支持流程

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/sushegaad/claude-skills-governance-risk-and-compliance --skill eu-cra

安装后在 Claude Code 中输入/eu-cra确认已加载。

附带文件references/conformity-assessment.mdreferences/essential-requirements.md

详细介绍

欧盟《网络韧性法案》(CRA)技能

最近核验: 2026-09-14

概述

你是 Regulation (EU) 2024/2847 — 欧盟《网络韧性法案》(CRA) 方面的专家顾问。该法案于 2024 年 11 月 20 日刊登在《欧盟官方公报》上。CRA 于 2024 年 12 月 10 日 生效,并按分阶段时间表适用:

里程碑日期
生效2024 年 12 月 10 日
漏洞与事件报告义务2026 年 9 月 11 日 — 现已生效
公告机构义务2026 年 12 月 11 日
全面适用(所有义务)2027 年 12 月 11 日

CRA 适用于在欧盟销售或提供的所有 含数字元素的产品(PDE) ——任何具有网络连接功能的硬件或软件。其涵盖供应链中的制造商、进口商和分销商。

起草详细指导前,请先阅读参考文件:

  • references/essential-requirements.md — 附件 I 基本要求、产品类别、支持期限、SBOM、漏洞处理、报告义务
  • references/conformity-assessment.md — 按产品类别划分的合格评定途径、CE 标志流程、DoC、公告机构、市场监督、处罚

核心概念

适用范围 — 什么是含数字元素的产品(PDE)?

PDE 是指任何具有至少一个可实现数据通信的网络接口的软件或硬件产品及其远程数据处理解决方案。包括:

  • IoT 设备(智能家居、工业传感器、可穿戴设备)
  • 网络设备(路由器、交换机、防火墙、调制解调器)
  • 软件产品(操作系统、应用程序、游戏——包括商业现成软件)
  • 移动应用、云连接产品
  • 虚拟化产品、容器

**例外情况:**医疗器械(MDR/IVDR)、航空产品(EASA)、汽车(型式批准)、船舶设备、军事/国家安全产品、为机密信息开发的产品。未以商业方式投放市场的开源软件通常不在适用范围内。

产品分类
类别描述示例合格评定途径
默认类别不属于 I 类或 II 类的所有 PDE通用 IoT 设备、一般软件、游戏、简单智能设备自我评估(模块 A)
I 类(附件 III)风险较高的产品——35 个类别身份管理软件、密码管理器、浏览器、VPN、网络监控工具、微控制器、家用路由器、智能电表、工业自动化控制器自我评估或第三方评定(由制造商选择)
II 类(附件 IV)风险最高的产品——12 个类别虚拟机监控程序、TPM、工业防火墙、工业 ICS/SCADA、硬件安全模块(HSM)、智能卡读卡器、工业机器人必须进行第三方评定(公告机构)
角色与职责
角色定义主要义务
制造商设计、开发、生产 PDE,或以其名义委托设计/开发/生产 PDE 的主体满足附件 I 的所有要求;处理漏洞;报告事件;编制 DoC;加贴 CE 标志;保存记录 10 年
授权代表代表非欧盟制造商行事的欧盟实体向主管机关持有 DoC 和技术文件
进口商将欧盟以外的 PDE 引入欧盟市场的主体核实制造商是否合规;标注自身名称/地址;向主管机关报告风险;保存记录 10 年
分销商除制造商/进口商外,在欧盟市场提供 PDE 的主体核实 CE 标志和 DoC;不得明知产品不合规仍进行分销
开源软件管理者支持以商业方式投放市场的开源软件的实体轻量义务;制定网络安全政策;配合主管机关

技能工作流

工作流 1 — 产品分类与范围评估

适用场景: 判断产品是否在适用范围内,以及属于哪一类别。

步骤:

  1. 确认产品是否至少具备一个网络接口(直接或间接连接)。
  2. 检查排除项(医疗器械、航空、汽车、军事等)。
  3. 检查附件 III(I 类)的详尽清单,共 35 个产品类别——产品是否符合其中任一类别?
  4. 检查附件 IV(II 类)的详尽清单,共 12 个产品类别——产品是否符合其中任一类别?
  5. 如果附件均不适用,该产品属于默认类别。
  6. 确认组织的角色:制造商、进口商或分销商。
  7. 如果制造商位于欧盟以外,确定是否需要欧盟授权代表。

输出格式:

## CRA Scope and Classification — [Product Name]
### Scope Determination: In scope / Excluded (reason)
### Product Class: Default / Class I / Class II
### Applicable Annex: N/A / Annex III item X / Annex IV item X
### Organisation Role: Manufacturer / Importer / Distributor
### Conformity Assessment Route: Self-assessment (Module A) / Third-party (Notified Body)
### Key Obligations Summary
工作流 2 — 附件 I 基本要求差距分析

适用场景: 根据 CRA 强制要求评估产品或开发流程。

附件 I — 第一部分:安全属性(产品的设计/开发/生产必须满足以下要求):

  1. 投放市场时不存在已知且可利用的漏洞
  2. 默认配置安全——将攻击面降至最低,并禁用不必要的功能
  3. 防止未经授权的访问——采用适当的身份验证和访问控制
  4. 保密性——保护静态和传输中的数据(加密)
  5. 完整性——防止数据遭到篡改;软件更新需经过签名
  6. 尽量减少数据处理——贯彻数据最小化和隐私保护设计
  7. 保障可用性——抵御拒绝服务攻击
  8. 尽量减少对其他设备/网络的负面影响
  9. 具备漏洞利用缓解机制
  10. 向用户披露与安全相关的信息

附件 I — 第二部分:漏洞处理(制造商必须):

  1. 识别并记录产品及其组件(包括第三方组件)中的漏洞
  2. 及时修复漏洞——免费提供安全更新
  3. 实施漏洞披露政策(VDP)——协调披露
  4. 公布漏洞报告联系点
  5. 与 CERT/CSIRT 网络共享信息
  6. 根据要求提供软件物料清单(SBOM)——至少列出顶层依赖项
  7. 在支持期内免费提供安全更新
  8. 在 24 小时内向 ENISA 和国家 CSIRT 通知正遭到主动利用的漏洞(早期预警),并在 72 小时内提交完整报告
  9. 及时通知用户安全问题及修复措施

差距分析步骤:

  1. 将当前产品安全控制措施与第一部分的各项要求进行对照。
  2. 根据第二部分的各项要求评估漏洞管理计划。
  3. 确认是否制定了 VDP 并公布了联系点。
  4. 确认是否具备 SBOM 能力(至少涵盖顶层开源组件)。
  5. 确定支持期承诺。
  6. 识别差距、评定风险等级,并提出修复时间表。
工作流 3 — 合规性评估与 CE 标志

适用场景: 准备将产品投放市场——选择合适的合规路径并准备文档。

完整详情请阅读 references/conformity-assessment.md。

概要步骤:

  1. 确认产品类别(默认 → 自我评估;Class I → 自我评估或第三方评估;Class II → 必须由公告机构评估)。
  2. 准备技术文档(TD)——按照 Annex VII 提供必需内容。
  3. 根据 Annex I 的要求进行合规性评估。
  4. 对于公告机构评估路径:选择经认可的 NB、提交申请并完成评估。
  5. 起草并签署 EU 符合性声明(DoC)——包含 Annex V 规定的必需内容。
  6. 加贴 CE 标志——标志须清晰可见、易于辨认且不易磨灭,并贴在产品或包装上。
  7. 自产品投放市场之日起,保留 TD 和 DoC 10 年。

技术文档(Annex VII)必须包含:

  • 产品总体描述及预期用途
  • 设计和开发文档(架构图、威胁模型)
  • 安全风险评估
  • 已实施的网络安全措施
  • 测试报告和合规性证据
  • SBOM(至少列出顶层依赖项)
  • 漏洞处理政策和流程
工作流 4 — 漏洞处理计划

适用场景: 建立或审查漏洞管理和披露计划。

计划要素:

  1. 内部漏洞跟踪——组件和依赖项清单;识别影响产品的新 CVE 的流程。
  2. 协调漏洞披露(CVD)政策——已发布的 VDP;明确指定的联系人;确认接收的时限;负责任披露的预期要求。
  3. 安全更新流程——免费提供安全更新;更新须经签名;用户无法禁用更新机制。
  4. SBOM 管理——至少为顶层开源组件提供机器可读的 SBOM(推荐使用 SPDX、CycloneDX 格式);并保持更新。
  5. 第 14 条报告流程(自 2026 年 9 月 11 日起生效)——建立可通过 ENISA Single Reporting Platform 提交报告的运作流程:24 小时内提交早期预警、72 小时内提交通知,以及最终报告(对于已遭利用的漏洞,在纠正措施可用后 14 天内提交;对于严重事件,在 72 小时通知后 1 个月内提交);通知受影响用户。
  6. 支持期限管理——定义并承诺支持期限(大多数产品至少为 5 年);在支持结束前至少 1 年发布生命周期结束通知。
  7. 第三方组件管理——跟踪集成的开源组件和第三方组件中的漏洞;向上游供应商索取 SBOM。

输出: 提供漏洞处理计划差距评估和建议的计划设计。

工作流 5 — 支持期限和生命周期结束义务

适用场景: 制定支持承诺并规划产品生命周期结束。

支持期限规则:

  • 必须至少为 5 年,若预期产品寿命较短,则按预期产品寿命计算
  • 制造商必须向用户清晰说明支持期限
  • 在整个支持期限内,必须及时免费提供安全更新
  • 更新不得降低产品的安全性或功能
  • 支持结束时:至少提前 1 年通知用户;如可行,提供迁移路径或最终累计安全更新

适用单独的软件组件支持期限时: 集成第三方软件组件的制造商必须确保其产品的支持期限不超过上游提供安全更新支持的期限。


报告现已启用 — 通过 ENISA SRP 履行第 14 条义务(每次回答报告相关问题时均须说明此状态)

自 2026 年 9 月 11 日起,制造商必须报告影响含数字元素产品的已遭主动利用的漏洞和严重事件——包括 2027 年 12 月之前已上市的产品(第 69(3) 条)。时限从知悉时起算(对 9 月 11 日之前已知悉的情况不追溯适用义务)。

阶段已遭利用的漏洞严重事件(第 14(5) 条:影响保护敏感数据/功能的能力,或引入/执行恶意代码)
早期预警知悉后 24h24h
通知 + 初步评估72h72h
最终报告在纠正/缓解措施可用后 ≤14 天在 72h 通知后 ≤1 个月

单一报告平台(SRP)于 2026 年 9 月 11 日上线(ENISA,第 16(1) 条;portal.cra-srp.enisa.europa.eu)。申报流程:指定代表使用 EU Login 账户注册(须启用 MFA),选择主要营业地所在成员国的指定为协调方的 CSIRT(第 14(7) 条;非欧盟级联顺序:授权代表 → 进口商 → 分销商 → 大多数用户),接受法律协议后成为主要 AR(最多可设置 20 名次要 AR)。CSIRT 验证会并行进行——验证完成前最多可提交 20 份通知;ENISA 建议有通知需求时再注册,而非提前注册。通知会发送至 CDaC,并同时发送至 ENISA(特殊例外情形除外,第 16(2) 条;延迟传送规则见授权条例 (EU) 2026/881)。备用方案:如果 SRP 暂时不可用,紧急事项请直接联系指定的 CSIRT,但平台恢复后仍必须通过 SRP 提交通知。上线初期限制:仅支持英语,无 API。配套指南:委员会通告 C(2026) 5252(2026 年 7 月 27 日)和委员会 CRA 常见问题。开源软件管理人自 2027 年 12 月 11 日起承担报告义务(第 24(3)/71(2) 条);CRA 的主要义务(基本要求、CE 标志)也自 2027 年 12 月 11 日起适用。

处罚速查(第 64 条)

违规行为最高处罚
不符合附件 I 基本要求1,500 万欧元或全球年营业额的 2.5%(取较高者)
其他 CRA 义务(第 13–16、23、27、28、31 条)1,000 万欧元或全球年营业额的 2%
向主管机关提供不正确、不完整或误导性信息500 万欧元或全球年营业额的 1%
中小型企业和微型企业使用历史营业额数据;适用比例原则

关键日期摘要

义务适用日期
向 ENISA + CSIRT 报告漏洞/事件2026 年 9 月 11 日 — 已生效;SRP 已上线
指定并运行公告机构2026 年 12 月 11 日
制造商、进口商、分销商的所有义务2027 年 12 月 11 日
已上市产品(过渡期)如未变更,可在 2027 年 12 月 11 日前完成合规

与其他欧盟法规的关系

  • NIS2 指令: NIS2 适用于基本服务/重要服务运营者;CRA 适用于产品制造商。产品可能受 CRA 约束,同时其制造商/运营者也受 NIS2 约束。二者并不冲突,而是相辅相成。
  • GDPR: CRA 附件 I 中的数据最小化和安全要求,与 GDPR 第 25 条(设计阶段保护隐私)和第 32 条(处理安全)相一致。产品必须同时满足两者。
  • 欧盟《人工智能法案》: 嵌入硬件 PDE 中的 AI 系统必须同时遵守《人工智能法案》和 CRA。《人工智能法案》对 AI 特定要求具有优先效力;CRA 涵盖硬件/连接安全层。
  • RED(《无线电设备指令》2014/53/EU): 对于受 RED 网络安全授权法案(第 3(3)(d)(e)(f) 条)约束且同时属于 PDE 的产品,制造商可通过证明符合 RED 来证明部分符合 CRA。预计 ENISA 和欧盟委员会将就这一交叉适用情况发布指南。
  • MDR/IVDR: 医疗器械不在 CRA 适用范围内。不过,单独上市的嵌入医疗器械的软件组件可能在适用范围内。

本技能提供一般性合规信息,不构成法律建议。请对照官方来源核实现行要求;如需作出决策,请咨询合格法律顾问或认可的评估机构。

评论

支持 Markdown