网络漏洞治理与合规应对系列之一： 欧盟《网络弹性法案》（CRA）下数字产品漏洞管理的核心规则与中企应对

引言：为什么从CRA讲起

2024年10月23日，欧洲议会与欧盟理事会正式通过了Regulation (EU) 2024/2847，俗称《网络弹性法案》（Cyber Resilience Act ，以下简称“CRA”）。它于2024年11月20日刊登在《欧盟官方公报》（OJ L），并自2024年12月10日起生效，进入过渡期。

CRA是欧盟首部全域覆盖各类数字产品的网络安全专项立法，对于将欧盟视为关键市场的中国数字产品制造商而言，其重要性已刻不容缓。CRA自2024年12月10日生效并进入过渡期至今已有超过一年半的时间。CRA中被业界高度关注的网络漏洞管理与上报义务，将自2026年9月11日先行实施。剩余其他的义务条款也将于2027年12月11日全面落地施行。该法案所有条款对欧盟各成员国具备完整约束力，在成员国境内可直接适用。 

本文为“网络漏洞治理与合规应对”系列的开篇。本系列将围绕欧盟与中国的网络漏洞管理规则展开横向比较研究，本篇率先聚焦欧盟规则，重点解析CRA构建的漏洞治理义务体系。

一、 CRA的合规框架与主要内容

（一）立法背景

CRA是欧盟首部全域覆盖“带数字元素产品”（products with digital elements，以下简称“数字产品”）网络安全的立法，其立法出台背景与核心考量已在前言部分阐释：网络安全是欧盟面临的核心挑战之一。未来数年，联网设备的数量与品类将呈指数级增长。网络攻击事关公共利益，其不仅会对欧盟经济造成重大影响，还会冲击民主秩序，威胁消费者的人身安全与健康。为此，欧盟亟需完善网络安全治理体系，通过建立统一法律框架，明确数字产品进入欧盟市场必须满足的基础网络安全要求，以此优化内部市场运行秩序¹。

目前有两大问题持续抬高欧盟的用户成本与社会成本，亟待解决：

• 供给侧：联网设备的数量与品类呈指数级增长，但数字产品整体网络安全水准偏低，安全漏洞普遍存在，且配套安全更新服务供给不足、标准不一；

• 需求侧：用户对产品安全信息认知不足、信息获取渠道受限，既难以挑选具备合格网络安全能力的产品，也无法安全地使用产品²。

有鉴于此，CRA旨在解决数字产品的安全问题与信息不对称问题，其核心目标是通过在欧盟成员国之间建立标准基线安全要求和义务，确保数字产品的网络安全。

（二）适用范围与排除情形

CRA规制所有投放于欧盟市场的数字产品。凡是软硬件产品，在预期用途或可合理预见的使用方式下，能够与设备、网络建立直接或间接逻辑或物理数据连接的，均纳入监管范围³。这一范围可涵盖智能家电、监控摄像头、可穿戴设备、网络通信设备、工业传感器、工控模块、联网办公设备、消费电子等多个品类。这一界定，旨在将绝大多数具备联网功能、搭载数字组件的产品，统一纳入网络安全治理体系。

同时，CRA也明确了多项排除适用情形，主要包括三类：

• 行业法规优先适用：医疗器械（Reg (EU) 2017/745、2017/746）、车辆设备（Reg (EU) 2019/2144）、航空（Reg (EU) 2018/1139）与船舶装备（Dir 2014/90/EU）；

• 公共安全与国家安全例外：用于国防和国家安全的专用产品、处理涉密信息的设备；以及

• 结构性排除：按照原厂标准生产的，用于替换同类组件的替换配件⁴。

此外，针对同时受欧盟其他行业法规监管的产品，CRA制定了衔接规则——如若相关行业法规已对网络安全风险设定要求，且能实现与CRA同等或更高保护水平，则CRA的适用可被限制或排除⁵。对中国企业而言，这意味着在判断CRA是否适用时，不能只看产品类别，还要看产品所处行业是否已被专项规制。

特别提示：与欧盟《人工智能法案》（Regulation (EU) 2024/1689）的衔接。CRA第12条规定，被欧盟《人工智能法案》第6条列为“高风险AI系统”且属于CRA范围的产品，如满足CRA的基本网络安全要求（Annex I），即被视为已满足欧盟《人工智能法案》第15条对高风险AI系统的网络安全要求。两法之间形成“一次合规、双重满足”的衔接安排——这对同时受两法管辖的中国企业而言，是合规策略上的重要红利。

（三）主要内容

CRA共8章71条+8个附件，总体搭建起覆盖全链条的数字产品安全监管体系。其中包含四大核心板块：

• 总则：界定监管对象与适用范围，为整部法规筑牢根基；

• 制造商义务：作为核心内容，从源头规范产品安全设计与后续运维服务；

• 产品合规：统一市场准入规则，明确合格评定与认证要求；

• 市场监管：落地监督、抽检及违规处置各项举措。

本文所关注的漏洞管理贯穿了基本要求、制造商义务、上市后报告三个板块：基本要求层面落于Annex I Part II（漏洞处置基本要求）；制造商义务层面落于第13条（一般义务，含支持期）；上市后报告层面落于第14条至第17条（漏洞与严重事件的强制及自愿报告）。三个板块共同构成CRA的漏洞治理义务体系。

（四）罚则概览

CRA并不直接规定罚款金额由欧盟统一执行，而是要求各成员国制定“有效、相称且具有劝阻力”的处罚规则，并设定罚款上限。第64条规定的三个等级如下：

1. 最高1500万欧元或前一财年全球年营业额的2.5%（取高者）：违反Annex I基本要求和第13条、第14条义务，即漏洞处置基本要求与漏洞报告义务的违反位列最严档；

2. 最高1000万欧元或前一财年全球年营业额的2%（取高者）：违反第18-23条（其他经济运营者义务）、第28、30-33条（合格声明、CE标志、技术文档等）、第39、41、47、49、53条等；

3. 最高500万欧元或前一财年全球年营业额的1%（取高者）：向被通知者或市场监管机关提供错误、不完整或具有误导性的信息。

微型企业和小型企业关于第14(2)(a)与14(4)(a)项（24小时早期预警）逾期不适用上述第1款罚则；开源软件管理者（open-source software steward）豁免CRA框架下的行政罚款。但需注意——第1款（针对Annex I与第13、14条）的1500万欧元/2.5%罚则并未对微型、小中型企业整体豁免，仅在罚款裁量上要求考虑企业规模。

从罚则设计逻辑来看，把第14条的违反置于最严档，反映出欧盟将“漏洞与事件的可见性”置于整个数字产品安全治理的核心枢纽位置——某种意义上讲，它构成了整个治理体系的“神经网络”。

二、 CRA对数字产品漏洞管理的强制性要求

如上文提到，漏洞管理是CRA的核心规制内容之一，贯穿数字产品上市后的全生命周期。该项义务规则明确、约束严格，也是中国企业产品出海欧盟需遵守的合规基准线。整体而言，制造商的漏洞管理义务分为三层结构：

第一层：实体义务——产品本身必须“无已知可利用漏洞”上市，且在“支持期”内具备持续的漏洞处置能力（第13条、Annex I Part II）；

第二层：流程义务——必须建立软件物料清单（Software Bills of Materials, SBOM）、协调漏洞披露（Coordinated Vulnerability Disclosure, CVD）政策、单一联系点（Single Point of Contact）等结构性流程（第13条、Annex I Part II）；

第三层：报告义务——对“正在被利用的漏洞”与“严重安全事件”强制上报，对其他漏洞与事件可自愿上报（第14条至第17条）。

本章将着重梳理CRA下中有关产品漏洞管理的报告义务，即第14条至第17条。

（一）通报监管

根据CRA第14条规定，制造商一旦获知其数字产品存在“正在被利用的漏洞”或者“影响数字产品的严重安全事件”时，应当履行通报义务。该条重点规制漏洞及安全事件的强制性上报义务。在此基础上，CRA第15条增设自愿上报机制，明确制造商及其他自然人、法人，均可主动向计算机安全事件响应小组（Computer Security Incident Response Team，以下简称“CSIRT”）或欧盟网络安全局（European Union Agency for Cybersecurity，以下简称“ENISA”⁶）报备各类数字产品安全事件，以及存在诱发同类风险的潜在安全隐患。CSIRT可优先处理强制上报信息，再处理自愿上报信息。若第三方主体主动报备已被实际利用的漏洞或影响产品安全的严重事件，CSIRT须第一时间告知涉事产品所属制造商，督促其知悉并处置相关风险。

（二）触发条件：何为正在被利用的漏洞与严重安全事件

根据CRA第3条第42款，“正在被利用的漏洞”是指有可靠证据表明恶意行为者已在未经系统所有者许可的情况下利用过的漏洞。前言（Recital）第68段解释：此类漏洞的示例包括产品身份验证和认证功能中的弱点。该段进一步说明，出于善意测试、调查、修正或披露以促进系统所有者及其用户的安全或保障目的而发现的、不带有任何恶意意图的漏洞，不适用强制性通报义务。

根据CRA第14条第5款，“严重安全事件”包括：（1）该事件已经或可能对数字产品保护敏感数据、重要数据或核心功能的可用性、真实性、完整性或保密性的能力产生负面影响；或者（2）该事件已经或可能导致在数字产品中，或在数字产品的用户的网络信息系统中引入或执行恶意代码。

关于如何获知漏洞或事件，CRA并未规定制造商如何获知漏洞或严重事件。实务中，“获知”可能来源于客户或合作伙伴报告、威胁情报、安全研究人员或第三方网络安全机构发布的报告、政府网安机构通知、道德黑客（ethical hackers）披露、内部遥测/扫描/蜜罐（即用于诱使网络犯罪分子远离合法目标的安全机制）告警等。值得注意的是，CRA第14(8)条与Annex I Part II（6）已要求建立单一联系点和便于信息共享的措施——这些机制本身就构成“获知漏洞”的法律入口。建议企业将外部威胁情报订阅、CVD邮箱、产品遥测告警与安全运营中心监控统一纳入“漏洞或事件触发矩阵”，对每个入口设定清晰的内部升级路径与时间戳记录。

（三）通报对象与主营地规则

根据CRA第14条第1款规定，制造商应通过单一报告平台（single reporting platform），同时向作为协调员的CSIRT和ENISA通报。第14条第7款规定了通报对象的具体确定规则：

• 若制造商在欧盟有“主营业地”（main establishment）：使用主营业地所在成员国的CSIRT端口。“主营业地”指对其数字产品网络安全相关决策预先作出的成员国；若无法确定，则按欧盟内员工最多的所在地确定；

• 若制造商在欧盟无主营业地（绝大多数中国企业的情形），依以下顺序确定：

（a）由该制造商授权代理数字产品数量最多的授权代表所在的成员国；

（b）进口该制造商数字产品数量最多的进口商所在的成员国；

（c）分销数字产品数量最多的分销商所在的成员国；

（d）该制造商数字产品用户数量最多的所在成员国。

特别提示：对在欧盟没有主营业地的中国企业而言，向哪国CSIRT上报取决于商业链条的分布。这意味着选择哪个成员国的授权代表或主要进口商，将决定企业未来跨境合规对接的端口。语言、监管文化、CSIRT的成熟度——这些都需在选择授权代表/进口商时一并评估。建议企业尽快明确“首选CSIRT”，并据此完成账户注册、技术对接与内部演练。

（四）通报时间

根据CRA第14条第2款以及第14条第4款的规定，一旦产品出现漏洞或严重安全事件，制造商须恪守法定时限，依规完成通报与报告工作。CRA结合事件处置的不同阶段，设定分层报送规则，对各节点所需提交的文书内容逐一明确，详见如下。

• 预警通报（24小时）

漏洞：在获知漏洞被利用后立即报送，最迟不得超过24小时；通报中需列明已知该产品流通的欧盟成员国⁷。

严重事件：在获知严重事件后立即报送，最迟不超过24小时；通报中至少说明事件是否疑似由非法或恶意行为引发，并入适用列明已上架的成员国⁸。

• 专项通报（72小时）

漏洞：若相关信息尚未在前序环节提交，需在获知漏洞被利用后立即报送，最迟不得超过72小时；通报内容包括涉事产品基本信息、漏洞与攻击行为概况、已采取的纠正或缓解措施，以及用户可采取的纠正或缓解措施；同时，如适用，还应说明制造商对所通知信息的敏感程度⁹。

严重事件：若相关信息尚未在前序环节提交，需在获知严重事件后立即报送，最迟不得超过72小时；通报内容包括严重事件的性质、初步评估、已采取的纠正或缓解措施，以及用户可采取的措施；如适用，还应说明信息敏感度评估¹⁰。

• 最终报告（14天/1个月）

漏洞：除非相关信息披露已提供，否则应在纠正或缓解措施可用后的14天内提交最终报告，内容至少包括以下信息：（i）漏洞的描述，包括其严重性和影响；（ii）涉及已利用或正在利用该漏洞的恶意行为者的信息（如有）；（iii）漏洞修复补丁及其他整改措施详情¹¹。

严重事件：除非相关信息披露已提供，否则应自72小时事件通报提交之日起1个月内提交，内容至少包括以下信息：（i）事件详细描述，包括其严重性和影响；（ii）可能引发事件的威胁类型或根本原因；（iii）已实施与正在实施的缓解措施¹²。

• 阶段性进展报告（按实际需要）

漏洞与严重事件：接收上报信息的指定CSIRT，可根据实际需要，要求制造商针对已被利用的漏洞或严重安全事件，提交阶段性进展报告¹³。

（五）通知用户

除上报监管外，制造商一旦察觉漏洞遭利用或突发严重安全事件，须即刻通知受影响用户，必要时须通知全体用户，告知漏洞或事件详情，以及用户可采取的风险缓解、问题修复措施；适当情况下，应采用结构化、机器可读、易于自动处理的格式发布。倘若制造商怠于向用户推送信息，受理上报的CSIRT在恪守比例原则、确有必要控减风险的前提下，可直接面向用户发布相关提示¹⁴。

此外，若为防范、缓解影响数字产品安全的严重事件，或处置正在发生的安全事件，有必要向公众披露信息，或是披露行为符合公共利益，相关成员国的CSIRT可在征询涉事制造商意见后，必要时联合ENISA，向公众通报事件情况，或要求制造商履行公众告知义务¹⁵。

当漏洞修复补丁或其他整改、缓解措施正式上线后，ENISA经涉事数字产品制造商同意，应当将已上报且已公开的漏洞信息，录入依据NIS 2 Directive¹⁶第12条第2款设立的欧洲漏洞数据库（European vulnerability database）¹⁷。

特别提示：如果中国企业未及时通知用户，CSIRT直接向用户发布信息可能引发连锁后果。一是品牌与舆情风险（被外国监管机关“代行通知”暴露了内部响应失能）；二是可能与中国《网络产品安全漏洞管理规定》下的国内披露义务在时间窗口上不同步。建议企业在建立内部通知流程时，将欧盟的通知义务与中国的报送义务协同考虑，避免时间窗口错位。

（六）延迟通报

如遇特殊情形，尤其是应制造商要求，且结合制造商依据CRA第14条第（2）款第（a）项标注的信息敏感程度，可基于正当网络安全理由延迟上报。延迟时长应严格限定在必要范围内。若CSIRT决定暂缓通报，应当立即将该决定、暂缓理由以及预计上报时间告知ENISA，并遵守相应的上报流程。ENISA可就延迟上报的网络安全适用理由，为CSIRT提供协助¹⁸。注意，延迟通报的规范对象是CSIRT接收后向其他CSIRT分发，而不是制造商向CSIRT上报。也就是说，制造商对CSIRT的通报义务并不因此放宽，放宽的是该信息向其他成员国扩散的速度。

若逢极端特殊情形，且制造商在上报材料中注明以下情况：（i）上报漏洞已遭恶意主体利用，且根据现有信息，仅在接收本次上报的CSIRT所属成员国境内被利用；（ii）立即全面通报该漏洞信息的行为可能会损害该成员国核心重大利益；（iii）进一步扩散该漏洞信息会即刻引发高等级网络安全风险。则在向CSIRT及ENISA完整推送上报信息前，仅可同步向ENISA披露以下内容：制造商已提交上报、涉事产品概况、攻击行为基本特征，以及本次上报申请延迟通报的相关情况。倘ENISA经研判认为该隐患将对欧盟统一市场形成系统性风险，则可督促制造商提交全部上报资料¹⁹。

三、 CRA对中企出海的影响及合规建议

深耕欧盟市场的中国企业，需全面正视CRA带来的合规挑战。企业应当先界定产品监管归属，再严格恪守事件上报、风险披露等各项规制，合理管控上报流程。对外维系好与监管机构的常态化对接，对内搭建好完备的合规体系，持续完善风险应对能力。相关实施要点详述如下。

• 判断其是否落入CRA管辖范围之内：CRA监管辐射范围极广，基本覆盖所有投放欧盟市场的联网软硬件与数字产品，囊括消费电子、智能家居、工控设备、嵌入式软件等常见品类。CRA同时明确法定豁免范畴，医疗器械、车载设备、航空与船舶装备、国防安全专用产品、涉密设备及原厂替换备件等品类，可依法排除适用。除此之外，若行业专项法规已设立同等乃至更高标准的安全规制要求，亦可酌情限制或豁免CRA适用效力。对出海中资企业而言，首要核心工作即是精准完成产品合规定性、厘清自身监管归属，一旦确认落入CRA监管范畴，企业即成为合规第一责任人，自产品入市欧盟伊始，须全面恪守漏洞治理、事件上报等全链条法定义务。

• 确定欧盟入口、授权代表、进口商与首选CSIRT：对于在欧盟无主营业地的中企（绝大多数情形），主营地确定规则使授权代表与进口商的选择具有确定监管地的意义。建议企业尽快确认欧盟授权代表、主要进口商，并据此确定首选协调员CSIRT，完成单一报告平台账户注册、技术对接与首次演练。

• 建立漏洞或事件获知矩阵：将外部威胁情报、CVD邮箱、产品遥测告警、客户支持工单、安全研究人员沟通等所有可能的漏洞或事件“入口”统一企业的漏洞或事件获知矩阵；为每一条记录设定原始时间戳、初判类型（普通漏洞/可利用漏洞/正在被利用的漏洞/严重事件）与升级路径。这是通报时限可追溯的法律基础。

• 建立软件物料清单（SBOM）、协调漏洞披露（CVD）政策、单一联系点等结构性流程：建立SBOM生成与维护流程、明确SBOM内部访问权限与对外披露策略；制定并对外发布CVD政策，明确单一联系点、报告渠道、响应承诺等。CVD政策应同时考虑《网络产品安全漏洞管理规定》等相关法规项下中国境内报告人的接收路径，避免出现“对外接收口径与对内合规口径不一致”的情形。

• 严格执行分级限时上报规则：产品出现被利用漏洞或严重安全事件，需通过单一报告平台向CSIRT与ENISA上报，严守24小时预警通报、72小时专项通报、14天（或1个月）的最终报告的时效红线，同时配合监管要求提交阶段性进展报告。

• 规范上报与延迟处置管理：企业需明晰强制上报与自愿上报的适用边界，尤其需重视第三方举报场景，外部主体上报的漏洞与安全事件，将直接触发企业法定处置义务。针对特殊网络安全场景，企业虽可依规申请延迟上报，但该权限约束极严，仅可基于正当安全理由申请，且需同步向ENISA报备暂缓缘由与预计报送时限；极端特殊情形下的极简报备机制更需审慎适用，严禁随意拖延上报、滥用合规豁免权限。

• 嵌入漏洞协同条款：在与上游组件供应商、下游分销商、授权代表、进口商的合同中嵌入合规协同条款，明确漏洞双向通报与协作修复、安全更新分发的时限、信息保密与监管协助、罚则后果分配、技术文档保存与配合义务。

• 落实用户与公众披露义务：漏洞或安全事件发生后，企业须第一时间面向受影响用户同步事件详情、风险缓释方案与修复举措，主动履行告知义务。若企业履职滞后、处置迟缓，未能及时完成用户通知，对应监管机构可径直对外公开事件信息，从而可能损害企业海外品牌口碑，滋生舆情风险。

• 建立官方常态化对接机制：企业需主动对接ENISA、产品流通地成员国CSIRT及各国市场监管部门，跨境安全事件需配合多国监管协同处置，接收常态化合规核查与抽检。

• 搭建内部合规体系：设立专项响应小组，明确合规、技术、海外对接、应急处置专职岗位，固定对外对接人；制定漏洞分级处置、跨境上报、延迟审批、信息披露全套内部制度，实现流程标准化、留痕化。企业需针对性组建CRA专项应急响应团队，厘清合规审核、技术研判、海外对接、应急处置等岗位职责，固定专属对接人。同时构建覆盖漏洞分级研判、跨境上报审批、延迟上报管控、信息对外披露的全流程内部制度，推动各项合规动作标准化、流程化。

• 常态化演练与产品优化：企业需将CRA合规要求前置融入产品研发、设计、迭代流程中，从源头降低风险。同时常态化开展漏洞处置、跨境上报、用户告知全流程应急演练，持续完善漏洞补丁推送与产品上市后运维服务能力。

四、 结语与本系列后续看点

CRA的合规已迫在眉睫。中企无论在欧盟业务规模如何，都需要尽快完成网络漏洞管理与上报的体系制度建设。我们希望本系列能够帮助企业在条文之外看到“机制”，在合规之外看到“机会”——把强制性义务转化为长期产品竞争力的过程，本身就是中国数字产品在全球市场中持续向上的过程。

在本系列后续文章中，我们将依次展开：中国网络产品安全漏洞监管体系全景介绍、中国《网络产品安全漏洞管理规定》专项解读，以及中欧网络漏洞管理的横向比较研究。敬请期待。

[1] 参见CRA前言部分第1-2段。

[2] 参见CRA前言部分第1-2段。

[3] 参见CRA第2条第1款。

[4] 参见CRA第2条第2、3、4、6、7款。

[5] 参见CRA第2条第5款。

[6] ENISA的旧称为European Network and Information Security Agency，因此缩写为ENISA。即便后续更换名称为European Union Agency for Cybersecurity，缩写仍沿用了ENISA。

[7] 参见CRA第14条第2款a项、第14条第4款a项。

[8] 参见CRA第14条第4款a项。

[9] 参见CRA第14条第2款b项、第14条第4款b项。

[10] 参见CRA第14条第4款b项。

[11] 参见CRA第14条第2款c项、第14条第4款c项。

[12] 参见CRA第14条第4款c项。

[13] 参见CRA第14条第6款。

[14] 参见CRA第14条第8款。

[15] 参见CRA第17条第2款。

[16] NIS 2 Directive全称为Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)

[17] 参见CRA第17条第5款。

[18] 参见CRA第16条第2款。

[19] 参见CRA第16条第2款。

声 明

《君合法律评论》所刊登的文章仅代表作者本人观点，不得视为君合律师事务所或其律师出具的正式法律意见或建议。如需转载或引用该等文章的任何内容，请注明出处。未经本所书面同意，不得转载或使用该等文章中包含的任何图片或影像。如您有意就相关议题进一步交流或探讨，欢迎与本所联系。