修完必须验证三件事
漏洞修复不能以“包已经装上”作为结束标志，必须验证三件事：版本或开关确实生效、业务功能正常、原来的验证方法不再复现。三者缺一都不算修完。实际工作中最常见的两种失误是：装完包没重启服务，运行进程仍是旧代码；集群里只修了部分实例，负载均衡仍会打到未修复的节点。
基本信息
| 适用平台 | 全部平台（Linux、Windows、容器、应用） |
|---|---|
| 验证三层 | 版本与配置、运行态与功能、原验证方法复测 |
| 证据要求 | 命令、时间、结果三者齐备并留档 |
| 基线 | 修复过程有可追溯的验证记录 |
| 风险等级 | 中 |
典型使用场景
- 高危漏洞应急：修复后向上级提供验证证据
- 补丁管理闭环：把验证纳入变更单必填项
- 集群环境：确认所有实例都已修复且流量可正常分发
- 容器环境：确认线上运行的确实是用新镜像重建的实例
- 审计复盘：出问题时用验证记录判断影响窗口长度
验证清单
验证清单
echo '1) 版本与配置已生效：'
uname -r; nginx -v 2>&1; cat /proc/version | head -1
echo '2) 运行态：'
systemctl is-active nginx sshd; systemctl --failed | head
echo '3) 业务功能：'
curl -s -o /dev/null -w 'http=%{http_code} time=%{time_total}\n' https://业务域名/
echo '4) 复测：'
# 用原验证思路在测试环境或受控条件下确认不再复现
journalctl --since '30 min ago' -p err --no-pager | tail -20三层验证读法
| 层次 | 验证内容 | 常见漏项 |
|---|---|---|
| 版本层 | 包版本、内核版本、配置开关 | 只确认已安装，未确认服务已重启 |
| 运行态层 | 服务状态、端口监听、错误日志 | 只看状态码不看实际进程版本 |
| 功能层 | 核心接口与业务链路 | 只验证本机，未验证入口链路 |
| 复测层 | 原验证方法不再复现 | 未复测，无法确认修复有效 |
| 证据层 | 时间、命令、结果留档 | 口头确认无记录，争议时无依据 |
原验证方法复测可能触发安全设备告警：提前与安全团队沟通，并把范围限定在测试环境或受控条件内。
落地要点
- 验证记录要能回溯：时间、命令、结果、执行人四项齐全
- 集群与多副本环境逐台确认，避免只修一台就宣布完成
- 容器环境验证镜像摘要与实例创建时间，确认是新版本
- 业务验证要覆盖真实入口链路（负载均衡、CDN、网关）
- 把复测结果与修复清单一起归档，形成闭环证据
验证越早做成本越低：上线后几天才发现未生效，意味着漏洞窗口被无形延长，而且此时已难判断期间是否被利用。