---

name: implementing-vulnerability-remediation-sla description: 漏洞修复 SLA（服务级别协议）根据严重程度、资产重要性和漏洞利用可用性定义修补或缓解已识别漏洞的强制时限。有效的 SLA 计划推动责任落实、确保一致的修复时间线，并为漏洞管理成熟度提供可衡量的 KPI。 domain: cybersecurity subdomain: vulnerability-management tags: [vulnerability-management, cve, sla, remediation, patch-management, risk] version: "1.0" author: mahipal license: Apache-2.0

实施漏洞修复 SLA

概述

漏洞修复 SLA（服务级别协议，Service Level Agreement）根据严重程度、资产重要性和漏洞利用可用性，定义修补或缓解已识别漏洞的强制时限。有效的 SLA 计划推动责任落实、确保一致的修复时间线，并为漏洞管理成熟度提供可衡量的 KPI（关键绩效指标）。

前置条件

• 定期产出发现结果的漏洞扫描计划
• 包含重要性分类的资产清单
• 用于修复跟踪的工单系统（Jira、ServiceNow 等）
• SLA 执行的高管支持
• IT 运营、开发和安全团队的跨职能协议

核心概念

SLA 框架组件

1. 严重程度分类：CVSS 基础分数 + 威胁上下文（EPSS、KEV）
2. 资产分层：业务重要性和暴露程度
3. 修复时间框架：按类别的最大修复天数
4. 例外流程：SLA 延期的书面审批
5. 升级程序：违反 SLA 时的行动
6. 指标和报告：合规性跟踪的 KPI

推荐的 SLA 矩阵

严重程度	Tier 1（关键）	Tier 2（重要）	Tier 3（标准）
关键（CVSS 9.0-10.0）	24-48 小时	72 小时	7 天
高（CVSS 7.0-8.9）	7 天	14 天	30 天
中（CVSS 4.0-6.9）	30 天	45 天	60 天
低（CVSS 0.1-3.9）	90 天	90 天	90 天
CISA KEV 列表	24 小时	48 小时	7 天

SLA 加速因素（SLA 缩短 50%）

• 公开可用的漏洞利用代码
• 在野外观察到的主动利用（CISA KEV）
• 受影响的互联网可访问资产
• EPSS 分数 > 0.5（50% 利用概率）
• 之前曾通过类似漏洞类型发生过违规

实施步骤

步骤 1：定义资产分层

Tier 1（关键资产）：
- 面向客户的生产系统
- 支付处理基础设施
- 域控制器和身份系统
- 核心网络基础设施（防火墙、路由器）
- 包含 PII/PHI/PCI 数据的数据库

Tier 2（重要资产）：
- 内部生产应用程序
- 电子邮件和协作系统
- 含有生产数据的开发/预发布环境
- 备份和恢复基础设施
- VPN 和远程访问网关

Tier 3（标准资产）：
- 终端用户工作站
- 开发/测试环境
- 打印服务器和外设管理
- 非关键内部工具

步骤 2：建立 SLA 策略文档

需要包含的关键部分：

• 目的和范围
• 角色和职责（RACI 矩阵）
• 严重程度定义和计算方法
• 按严重程度和资产分层的修复时间框架
• 例外请求流程和批准权限
• SLA 违规的升级程序
• 指标、报告频率和治理
• 策略审查和更新计划

步骤 3：与工单系统集成

# ServiceNow/Jira 集成，自动创建工单
# 修复工单的关键字段：
# - 漏洞 ID（CVE/插件 ID）
# - 受影响主机
# - 严重程度（CVSS + 上下文因素）
# - 资产分层
# - SLA 截止日期（从发现日期计算）
# - 负责团队
# - 修复说明
# - 验证标准

步骤 4：配置升级链

SLA 状态            动作                        通知对象
──────────────────────────────────────────────────────────────
75% 已用时         警告邮件                     资产负责人
100% 已用时        SLA 违规通知                 管理者 + CISO
100% + 7 天        高管升级                     VP/CTO
100% + 30 天       需要风险接受                  CISO 批准
100% + 90 天       强制补偿控制                  董事会报告

步骤 5：建立例外流程

有效的例外原因：

• 系统无法在不造成重大停机的情况下打补丁（安排维护窗口）
• 无供应商补丁可用（应用补偿控制）
• 补丁破坏关键功能（需要测试结果作为证据）
• 生命周期结束的系统待退役（记录风险接受）

例外要求：

• 书面理由及业务影响说明
• 补偿控制已记录并实施
• 由资产负责人和安全领导层批准
• 最长例外期限：90 天（可重新批准续期）
• 在漏洞管理平台中跟踪

关键绩效指标（KPI）

主要指标

KPI	定义	目标
SLA 合规率	在 SLA 内修复的漏洞百分比	>90%
平均修复时间（MTTR）	从发现到修复的平均天数	关键：<3 天，高：<10 天
漏洞积压	超过 SLA 的开放漏洞	<5% 总数
例外率	有活跃例外的发现百分比	<10%
复发率	修复后重新出现的漏洞百分比	<5%

趋势指标

• 按月 SLA 合规趋势
• 按严重程度的 MTTR 趋势
• 每资产漏洞密度（漏洞数/主机）
• 补丁覆盖率（已扫描且合规的资产百分比）
• 首次响应时间（发现确认）

最佳实践

1. 从可实现的 SLA 开始，随着成熟度提高逐步收紧
2. 使用自动化工单消除手动 SLA 跟踪
3. 为修复团队提供清晰的修复说明，而不仅仅是 CVE 编号
4. 在团队/部门级别跟踪 SLA 合规性以落实责任
5. 每月向高管层报告 SLA 指标
6. 将补偿控制纳入有效的临时修复措施
7. 使 SLA 与法规要求对齐（PCI DSS、HIPAA、SOX）
8. 根据威胁态势变化每年审查和调整 SLA

常见陷阱

• 设置团队无法满足的不切实际 SLA（造成 SLA 疲劳）
• 高管不执行 SLA 违规处理
• 未按分层差异化处理所有资产
• 未在 SLA 计算中考虑漏洞上下文（EPSS、KEV）
• 缺少例外管理流程（导致未跟踪的风险）
• 仅衡量合规率而不分析违规根本原因

相关技能

• prioritizing-vulnerabilities-with-cvss-scoring
• implementing-patch-management-workflow
• implementing-vulnerability-metrics-and-reporting
• implementing-exception-management-process