导语：漏洞多到修不完才是常态
如果扫描器报出几千个漏洞、团队要求"全部尽快修复"，结果往往是被拖垮，真正高危的反而被淹没。漏洞管理的核心不是把漏洞清零（这不现实），而是在有限资源里优先修复最危险、最可能被利用的漏洞，并持续度量效果。
一句话总结： 漏洞管理 = 发现 → 评估 → 排序 → 修复 → 验证 → 复盘 的闭环；它的本质是用风险优先级代替"按数量修"，把安全投入花在最危险的地方。
1. 漏洞发现：来源不止扫描器
| 来源 | 类型 | 特点 |
|---|---|---|
| 安全扫描器 | SAST/DAST/IAST | 覆盖面广、误报多、偏技术 |
| 组件/主机扫描 | SCA、OS 补丁检查 | 需结合版本与利用条件 |
| 渗透测试/红队 | 人工验证的真漏洞 | 精、少、可信度高 |
| 众测/赏金（SRC） | 外部提交 | 真实攻击视角 |
| 应急通报/0day 情报 | 已知漏洞预警 | 需快速响应 |
| 外部数据库 | CVE/NVD/CNVD | 需自行比对资产 |
漏洞管理的第一步，是把来自各处的漏洞归并成一个统一池子：
去重、补齐详情、标明责任方与资产，才能进入评估环节。
一句话总结： 发现来源多样化，但必须归一到一个漏洞池——否则同一个漏洞被扫出 5 次、各有各的责任人，管理无从谈起。
2. 风险评估：CVSS 与 EPSS
2.1 CVSS 评分
CVSS v3.1 = 基础分 + 时间分 + 环境分，范围 0.0~10.0
优点：业界通用、可比较
局限：只看"技术上能不能打"，不看"实际会不会被打"
一个 9.8 的漏洞，如果只存在于没人用的软件里，
实际风险可能低于一个 6.5 但跑在核心链路上的通用组件漏洞。
2.2 EPSS：从"多严重"到"多可能被打"
EPSS（Exploit Prediction Scoring System）：
用全网威胁情报预测"该漏洞未来 30 天被利用的概率"（0~1），
关键输入包括是否已有在野利用、PoC 公开情况、攻击者活跃度等。
组合决策框架：
Risk = 严重性(CVSS) × 被利用概率(EPSS) × 资产重要性 × 暴露面
实践建议：
EPSS > 0.9 且高严重性 → 24h 内响应
EPSS 低但影响资产重大 → 常规排期但不忽略
一句话总结： 用 CVSS + EPSS + 资产重要性 + 暴露面四维打分，才能区分"很严重但没人打"和"一般严重但正在被利用"——后者必须优先。
2.3 风险优先级矩阵
高严重
┌─────────┬──────────┐
│ 高 │ P1 紧急 │ ← 立即响应
│ 概率 │ P2 高优先 │ ← 7 天内修复
├─────────┼──────────┤
│ 低 │ P3 常规 │ ← 纳入迭代
│ 概率 │ P4 低 │ ← 持续观察
└─────────┴──────────┘
低严重 高严重
3. 修复闭环与 SLA
3.1 优先级与 SLA 参考
| 等级 | 条件 | 目标 SLA | 说明 |
|---|---|---|---|
| P1 | 可利用且直接 RCE/数据泄露 | ≤ 24h | 立即响应；可先用缓解措施（隔离/禁用/临时配置） |
| P2 | 高严重 + 暴露面大 | ≤ 7 天 | 排期修复 |
| P3 | 中低危、影响局部 | ≤ 30 天 | 纳入迭代计划 |
| P4 | 低危/疑似误报 | 持续观察 | 定期复核 |
3.2 闭环动作
① 验证修复：部署后重新扫描，确认漏洞消失
② 例外管理：无法立即修复的（遗留系统、商业组件不可升级），需申请例外
- 例外必须附：原因、影响评估、补偿性控制、过期日期、定期复查
③ 全程留痕：每个漏洞的处置（谁、何时、怎么处理、例外何时到期）
④ 复盘沉淀：重大漏洞复盘 → 找根因 → 补流程/补扫描规则
一句话总结： 闭环 = 修复 + 复扫验证 + 例外管理 + 留痕 + 复盘。“粘住不放"不等于修好，复扫通过才算。
4. 度量与改进指标
| 指标 | 说明 |
|---|---|
| 修复耗时（MTTR） | 从发现到验证通过的时间分布 |
| 到期未修复数 | 越少越好，反映流程阻塞 |
| 按时修复率 | 按 SLA 达标比例 |
| 存量 vs 新增 | 存量是否在下降、新增是否受控 |
| 例外存续周期 | 例外是否有人定期复查、不无限期挂起 |
指标设计的原则：
帮助判断"风险敞口在收敛"，而不是"我们修完了多少条"。
覆盖率（资产是否都被扫到）、闭环率比"扫描数量"更有意义。
一句话总结： 用指标反映风险敞口在收敛——存量下降、致命优先、例外有期，而不是盯着"修了几千条"自我感动。
5. 与团队流程集成
· 统一漏洞池：各扫描器/来源结果汇入一个平台，去重归一
· 自动分派：按资产归属/模块自动指派责任方
· 与 CI/CD 集成：镜像/依赖层高危漏洞在发布前拦截（DevSecOps 门禁）
· 与变更审批集成：重大修复走变更管理流程
· 与情报联动：出现 0day/在野利用时自动升级 P 级并触发应急
· 与审计集成：高危漏洞修复情况纳入合规审计证据
一句话总结： 漏洞管理不是安全团队"追着修”，而是接入开发、发布、运营既有流程，让修复责任落在离资产最近的人身上。
6. 易踩的坑
| 坑 | 影响 | 对策 |
|---|---|---|
| 只看 CVSS 不看 EPSS | 修了没人打的、漏了正在被利用的 | CVSS + EPSS + 资产四维排序 |
| 只扫不修 | 漏洞列表越积越长 | 建立责任分派与闭环 |
| 例外不给期限 | 例外变永久豁免 | 例外限定期限 + 定期复查 |
| 修复不验证 | 复扫发现漏洞还在 | 修后必须复扫 |
| 资产覆盖不全 | 影子资产无人管 | 资产盘点 + 覆盖率指标 |
| 指标只看完成量 | 团队刷数量不降风险 | 指标面向"风险收敛" |
7. 总结
漏洞管理是一座连接"发现"与"修复"的桥，用优先级而非数量做决策：
| 环节 | 关键动作 |
|---|---|
| 发现 | 扫描 + 情报 + 赏金，统一入池 |
| 评估 | CVSS + EPSS + 资产四维排序 |
| 处置 | 按优先级分派、SLA、例外有期 |
| 闭环 | 复扫验证、例外管理、复盘沉淀 |
| 度量 | 盯风险收敛与存量走势 |
一句话记住：漏洞管理不是消灭清零，而是分清"哪里最容易被打、影响最大"，让修复优先照顾那里。把扫描器从"报漏洞的服务器"变成"调度风险的平台"，漏洞治理才能真正闭环。
延伸阅读
- SAST/DAST/SCA 代码安全分析 — 工具层如何发现漏洞
- DevSecOps 流水线实践 — 把漏洞修复挡在 CI/CD 门禁里
- SIEM 与安全运营中心（SOC）建设 — 漏洞与告警、情报的运营联动
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。