一家智能设备工厂收到欧盟进口商转来的异常反馈，技术团队发现某固件漏洞已有利用证据。眼下最急的是确认谁负责报告、报告时钟什么时候开始，以及在调查还没完时先交什么。
一、什么是CRA漏洞上报，哪些企业要做
1.1 先看产品和义务开始时间
CRA是欧盟针对带数字元素产品的网络安全法规。第14条规定制造商需报告已被积极利用的漏洞和影响产品安全的严重事件。欧盟委员会报告义务说明明确，该报告义务自2026年9月11日起适用，法规的其他大部分要求自2027年12月11日起适用。不要把后一个日期当作事件报告的开始日期。针对较早投放的在范围内产品，ENISA报告平台问答也说明报告义务适用，先核具体产品范围和角色。
1.2 中国出口商看身份和实际销售方式
自有品牌直接面向欧盟市场的工厂，要核自己是否属于制造商。按客户品牌代工时，应从产品和合同核实际制造商，并约定工厂接到售后或研发线索后谁评估、通知并协助报告。只负责进口或经销的企业，要按其角色处理通知、风险与配合，不能把制造商专有报告流程直接套给每个贸易商。如果进口商以自己的名称或商标投放，或作出实质性修改，应进一步按法规核是否视为制造商。可对照欧盟委员会CRA立法摘要梳理角色。
1.3 什么情况要按第14条处理
可先区分一般漏洞线索、已有利用证据的漏洞，以及影响产品安全的严重事件。研发测试发现潜在问题时，先按内部漏洞处理流程调查；收到可信证据表明该漏洞被恶意方实际利用时，马上核强制报告条件。严重事件也要按法规判定，比如是否已经或可能严重影响产品保护敏感或重要数据及功能的能力，或在产品及其用户系统中引入或执行恶意代码。报告判断看实际证据和影响，不等补丁发布后才开始。
1.4 用一个实际销售组合确认产品版本
例如同名路由器在欧盟销售两种硬件版本，另有一款只在国内卖。排查时把欧盟在售、曾售的型号与固件、组件版本分开，确认哪个版本受影响、哪些成员国有销售、谁负责售后。记录线索来源、时间、技术判断依据和负责人。合作方提供日志时，根据权限保存必要资料，内部共享以完成调查所需为限。
1.5 先把“收到线索”和“已经知悉”记清楚
可在事件表中同时留接收时间、首次确认影响范围时间、掌握实际利用证据或严重事件的时间以及判断依据。报告期限与制造商依法得知相应情况有关，不能把内部签字、客户回复或调查完成时间任意作为起点。若多人分布在不同时区，表内保留统一时区及原始记录，交接时把最早需要行动的节点告诉所有负责人员。
二、24小时、72小时和最终报告各写什么
2.1 第一步：在时限内提交早期预警
欧盟委员会第14条报告时限说明列出，自制造商得知符合条件的漏洞或事件起应无不当延迟，最迟24小时提交早期预警。工厂先记录得知时间，按事件类型准备适用信息、相关产品和已知投放市场的成员国。调查未结束时区分已核实和待确认事项。跨时区企业指定日常值班联系人和替补，确保信息经授权送达报告人。
2.2 第二步：72小时通知补上影响和措施
除已提交相关信息外，制造商须在得知后无不当延迟、最迟72小时补充通知。根据事件类型列受影响产品、已知性质、已有修正或缓解措施、用户可采取的措施，以及适用的敏感信息说明。用型号和固件版本对应证据，记录临时缓解与正式修补的进度。若只有部分数据已确认，保留待补项目和计划时间，别为了填表猜测受影响数量。
2.3 第三步：区分最终报告的两种时钟
对正在被利用的漏洞，最终报告最迟在修正或缓解措施可用后14天内提交；对严重事件，最迟在72小时通知提交后1个月内提交。两者各有触发点，内部表格分别记录。最终报告应按对应类型归纳已知影响、经过、修复和缓解等信息，实际填报时逐项参照ENISA平台字段及报告问答。保存每次提交时间、编号和后续往来，便于追踪。
2.4 模拟一次跨部门交接
假设周五下午收到欧盟客户异常登录线索，售后记录时间和报告人，技术团队核日志与受影响版本，产品安全负责人判断是否进入强制报告流程，业务人员更新涉及国家和联系方式。已经有充分证据符合触发条件时，安排负责人按时先提交，后续调查继续进行。若没有触发条件，也保留判断理由与复核安排，发现新证据立即重新判断。
2.5 先给用户可操作的缓解信息
发现影响已售产品时，除向监管报告外，还要按适用要求告知受影响用户。比如同一型号只有某一批次的软件受到影响，应说明如何查看版本、能否暂时关闭有关功能、补丁何时可用，以及如何确认更新成功。公开说明避免披露不必要的利用细节，内部报告则应保留证据来源、判断时间和措施版本。
三、出口团队如何把上报流程做进日常
3.1 准备ENISA平台和人员权限
制造商通过单一报告平台（SRP）提交，平台把信息送达适用的协调 CSIRT 并按法规机制处理。进入ENISA官方报告问答与入口核注册、制造商关联、授权人员和字段要求。没有欧盟主要营业地的企业，应按第14条和官方指引判定适用的协调方，不随意选一个国家。安排替补账户和授权，保留提交后可供继续更新的记录。
3.2 把现有售后、研发和进口商连起来
给客户和供应商一个清楚的漏洞反馈入口，规定收到反馈后传给谁。内部事件记录表包括联系渠道、型号、序列或批次、软件版本、投放国、得知时间、证据、临时措施和处理进度。进口商或渠道商确认受影响客户和售后方式，研发提供补丁适用范围和发布依据。发现影响可能扩大时同步内部负责人，按法规和官方指引处理用户告知等后续工作。
3.3 在发货或换固件时更新台账
不同渠道下同型号可能装不同固件。用订单、批次、设备版本和销售国记录组合关系。固件改版时更新销售与售后数据库，同时保留历史版本、补丁路径和对外通知；收到组件供应商通告后就能快速定位实际受影响机型。支持团队和运营做一次样例演练，检查跨时区联络是否及时、提交内容能否追溯以及客户能否拿到与自己版本匹配的建议。
3.4 整理三份现场能用的材料
第一份是欧盟市场的产品、角色和配置表，第二份是事件判定及24小时、72小时、最终报告节点表，第三份是安全补丁、用户告知、提交回执和负责人交接档案。每次处理后复核最耗时的环节，例如缺旧固件映射、没有有效负责人或无法确认销售国。下一批产品上市时，将这些信息补进交接，避免靠临时查找。
3.5 代工协议建议落到三个联系人
品牌或制造商的产品安全负责人主导判断与提交，工厂研发联系人负责排查和确认版本，进口商或分销联系人帮助确认涉及市场和客户。约定哪些线索必须马上升级，夜间或周末如何联络，以及哪一方保存报告回执和后续修正。比如组件供应商直接把警报发给工厂，也要约定工厂如何及时通知承担制造商责任的一方。
四、结论与办理准备
CRA漏洞上报先判企业角色与事件性质，确认得知时间，再按两类时钟提交。出口企业可先准备欧盟销售版本清单、漏洞反馈入口和跨部门责任表，有事件时能迅速拿到正确资料。
如果需要核产品是否在CRA范围、制造商义务或上报资料，可把型号、软件版本、市场和品牌关系发给权检认证沟通。涉及具体漏洞时，先用适当的安全渠道交流敏感材料。
本文包含AI辅助创作内容。
