Ivanti 博客: 补丁管理

要提升安全成熟度，请重新审视您的漏洞修复能力

Thu, 28 May 2026 14:00:05 Z

安全团队正被海量漏洞淹没。我们说的是每个季度数以万计的发现项；在大型组织中，这一数字可能达到数十万。如今的 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 暴露面管理成熟度模型。

我们正处于补丁末日。这意味着这三个 IT 借口将不再奏效。

Wed, 29 Apr 2026 14:00:07 Z

4 月 7 日，Anthropic 宣布，其 Claude Mythos Preview 模型已在各大主流操作系统和主流 Web 浏览器中自主识别出数千个高危和严重级别的零日漏洞。其中超过 99% 在披露当天尚未修补。

两周后的 4 月 21 日，Mozilla 表示已使用同一模型在最新版 Firefox 中发现并修补了 271 个漏洞。Mozilla 自己的评估是：“到目前为止，我们还没有发现任何一种人类能够发现、而该模型无法发现的漏洞类别或复杂程度。”

271 个漏洞只是第一波。Chrome、Edge、Windows、macOS、Linux、FreeBSD——Anthropic 红队披露的 FreeBSD 中存在了 17 年的远程代码执行漏洞（CVE-2026-4747），只是未来趋势的一个早期例子。Anthropic Project Glasswing 旗下的每一家供应商都有望以前所未有的节奏发布修复程序。所有这些修复都会成为带有可用补丁的公开 CVE，并最终指向同一个地方：您的环境。

围绕控制范围的说法也出现了裂痕。4 月 21 日，彭博社报道称，一个与 Discord 相关的组织通过第三方供应商环境未经授权访问了 Mythos。Anthropic 表示，该活动并未扩展到该供应商之外。无论类似能力是否已经落入攻击者手中，防御方的准备时间都比 4 月 7 日公告所暗示的更短。

Mythos 进入的是一个本已朝这个方向发展的世界。CrowdStrike《2026 年全球威胁报告》记录显示，2025 年 AI 赋能攻击同比增长 89%。这一趋势线早在 Mythos 出现之前就已经存在。

不妨称之为补丁末日。这是一种很现实的运营层面挑战：带有可用补丁的公开 CVE 数量和发布节奏，即将超出大多数 IT 和安全团队现有工作方式的承受范围。

NIST 已经感受到补丁末日的影响。4 月，该机构宣布对国家漏洞数据库（NVD）的运营进行重大调整，以应对提交量激增 263% 的情况。NIST 将不再为所有提交的漏洞提供详细增强信息，而只会为符合高风险标准的漏洞提供此类信息，例如 CISA 已知被利用漏洞目录中的漏洞，或影响关键政府软件的漏洞。NIST 将依赖 CVE 编号授权机构（CNA），例如 Ivanti，而不是自行开展独立评估。

自公告发布以来，我从客户和同行那里听到了同一种回应的三个版本。这三种说法本质上都是为一个节奏更慢的世界设计的方案。

“我们有漏洞扫描器”

Qualys、Rapid7 和 Tenable 在漏洞发现方面表现出色。扫描器可以发现、标记、评分并列出漏洞。但部署、验证、重启处理和回滚都不在其范围内。这些工作仍然必须在某个地方完成。在大多数项目中，它们会在另一个工具中、由另一个团队、按照另一个节奏来完成。

如今，漏洞利用窗口已缩短到以小时计算，而 Glasswing 队列又即将让积压量翻倍；如果扫描器生成 587 个严重漏洞并把清单交给人工团队处理，它就会成为一种负担。务实的做法是，将您已有的扫描器连接到可根据其发现结果自动采取行动的修复引擎。一个自主端点管理（AEM）平台，具备分环部署和回滚能力，并利用漏洞情报为高效修复决策提供基于风险的背景信息，从而在无需人工逐项决策的情况下缩短漏洞清单。

“我们通过工单系统推进审批”

说到必须由人来做决策……冗长的线性审批流程将显著拖慢修复进程。您上一次需要决定是否部署最新操作系统或浏览器更新是什么时候？

组织其实已经知道这些更新是要部署的。审批流程往往源于复杂的内部政治因素以及安全结果上的不一致。最终结果是什么？一个非常线性的流程：需要前面提到的漏洞扫描器，需要分析师批准一项您已经知道必须完成的工作，需要向业务负责人发送工单并在收件箱中等待批准，最终把宝贵时间浪费在一个本质上已经非常明确、并不真正需要再做的决策上。

市场正在转向暴露面管理，它以截然不同的方式处理这一流程，重点是定义组织的风险偏好并监测风险态势。下次 Windows 操作系统更新发布时，您已经知道会部署它、会按什么计划部署，以及会用哪些 SLA 和合规指标来衡量成功。您真正想知道的是：

1. 是否需要加快速度，因为该更新包含已知被利用的漏洞？

或者

2. 该更新是否正在影响运营，因此我们需要放慢速度（好在自主端点管理平台包含带回滚能力的分环部署）？

“我们有 Intune”

Microsoft Intune 在这里有两个重要的范围限制。

第一，它只管理已注册到 Intune 的设备。未注册和未受管的端点——服务器、承包商笔记本电脑、影子 IT、被忽视的边缘设备——完全不在其可见范围内。在漏洞数量上升期间，这些盲点的增长速度会超过团队手动处理的能力。

第二，虽然 Intune 简化了应用程序部署和更新，但其第三方应用程序覆盖范围和优先级排序深度比大多数管理员意识到的更窄。Intune 可以告诉您哪些内容已过期，但不能告诉您哪些因素真正增加了您的暴露风险——这迫使团队在时间紧迫时被动地修补一切，或者依靠猜测行事。

大多数企业环境并非只有 Windows，也并非所有设备都已完整注册，更不是只运行一个小而同质的应用程序栈。当漏洞披露激增时，按常规流程分派补丁会留下缺口，并演变成系统性风险。

保留 Intune。将它与一个发现和修复层配合使用，该层可以发现 Intune 看不到的资产，优先处理最关键的漏洞，并在 Intune 未覆盖的应用程序中可靠地应用补丁。

该如何应对

自动化就是运营模式。它必须内置到工作流中。

从业者早已理解这一原则。它体现在三个方面：

持续分诊。已知被利用的漏洞可以走零日响应通道，尤其是在组织中安全性较弱的部分，例如终端用户系统。在此之上，设定并明确浏览器和通信应用等特定应用程序，使其进入优先更新通道，并每周甚至每天检查。其他内容可以等待常规维护窗口到来。
带自动回滚的分环部署。测试环、早期采用者环、广泛生产环境、任务关键环境。这个顺序并不新鲜，但对大多数维护工作都有效。变化在于，某些更新需要压缩时间以适应漏洞利用窗口，而不能等到每月维护。测试环必须实现自动化并具备检测能力——人工检查清单跟不上这样的速度。
闭环验证。只有在确认补丁已安装到端点后，才算完成部署；只有在重新扫描确认后，CVE 才算关闭。大多数团队会跳过这一步，这也是为什么合规证据会在审计前一周变成一场救火。正因如此，我们本周在平台中推出了持续合规功能——在补丁部署过程中持续、自动生成合规证据，并由自动化处理大多数团队无暇完成的优先级决策。

Mozilla 的 271 个 Firefox 漏洞只是一个预告。Glasswing 旗下的每一家主要软件供应商都将开始以更快速度修复更多漏洞；而一旦攻击者获得类似模型的访问权限，具备同类能力的攻击者就会寻找这些确切的入口。由此产生的 AI 军备竞赛将直接影响组织需要修复的更新数量和频率，并且节奏会进一步加快。自动化才是支撑项目走下去的关键。仍然只按月打补丁的团队，将面临一段艰难时期。

如果您负责 IT 或安全项目，现在就值得进行一次自我评估。回顾上一次推出的关键补丁。更进一步，如果某个零日漏洞在周五披露，您能否在周一之前完成修复？从 CVE 发布到最后一个端点完成验证安装，计算这段时间。如果这个数字是以周为单位，补丁末日就会找上门来。

AI 驱动的自动化如何破解补丁管理孤岛

Thu, 02 Apr 2026 15:37:11 Z

“我们发现了 10,000 个严重漏洞！”

“我们上周已经完成了所有补丁修复！”

这样的对话每天都在企业 IT 部门上演。安全团队展示的是充满红色警报的仪表板。IT 团队展示的是成功率达 98% 的部署报告。双方看到的都是真实数据。双方都完全正确。同时，双方也都无法全面了解整个端点环境中实际发生的情况。

这不是人员问题——您的团队并非能力不足。这也不是流程问题——您的工作流并未失效。这是技术问题：您要求两个团队使用呈现不同现实的系统来管理同一项风险。

安全团队通过漏洞扫描器和威胁情报看到的是一种现实。与此同时，IT 团队在查看设备管理和补丁部署报告时，看到的又是另一种情况。

棘手之处在于，这两种视角单独来看都可能是正确的，但在实际操作中仍可能产生误导。于是就会出现熟悉的僵局：安全团队报告有数千个严重漏洞；IT 团队报告补丁已成功部署。脱节正存在于这些系统之间的缝隙中。

为什么 IT 与安全团队在补丁修复上难以保持一致

大多数组织在应对 IT 与安全团队之间的补丁修复错位时，通常会选择改善 IT 与安全团队之间的沟通。他们安排更多会议，建立升级路径，实施 SLA。六个月后，他们仍在争论同一个问题，只是 PowerPoint 做得更好了。

有一点很少有人愿意承认：单靠协作无法解决数据碎片化问题。当 IT 与安全团队基于完全不同的清单来判断哪些资产存在、哪些存在漏洞以及哪些已经修复时，增加更多协调工作只会拖慢一个本已失效的流程。

这正是许多组织内部反复出现同样对话的原因。两个团队都对自己的数据充满信心，并且在其依赖工具的狭窄语境中，双方都是“正确”的。

问题也正在于此。虽然两种视角都“正确”，但都没有反映风险的完整生命周期。漏洞数据并不总能反映受影响设备是否已纳入管理或是否可访问。补丁报告也并不总能覆盖仍可访问企业资源的未管理、误分类或新发现的端点。缺少的是对真正关键问题的可靠回答：哪些端点此刻正处于暴露状态？

技术孤岛造成相互冲突的现实

大多数企业通过一组长期独立演进的零散系统来管理端点，而每个系统都只捕捉到现实的一部分。

一个系统可能会暴露严重风险，却不知道该设备是否正在被管理。另一个系统可能会确认修复成功，却没有将仍具备访问权限的新发现或误分类端点纳入考虑。结果是什么？无法以可靠方式追踪风险从发现、部署到实际暴露的全过程。

请看这一点：根据 Ivanti 的《保护无边界数字环境报告》，一般组织平均只管理 60% 的边缘设备。这意味着 40% 的潜在入口点处于 IT 视野之外，也不在其补丁工作流之内。安全团队能看到它们，IT 团队看不到。这就是您的漏洞缺口。如果缺少这种连续性，团队就只能手动对齐局部视图。数据被反复争论，而不是被付诸行动。

不同的数据视图会引发摩擦

试想一个周一早晨：安全团队在一款广泛使用的 VPN 客户端中发现了一个严重的零日漏洞。他们向 IT 发送紧急警报：“检测到 30,000 个存在漏洞的端点——请立即修补。”

IT 查看其部署控制台：“VPN 客户端已于上周四在 28,000 台设备上完成更新。”

这两种说法都是真的。安全团队扫描的是整个网络——包括承包商笔记本电脑、BYOD 设备，以及曾短暂连接到 VPN 但未纳入 IT 管理的系统。IT 团队则对其设备清单中的所有设备完成了补丁修复。

与此同时，2,000 个确实存在漏洞的端点仍处于暴露状态，因为它们存在于安全团队的视图中，却不在 IT 的视图里。原本应在 24 小时内完成的补丁修复，现在需要三天的手动对账。

当 IT 与安全团队基于不同的数据源开展工作时，漏洞管理优先级错位就不可避免。安全团队关注漏洞数量、严重性评分和利用情报。IT 团队则优先考虑部署成功率、系统稳定性和用户影响。这两种视角都不可或缺，但如果缺少共同的参照框架，它们就会朝不同方向发力。

随之而来的不仅是紧张关系，更是决策停滞。团队在对齐清单、验证发现结果并争论范围时，修复速度会放慢。漏洞开放的时间超过应有时长，并不是因为没有可用补丁，而是因为缺少一个能够连接检测、部署和暴露状态的统一视图。

补丁优先级错位带来的风险

错位会减缓协作，更重要的是，它会造成可衡量的风险，其影响远超内部摩擦。

Ivanti 的自主端点管理研究在实践中反映了这一挑战：

38% 的 IT 专业人员表示难以跟踪补丁状态。
35% 的受访者因端点可见性不完整而难以按时完成修复。

当漏洞开放时间超过必要范围时，暴露窗口就会扩大。攻击者不会等待。CISA KEV 目录揭示了一个严峻事实：当前正在被主动利用的漏洞中，有 30% 最初是在五年多前披露的。

这不是补丁修复问题，而是可见性问题。组织并非忽视可用补丁，而是遗漏了仍然需要这些补丁的端点。

延长的暴露窗口与数据泄露风险

碎片化会以不易察觉的方式拉长暴露窗口。未曾纳入管理平台的设备，例如影子 BYOD、未受保护的承包商设备，或传统边界之外的远程端点，往往不会被发现。

Ivanti 的研究显示，只有三分之一的雇主为远程员工实施了零信任网络访问，这使分布式环境中的可见性存在显著缺口。新发现的端点会在补丁报告生成后出现。系统会在扫描周期之间偏离合规状态。每一次延迟都会叠加风险，延长攻击者武器化已知弱点的时间。

常见补丁后问题与 IT 工单过载

即使补丁按计划部署，手动补丁修复也经常引发后续问题。更新失败、代理损坏、性能问题和意外重启会触发支持工单和紧急修复。原本是一项安全任务，很快就会成为运营负担。

IT 团队把时间花在解决可预见的故障上，而不是改善端点态势。安全团队将延迟视为未解决的风险。用户则把补丁修复与干扰联系在一起。即便团队目标一致，这种摩擦仍会持续存在。

利用自主端点管理变革补丁管理

AI 和自动化通过统一可见性并减少手动协调，解决补丁管理中的核心脱节问题。当端点发现、漏洞数据、设备运行状况和补丁状态被关联到统一视图中时，IT 与安全团队就可以基于相同事实开展工作，而不必在不同工具之间对齐局部数据。

自主端点管理 (AEM) 通过 AI 智能和自动化，为 IT 与安全团队提供一个持续更新的端点、运行状况和暴露状态统一视图，让混乱局面变得清晰。

AI 如何改进补丁决策

AI 通过基于真实风险而非仅凭严重性评分来确定漏洞优先级，从而改进补丁决策。通过纳入利用活动、资产关键性和暴露背景，团队可以就应优先修补哪些漏洞达成一致，并将精力集中在最快降低风险的领域。

借助自主端点管理，同样的周一早晨场景会有不同的发展：

漏洞被检测到后，AI 会立即将其与统一端点清单进行交叉比对。它识别出 1,560 台运行易受攻击版本的设备，其中包括 217 台此前未受管理的设备。

自动化补丁工作流会同步执行多项操作：纳入未管理设备，根据暴露风险和资产关键性确定补丁优先级。随后，它们会在低使用率时段安排部署，并开始按环分阶段推出。

等到安全团队发送警报时，IT 已经拥有一个显示修复正在进行的实时仪表板——其中包含相同的设备数量、相同的暴露数据以及相同的优先级逻辑。无需再进行对账。

自动化如何加速修复

自动化随后将这些决策转化为行动。补丁工作流可以实现端到端编排：识别受影响设备、部署更新并验证修复结果，无需持续的人工干预。

AI 驱动的智能补丁调度通过使部署与设备使用模式、维护窗口和运营约束保持一致，将对用户的影响降至最低。按环分阶段推出可先在较小范围内验证补丁，再进行更广泛部署，从而在减少中断的同时加速修复。其结果是补丁修复更快、停机时间更短，并为两个团队带来更可预测的流程。

自修复工作流可自动检测并解决常见问题，例如重启服务、重新安装代理或纠正配置错误。这些工作流能够在可避免的事件转化为支持工单之前将其阻止。

从数据争论走向统一智能与共享可见性

AI 驱动的平台通过将发现数据、漏洞背景、设备运行状况和补丁状态关联到单一端点记录中来统一端点可见性，并通过注册与访问控制确保设备在整个生命周期中持续被发现和管理。IT 与安全团队能够实时看到相同的设备、相同的暴露状态和相同的修复状态。

这种统一智能消除了围绕谁的数据正确的争论，并将其转化为对优先处理哪些风险的共识。通过将修复集成到更广泛的端点工作流中，团队可以减少手动工作，并在规模化环境中保持一致的补丁结果。通过将修复集成到更广泛的端点工作流中，团队可以减少手动工作，并在规模化环境中保持一致的补丁结果。

共享补丁责任：推动 IT 与安全团队协作

只有与共享责任相结合，AI 和自动化才能真正改进补丁管理。当 IT 与安全团队基于相同的端点数据和修复工作流开展工作时，责任就会从维护各自报告转变为共同降低暴露风险。

数据驱动的补丁流程始于共同目标。组织不再在孤立工具中跟踪成功与否，而是围绕能够反映真实风险和运营影响的共同指标来协调 IT 与安全团队。这种共享衡量方式可明确优先事项，并消除围绕责任归属的模糊性。

有效协作取决于两个团队都信任并共同采取行动的指标。常见 KPI 包括：

平均修复时间 (MTTR)：衡量严重漏洞的解决速度
补丁合规率：覆盖已管理和此前未管理的端点
暴露持续时间：高风险漏洞保持开放状态的时长
端点可见性：已被全面发现和管理的设备百分比

这些指标将对话从补丁数量转向可衡量的风险结果，帮助团队关注成果，而不是活动本身。

共同责任需要覆盖整个补丁生命周期的工作流。AI 驱动的平台通过自动执行常规任务，同时呈现需要人工判断的异常情况来提供支持。

IT 与安全领导者为自动化定义护栏，包括审批阈值、测试要求和推出约束。在这些边界内，自动化能够以一致且可规模化的方式执行修复，而无需持续的手动协调。随着时间推移，对流程的信任会增强，协调开销会减少，补丁修复也会从摩擦点转变为一项协同的运营责任。

访问我们的解决方案页面，了解 Ivanti 自主端点管理解决方案如何为 IT 与安全团队提供所需的统一可见性，帮助他们消除补丁修复孤岛并更快关闭漏洞。