补丁管理与 SLA

优先级排序会告诉您需要修复什么；补丁管理则是一套有纪律的流程，确保这些修复实际按时完成，并覆盖整个资产环境。

SLAs（服务级别协议）规定不同严重程度的问题必须在多长时间内完成修复。没有这些协议，紧急修复就会被拖延，责任也会逐渐落空。

可重复执行的周期有助于保持系统最新：

• 识别可用的补丁（厂商公告、扫描结果）。
• 评估补丁的适用性以及应用补丁的风险。
• 在非生产环境中测试。
• 以受控的批次部署。
• 验证补丁已成功应用且系统运行正常。

每个步骤都有负责人和证据，与更广泛的 VM 生命周期相呼应。

SLA 会把意图转化为截止期限。它根据严重程度分级，规定从发现到修复所允许的最长时间。例如：

• 严重 / KEV：7 至 15 天（面向互联网的资产需要更快）。
• 高危：30 天。
• 中危：90 天。
• 低危：尽力而为 / 下一周期。

SLAs 让问题持续时间变得可衡量，并推动团队关闭问题，而不只是确认问题存在。

请让时限与实际风险关联，而不只是与 CVSS 关联。列入 KEV 或面向互联网的严重漏洞，其 SLA 应比内部环境中的中危漏洞更严格。

相关框架可以提供参考：CISA 要求联邦机构在规定期限内完成 KEV 修复，许多企业也会针对正在被利用的漏洞采用类似的加速时限，无论其 CVSS 评分如何。

补丁可能会破坏现有功能。在预发布环境中进行测试，可以在问题影响生产环境前发现回归：

• 先应用到具有代表性的测试组。
• 验证关键功能和性能。
• 确认不会与现有软件发生冲突。

请在速度和安全之间取得平衡：对于已在野外被利用的 KEV 漏洞，应接受更多风险并比例行更新更快地打补丁。

请分批部署（环形部署）：先部署到试点组，再逐步扩大范围，最后覆盖全部系统。在进入下一批次前，请监控当前批次的运行状况。

请始终准备好回滚计划：包括快照、软件包降级或配置恢复。如果补丁导致服务中断，您必须能够在调查期间快速恢复。

手动打补丁无法扩展到大规模环境。请使用集中式工具：

• Windows 使用 WSUS / SCCM / Intune。
• Linux 资产群使用配置管理工具（Ansible、Puppet、Chef）。
• 为云环境和容器使用应用补丁后重新构建的黄金镜像或基础镜像。

自动化能够保持一致性，并缩短补丁发布到部署之间的时间窗口。

有时您无法立即打补丁：可能是厂商延迟、脆弱的旧系统，或必须保持系统可用。请在此期间应用补偿性控制措施来降低风险：

• 网络分段 / 防火墙规则。
• 通过 WAF 或 IPS 特征进行虚拟补丁防护。
• 禁用存在漏洞的功能或服务。

这些措施可以争取时间，但不能永久替代真正的修复。

生命周期结束的系统可能根本没有可用补丁。可采取以下措施：

• 将其隔离在受限的网络分段中。
• 使用严格的访问控制和监控对其进行保护。
• 制定迁移或退役计划，并设定截止期限。
• 正式接受剩余风险，并设定到期日期。

请记录所有内容；未记录的无法打补丁系统会带来审计风险和安全事件风险。

请跟踪该计划是否真正履行了承诺：

• 按严重程度统计 MTTR，并与 SLA 目标比较。
• SLA 合规率（在截止期限内关闭的比例）。
• 按团队和资产统计逾期 / 持续时间较长的发现项。
• 补丁覆盖率（资产群中保持最新的比例）。

请按负责团队进行报告，使责任清晰可见，并让进展缓慢的领域得到关注。

部署后请验证：重新扫描以确认该 CVE 对应的问题已消失且系统运行正常，然后使用证据关闭发现项。请将反复出现的问题（例如某个不断重新出现的库，或长期延误的团队）反馈到流程改进中。

完善的补丁管理能够将已排定优先级的风险转化为可衡量、按时完成的风险降低成果。

请确认修复 SLA 的作用。

补丁管理通过识别、评估、测试、分阶段部署和验证，推动已排定优先级的发现项完成修复，并以回滚计划和自动化作为保障。SLAs 根据严重程度和风险等级设定截止期限（对 KEV 或面向互联网的项目要求更严格），确保修复按时完成。

无法打补丁时，请使用补偿性控制措施，并以有记录且设定时限的方式接受风险。请衡量 MTTR、SLA 合规率和覆盖率，并将经验反馈到整个生命周期中。