漏洞管理生命周期是什么
漏洞管理是一条闭环：发现（扫描/情报/人工报送）、评估（资产匹配、定级、指派）、修复或缓解、验证（复测）、关闭归档。闭环之所以强调「验证」，是因为跳过它就会出现典型的假闭环：工单状态已关闭，漏洞实际仍在。判断闭环是否成立的简单标准是——每个环节都有可查的产出物。
基本信息
| 适用对象 | 企业漏洞管理流程、等保与 ISO 27001 相关要求 |
|---|---|
| 核心角色 | 扫描/评估岗、系统责任人、变更审批、验证岗 |
| 关键产出 | 漏洞清单、处置工单、变更记录、验证证据、结案记录 |
| 度量口径 | 修复时效、按期修复率、复测通过率、例外数量 |
环节与产出
| 环节 | 关键动作 | 产出物 |
|---|---|---|
| 发现 | 扫描、情报订阅、人工报送 | 漏洞清单 |
| 评估 | 资产匹配、分级、负责人指派 | 处置工单 |
| 修复 | 补丁 / 配置变更 / 缓解措施 | 变更记录 |
| 验证 | 复测、抽样复核 | 验证证据 |
| 关闭 | 归档与复盘 | 结案记录 |
闭环自查问题
闭环自查问题
1. 这个漏洞影响哪些资产？谁来修？
2. 修复后谁验证、用什么方法验证？
3. 无法修复的走缓解还是风险接受？谁批准、什么时候复审？
4. 同类问题是否需要在其他系统同步排查？（同类组件、同批镜像）典型使用场景
- 月度扫描后把结果转成工单：先做资产匹配，再按责任人分派
- 等保测评与审计取数：按环节调取证据，而不是只给一份扫描报告
- 补丁窗口排期：结合暴露面与利用情报排优先级，而非只按 CVSS 排序
- 无法修复的老系统走例外流程：写明缓解措施、批准人与复审时间
- 复盘：同类漏洞反复出现时，回到流程里找失效环节而不是只催修复
常见断点与后果
| 断点 | 典型表现 | 后果 |
|---|---|---|
| 评估不匹配资产 | 工单派给了不拥有该系统的团队 | 来回退回，时效全部浪费 |
| 只改状态不验证 | 工单关闭但复测仍命中 | 假闭环，风险长期留存 |
| 无例外流程 | 修不了的漏洞永远挂在待办 | 清单越滚越大，没人再认真看 |
| 无度量口径 | 提及时效时各部门算法不同 | 管理动作无法落地 |
复测建议用与原发现手段不同的方法交叉验证：扫描器发现的用人工或配置检查复测，人工发现的用策略扫描复测，避免同一个误报逻辑同时骗过发现与验证两头。
漏洞数据与资产台账要能互相关联：同一资产在扫描平台与 CMDB 中的命名不一致，是「漏扫漏修」最常见的隐藏原因。