修复验证是什么
关闭漏洞前必须完成复测：用与发现时相同或更严格的路径验证，并留存证据。缺了这一步，问题就会以两种方式回归——修复只覆盖了部分主机，或修改了配置但未生效。验证的目标不是「看起来修好了」，而是确认原有的利用路径不再可用，同时确认正常业务未被打断。仅凭「已修复」的口头反馈直接关闭是管理漏洞，因为后续审计与事件复盘时没有可核对的依据。
基本信息
| 验证对象 | 原发现路径、同类接口、批量修复的全部主机 |
|---|---|
| 验证方式 | 原参数复测、版本核查、配置核查、抽样加全量策略核查 |
| 证据要求 | 命令、时间、结果与执行人，附在工单里 |
| 回归要求 | 确认修复动作未影响正常业务功能 |
| 例外处理 | 无法复测时说明原因并约定替代验证方式 |
| 关闭条件 | 复测通过且证据完整才可关闭 |
典型场景
- 弱口令类问题：确认强口令策略生效且默认账号已处理
- 未授权访问类问题：从外部视角确认接口已不可达或必然被拒
- 组件版本类问题：确认运行进程加载的版本在修复范围内
- 代码类问题：确认修复分支已发布到全部环境并覆盖同类接口
- 配置类问题：确认配置生效范围与预期一致，不只改了一台
- 批量修复后：抽样复测加全量策略核查，避免只改了样例
复测要点
复测要点
# 原路径原参数复测（示例：确认未授权访问已阻断）
curl -sk -o /dev/null -w '%{http_code}\n' https://api.example.com/api/order/status
# 期望 401/403；再带合法凭据确认业务未被打断
# 若为版本升级类：核对新版本号与公告修复范围
dpkg -l nginx | tail -1
# 若为配置类：核对生效配置而非配置文件内容
sshd -T | grep -E 'passwordauthentication|permitrootlogin'三类验证口径
| 问题类型 | 验证方式 | 通过标准 |
|---|---|---|
| 访问控制类 | 用原路径与原身份复测 | 越权路径被拒且正常路径可用 |
| 版本与补丁类 | 核查运行进程与包的版本 | 版本在修复范围内且服务已重启 |
| 配置类 | 核查生效配置与生效范围 | 全部目标主机的生效值符合要求 |
| 代码类 | 确认修复上线并覆盖同类接口 | 原问题路径与同类路径均不可利用 |
批量修复后建议抽样复测 + 全量策略核查：只改了一台机器的『批量修复』很常见。
复测记录要能被人独立重放：写明命令、参数、目标与时间。同一份记录既是关闭依据，也是后续审计与复盘的材料。