大约 60% 的漏洞入侵事件中，攻击者得手时其实早已有可用补丁。这一发现来自 J.P. Morgan 2026 年 7 月发布的报告“Patchmageddon”，它将问题从“是否有修复方案”转向“部署修复方案需要多长时间”。
那个窗口正在迅速缩小。同一份报告还指出，AI 工具可以对新发布的补丁进行逆向工程，并在几分钟内将其转化为可用的漏洞利用程序。可用补丁每多一天未部署，攻击者就多一天可乘之机。
对于在 Microsoft Intune 中管理的第三方应用来说，其中很多时间都花在打包上。IT 团队要下载安装程序、构建软件包、编写检测规则、测试并分配，然后针对每个应用和每次发布再把这一整套流程重复一遍。结果就是出现了没人计划过的补丁延迟。
以下说明利用窗口正在以多快的速度关闭、Intune 应用打包在哪些环节拖慢了进度，以及需要如何弥合这一差距。
如今攻击者利用新漏洞的速度有多快
利用漏洞如今已成为攻击者入侵最常见的方式。根据2026 Verizon Data Breach Investigations Report，漏洞利用占数据泄露事件初始访问的 31%，高于一年前的 20%。
其中许多攻击会立即开始。根据 Zero Day Clock，在 2026 年上半年新列为已遭利用的漏洞中，超过四分之一在公开当天就已经遭到攻击。
补丁更新没有跟上节奏。Verizon 发现，企业完全修复已知被利用漏洞的时间中位数为 43 天，高于之前的 32 天，而且其中只有约四分之一最终得到了完全修复。
旧漏洞也仍然在被利用。根据 Zero Day Clock 的数据，在 2026 年 8 月下旬的某一周内，攻击者针对的典型漏洞已经公开了四年。
以数周为单位的补丁周期，会让第三方应用在风险最高的时期持续暴露。从未发布的更新会让它们多年持续暴露在风险之中。
为什么现有补丁没有被应用
如果补丁已经存在，为什么还有这么多迟迟未部署？根据 TuxCare 的《2026 开源格局报告》，在企业开源软件用户中，61% 的安全事件都涉及已可用但从未应用的补丁。停机限制是导致延迟的最常见原因，43% 的受访者提到了这一点。
这项调查聚焦于开源环境，但无论 IT 团队在哪里部署更新，都会出现同样的原因：
担心弄坏什么东西。一次会干扰业务关键应用或迫使系统意外重启的更新，本身就会成为一起事故。在没有经过测试时，等待会让人觉得比部署更安全。
具备合适技能的人太少。正确打包 Win32 应用需要专业知识。当这些知识只掌握在一两个人手中时，每次更新都得等他们有空。
每次更新都是一个独立项目。第三方供应商按各自的时间表发布版本，而每次发布在推出前都需要同样 的准备工作。这些工作很难被整齐地集中处理，因此队列增长的速度往往快于缩减的速度。
没有证据表明补丁已成功部署。如果没有设备级确认，IT 就无法判断哪些端点仍在运行存在漏洞的版本，而这些缺口往往要等到有人专门去查时才会被发现。
Intune 应用打包拖慢第三方补丁管理的原因
虽然 Intune 能很好地处理 Windows 和 Microsoft 365 更新，但第三方应用更难管理。Microsoft 的 Enterprise App Management 通过提供一个预先准备好的 Microsoft 和非 Microsoft Windows 应用目录来帮助解决这一问题，Intune 可以让这些应用保持最新。不过，该目录只包含 Microsoft 已准备好的应用，而且 Microsoft 不保证会添加所请求的应用。
目录之外的应用、自定义和内部应用，以及未启用 Enterprise App Management 的租户，仍然会走标准的 Win32 流程。
对于每次新版本发布，这一流程通常如下：
从供应商处下载安装程序，并确认其版本和架构正确无误。
查找静默安装和卸载命令。Intune 要求 Win32 应用在无需用户交互的情况下安装，因此必须有人确定每个安装程序支持哪些开关参数。
使用 Microsoft Win32 Content Prep Tool 将安装程序封装为 .intunewin 文件。
编写检测规则，以便 Intune 确认应用已正确安装。
设置取代关系，让新版本替换旧版本。
在将其交付给用户之前，先在备用设备或虚拟机上测试该套件。
将应用分配给正确的组。
验证部署推出情况，并排查所有失败的设备。
接着，供 应商又会发布另一个更新，然后这一循环重新开始。把这些步骤乘以环境中的每个第三方应用，再乘以各自发布的每一个版本，Intune Win32 应用部署就会变成一项持续积压的工作。积压一旦形成，“可用”就会变成以周为单位的等待。
更快的第三方补丁流程需要什么
J.P. Morgan 的报告建议，企业应运行最新的软件版本，并缩短补丁测试和部署周期。对于 Intune 中的第三方应用，这归结为几个运营层面的要求：
第三方应用的最新清单。每次决定如何打补丁，都要先了解哪些设备上运行着哪些应用及其版本。
可信、经过验证的安装程序来源。从经过审查的来源获取安装程序，可降低部署被篡改或恶意软件包的风险。
自动化打包。应为每个版本自动生成静默安装和卸载命令、检测规则以及取代关系，而无需手写脚本。
自动检测新版本。当供应商发布更新时，应立即构建新软件包，而不必等到有人注意到该版本发布。
部署前进行自动化测试和安全扫描。在干净的机器上测试每个构建版本，可以消除团队推迟更新的一个主要原因。
分阶段推出。先部署到试点组，如果更新确实引发问题，也能将影响控制在较小范围内。
最终用户控制。延迟、重启提示和宽限期让更新得以推出，而不会在有人处理中断任务时打扰到对方。
部署状态和审计可见性。按设备提供的报告可确认每个补丁都已实际部署到位，并为审计保留记录。
衡量第三方补丁窗口的 几个问题
在更换工具或流程之前，先了解团队当前所处的状态会很有帮助。这些问题能显示出您的风险暴露窗口究竟有多大：
对于排名前 10 的第三方应用，从供应商发布到在 Intune 中分配，通常会经过多少天？这个数字就是实际的补丁窗口，而且往往比团队预期的更长。
团队中有多少人能正确打包 Win32 应用？如果答案是一两个人，那么每次更新都取决于他们是否有空。
您上一次因测试尚未完成而推迟更新，是什么时候？频繁延迟说明问题出在测试瓶颈，而不是排期。
能否证明补丁已覆盖每一台设备？如果没有针对每台设备的确认，看似已完成的更新仍可能让终端设备暴露于风险之中。
智能体包装如何缩短从发布到部署的路径
J.P. Morgan 的报告指出了一个很容易在各种警告中被忽略的重点：用于发现并利用漏洞的同类 AI 工具，也可以帮助修复这些漏洞。智能体包装将这一理念应用到了第三方补丁处理中最慢的环节。
在代理式打包工作流中，AI 代理会接手 Intune 应用打包中的重复性步骤。它们会读取安装程序，找出静默安装和卸载命令，构建安装包，并生成检测逻辑。然后，每次构建都会在一台干净的机器上进行测试，测试结果会先交由管理员审核，之后才会发布到 Intune。
10 月 21 日查看 agentic packaging 的实际演示
一个已经存在的补丁，只有在它能多快送达每台设备时，才真正有用。对于 Intune 中的第三方应用，这些时间中很大一部分都花在了打包上。
智能打包可免去每次发布中的重复性工作，让新版本无 需排队等待，就能完成测试并进入分阶段发布。
Splashtop 将于 10 月 21 日举办一场 30 分钟的网络研讨会“From Manual to Agentic Packaging: Simplifying App Deployment with Microsoft Intune”，时间为太平洋时间上午 8 点 / 美国东部时间上午 11 点。Microsoft MVP Maxime Guillemin 和 Splashtop 产品负责人 Brandon Shopp 将讲解 AI 和 agentic 工作流如何减少打包工作量与错误，其中还将展示 agentic packaging 的实际应用。
