安全修复已合入却迟迟未上线时，漏洞负责人应如何判断风险是否真正关闭？

# 核心结论

安全修复进入代码仓库并不代表风险已经关闭。漏洞负责人应以可验证的生产状态为关闭标准：根因修复覆盖全部受影响分支、服务和部署单元；生产环境运行可识别的安全构建；原有利用路径经过复测已失效；可能泄露的凭证、密钥和会话已经轮换或撤销；历史数据、日志与敏感操作完成影响排查；同时存在能够发现回归的测试或监控。工单状态、合并记录、开发环境测试和扫描器显示通过，都只能作为证据的一部分，不能单独证明风险消失。

# 底层机制

漏洞影响常常横跨源代码、锁文件、构建制品、镜像、运行配置、缓存和发布权限。即使源代码已经修复，旧构建仍可能停留在生产实例、边缘节点、离线缓存或 Service Worker 中。删除仓库当前版本里