欧盟《网络韧性法案》（CRA）深度解读：漏洞报告义务与企业合规全攻略

EUCYBERRESILIENCEACT·REGULATION(EU)2024/2847欧盟《网络韧性法案》深度解读与合规全攻略聚焦9月11日启动的漏洞报告义务从产品判定到合规落地的完整行动指南2026年9月·政策解读专题第14条·漏洞与事件报告目录CONTENTS·六大模块系统解读01CRA法案概述立法背景、目标、时间线与监管体系02适用范围与产品分类带数字元素产品判定、三级分类与角色03漏洞报告义务详解第14条、SRP平台、24/72小时报告机制04企业合规准备产品清单、漏洞发现、研判与决策流程05全面合规与处罚基本安全要求、CE认证、透明度与处罚06合规路线图与建议2026-2027行动清单、误区与展望01CRA法案概述立法背景·核心目标·实施时间线·监管体系Regulation(EU)2024/2847·欧盟首部横向网络安全法规什么是《网络韧性法案》（CRA）《网络韧性法案》（CyberResilienceAct，CRA）是欧盟于2024年12月10日正式生效的首部针对含数字元素产品的横向网络安全法规，法规编号为Regulation(EU)2024/2847。它要求所有将硬件、软件及远程数据处理解决方案投放欧盟市场的制造商，确保产品在设计、开发、生产和维护全生命周期内达到适当的网络安全水平。核心定位：从"事后响应"转向"默认安全"，将网络安全要求嵌入产品设计与上市前合规流程，覆盖从消费级IoT到工业控制系统的广泛产品类别。欧盟委员会总部·比利时布鲁塞尔立法背景与四大核心目标随着IoT设备爆发式增长和供应链攻击频发，欧盟数字单一市场面临日益严峻的网络安全威胁，CRA应运而生。01提升产品网络安全水平确保产品在设计和开发阶段即具备适当的网络安全属性，减少已知可利用漏洞。02统一欧盟市场规则建立统一的网络安全要求和合格评定程序，消除成员国间法规碎片化。03增强漏洞与事件透明度建立强制漏洞报告机制，让监管机构和用户及时获知安全风险。04保护用户与数字单一市场保障消费者和企业用户安全，维护欧盟数字单一市场的信任与稳定。立法动因：全球IoT设备数量预计2030年超290亿台，其中大量设备存在安全漏洞；供应链攻击（如SolarWinds、Log4j）暴露了软件组件安全的系统性风险。CRA实施时间线：三个关键节点2024.12.10法案正式生效Regulation(EU)2024/2847进入实施过渡期法规文本正式生效，开始36个月过渡期。企业可在此期间进行合规准备。2026.09.11漏洞报告义务启动第14条报告义务正式适用，SRP平台上线首个强制合规里程碑。制造商须24小时内报告已被主动利用的漏洞和严重事件。2027.12.11全面强制执行全部条款适用，CE标志强制，处罚启动所有新产品必须符合基本安全要求，加贴CE标志才能上市。违规可处最高1500万欧元罚款。当前位置：2026年9月11日，漏洞报告义务已正式生效。距离全面强制执行仅剩约15个月，企业需立即启动合规建设。监管机构体系：多层协作网络欧盟委员会EuropeanCommissionENISA欧盟网络安全局·运营SRP市场监管机构MarketSurveillanceAuthorities协调CSIRT制造商主要营业地所在国CSIRT，负责接收报告并协调分发成员国CSIRT网络各成员国至少一个国家CSIRT，纳入欧盟CSIRTs网络协同响应信息转交与协同CSIRT（ComputerSecurityIncidentResponseTeam）即计算机安全事件响应团队，源于NIS指令并由NIS2强化，负责漏洞信息处理、攻击事件分析、跨组织协同和重大事件应急响应。02适用范围与产品分类产品判定·三级分类·适用例外·供应链角色ProductswithDigitalElements(PDEs)·第2条、第3条什么是"带数字元素的产品"（PDEs）CRA第3条将"带数字元素的产品"定义为：任何软件或硬件产品及其远程数据处理解决方案，其预期用途或可合理预见的用途包含与设备或网络的直接或间接数据连接。典型覆盖范围类别典型产品硬件产品笔记本、手机、网络设备、IoT设备、工业控制系统、芯片软件产品操作系统、应用程序、移动App、游戏、软件库与组件远程处理与产品相关的云端数据处理、SaaS服务组件单独组件单独上市的硬件组件和软件组件均纳入监管智能家居IoT设备均属CRA监管范围适用对象三要素判定法产品是否落入CRA管辖，需同时满足以下三个条件，缺一不可：01带数字元素产品包含软件、固件或硬件，能够处理、存储或传输数字数据。纯机械产品不适用。02可直接或间接连接有线、无线、蜂窝网络均算；通过配对网关间接联网也纳入。完全离线且无数据接口的产品不适用。03以商业活动提供在欧盟市场销售、赠送换取市场曝光、或搭硬件卖订阅等商业行为。个人非商业项目不适用。三要素同时满足=落入CRA监管范围，无论制造商总部位于何处产品三级分类体系与合规路径等级法规位置典型产品合规评估路径默认类不在附件III/IV存储芯片、移动App、智能音箱、电脑游戏、普通消费IoTModuleA自我评估，无需公告机构参与重要类附件III操作系统、防病毒软件、路由器、防火墙、密码管理器、VPN客户端、家用安防摄像头适用协调标准可自评；无标准时须公告机构第三方评估关键类附件IV智能卡、支付设备、身份认证设备、高安全级别的网络设备强制欧洲网络安全认证，按指定保障等级通过认证方案分类决定合规成本与周期：关键类产品需提前6-12个月启动认证流程不在范围内的产品与适用例外明确排除的产品类别非商业活动产品：个人爱好项目、非商业开源项目独立服务：不与具体产品绑定的纯服务已被专项法规覆盖的产品：·医疗器械（MDR）·航空产品（EASA法规）·机动车（UNR155/R156）·欧盟公共部门机构自用产品传统金融服务产品：受金融监管覆盖的领域国家安全相关设备：用于国防、公共安全的专用设备开源软件的特殊安排轻触监管原则（Light-touch）：·非商业开源项目本身不适用CRA·不得对开源软件加贴CE标志·开源贡献者不因贡献代码承担制造商责任但需注意：·企业将开源软件纳入商业产品销售时，该企业作为制造商需承担CRA义务·以开源为核心的商业发行版（如付费支持的Linux发行版）属于商业活动，需合规·企业仍需管理开源组件的漏洞并维护SBOM即使产品被专项法规覆盖，其未被覆盖的数字元素安全要求仍可能适用CRA供应链经济运营商角色与责任制造商Manufacturer·设计开发安全产品·履行漏洞处理义务·24小时漏洞报告·技术文档与SBOM·合格评定与CE标志·安全更新支持·用户信息告知授权代表AuthorisedRepresentative·非欧盟制造商必须指定·保存合规声明与技术文档10年·配合监管机构调查·提供产品信息与文档·协助制造商履行义务·可承担额外约定任务进口商Importer·核实制造商已合规·确认合格评定已完成·检查CE标志与文档·确保产品标签正确·发现不合规须采取纠正·记录供应链追溯信息分销商Distributor·尽到应有的注意义务·核查CE标志与随附文件·确保存储运输不影响合规·发现风险须采取行动·配合监管机构调查·保存追溯记录10年非欧盟制造商必须在欧盟境内指定授权代表，否则产品不得进入欧盟市场03漏洞报告义务详解第14条·SRP平台·24/72小时机制·分阶段报告Article14·2026年9月11日正式适用第14条报告义务总览制造商发现产品存在正在被积极利用的漏洞或发生严重网络安全事件后，须通过欧盟单一报告平台（SRP）履行报告义务。关键原则：不是所有漏洞都要报告。CRA重点关注已被主动利用的漏洞，而非所有新发现的漏洞。无论漏洞危急程度如何，只要已被实际利用，均必须上报。两类需报告的情形情形一：已被主动利用的漏洞攻击者已在真实环境中利用该漏洞入侵产品。需通过日志、威胁情报、事件响应等证据确认"已被利用"状态。情形二：严重网络安全事件影响产品安全的严重事件，如认证功能被绕过、安全更新链接被劫持等。不必等到实际被利用即可上报。报告机制：一次提交·统一分发·分阶段报告（24小时预警→72小时完整通知→最终报告）什么是"已被主动利用的漏洞"这是企业最需要建立能力的地方——区分"漏洞存在"、"可被利用"和"已被利用"三个不同阶段。阶段A：漏洞发现安全研究人员发现某IoT产品存在命令注入漏洞，并提交给厂商。这是漏洞发现，还不是CRA意义上的主动利用。阶段B：可利用性证明研究人员制作PoC，证明该漏洞可以实现远程代码执行。这仍然是可利用性证明，尚未触发报告义务。阶段C：已被利用厂商在日志、威胁情报或事件响应中发现攻击者利用该漏洞入侵产品。进入CRA关注范围，必须上报。核心判断标准：是否有证据表明攻击者已在真实环境中利用该漏洞实施了攻击。证据来源包括：产品日志分析、威胁情报订阅、蜜罐捕获、客户事件报告、CISAKEV等已知被利用漏洞目录。"主动利用"研判能力建设要点企业需建立多源证据采集与交叉验证机制，快速判定漏洞是否进入真实攻击阶段。四大证据来源证据来源说明产品日志设备端日志、云端日志中出现利用特征、异常请求模式、成功入侵痕迹威胁情报商业威胁情报源、CISAKEV目录、行业ISAC共享信息蜜罐与传感器部署蜜罐捕获真实攻击流量，分析攻击载荷与利用手法客户事件客户报告的安全事件、SOC分析确认的入侵行为研判流程与时间要求T+0：漏洞信息进入研判队列，安全分析师启动调查T+12h：完成多源证据交叉验证，初步判定是否已被利用T+18h：管理层决策确认，法务审核报告内容T+24h：必须通过SRP提交早期预警（硬性截止）建议企业将研判流程压缩至18小时内完成，预留6小时用于报告撰写与审批什么是"严重网络安全事件"CRA不仅要求报告已被利用的漏洞，还要求报告影响产品安全的严重事件。这类事件不必等到实际被利用即可上报。严重事件的判定标准（满足任一即触发）影响产品安全属性事件已经或可能影响产品保护重要数据或功能的机密性、完整性、真实性、可用性。恶意代码进入或执行事件已经导致或可能导致恶意代码进入产品或在产品中执行。典型严重事件示例事件类型具体场景认证功能被绕过产品安全认证机制存在缺陷或被攻击绕过，导致未授权访问更新链路被劫持产品安全更新分发链接被劫持，可能推送恶意固件或软件单一报告平台（SRP）CRA建立了"一次提交、统一分发"的报告机制。制造商通过欧盟单一报告平台（SingleReportingPlatform，SRP）提交报告，无需分别向多个成员国监管机构重复报告。SRP关键信息运营方：ENISA（欧盟网络安全局）负责建设与运营上线时间：2026年9月11日正式投入运行核心功能：统一入口提交、自动路由分发、状态跟踪当前状态：功能与安全测试阶段，企业应提前熟悉平台界面SRP是欧盟数字单一市场的统一网络安全报告入口报告链路与CSIRT协作体系制造商发现事件并提交报告SRP平台ENISA运营·统一入口协调CSIRT制造商主要营业地所在国CSIRT同时提供给ENISAENISA欧盟网络安全局产品在其他成员国提供时，协调CSIRT负责转交受影响成员国CSIRTA产品销售覆盖国受影响成员国CSIRTB产品销售覆盖国报告链路总结：制造商→SRP→协调CSIRT（制造商主要营业地所在国）+ENISA→其他受影响成员国CSIRT。协调CSIRT负责信息转交，形成制造商、SRP、ENISA、协调CSIRT及其他成员国CSIRT之间的完整报告链路。第一阶段：24小时早期预警制造商意识到发生主动利用漏洞或严重事件后，24小时内必须提交早期预警。这一阶段不要求企业已调查清楚，重点是尽快让监管和CSIRT知道："出事了，且可能正在影响产品安全。"早期预警应包含的核心信息序号信息项说明1事件类型主动利用漏洞/严重网络安全事件2受影响产品产品名称、型号、版本、受影响的欧盟成员国3已知影响漏洞或事件的性质、已观察到的影响范围4已采取措施企业已实施的缓解措施、用户指导建议计时起点：制造商"获知"事件之时，而非漏洞被发现之时。信息不完整不构成延迟报告的理由。第二阶段：72小时完整通知在24小时早期预警之后，72小时内提交主要/完整通知。此时应提供更多已确认的信息，企业实际上只有很短的时间完成第一轮技术研判。完整通知需补充的信息漏洞/事件详细描述漏洞技术细节、攻击向量、CVSS评分、CVE编号（如有）影响评估受影响用户数量、数据泄露情况、业务影响范围缓解与修复措施已发布的安全更新、临时缓解方案、用户操作指引后续计划修复时间表、进一步调查计划、与监管机构的沟通安排第三阶段：最终报告两类事件的最终报告期限不同，需特别注意区分。主动利用漏洞14天内从纠正或缓解措施可用之日起计算严重网络安全事件1个月内从72小时完整通知提交之日起计算最终报告应包含的完整内容·事件的完整时间线与根因分析·漏洞的技术细节与根本原因·已采取的所有纠正和缓解措施及效果评估·受影响产品与用户的完整清单·lessonslearned与防止复发的改进措施信息延迟披露机制2025年12月11日，欧盟委员会通过授权法案，明确了CSIRT可延迟向其他CSIRT和ENISA分发报告信息的情形。三种可延迟分发的理由信息性质报告信息的性质经评估后认为应暂缓分发，例如漏洞细节可能被用于制造攻击工具。保密性接收CSIRT无法保证信息将被安全保管，存在泄露风险时可暂缓分发。平台完整性单一报告平台的完整性或安全性存在问题，可能影响信息安全传输。关键规则：延迟分发由最初接收通知的CSIRT决定，而非制造商。一旦有效的风险缓解措施（如安全更新）可用，CSIRT应立即分发通知。延迟期限不得超过必要时间。04企业合规准备产品清单·漏洞发现·研判能力·决策流程·SBOM从"漏洞发现"到"法规报告"的完整运营体系建设准备一：建立CRA产品清单没有产品清单，就无法判断一个漏洞到底是否需要报。这是所有合规工作的基础，必须首先完成。每个产品应建立的唯一标识信息信息项具体内容产品基本信息产品名称、型号、版本、SKU编号软件/固件版本当前发布版本、历史版本、各版本支持状态市场覆盖产品投放的欧盟成员国清单、销售渠道制造商信息制造商及欧盟主要营业地、授权代表信息责任人产品安全负责人、漏洞响应联系人、7x24联系方式组件清单产品包含的软件和第三方组件（关联SBOM）建议建立动态更新的产品资产库，与研发发布流程联动，确保新产品上市即纳入清单准备二：建立持续漏洞发现能力企业除了被动接收客户、安全研究人员和供应商的漏洞通告，还应主动发现漏洞。六大漏洞发现渠道产品安全测试渗透测试、模糊测试、红队评估代码审计人工安全代码审查、安全编码规范SAST/DAST自动化检测静态/动态应用安全测试集成CI/CD第三方组件监测开源软件漏洞监测、SCA工具SBOM管理软件物料清单维护与漏洞关联漏洞情报跟踪CVE、CISAKEV等情报源订阅漏洞管理仪表盘示例关键：建立漏洞接收的统一联系点（security@邮箱），并发布协调漏洞披露政策（CVDPolicy）。准备三："主动利用"研判能力（最关键）这是CRA合规最核心的能力。只有准确判断漏洞是否已进入真实攻击阶段，才能正确触发第14条报告义务。研判能力建设四要素攻击日志分析·产品端入侵检测日志·云端访问日志审计·异常请求模式识别·利用特征签名匹配·成功入侵痕迹确认威胁情报订阅·商业威胁情报平台·CISAKEV目录监控·行业ISAC信息共享·暗网论坛监控·漏洞利用代码追踪蜜罐与诱捕·部署产品蜜罐节点·捕获真实攻击流量·分析攻击载荷手法·攻击者画像构建·零日利用早期预警客户事件渠道·客户安全事件上报·技术支持工单分析·SOC协同调查·应急响应联动·入侵证据固化准备四：严重事件判定与升级机制不能只盯漏洞。CRA还要求报告影响产品安全的严重事件，企业需在SOC、CSIRT和产品安全团队之间建立事件升级规则。三级事件升级机制P3·一般事件·局部功能异常·无安全属性影响·无恶意代码迹象·常规运维处理·无需CRA报告P2·重要事件·影响部分用户·可能影响安全属性·需安全团队介入·启动深度调查·评估是否升级P1P1·严重事件·影响机密性/完整性·认证功能被绕过·恶意代码进入执行·启动CRA报告流程·24小时内提交预警关键：制定明确的升级判定标准，避免"安全团队认为该报、法务还在研究、管理层没批准"的僵局。准备五：24小时报告决策流程制定明确的漏洞响应及上报流程，明确每个环节的责任人和时限。谁发现安全团队/研发/客户支持T+0记录事件信息谁研判产品安全分析师T+12h完成利用判定谁确认安全负责人+法务T+18h确认报告必要性谁批准管理层/合规负责人T+20h批准报告内容谁提交指定报告人T+24hSRP提交流程建设关键要求·每个环节指定主责人和备份人，确保7x24小时可联系·预设报告模板，包含早期预警和完整通知的标准字段·定期开展桌面演练（建议每季度一次），验证流程可行性·建立SRP平台账号和操作手册，提前完成测试提交·明确"先报后补"原则，信息不完整不构成延迟理由准备六：SBOM软件物料清单管理SBOM（SoftwareBillofMaterials）是产品的"软件成分身份证"，CRA要求制造商维护最新的SBOM，至少覆盖顶层依赖。SBOM核心要素要素说明组件清单所有第三方组件、开源软件、库文件版本信息每个组件的精确版本号、发布时间依赖关系组件与产品、组件间的依赖拓扑安全状态关联CVE、已知漏洞、修复状态许可证开源许可证类型、合规义务SBOM管理要求机器可读格式：使用SPDX或CycloneDX等通用标准格式持续更新：每次产品发布时同步更新SBOM，保持与实际版本一致漏洞关联：与CVE数据库联动，自动识别组件漏洞影响保存期限：技术文档（含SBOM）需保存10年准备七：安全更新与支持期义务CRA要求制造商在产品支持期内提供免费、及时的安全更新，并明确告知用户支持期限。支持期要求·至少5年安全更新支持（或基于产品预期寿命）·上市时必须明确告知用户支持期限·支持期内安全更新免费提供更新机制要求·安全的OTA固件更新机制，签名校验·默认自动安装安全更新·安全更新与功能更新分离发布漏洞处理全流程要求（AnnexIPartII）发现与记录建立漏洞接收渠道，记录所有已知漏洞修复与缓解不延迟地修复漏洞，提供安全更新用户告知更新可用后公开披露已修复漏洞信息上游报告组件漏洞向上游制造商报告并共享修复持续测试定期安全测试与审查05全面合规与处罚基本安全要求·CE认证·透明度义务·处罚体系2027年12月11日全面强制执行AnnexI基本网络安全要求AnnexI分为两部分：产品属性安全要求（PartI）和漏洞处理要求（PartII）。PartI：产品安全属性设计开发安全：基于风险评估，在规划、设计、开发、生产、交付、维护全生命周期确保适当安全水平默认安全配置：出厂即安全配置，最小化攻击面，减少不必要的功能和端口无已知可利用漏洞：产品上市时不得存在已知的、可被利用的安全漏洞安全属性保障：保障机密性、完整性、真实性、可用性、不可否认性PartII：漏洞处理要求漏洞识别与记录：建立漏洞处理流程，维护SBOM，记录所有已知漏洞及时修复：不延迟地修复漏洞，提供安全更新，与功能更新分离定期测试：实施有效、定期的安全测试和审查信息披露：更新可用后公开披露已修复漏洞的详细信息核心原则：要求是目标导向、技术中立的，具体实现方式由制造商基于风险评估自行决定，但需记录在技术文档中。符合性评估与CE标志获取流程Step1风险评估Step2确定产品等级Step3编制技术文档Step4合格评定Step5签署DoCCE各步骤关键说明步骤关键要求风险评估评估产品网络安全风险，结果贯穿全生命周期，记录在技术文档中确定等级判断属于默认类、重要类（附件III）还是关键类（附件IV），决定评估路径技术文档按附件VII编制，包含设计描述、风险评估、测试结果、SBOM等，保存10年合格评定默认类ModuleA自评；重要类用协调标准或公告机构；关键类强制欧洲认证用户透明度义务CRA要求制造商向用户提供充分的产品安全信息，确保用户能够做出知情决策。上市时需提供的信息·产品支持期限（安全更新时长）·产品使用说明与安全配置指南·已知的安全风险与缓解措施·漏洞报告联系渠道事件发生时的告知义务·主动利用漏洞须告知受影响用户·提供风险缓解和纠正措施指引·必要时采用结构化、机器可读格式·严重事件须告知所有用户（如适用）安全更新发布后的信息披露安全更新一旦可用，制造商必须公开披露已修复漏洞的信息，包括：·漏洞的描述与技术细节·允许用户识别受影响产品的信息·用户可采取的风险缓解措施·建议以结构化、机器可读的格式发布，便于自动化处理三级处罚体系（第64条）CRA设立了三级行政罚款，取固定金额和全球年营业额比例中的较高者。第一级·最严重€1500万或2.5%全球年营业额适用情形：·违反AnnexI基本安全要求·违反第13条制造商义务·违反第14条报告义务第二级·较重€1000万或2%全球年营业额适用情形：·违反其他经济运营商义务·进口商、分销商责任·授权代表义务违反第三级·一般€500万或1%全球年营业额适用情形：·向公告机构提供不正确或误导性信息·向市场监管机构提供虚假信息其他执法措施：禁止或限制产品上市、责令产品