1. 课程导入与全景认知
在企业安全建设中，漏洞管理常被误解为“扫描器跑一遍、把高危漏洞修掉”的运维动作。但真实的企业环境里，漏洞从来不是孤立存在的技术缺陷，而是资产、配置、业务依赖、攻击面与修复成本交织形成的风险集合。企业漏洞管理（Enterprise Vulnerability Management，EVM）指的是：以组织资产为基础，持续发现、评估、处置、验证和度量安全弱点的系统性工程活动，其目标不是“漏洞数量归零”，而是把可被利用的风险控制在业务可接受的范围内。
理解这一定义，需要区分三个容易混淆的概念。漏洞扫描是发现手段，输出的是“可能存在问题的清单”；漏洞管理是围绕清单展开的评估、优先级排序、修复跟踪与验证闭环；漏洞管理工程则进一步把流程、工具、角色、指标和治理机制固化下来，使其可重复、可度量、可持续。三者是手段、过程与体系的关系，而非同义词。
一是风险收敛——把有限的修复资源投向真正可被利用、且影响关键业务的弱点；
二是攻击面可见——让资产、服务、暴露面与弱点的对应关系从“说不清”变为“查得到”；
三是合规与信任支撑——为等保、ISO 27001、行业监管及客户审计提供可追溯的证据链。
然而，落地过程中企业普遍面临四类核心挑战。第一是资产不清：影子资产、临时上线系统、云上弹性实例导致扫描范围永远滞后于真实暴露面。第二是优先级失真：若只按 CVSS 基础分排序，会忽略“该漏洞是否已被在野利用”“资产是否对外暴露”“是否存在可利用的公开 EXP”等关键上下文。第三是修复协同难：漏洞归属常跨开发、运维、云平台、外包团队，责任边界模糊导致工单长期挂起。第四是验证与度量缺失：修复后未复测、未回归，指标只统计“发现数”而不看“闭环率”和“平均修复时长”，管理动作无法持续改进。
为应对这些挑战，本课程采用全生命周期工程的视角，把漏洞管理拆解为六个相互衔接的阶段：资产与暴露面梳理、漏洞发现与采集、风险评估与优先级排序、修复与缓解处置、复测验证与闭环、度量与持续改进。这六个阶段不是一次性流水线，而是带反馈的循环：度量结果会反向驱动资产梳理范围和扫描策略调整，验证结果会修正优先级模型，处置经验会沉淀为修复基线。
图中六个阶段构成主链路，橙色虚线表示两条关键反馈：度量结果反向调整资产梳理与扫描策略，验证结果回写优先级模型与修复基线。底部列出五类关键角色——安全运营/漏洞管理负责流程驱动与指标，资产与运维团队提供资产台账和基础环境，研发/应用负责人承担代码与业务系统修复，云平台/外包团队处理弹性资源与第三方组件，风险与合规负责标准对齐与证据留存。角色之间不是串行交接，而是围绕同一漏洞工单并行协作。
为了让后续章节有统一的判断基准，这里先给出一个可操作的优先级示例。假设某企业扫描发现三个漏洞：
| 漏洞 | CVSS | EPSS | 是否在野利用 | 资产暴露 | 业务等级 | 建议优先级 |
|---|---|---|---|---|---|---|
| CVE-A（反序列化） | 9.8 | 0.72 | 是（KEV） | 公网可达 | 核心交易 | P0，24 小时内缓解 |
| CVE-B（信息泄露） | 7.5 | 0.08 | 否 | 内网 | 一般办公 | P2，按迭代修复 |
| CVE-C（权限提升） | 8.1 | 0.31 | 否 | 内网 | 核心数据库 | P1，7 天内修复 |
该示例说明：CVSS 高不等于优先级最高，必须叠加 EPSS（利用概率）、KEV（已知被利用漏洞目录）、暴露面和业务等级。CVE-B 虽然 CVSS 7.5，但利用概率低、内网、业务等级一般，可降级处理；CVE-C 分数略低，但落在核心数据库上，优先级反而高于 CVE-B。这就是“风险收敛”而非“分数排序”的实际含义。
最后需要强调，漏洞管理工程的成熟度不是由工具数量决定的，而是由闭环能力决定的。一个企业即使只使用基础扫描器，只要能做到资产可查、优先级有依据、修复有责任人、验证有记录、指标可复盘，其实际风险控制水平往往高于堆砌多套工具却无法闭环的组织。本章建立的全景认知，将作为后续 29 章的方法论锚点。