通告确认已在野利用并进入已知被利用清单,排期要不要提级
通告确认已在野利用并进入已知被利用清单,排期要不要提级:应当提级。提级的理由不是分数变高,而是证据性质变了——严重度评分描述的是「可能被利用」的可能性,在野利用与已知被利用清单描述的是「已经在发生」的事实。两者不能互相替代,读通告时要把它们分开看。
两类信号各说明什么
| 信号 | 性质 | 稳定性 | 对排期的作用 |
|---|---|---|---|
| 严重度评分或评级 | 可能性判断 | 会随分析深入调整 | 决定常规优先级 |
| 在野利用确认 | 已观察到的攻击行为 | 出现即成立 | 触发提级 |
| 进入已知被利用清单 | 官方汇总的在野利用事实 | 有明确收录时间 | 通常伴随处置时限要求 |
| 官方启用强制更新通道 | 厂商对紧迫性的判断 | 与版本发布绑定 | 说明等待窗口已不适合 |
评级高但无在野利用,可以按常规窗口排;评级中等但已确认在野利用,应当提级。后一种情况里,「等下个维护周期」的机会成本已经变了。
提级怎么读时间线
一条缺陷的跟进时间线里常常同时出现上报日、公告日与清单收录日。提级判断按最后一个可确认的事实来排,而不是按最早的那个:
- 公告日决定修复版本是否可用;
- 在野利用确认日决定窗口是否已经关闭;
- 清单收录日决定是否有外部时限压力。
同一时间窗内的两条通告常常出现「一条已收录、一条仅评级高」的差异,按上面的顺序分别定级即可,不必合并成一条内部结论。
提级之后仍要保留的三个动作
提级不等于直接在生产站上执行升级。顺序仍然要完整:
- 先备份。备份范围要包含数据与静态文件,只导数据库会让恢复时图片与已生成的页面落空。提级场景里最容易犯的错就是为了快跳过这一步。
- 再升级。确认自己所在的维护线有对应修复版本,跨分支时不要混用补丁。内容管理系统自身也有过按版本线发布修复的例子:v3.6.6 处理了列表排序参数注入与站点切换登录凭证可被伪造两项高危问题,升级后还要轮换令牌密钥并修改管理员密码。
- 后核验。用可达路径复现一次判定:触发点在对外入口上的,升级后要确认原路径已经不再返回异常结果;同时确认防御层(针对 SQL 注入、XSS 的处理、敏感词过滤与干扰码等)没有被配置变更覆盖掉。
提级要通知谁
提级影响的不只是运维排期。到期提醒与邮件通知的收件人要覆盖能决策停服的人,否则技术侧判断成立但没人批窗口。核验完成后,把结论与理由写进工单,下一次同类信号来时可直接对照。
常见问题
只有厂商评级、没有在野利用,要不要等? 可以按常规窗口排,但要确认暴露面:无认证可达的入口即使评级中等,也不宜放到下个季度。
已知被利用清单收录了但我的版本不受影响,怎么处理? 记录判定依据即可。不受影响的结论要能复现,写明所在版本线与对照的受影响区间。
提级后可以只加临时防护吗? 临时手段只能缩小暴露面,不能替代修复版本。用了临时手段也要留下替换计划与到期时间。