漏洞管理生命周期

漏洞管理（VM）不是一次性扫描，而是一项持续开展的计划。将其作为一个生命周期来管理，可以确保漏洞得到可靠的发现、评估、确定优先级、修复和确认关闭，而不是在被忽视的报告中越积越多。

经典循环是：发现、评估、确定优先级、修复、验证，然后重复进行。每个阶段都有负责人、输入和输出。

看不见的对象无法得到保护。发现会建立并维护准确的资产清单，并在其中查找漏洞：

• 主机、云实例、容器、服务和软件版本。
• 经过身份验证和未经过身份验证的扫描。
• 被动发现和外部攻击面映射。

资产清单不完整，是 VM 计划失败的最常见原因。

评估用于验证原始发现项并为其补充上下文。扫描器报告了一个 CVE；评估要回答：

• 这是真实暴露还是误报？
• 受影响的组件是否确实正在使用且可以访问？
• 技术严重性和业务上下文是什么？

此阶段会将杂乱的扫描输出转化为可信且可采取行动的发现项。

漏洞数量总是超过您能够修复的数量。优先级排序会对漏洞进行排列，让有限的修复资源首先处理风险最高的漏洞。

良好的优先级排序会综合考虑严重性（CVSS）、被利用的可能性（EPSS）、已知的活跃利用（KEV），以及资产的业务价值和暴露程度。仅按 CVSS 打补丁会把精力浪费在理论性问题上，而真正的威胁却得不到处理。

修复用于弥合这一差距。以下是大致按照优先顺序排列的选项：

• 修补/升级有漏洞的软件。
• 缓解/配置（禁用功能、限制访问、添加 WAF 规则）。
• 在修复不可行时，通过正式签字确认接受风险。

修复需要跨职能协作：安全团队负责识别，但 IT/开发/运维团队通常负责实施修复。

标记为完成的工单并不能证明问题已经解决。验证会重新扫描或重新测试，以确认漏洞确实已经消失且未发生回归。

没有验证，仪表板就会提供虚假信息：团队在暴露风险仍然存在时关闭工单。用证据闭环，才能让整个计划值得信赖。

年度或季度扫描会留下很长的盲区。现代 VM 是持续的：新资产、新代码和新的 CVE 每天都会出现。

将扫描集成到持续集成/持续交付、镜像构建和云资源配置流程中，使漏洞能够尽早被发现，并让生命周期持续运行，而不是以压力很大的大批次方式进行。

VM 只有在职责归属明确时才能发挥作用：

• 安全团队负责扫描、优先级排序和报告。
• IT/DevOps负责资产修补和配置。
• 应用团队负责修复代码级别和依赖项问题。
• 风险负责人负责批准例外并接受剩余风险。

每个发现项都需要指定负责人和截止日期，否则就会停滞。

衡量整个计划，而不仅仅是发现项数量：

• 按严重性统计的平均修复时间（MTTR）。
• SLA 合规率。
• 未关闭项与已关闭项随时间的趋势。
• 覆盖率（已扫描资产所占的百分比）。
• 重新打开/重复出现率。

跟踪按存续时间划分的区间，避免旧的严重漏洞悄无声息地长期存在。

并非每个漏洞都能及时修复。正式的例外流程会记录以下内容：

• 推迟修复的原因。
• 已采取的补偿性控制措施。
• 接受该风险的风险负责人。
• 强制重新审查的过期日期。

例外必须设定时限；无期限的例外只是被忽视的风险。

生命周期应当能够自我改进。利用验证和指标来发现系统性问题：某个库反复出现 CVE、团队响应缓慢，或存在扫描盲区。

将这些反馈用于改进发现阶段（提高覆盖率）、优先级排序（调整阈值）和修复阶段（自动化、标准镜像）。VM 的成熟度取决于该闭环运行的速度和可靠性。

确认最后阶段的目的。

VM 生命周期是一个持续闭环：发现资产和弱点，评估并验证它们，按照实际风险确定优先级，通过修补/缓解/接受风险进行修复，并验证修复是否有效。明确的责任归属、SLA、指标和有时限的例外机制可确保流程不流于形式。

接下来，我们将深入了解发现的基础：扫描并构建准确的资产清单。