CRA 第 14 条自 2026 年 9 月 11 日起适用:发现被在野利用的漏洞,24 小时内向 CSIRT 与 ENISA 预警,72 小时内发出漏洞通知。法规规定了公告要写什么,却没规定长什么样、放在哪;第 14(8) 条要求必要时用「结构化、机器可读、可自动处理」的格式。这意味着一份要长期维护的文档,而不是事故当天的一篇通稿。

三个日期,两种义务
- 发现被在野利用的漏洞,24 小时内向协调 CSIRT 与 ENISA 发出早期预警
- 72 小时内补发漏洞通知,写清产品、漏洞性质、已采取的缓解措施,以及用户自己能做的动作
- 修复或缓解措施可用后 14 天内交终报
法规管内容,不管样子
- 安全更新一旦可用,就要公开已修复漏洞的信息,包括描述、受影响的识别信息、影响、严重程度和修复指引
- 安全更新要免费、及时分发,并附带公告信息,说明用户该采取什么动作

一份公告,四个问题
- 摘要:产品名、问题类型、严重程度,加公告编号、首版日期、最后更新日期、作者与联系方式;三句话说清问题,和一个必做动作
- 细节:漏洞与利用方式、严重程度、受影响范围(认证、接口、数据)、根因分析的结论
- 影响:用日常语言讲攻击者能做什么,已经发生了什么
- 缓解与下一步:用户要做的动作(改密码、吊销令牌、轮换密钥),厂商已经修了什么,下次更新在什么时候
今天能做的
- 翻出最近一次安全更新对应的公告,查三件事:地址是否固定、有没有编号和最后更新日期、能不能说清受影响版本。
- 建一份公告模板,四段结构加三关复核,字段先定下来,下次出事直接填。
- 用策思路 C456 跑一次 GEO 诊断,把「产品 + 漏洞 + 怎么做」这类问题留成基线,答案页放进 Baklib 维护。

博客