被在野利用的漏洞要在二十四小时内上报，谁要交这份报告
被在野利用的漏洞要在二十四小时内上报，这条新规管到谁，做网站运营的要交哪份报告？义务落在把带数字要素的产品放进欧盟市场的制造者，以及特定条件下的开源软件维护方，而不是每一个装了站点的运营者。多数国内站点不在辖内，但这套三档时限值得借来做自己的应急节拍。
新规从哪天开始生效
规则的申报义务从今年九月十一日开始适用，触发条件是两类事件：正在被在野利用的漏洞，以及影响产品安全的重大事件。也就是说，光「有漏洞」不必然启动申报，是否已被利用、是否影响安全，是判断起点。
三档时限各交什么
| 时限 | 交什么 | 内容重点 | 常见缺口 |
|---|---|---|---|
| 二十四小时 | 早期预警 | 事件存在、影响面初判 | 等到查明根因才报 |
| 七十二小时 | 漏洞或事件通报 | 技术细节、被利用情况 | 没区分受影响版本 |
| 十四天内 | 最终报告 | 整改措施与根因 | 修复上线即归档，不写根因 |
第一档要在意识到事件后的二十四小时内给出，第二档补上更完整的信息，第三档在可用的整改措施落地后十四天内提交最终报告。三档的差别不是「越写越长」，而是回答三个不同问题：出事了没有、影响是什么、怎么彻底修好。
谁被算成需要申报的一方
需要申报的是产品的制造者，包括把硬件、软件与云服务组合投放市场的主体；开源软件维护方在规则里承担属于自己的申报义务，但范围与商业制造者不同。
站点运营者通常处在「使用者」位置：你自己不构成制造者，但你依赖的系统与插件属于受辖产品。真正影响运营者的是间接义务——上游一旦启动申报，修补节奏与披露信息会更快公开，你的应急窗口随之压缩。
不受辖的站点能借这套时限做什么
把三档时限当成内部处置节拍，是一套很好用的组织方式。
- 发现被在野利用的漏洞：二十四小时内完成影响面初判并对外沟通口径，明确哪些站点受影响；
- 七十二小时内：补齐受影响版本清单、暴露面与是否已有入侵痕迹的判断，形成通报稿；
- 措施可用后十四天内：写根因与整改结论，归档到运维记录。
自建系统侧的配套能力同样重要。AnQiCMS 在 v3.6.6 的发布说明里同时处理了列表排序参数注入与站点切换登录凭证可被伪造两项高危问题，并给出轮换站点签名配置、修改管理员口令的后续动作，这类「修完还要换凭证」的条目正对应时限表里的最终报告环节。接入自动化时，MCP 接口按意图域设置暴露范围，备份、升级、多站点这类全站级操作默认关闭；写操作在回合级合并确认，避免应急窗口里被自动化脚本一把梭执行。外部 AI 客户端如 Claude、Cursor 可以接入这套接口，但审批环节留在人这一侧。
落到日常值班上的四件事
- 订阅依赖系统的公告源，别等漏洞已在野利用才知道有公告；
- 把「谁有权限关停公开入口」写成明确的值班规则；
- 每次处置都留时间戳，最终报告直接从中拼装；
- 演练一次二十四小时与七十二小时的窗口，看内部流程能不能跟上。
常见问题
我只是运营方，需要向监管申报吗？ 一般不需要，规则管的是制造者与维护方；运营者的动作是把上游公告转成内部处置。
二十四小时从什么时候起算？ 从「意识到」事件起算，而不是从查明根因起算，这就是早期预警存在的意义。
没赶上时限怎么办？ 记录延误原因与补救动作，监管关注的是流程有效性，事后完整留档比隐瞒更有利。
内部节拍有必要卡这么紧吗？ 有被在野利用风险的场景下，窗口越短越能减少暴露时间；普通缺陷不必套同一强度。