适用时区：亚洲/新加坡；撰写日期：2025-10-23。文中涉及的日期与里程碑已按官方来源逐一核验。
什么是 CRA —— Cyber Resilience Act
CRA 是欧盟的一部横向网络安全法规，中文可译作 网络复原力法。它要求所有带数字元素的产品在全生命周期里满足强制性的网络安全要求，覆盖设计、开发、生产、投放市场、维护到退市等环节，属于直接适用于成员国的 欧盟法规，无需各国再立法转置。欧盟委员会明确：CRA 于 2024-12-10 生效，大部分义务自 2027-12-11 起适用；其中漏洞与严重事故的通报义务更早生效，自 2026-09-11 起执行。(Digital Strategy)
为了让产业在统一框架下合规，CRA 与 NIS 2、EUCC 等既有制度协同运作，目标是减少软件与硬件产品中的普遍性漏洞、提高更新透明度、统一合规路径、并允许使用 CE 标志 来表明符合性。(Consilium)
适用范围与对象
产品与数字元素 PDE 的定义非常宽，包括可直接或间接连接其他设备或网络的软件与硬件，以及其由制造商提供、用于实现核心功能的远程数据处理。这不仅涵盖传统 IoT 设备，也囊括纯软件与混合形态产品。(EUR-Lex)
对象角色主要有：制造商、进口商、分销商与授权代表。不同角色承担的合规义务不同，但都围绕本质安全要求、技术文件、符合性评估与市场监督展开。(EUR-Lex)
时间线与关键里程碑
- 2024-10-10：欧盟理事会通过文本。(Consilium)
- 2024-11：官方公报发布
Regulation (EU) 2024/2847正文。(EUR-Lex) - 2024-12-10：法规生效，进入过渡期。(Digital Strategy)
- 2026-06-11：市场监督与通用执行框架章节先行适用。(EUR-Lex)
- 2026-09-11：制造商的漏洞与严重事故通报义务开始实施，并接入 ENISA 的单一通报平台。(EUR-Lex)
- 2027-12-11：其余主体义务全面适用；不合规产品不得进入欧盟市场。(Digital Strategy)
对开源的特别安排：谁在范围内，谁被豁免
业界最关心的是开源是否被强制纳入。CRA 的最终文本采用风险与商业性并重的划分：
- 非商业性开源的开发与供给（例如个人或非营利组织无变相变现地发布的开源软件）不视为商业活动，不落入制造商义务。(EUR-Lex)
- 为确保生态稳健，文本引入**
开源软件管理者open-source software steward的轻量监管机制**：若其持续支持一个最终用于商业活动的开源产品的开发，例如托管社区、治理项目或接受稳定赞助以保障发布连续性，则需履行比制造商更轻的定制化义务，尤其是与通报协作相关的部分。(EUR-Lex) - 多家研究与社区解读指出：未货币化的开源开发者原则上无 CRA 直接义务；但向商业集成方供件时，建议提供漏洞披露渠道与安全版本公告以协助下游合规。(LWN.net)
这套设计兼顾了非商业开源的活力与商业化产品的用户安全，也回应了早期草案阶段社区的广泛意见。(cnll.fr)
合规要求的四根支柱
1) 本质安全要求与工程实践
制造商需要证明产品在设计与开发阶段就落实安全，包括威胁建模、安全更新机制、默认安全配置、漏洞处理流程与供应链尽职调查等，并在维护期内持续提供安全更新与支持周期信息。欧盟文件明确了通过协调标准或公共规范来推定符合性的路径，未来 EUCC 等证书也可提供符合性推定。(EUR-Lex)
2) 分级与评估
法规按风险将产品划为一般、重要 Class I/II与关键 critical类别，越高等级越可能需要第三方评估或甚至强制欧盟网络安全认证。例如防火墙与入侵检测/防御属于 重要产品，通常需要更严格的评估。(EUR-Lex)
3) 漏洞与事故的强制通报
自 2026-09-11 起，制造商必须通过 ENISA 的单一通报平台在紧急时限内报告被主动利用的漏洞与对产品安全造成影响的严重事故；国家 CSIRT 协调员会在平台内跨国分发信息，并在必要时协调延后公开披露，以配合协同漏洞披露 CVD。(EUR-Lex)
4) 市场监督与处罚
各国市场监督机构可组织联合执法与飞检 sweeps，对形式不合规如 CE 标志、符合性声明 与 技术文档 缺失的产品直接纠正或召回。罚则上限按条款区分：对违反本质安全要求与通报义务的最高可至一千五百万欧元或全球年营收 2.5%，以较高者为准；对其他义务为一千万欧元或 2%。值得注意的是：微型与小型企业在** 24 小时早期通报时限超时时不适用行政罚；开源软件管理者对任何违规不适用**行政罚。(EUR-Lex)
对企业工程团队意味着什么
- 产品路线图需要引入安全需求与支持周期的显式承诺，并可通过协调标准与欧盟认证来获取符合性推定。(EUR-Lex)
- 应急响应必须接入单一通报平台与国家 CSIRT 的流程，确保在被动利用与严重事故场景下能及时、完整地上报。(EUR-Lex)
- 开源治理方面：若你是未货币化的上游，一般无 CRA 直接义务；但若你属于开源软件管理者并服务于商业集成，应具备轻量合规能力，例如安全通报窗口、版本安全通报、基础清单。(EUR-Lex)
一个真实世界的落地蓝图
设想一家在欧盟销售的 智能门锁 厂商，同时在固件中集成了 开源加密库。为了符合 CRA：
- 在设计阶段，固件团队把更新与回滚、密钥保护、最小权限等纳入安全需求；供应链侧要求开源库提供安全通告渠道与版本签名记录。(EUR-Lex)
- 在发布阶段，生成技术文档，完成风险分级与必要的符合性评估，并在包装与文档上加贴
CE 标志与符合性声明链接。(EUR-Lex) - 在运营阶段，接入 ENISA 单一通报平台 的对接流程；一旦发现被利用的漏洞，同时通知国家 CSIRT 协调员与 ENISA，并在修复可用后把已公开的漏洞加入欧洲漏洞库。(EUR-Lex)
工程示例：最小可运行的 CRA 就绪 漏洞与合规素材生成器
说明：下面是一个可独立运行的
Python 3小工具。它不联网，用于模拟 CRA 所需的三类产出： a) 合规声明模板EU_Declaration_of_Conformity.md， b) 安全支持与更新策略Security_Support_Plan.md， c) 漏洞与事故的早期通报草稿Early_Notification.yaml。 你可以把它纳入CI，在构建时自动更新版本号与哈希。代码避免使用英文双引号，全部使用单引号。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# CRA minimal artifacts generator: DoC, Support Plan, Early Notification (offline)
# Usage: python cra_min_gen.py --name SmartLock-X --version 1.2.3 --support-years 5
import argparse, hashlib, json, os, textwrap
from datetime import datetime, timezone
def sha256_of_file(path):
h = hashlib.sha256()
with open(path, 'rb') as f:
for chunk in iter(lambda: f.read(65536), b''):
h.update(chunk)
return h.hexdigest()
def write(path, content):
os.makedirs(os.path.dirname(path) or '.', exist_ok=True)
with open(path, 'w', encoding='utf-8') as f:
f.write(content)
def gen_doc(name, version, support_years, artifacts):
now = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%SZ')
lines = f'''# EU Declaration of Conformity for CRA
产品名称: {name}
产品版本: {version}
生成时间: {now}
## 制造商声明
我们声明上述带数字元素的产品在设计与开发阶段已采取适当的网络安全措施, 并在维护期内提供安全更新。
## 参考与符合性路径
- 采用风险导向的安全工程与供应链尽调
- 技术文件与测试记录见附件列表
## 附件清单与校验
'''
for label, path in artifacts.items():
digest = sha256_of_file(path) if os.path.exists(path) else 'N/A'
lines += f'- {label}: {path} sha256={digest}\n'
return lines
def gen_support_plan(name, version, support_years):
return textwrap.dedent(f'''
# Security Support Plan
产品: {name} 版本: {version}
支持周期: 发布日起至少 {support_years} 年
覆盖范围: 安全缺陷修复、紧急缓解配置、公告与版本升级路径
更新策略:
- 严重等级为高或被主动利用时, 目标在 72 小时内提供缓解或修复版本
- 提供历史版本的安全支持窗口与退役时间表
- 建立公开的安全公告与版本哈希列表
''')
def gen_early_notification(name, version, cve='CVE-XXXX-YYYY', severity='high'):
now = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%SZ')
# 以 YAML 便于提交到内部工单或自动转报 ENISA 平台前的网关
return textwrap.dedent(f'''
type: actively_exploited_vulnerability
product_name: {name}
product_version: {version}
cve: {cve}
severity: {severity}
detected_at: {now}
impact_summary: |
远程未授权攻击者可绕过认证导致设备被接管, 存在供应链扩散风险。
temporary_mitigation: |
立即关闭远程调试端口, 启用严格的最小权限策略, 并限制管理接口来源地址段。
planned_fix:
eta: 72h
channel: ota
contact:
cert_contact: security@example.com
pgp: https://example.com/pgp.txt
disclosure_coordination:
follows_cvd: true
public_advisory_after_fix: true
''')
if __name__ == '__main__':
ap = argparse.ArgumentParser()
ap.add_argument('--name', required=True)
ap.add_argument('--version', required=True)
ap.add_argument('--support-years', type=int, default=5)
ap.add_argument('--artifact', action='append', default=[], help='label=path')
args = ap.parse_args()
artifacts = {}
for pair in args.artifact:
if '=' in pair:
k, v = pair.split('=', 1)
artifacts[k.strip()] = v.strip()
write('EU_Declaration_of_Conformity.md', gen_doc(args.name, args.version, args.support_years, artifacts))
write('Security_Support_Plan.md', gen_support_plan(args.name, args.version, args.support_years))
write('Early_Notification.yaml', gen_early_notification(args.name, args.version))
print('生成完成: EU_Declaration_of_Conformity.md, Security_Support_Plan.md, Early_Notification.yaml')
如何试跑：把上述脚本存为 cra_min_gen.py，并准备任意二进制或构建产物文件作为附件测试，例如 firmware.bin。在终端执行：
python3 cra_min_gen.py --name SmartLock-X --version 1.2.3 --support-years 5 --artifact firmware=firmware.bin --artifact sbom=sbom.spdx
它会在当前目录生成三份合规素材，支撑你在 CE 标志 与平台通报之前的内部流程演练。
工程要点清单 CRA Ready Checklist
- 威胁建模与默认安全：把安全需求前置到
PRD与设计评审。(EUR-Lex) - 供应链尽调：对第三方组件执行安全更新历史检查与漏洞库比对，保留证据。(EUR-Lex)
- 支持期承诺：在文档与门户上公布安全支持年限与退役计划。(EUR-Lex)
- 文档与符合性：准备技术文件、符合性声明与使用说明，为市场监督与联合飞检做好材料。(EUR-Lex)
- 通报接入：串联
SOC、PSIRT与 ENISA 单一通报平台 的流程，明确谁在** 24 小时**内收集信息并提交。(EUR-Lex) - 开源策略：未货币化的上游可明确声明非商业、提供披露渠道；若担任开源软件管理者且面向商业生态，配备轻量合规组件。(EUR-Lex)
常见误解与澄清
所有开源都要背锅？不对。最终文本明确非商业开源开发与供给不按商业活动处理，不触发制造商义务；对开源软件管理者也仅施加有限且定制化的要求，并且不适用行政罚。(EUR-Lex)我们到 2027-12-11 再忙也不迟？不对。通报义务与部分监督机制将在 2026 年提前启用，企业需要在 2026 年前搭建流程与接口。(EUR-Lex)没拿证书就一定不合规？并非如此。法规允许通过协调标准或公共规范获得符合性推定；在某些关键产品类别上，欧盟可能通过授权法案引入强制认证。(EUR-Lex)
进一步阅读与权威来源
- 欧盟数字战略页面：生效与全面适用日期、专家组信息。(Digital Strategy)
- 欧盟公报
Regulation (EU) 2024/2847正文：第 71 条 生效与适用时间、第 14 条 通报、第 64 条 罚则等。(EUR-Lex) - 欧盟理事会新闻通告：通过背景与
CE 标志。(Consilium) - ENISA 实施解读：分级、与
EUCC的衔接。(certification.enisa.europa.eu) - 开源生态解读与学术研究：非商业开源豁免与开源管理者定位。(LWN.net)
收尾建议：把 合规 变成 工程能力
将 CRA 看成一次推动工程系统化安全的契机，而非仅仅是合规负担。把产品安全路线图、开源治理、事件通报链路与证据留存做成可自动化、可审计的流水线，意味着当你为欧盟市场做足准备时，也在顺带提升了全球用户的信任与安全体验。这正是 CRA 的初心：把复原力落到产品与过程的每一处可验证的细节上。(European Cyber Resilience Act)
小结标题：从法律到代码：Cyber Resilience Act 在工程团队里的 360° 可执行方案
