CRA报告义务触发后，出海企业的24小时怎么走？

墨菲安全

墨衍会员 · AI 创作全网分发码龄5年

关注

原创 2026-09-21 19:08:27 285 阅读 AI 写同款· GEO 优化 ›

2026年9月11日起，欧盟 CRA 的报告义务已经正式开始适用。（适用详情可见上篇内容：CRA报告义务9月11日起适用：出海企业能在24小时内说清漏洞影响吗？）

如果企业收到一条漏洞情报：某个第三方组件的漏洞已经出现可靠的在野利用证据，而装了这个组件的设备固件可能已经被销往欧盟，对于这家出海企业来说，接下来要查什么？

从企业内部各团队来看：

安全团队先看到的可能只有一个CVE编号；
组件在哪些代码仓库里以及有哪些依赖版本，研发更清楚；
对应哪些设备型号，产品团队更清楚；
哪些版本去了欧盟市场，交付团队才有记录。

根据CRA报告义务要求，企业需要尽快并最迟在24小时内提交early warning，所以这些信息一定不能等到需要提交了才去临时拼凑。

CRA需要报告的主要是两类情况：

一种是被积极利用的漏洞；
另一种是影响带数字元素产品安全的严重事件。

这两类情形的判断和报告内容并不完全相同。

下面先拆解和软件成分管理联系更密切的第一种情况：企业收到一条被积极利用的组件漏洞情报后，前24小时要怎么走？

先明确一件事：24小时不是用来把漏洞全部修完

CRA的报告义务分为三个阶段：

制造商知悉被积极利用的漏洞后，应尽快并最迟在24小时内提交early warning；
随后最迟在72小时内补充更完整的漏洞通知；
纠正或缓解措施可用后，再在14日内提交最终报告。

从实际要求来看，分阶段去报告，给企业留下了继续补充信息的空间。24小时内企业要先整理好这几项基础事实：

企业在什么时间、通过什么来源知悉相关情况？
涉及哪个产品及产品版本？
产品在哪些欧盟成员国提供？
目前已经确认了什么，还有什么没有查清？
是否已有可以立即采取的纠正或缓解措施？

ENISA（欧盟网络安全局）在2026年9月10日更新的SRP Glossary中，也分别列出了24小时、72小时和最终报告所需要的字段。部分信息在24小时的early warning阶段是可选项，更多技术信息和处置进展可以在后续阶段的报告中继续补充。

所以，响应启动时，先记录知悉时间、明确责任人，并建立一份可以持续更新的基础信息。

接下来的工作可以归纳为四步：

登记线索；
并行核验；
形成受影响产品矩阵；
整理并提交early warning。

24小时里，这四步怎么衔接？

如果把企业知悉相关情况的时间节点记为T0，响应就从这里开始启动。

建议阶段	主要动作	主要参与团队	阶段输出
T0至T+2小时	登记线索和知悉时间，核验情报来源，指定事件负责人，判断是否需要启动报告响应	安全或PSIRT、报告负责人、线索接收团队提供原始记录	漏洞线索登记卡、事件编号、负责人
T+2至T+8小时	技术线匹配组件、受影响版本和最终制品，产品线同步反查产品型号和历史版本	安全或PSIRT、研发及构建、产品及发布	第一版受影响产品矩阵
T+8至T+16小时	继续核验利用条件、欧盟交付范围及已有缓解措施，区分已确认事项和未知项	安全或PSIRT、产品及发布、海外业务或交付	初步影响判断、未知项清单、措施清单
T+16至T+24小时	汇总early warning所需信息，完成内部审核，由指定人员通过SRP提交	安全或PSIRT、合规或法务、指定的SRP提交人员	early warning及内部留档

需要明确的是，各阶段不是等上一阶段完全结束才启动，完成基础登记后，技术核验、产品映射和交付范围确认就可以并行去推进。安全团队在核验漏洞与组件的同时，产品和交付团队就可以整理产品版本及欧盟市场信息，最终多条并行推进的工作线会汇总在“具体哪些产品受到影响”这个问题上。

此外，销售、售后或客户支持团队也可能会是最早收到外部通知的。所以企业最好明确统一入口，让原始邮件、告警或客户通知能及时进入正式响应流程，不要停在个人邮箱或客户群里。

第一步：登记漏洞线索和知悉时间

线索无论来自组件厂商、供应商、安全公告还是漏洞情报平台，都可以先按这个模板进行统一登记。

登记项	需要记录什么
收到时间	收到并识别该线索的时间，建议同时保留UTC时间
情报来源	厂商公告、供应商通知、CNA、漏洞库或其他可靠来源
漏洞标识	CVE、EUVD等已有编号；没有编号时保留原始通告链接和标题
组件信息	组件名称、受影响版本范围、可能涉及的功能模块
利用证据	是否有可靠的积极利用证据，证据来自哪里
当前负责人	谁负责技术核验、谁负责组织内部响应

这里有两个细节容易被忽略：

“高危漏洞”和“被积极利用的漏洞”不是一回事。CVSS分数高，说明潜在技术风险较高，但是否存在可靠的积极利用证据，还要结合厂商公告、权威漏洞信息和其他可信情报来判断；
知悉时间要从一开始就留痕，不要等影响面全部查清后才去补记。平台提交时间、内部工单创建时间和企业知悉时间并不是同一个概念，具体事件中如何认定“知悉”，应该由安全、合规及法律人员结合事实进行判断，所以要保留原始邮件、告警或通知的到达时间、以及内部升级记录。

第二步：技术线、产品线、交付线并行核验

登记完成后，接下来就要把外部线索对应到企业内自己的产品。这里的核验工作就需要多线并行，最终在把各链路上的信息汇总在一起：

技术线确认漏洞涉及哪个组件版本、组件是否进入最终制品、产品是否满足利用条件；
产品线确认相关制品对应哪些产品型号和历史版本；
交付线确认这些版本是否进入欧盟市场；

1、技术线：先确认产品里是否真的用了这个组件

先确认组件名称和版本，不要只依赖关键词搜索。

组件是直接依赖，还是由其他软件间接引入？
实际构建时使用的是哪个版本？
组件是否进入最终固件、安装包、容器镜像或交付制品？
是否存在同名组件、二次封装或供应商改造版本？
当前扫描结果对应源代码，还是对应最终发布制品？

如果只在开发仓库中发现组件，但它没有进入最终产品，判断结果会完全不同。反过来，供应商预编译包或历史固件中的组件，也可能不在当前代码仓库里。

2、技术线：再判断产品是否落在受影响范围内

确认组件存在后，还要继续判断：

使用版本是否处于受影响版本范围？
漏洞涉及的功能是否被编译或启用？
产品的配置、权限和网络暴露条件是否满足利用前提？
是否已经通过补丁、回移修复或配置调整消除了风险？
当前结论依据的是检测结果、构建记录、还是人员经验？

这一轮的输出不是必须做出“受影响”或“不受影响”的判断，在信息不足的情况下，可以明确标为“待核验”，并写清缺少哪项证据。

3、产品线：同步反查对应的产品型号和历史版本

智能设备、工业软件和IoT产品通常不只有一个当前版本。相同组件可能存在于不同固件分支、地区版本和客户定制包中。所以还需要继续反查：

哪些固件、软件包或镜像包含该组件版本？
这些制品对应哪些产品型号、软件版本和发布日期？
是否涉及已停止销售但仍在支持期内的版本？
是否存在客户定制版、OEM版或供应商交付版？

这里最容易遇到的情况是：当前主干代码已经升级，但欧盟客户仍在使用两年前交付的固件。所以只查最新仓库，并不能代表已经查清了实际影响面。

4、交付线：同步确认这些产品去了哪里

CRA的报告信息涉及产品已经在哪些欧盟成员国提供。所以还需要海外业务、供应链或交付团队协同提供：

产品是否已经进入欧盟市场？
涉及哪些成员国？
对应哪些型号、版本和交付批次？
是否仍有产品在库、在途或持续交付？
经销商、进口商或客户侧是否需要同步信息？

到这一步，技术核验结论、产品版本记录和欧盟交付信息汇合后，企业才得到第一版基本成形的影响范围信息。

第三步：形成受影响产品矩阵

多条并行推进的核验信息汇总之后，可以按下面的结构建立“受影响产品矩阵”，让安全、研发、产品和交付团队能围绕同一组对象去持续更新信息。

产品型号	固件/软件版本	组件版本	当前判断	利用条件	欧盟市场	判断依据	负责人
可填写	可填写	可填写	受影响 / 不受影响 / 待核验	已满足 / 未满足 / 待核验	成员国或待确认	扫描、构建记录、配置等	可填写