先缓解后修复
当漏洞已被在野利用、官方补丁尚未可得时，处置顺序是「先缓解、后修复」：隔离、拦截、关闭入口这些手段能在小时级压缩攻击窗口，而等补丁、排期、灰度、全量往往以周计。决策原则是业务连续性优先——缓解手段要和业务方一起选，明确各自的代价与恢复条件，并留下记录。
基本信息
| 适用场景 | 0day 或已在野利用的高危漏洞 |
|---|---|
| 适用平台 | 全部平台 |
| 风险等级 | 高 |
| 决策原则 | 业务连续性优先，安全与业务共同决策 |
| 基线要求 | 有可执行的 0day 缓解预案与联系人清单 |
典型使用场景
- 收到在野利用告警、官方补丁尚未发布
- 补丁已发布但业务系统无法立即重启或升级
- 边界设备或中间件出现高危漏洞且暴露在公网
- 需要给管理层一个可执行的处置顺序与时间点
- 漏洞处置完毕后清理临时措施并复盘
缓解手段优先级
缓解手段优先级
# 1) 网络层：防火墙或安全组限源，必要时临时关闭对外端口
# 2) 应用层：WAF 拦截利用特征，禁用脆弱功能或插件
# 3) 主机层：以最小权限运行进程，加沙箱或访问控制
# 4) 监控层：对利用特征集中告警，为溯源做准备
# 之后才是：等官方补丁 → 灰度验证 → 全量升级处置阶段与关键点
| 阶段 | 动作 | 关键点 |
|---|---|---|
| 确认 | 核实影响版本与暴露面 | 先确认受影响资产范围，不必全量停机 |
| 缓解 | 限源、拦截、关闭入口 | 以小时计，先于排期修复 |
| 监控 | 开启利用特征告警 | 缓解期间仍要假设可能已被利用 |
| 修复 | 补丁灰度再全量 | 回到既有变更流程执行 |
| 收尾 | 清理临时规则 | 避免临时策略长期遗留 |
「等补丁再说」是最贵的选项：在野利用的漏洞按小时演化，暴露窗口每多一天，被攻陷的概率都在上升。
紧急关闭业务功能（例如临时禁用某个接口）需要业务方书面确认：安全不能单方面停业务，但也不能把决策悬空，要明确谁在什么条件下能拍板。