欧盟《网络韧性法案》解读（三）：2027年底CRA全面落地，企业该拿什么来合规？
前两篇我们分别回答了两个问题：什么样的产品会受CRA的监管以及企业如何面对产品漏洞和严重事件报告义务。 但2027年12月11日，CRA主体规则将全面适用。企业面对的将不再只是漏洞要不要报、 真正的问题已经变成： 到2027年底，我究竟要拿出什么才算合规？ 第一件事：建立CRA合规台账 企业首先要对自己的产品进行系统梳理，形成产品级的CRA合规台账。 至少要能够明确：产品是否属于CRA范围、属于哪一类产品、适用什么符合性评估路径、产品由哪些软硬件和第三方组件构成、支持期到什么时候。 第二件事：实现产品全生命周期安全管理 企业需要形成产品级网络安全风险评估，并将风险评估结果落实到产品设计、安全控制和测试之中。 这意味着威胁建模、安全需求、安全架构、安全测试，都应该成为产品开发流程的一部分，而不是产品上线前临时补一份安全报告。 第三件事：软件供应链管理 今天一个产品往往由大量第三方软件、开源组件和SDK组成。 因此企业必须知道： 自己的产品究竟用了什么 。 未来当某个开源组件出现高危漏洞时，企业需要迅速回答：哪些产品使用了它？哪些版本受到影响？是否需要修复？是否需要通知用户？是否需要向欧盟报告？ 如果企业连产品的软件组成都不知道，就很难真正履行CRA要求。 第四件事：建立完整的漏洞闭环 2026年9月11日开始的漏洞报告，只是整个漏洞管理体系中的一个环节。 企业真正需要建立的是： 发现—分析—评估—修复—更新—通知—报告—验证的 完整闭环。 这意味着企业需要建立PSIRT或等效机制，并让研发、产品、安全、法务和合规形成协同。 一句话，漏洞不仅仅要及时上报，还必须具备闭环管理能力。 第五件事：别忘了把合规证据准备好 因此企业需要准备的不只是流程，而是能够拿出来的证据。事情要做，痕迹也要留。 CRA最终是可以被监管检查的。 整个产品周期的输出物矩阵如下所示。 CRA条款/要求 企业控制措施 输出物 责任部门 检查方式 Art.13 网络安全风险评估 风险评估报告 产品安全 是否完成 Annex I 安全设计 威胁建模报告 研发/安全 是否覆盖 Annex I 安全测试 测试报告 测试/安全 是否通过 Annex I 组件管理 SBOM 研发/供应链 是否完整 Annex I 漏洞处理 漏洞记录 PSIRT 是否闭环 Art.14 漏洞报告 CRA报告记录 PSIRT/合规 是否按时 Art.13 支持周期 支持周期声明 产品/合规 是否明确 Annex II 用户安全信息 用户安全操作指南 产品/技术文档 是否包含 Art.31 技术文档 技术辅助文档 合规 是否完整 Art.28 符合性声明 EU 声明 合规 是否签署 Art.30 CE CE 标志 产品/合规 是否标识 最终目标是为每一个监管范围的产品建立一条产品安全证据链。 写在最后 对于企业来说，归根结底还是自身网络安全内功的建设，将网络安全真正融入自家产品的完整生命 周期之中。这当然是一个费时费钱的过程，但是加强数字产品的安全毕竟是大势所趋，毕竟，合规也是一种竞争力 。 安全合规 网络韧性