两个人在办公室查看一台笔记本电脑,屏幕上显示“优先修复列表”图表,展示漏洞级别和操作措施,背景中还有其他人在工作。

安全团队正被海量漏洞淹没。我们说的是每个季度数以万计的发现项;在大型组织中,这一数字可能达到数十万。如今的 IT 环境已没有明确边界,并横跨各种操作系统平台。以线性方式管理和保护这些资产已不再可行,把每一次修复都视为简单、低影响任务的漏洞修复流程同样不可行。

基于风险的优先级排序通过将威胁背景和业务背景引入漏洞修复流程,帮助团队从噪声中理清重点。这是向前迈出的重要一步。但许多采用了基于风险优先级排序的组织,仍然无法满足 SLA,仍然与 IT 产生摩擦,并且仍眼看着例外事项比修复更快地堆积起来。

知道先修复什么,只是问题的一部分。

更困难、也是许多计划仍然欠缺的,是了解这项修复在现实环境中的影响。更重要的是,如何在平衡风险与影响的同时,将修复从每月一次加速为持续流程。

这就是运营平衡型修复:在承诺实施修复之前,先权衡该修复在现实环境中的影响。它是许多漏洞修复计划中缺失的关键环节,也是暴露面管理成熟度最明确的标志之一。Ivanti 暴露面管理成熟度模型将其确定为区分成熟安全计划与被动响应式安全计划的六项核心能力之一。

什么是运营平衡型修复?

成熟度模型对它的定义很简单:以既有效又切实可行的方式修复或缓解暴露项的能力。也就是在安全紧迫性与系统正常运行时间、补丁测试和业务连续性等 IT 现实之间取得平衡。

在实践中,它可以归结为一个等式:安全风险加上现实影响,等于有依据的修复决策。如果无法修复暴露项,识别它们就没有价值。而导致计划外停机、破坏生产系统或触发回滚的修复,并没有降低风险,只是转移了风险。

漏洞修复成熟度之旅:从被动响应到战略化

第 1 阶段:传统漏洞管理(扫描与打补丁时代)

许多组织的漏洞修复正是从这里起步的,也有许多组织至今仍停留在这里。优先级排序由 CVSS 驱动,并遵循先进先出原则。扫描器会告诉您“您有 10,000 个 CVE”,却不会提供哪些漏洞真正重要的背景信息。

例外事项没有记录。漏洞扫描和修复工作流存在于不同工具中,集成程度极低。

其结果就是被动响应模式:追逐最新的高关注度披露信息,而不是处理对环境构成最大风险的问题。

第 2 阶段:基于风险的漏洞优先级排序(增加背景信息)

基于风险的优先级排序提出了两个更好的问题:“这个漏洞是否正在被主动利用?”以及“它影响的资产有多关键?” 将严重性与威胁情报和资产关键性相结合,让安全团队能够更精准地聚焦漏洞修复工作。AI 驱动的漏洞情报和补丁可靠性评分进一步加速了这一流程,减轻了以往迫使安全团队在数据不完整的情况下做出优先级判断的手动分析负担。

但仍然缺少一块关键拼图。基于风险的优先级排序告诉安全团队要修复什么,却没有说明 IT 需要保持哪些系统持续运行。两个团队之间的协作仍常常逐案进行,而修复对 IT 运营的影响仍然是事后才考虑的问题,更多时候甚至成为阻碍组织加速修复活动的拖累。

第 3 阶段:缺失的关键环节——运营平衡型修复

对于已经具备成熟能力、能够理解某个暴露项现实风险的组织而言,他们接下来会问:“这项修复会对我们需要保持运行的系统产生什么影响?我们是否能够承受继续让其暴露的风险?”

如果在不考虑下游影响的情况下强行进行漏洞修复,结果就是停机、IT 抵触,以及不断增长的例外事项积压,最终削弱推动这种紧迫性的安全目标本身。

Ivanti 2026 年网络安全现状报告发现,48% 的安全专业人员表示 IT 团队并未紧急响应网络安全问题,40% 的人认为 IT 对其组织的风险承受能力缺乏了解。当安全和 IT 优先事项不同,又没有共同的解决方式时,就会出现这种情况。

最成熟的计划不仅通过流程对齐来解决这一问题,还通过自动化消除容易积累摩擦的手动交接环节。自动化自修复功能能够主动检测、诊断和修复端点及网络安全卫生问题。这首先减少了需要人工分诊的漏洞数量。当修复内置于端点运行方式之中,而不是事后附加上去时,安全紧迫性与 IT 能力之间的差距会自然缩小。

这里的成熟度指标很清晰:安全与 IT 之间共享的 KPI、记录在案的例外流程,以及同时兼顾风险降低和业务连续性的漏洞修复跟踪系统。要持续实现这一点,IT 和安全团队必须基于共享数据和共享工作流开展工作。

当资产可见性、暴露项聚合、基于风险的优先级排序和修复都在统一平台上运行时,第 3 阶段所要求的对齐就会成为系统的结构性属性,而不是艰难争取而来的文化成果。

运营平衡型修复与基于风险的优先级排序有何不同

理解这种演进最简单的方法,是看每种方法能够回答哪些问题。

方法

它能回答的问题

它忽略的内容

传统漏洞管理(VM)

存在多少漏洞?

背景信息和优先级排序

基于风险的优先级排序

哪些漏洞构成的风险最大?

运营可行性和影响

运营平衡型修复

在同时考虑安全风险和运营约束的情况下,我们应该先修复哪些漏洞?自动化如何确保这些修复高效且无中断地执行?

最全面的方法

这种方法为漏洞修复管理增加了一层背景信息:补丁测试要求、系统依赖关系、维护窗口、潜在停机时间和回滚能力。这些因素决定了一项修复是否能够站得住脚,还是会制造需要回滚的新问题。

为什么运营平衡型修复是暴露面管理的核心

成熟度模型确定了六项核心能力:资产可见性、资产重要性、现实环境中的漏洞评估、业务驱动的漏洞优先级排序、运营平衡型修复,以及数据/工作流集成。

在这些能力中,运营平衡型修复是让其他能力转化为行动的执行层。

没有它,暴露面管理就停留在理论层面。您可以构建完美的资产清单,精确评估每一个漏洞,并生成看起来令人印象深刻的仪表板。

但如果漏洞修复流程仍然割裂,就会在安全与 IT 之间制造摩擦,已知风险会不断累积,补丁会被延迟,而这些仪表板上的指标也不再反映真实的风险态势。

成熟度的演进路径从临时性的优先级排序(第 1 阶段),到逐案协作(第 2 阶段),再到由共享 KPI 驱动的修复(第 3 阶段),最终发展为经过审计的回顾复盘和持续改进闭环(第 4 阶段)。并非每个组织都需要在每项能力上达到第 4 阶段。但从临时性方式迈向共享、KPI 驱动的修复,才是真正产生收益的地方。

商业价值:平衡安全目标与运营目标

缺乏运营背景的修复所带来的隐性成本

当漏洞修复完全由安全紧迫性驱动时,成本会以看不见的方式不断累积,直到演变成系统性问题。

计划外停机是最明显的成本:关键业务系统在没有适当影响评估的情况下被下线。但其下游影响同样具有破坏性。

当安全要求在实践中难以执行时,IT 团队会建立变通方案,形成影子流程,反而增加风险而不是降低风险。当例外事项多于合规案例时,例外疲劳就会出现,使 SLA 失去意义。当双方把对方视为鲁莽或阻碍时,安全与 IT 之间的信任也会被侵蚀。

Ivanti 的研究证实了这种摩擦的普遍程度。39% 的网络安全专业人员表示,他们在确定风险修复和补丁部署优先级方面面临困难,35% 的人表示难以维持补丁合规性。

与此同时,仅有 60% 的受访者使用业务影响分析为风险优先级排序提供依据,只有 51% 使用网络安全暴露评分或基于风险的指数。

许多组织仍然依赖平均修复时间或已修复暴露项百分比等流程指标。这些指标孤立来看可能表现良好,却很少能说明漏洞修复流程是否真正改善了风险态势。

运营平衡型自动化漏洞修复的投资回报率

当组织完成这种转变时,成效会很快显现。共享 KPI 推动形成现实可行的修复时间表,进而提升 SLA 合规性。当部署障碍能够被提前预期,而不是在推出过程中才被发现时,平均修复时间就会下降。

修复能够长期有效,因为它们考虑了系统依赖关系和维护窗口,而不是制造需要回滚的新问题。分环部署就是一个很好的例子:补丁会逐步推送到更大的群组,并在每个阶段经过验证后再继续扩展。这正是平衡式修复能够落地的原因。

结合能够处理关联、分诊和部署编排的自动化工作流,这些机制将平衡式修复从概念转变为一个持续运行的系统。当平台承担运营复杂性时,安全团队就能减少管理修复流程的时间,把更多时间用于验证结果。

在 Ivanti 模型中达到第 3 阶段或第 4 阶段成熟度的组织,会使用同时反映安全和运营结果的指标来跟踪漏洞修复:

  • 按已知被利用漏洞与传统严重性分类拆分的 SLA
  • 已被利用漏洞的平均修复时间(MTTR)
  • 由安全和 IT 共同审核的例外请求百分比
  • 重复例外事项随时间减少的幅度

其战略价值还不止于此。当漏洞修复管理能够考虑 IT 需要保持哪些系统运行时,安全就不再被视为阻碍者,而是开始成为业务推动者。这种转变能够释放对暴露面管理的持续投资和高管支持。

从优先级排序到执行:弥合差距

基于风险的漏洞优先级排序是一项必要演进。但它只解决了问题的一半。如果修复行为本身会造成停机、阻力或不断增加的未记录例外事项,那么知道先修复什么的价值就会受到限制。

运营平衡型修复通过让安全和 IT 按照同一套行动方案协同工作来弥合差距。这体现在共享 KPI、明确定义的例外事项,以及保护业务连续性的维护窗口中。它还意味着自动化修复工作流,使其能够在潜在停机成为问题之前识别并避免风险。

借助优先级排序、洞察生成和编排,修复可以跟上环境变化的节奏,而不是被环境甩在后面。借助连接端点和安全数据的统一平台,团队不再与孤岛作战,而是同步推进。

如需更深入了解如何评估贵组织当前的成熟度,并制定有针对性的增长计划,请参阅Ivanti 暴露面管理成熟度模型