下一个 CVE 落地前，先做一次补丁管理自查

补丁管理最麻烦的地方在于：**它在出事之前，一直是隐形的。**​

平时没人会问"我们的补丁覆盖率是多少"，直到某台终端被勒索软件加密、某个漏洞被挂到资产清单上，问题才会从"怎么修复"变成"为什么没修"。

IDC 的数据是，终端安全事件中有 67% 源于补丁管理不及时。这个比例说明一件事：多数补丁事故不是卡在技术能力上，而是卡在流程上——清单不全、时限没定、例外没人管、部署完没验证。

ManageEngine（卓豪）官方博客近期发布了一份补丁管理审计清单，用 14 个问题帮团队在下一个 CVE 到来之前，把隐形的问题显性化。这篇文章把它整理成中文，并补上国内企业经常漏掉的三件事。

一、自查的价值：把"事后解释"提前成"事前修补"

先说清楚这份清单不是什么。

它不是一次合规打分，也不要求每一项都是"是"。它的用法是：**拿着这 14 个问题，去找真正对答案负责的人，逐条对。**​

其中回答"否"和"不知道"的，价值最高——它们直接指出了需要调查的方向。一份全是"是"的清单通常不是因为做得好，是因为问的人不对。

还有一个容易被忽视的前提：**补丁管理的失败，多数不是工具不够，而是清单不全。**​ 装了补丁管理软件，不等于知道网络里到底有多少台设备、装了什么软件、谁负责。这也是为什么清单把"清单与可见性"放在最前面——后面所有问题都建立在它的基础上。

二、清单与可见性（第 1–4 问）

第 1 问：设备清单是不是最新的？有没有覆盖未纳管设备和 BYOD？

如果你的答案是"一个季度更新一次的表格"，那你看到的是历史快照。不在清单里的设备可能照样在收更新，但你的团队无法可靠地验证它们的补丁状态。要分清三件事：哪些设备你完全纳管、哪些只是监控、剩下的谁负责。

第 2 问：清单是否覆盖第三方软件和开源组件，而不只是操作系统？

只跟踪操作系统更新的清单，等于把应用层漏洞放在视野之外。浏览器、办公软件、开发工具、以及应用里内嵌的第三方库都要算——**一个内嵌的脆弱组件，可能根本不会以"单独安装的软件"形式出现在清单上。**​

第 3 问：能不能分清哪些系统是对外暴露的，哪些是纯内网的？

优先级取决于暴露面。同样的一个漏洞，能被互联网触达的那台，紧迫性明显高于隔离内网里的那台。如果你分不清暴露与否，你的排序里就有一大块是在猜。

第 4 问：云主机、虚拟机和容器有没有纳入修复范围？责任归属清楚吗？

短生命周期的资源最容易从为长生命周期设备设计的流程里漏过去。对容器和不可变基础设施，修复可能意味着重建镜像再重新部署，而不是给运行中的实例打补丁。同时要明确：哪些由你的团队负责，哪些由云厂商或服务商负责。**攻击者的扫描器不会因为责任不清就放过你。**​

三、流程与 SLA（第 5–8 问）

第 5 问：有没有按风险定义的修复时限，并且真的在拿它做度量？

"尽快打补丁"不是 SLA。时限要综合利用证据、暴露面、业务重要性和严重等级来定。比如有的组织会要求：对外暴露的关键系统上、正在被主动利用的漏洞，必须在 72 小时内处置。这是内部目标，不是通用标准——关键是把"计时从什么时候开始"和"例外怎么升级"写清楚。

第 6 问：能不能在主维护窗口之外做紧急补丁或缓解措施？

漏洞不会挑时间。周四下午爆出一个正在被利用的漏洞，等到下周二窗口期，中间那几天就是不可接受的暴露。如果没有补丁，应对方式可能是厂商建议的临时规避、限制访问或临时隔离服务。审批依然要走，但紧急通道需要有明确的决策人和周转时限——**并且要知道实际要走多久，而不是纸面上写多久。**​

第 7 问：补丁例外有没有正式登记、限期和复核？

每个补丁项目都有确实无法按期修补的系统。要记录原因、涉及资产、责任人、补偿性控制措施和下次复核日期。一个两年前批出去、再也没人看过一眼的例外，很可能已经变成了一次"没人明确接受过"的永久暴露。

第 8 问：和第三方厂商、托管服务商（MSP）的合同里，补丁责任和时限写清楚了吗？

如果某个厂商替你管着系统，你内部的 SLA 不会自动约束他。要在合同里约定修复时限、紧急通知、例外处理和完成证据。这一条在国内尤其容易被跳过——把运维整体外包出去，不等于把风险也外包出去了。

​

四、风险排序（第 9–11 问）

第 9 问：有没有把 CISA 的已知被利用漏洞目录（KEV）和 CVSS 评分、资产上下文结合起来用？

CVSS 基础分描述的是漏洞的固有严重程度，KEV 目录提供的是"已经在野被利用"的证据。一个高分的 KEV 漏洞，优先级往往应该高于一个严重但没有利用证据的漏洞——具体还要看暴露面和业务影响。三类信号要合起来看，不能只看其中一个。

第 10 问：有没有跟踪漏洞是否与活跃的威胁组织或勒索软件活动相关？

严重度和 KEV 状态只讲了故事的一部分。如果某个勒索团伙正在利用一个影响你环境中资产的漏洞，紧迫性会明显上升，尤其是当它的活动与你的行业相关时。把威胁情报纳入风险评分，本质上是为了让排序更接近真实世界。

第 11 问：老系统和 OT 环境有没有单独的风险管理流程？

这些系统往往有运行、安全或厂商支持方面的约束，需要不同的处理方式。要记录约束、指定责任人、评估可用的补偿性控制；在没有官方修复的情况下，要纳入替换、升级或隔离计划。**不能因为"难打补丁"，就让一台设备从风险台账上消失。**​

五、测试与验证（第 12–14 问）

**第 12 问：部署之后有没有验证？包括重启、失败设备和离线设备。**​

"部署成功"的状态是有用的证据，但不该是唯一的检查。要确认目标版本确实装上了、必需的重启确实完成了，并用后续扫描发现残余暴露。失败的、长期离线的、结果不完整的设备，都要单独跟进。

第 13 问：补丁测试有没有按风险设定期限，以及紧急通道？

测试是必要的，但它也可能变成一个无限期的滞留区。要用有代表性的系统、明确的通过/暂停/回滚判据。如果某个补丁在测试环境里躺了两周，团队应该能解释清楚这段延迟的理由，以及期间暴露是怎么被管理的。

第 14 问：有没有定期把漏洞发现和补丁记录做对账？

部署后检查确认的是单次变更，定期对账找的是更大的缺口：补丁工具里没有的资产、过期的扫描结果、不受支持的软件、以及"看起来部署成功了但漏洞还开着"的情况。发现不一致时要去查原因，而不是默认某一方一定对。每一条未解决的发现都要落到责任人。

六、怎么读你的自查结果

按"是"的数量大致分三档：

• 12–14 个：体系已经比较成熟，重点转向已发现的缺口，并确认文档和实际做法一致。
• 8–11 个：基础扎实但有明确缺口。优先补第 5、6、9 问，这三条通常是风险影响最大的。
• 少于 8 个：存在实质性暴露。从第 1–4 问的清单开始，因为后面所有问题都依赖"你到底有什么"。

有一条规则要单独强调：**"不知道"按"否"计。**​

清单的目标不是拿一个分数，而是在下一个 CVE 把问题暴露给别人的时候，你手里已经有一张诚实的现状图。

七、国内企业要额外补的三件事

这份清单来自全球视角，落到国内环境，还有三件事需要单独处理。

**第一，信创终端的补丁源和节奏不一样。**​ 麒麟、统信 UOS 等国产操作系统，以及龙芯、鲲鹏、飞腾等国产芯片平台，补丁的发布节奏、镜像来源和验证方式都和 Wintel 生态不同。如果你的清单把国产终端和 Windows 混在一起排期，很容易出现"以为覆盖了、其实没覆盖"的假象。国产终端需要单独建清单、单独定窗口。

**第二，等保 2.0 要的是可追溯的过程，不是临考突击。**​ 补丁与漏洞管理是测评的控制项，证据链包括清单、审批、部署记录、例外登记和验证结果。年度测评前集中补一轮，记录链条是断的，反而是减分项。把补丁管理做成日常节奏，比对着一份检查表突击更省事。

**第三，攻击面的大头在第三方软件，不在操作系统。**​ Chrome、Java、Adobe 全家桶、Zoom、压缩与办公工具，是勒索软件和窃密程序最常走的入口。只统计操作系统补丁的团队，往往会高估自己的补丁覆盖率。第三方应用的清单要和操作系统清单一样当作常规项来维护。

把 14 个问题走一遍，你会发现真正难的不是修补，是清单、责任和验证这三件事。补丁管理成熟的标志，不是补丁打得多快，而是任何一台终端在任何时刻的状态都能被说清楚。

这类工作本质上要一个平台把"清单—时限—排序—验证"串成一条线。ManageEngine（卓豪）的 Endpoint Central 覆盖 Windows（含 Windows Server）、macOS、Linux 的系统补丁和主流第三方应用修补，漏洞管理侧支持按 CIS 基准的合规审计，风险评分把主动利用、威胁组织关注度和勒索团伙活动一并纳入排序，部署后自动跟进重启与失败设备；产品形态上有本地部署、SaaS 和混合三种，SaaS 版数据存于上海与北京数据中心、不出境。目前全球有 28000 多家企业客户在使用，覆盖 190 多个国家和地区，连续多年入选 Gartner 统一终端管理魔力象限并在 IDC MarketScape 的 UEM 评估中处于领导者象限。

如果只做一件事：**先回答第 1 到第 4 问。**​ 清单不清楚，后面十个问题都无从谈起。