补丁排不下去，你先补哪一个

先给一句最容易听到的话："我们上周刚打过补丁。"

这句话是真的，但它回答的是另一个问题。它回答的是"这台机器动过没有"，没回答"这一批里最该动的那一台动没动"。这两句话的差距，在今年秋天被三份公开材料同时照亮了一次，而它们照的恰好是老板最难盯的那一格：漏洞永远修不完，所以先补哪一个这件事，迟早要有人拍板。

拍板这件事现在没人替你做了。往下就是这篇要摊开的全部内容：一个排序变化、四格真约束、三问判据、九天窗口里的六件事、打完补丁之后最容易被省掉的那半截、不能停的那几条路，最后给管理层一页六个动作。

一、今年变的不是漏洞变多了，是"进门"这一招换了

先把最要紧的一个数摆出来。Verizon 那份每年一次的数据泄露调查报告，今年被中文安全圈反复引用的正是同一句结论：初始访问向量（也就是入侵者第一步从哪儿进来的）的排序变了——漏洞利用以 31% 的占比第一次成为占比最高的入口，而长期霸着榜首的凭据盗用降到了 13%。 这份报告用的样本覆盖 2024 年 10 月到 2025 年 11 月，解读文章在 2026 年 9 月密集出现。

请注意这一句的分量。过去十几年里，防守方的钱是照着"猜密码"这一种打法排的：强口令、定期改密、双因素、登录失败锁定、异常地点提醒。这一整套没有错，但它排的是第一名。而今年那份报告说的是：第一名换人了，你排的那一整套现在排的是第二名的活。

同一批材料给的第二个数，才是让老板应该坐不住的那一句：一个已经被人在野利用的漏洞，从被发现到被彻底修掉，中位时间从三十二天涨到了四十三天，补丁更新的平均时间多了十一天。这是厂商那边的解读稿里明确写出来的对比，方向是"变慢"。

把两个数并排放，就得到这篇的问题：攻击方拿公告的速度是按小时算的，你修的速度是按季度排产的。 这中间的差额不是靠"我们很重视"补得上的，只能靠一件事——在排不下去的时候，有一个所有人都认的取舍规则。

二、为什么你的窗口永远排不下：四格都是真约束，不是借口

先替技术团队说句公道话。"排不下"这四个字，绝大多数时候不是懒，是四格实打实的约束在互相顶。你不懂这四格，就定不出规则；懂了这四格，规则基本就能自己长出来。

第一格：停机要业务方点头，所以这是一个日历问题，不是技术问题。 一个补丁要重启，重启就要停服务。财务在月结那三天不能停，零售在大促前一周不能停，制造在月底盘库那两天不能停，医院有夜班和门诊两个高峰。这些都不是 IT 能决定的事。结果就是：一年里真正可用的窗口就那么几个，而漏洞公告是按周来的。 这两条时间轴的错配，是所有"排不下"的根。

第二格：测试环境跟生产不一样，"测过了"这三个字有含金量。 测试环境里那台机器是干净的、数据是假的、第三方接口是挡板、配置是三个月前抄的那一份。补丁在测试环境跑通了，只证明它不会让程序起不来，不证明它在生产那台上有六年历史数据、有四个奇怪定时任务的机器上不会出事。很多公司所谓"已经验证过"，验的是第一件，怕的是第二件。

第三格：清单不全，所以永远不知道有多少台。 这一格最要命，因为它会让前面三格全部失真。一份漏扫报告说"发现三百二十个高危项"，你要问的第一个问题不是"三百二十个怎么办"，而是**"这三百二十个分布在多少台机器上，而我们一共有多少台"**。绝大多数公司答不出第二个数。云上开一台机器只要三分钟，谁都能开，一年之后没人记得那台是干什么的、能不能停。不在清单上的那台，永远排不进窗口，也永远没人给它补。

第四格：修完没人签"已修"，所以同一批漏洞每个月重新排一遍。 这一格是纯管理问题：没有一条"谁在什么时候修了哪一台、验证方式是什么"的闭环记录。于是漏扫报告每月一份，前一份的处置结果对不上后一份的剩余项，谁都不知道到底少了多少个。技术团队不敢说"清完了"，老板不敢听"还在排"。

这四格里，第三格和第四格不花钱，第一格和第二格要花钱花人。所以下面所有判据的前提是：先把清单和闭环这两格补上，否则三问判据也救不了你——因为你连"哪些洞存在"都不知道，谈什么先堵哪个。

三、先补哪一个：别按分数排，按三问排

市面上所有漏扫工具都会给每个漏洞打一个分，最常见的那一套叫 CVSS，零到十分，十分是"理论上的最坏"。很多公司的规则就是照这个分数排：十分先修，五分排队。 这一条规则在今年被官方自己否掉了。

先说官方那一侧发生了什么。 美国那个负责协调这类通报的机构（CISA）在 2026 年 9 月停掉了它的每周漏洞公告。给出的理由写得很直白：这类海量汇总只能告诉别人"发生了什么"，本质是信息轰炸，会加剧告警疲劳，而且没法直接指导"今天先修哪个"这个决策。它继续维护的是另一份东西——已知被利用漏洞清单，只收那些已经确认在野被拿来打的漏洞，并且要求被点名的单位在限期内处置。中文圈的解读稿把这件事的意义讲成一句话：漏洞管理从"看分数"转向"看真实风险"。

那"真实风险"怎么算？解读里给的框架是三块乘在一起：技术严重程度、真实利用情况、资产暴露程度，再绑定这台资产的业务重要性。翻成人话，就是下面这三问。

第一问：它在外面能被碰到吗？ 这是三问里唯一能一票否决的。一个洞挂在内网办公网段后面、只有三个运维能访问，和一个洞挂在公网上、任何人打开浏览器就能戳到，风险不是一个量级。这一问要的那一列数据，就是上面第三格缺的那一列：这台机器有没有公网地址、有没有对外开放的端口、是不是被反向代理露出去了。

第二问：有没有人已经在打它？ 分数回答的是"能被打成什么样"，这一问回答的是"现在正在被打"。已经在野利用的漏洞，意味着攻击方手里有能用的工具、而且已经用过一轮了。这一问要的是有人每周去看那类"已知被利用"清单，而不是等安全厂商打电话来。

第三问：打穿了赔多少？ 同一台机器上的一个洞，装在测试环境和装在收钱的系统上，是两个完全不同的问题。这一问只能业务方回答，技术团队答不了。

拿今年 9 月那一个满分漏洞走一遍这三问，比讲十句道理都清楚。

那一个漏洞的编号是 CVE-2026-85706，评分 CVSS 10.0（满分），2026 年 9 月 10 日公告，影响的是自建部署的那一类代码托管与流水线服务，给出的修复门槛是三条版本线（16.11.11、17.11.10、18.5.5 及以上）。它在公告后的第二天就被收进已知被利用清单，限期是 9 月 17 日之前修补或者停用。

如果按分数排，这个满分在所有公司都是第一。但按三问排，答案会分成三种：

• 你的这套服务挂在公网上、任何员工都能从外面访问 ⇒ 它是你今天唯一的一件事，别的都往后放。
• 它只在内网、只给开发用、外面戳不到 ⇒ 它降到第二档，但第二问已经亮了灯（有人在打），所以不能进"排队"那一堆。
• 你根本没用这一类服务 ⇒ 这一条与你无关，漏扫报告里那行是误报，划掉。

同一次演练反过来走一遍，才知道分数为什么会骗人：一个只打五分、但挂在公网上、已经被写进在野利用清单、后面接着客户数据库的洞，排在一个满分但只活在内网测试机上、且没人用过的洞前面。这不是取巧，这就是那三问的算法本身。

四、那九天窗口里到底要发生几件事：逐日拆开看

老板侧最容易低估的就是这一节。"一个补丁而已，装上要多久？" 装五分钟，走完一条能落地的处置流程要九天，而且这九天还是官方给的上限。

那一个满分漏洞的时间线是这样的：9 月 10 日公告，9 月 11 日进已知被利用清单并给出限期，9 月 17 日之前必须修补或停用。九天。 下面这六件事要在九天里发生，一件都省不掉：

1. 清点。 我们到底有几台机器跑着这一类服务、分别是什么版本。这一条要的输出是一串具体的机器名，不是"应该就那两台"。
2. 找到你这一档的修复版本。 三条版本线意味着你可能停在任何一条上，从你当前版本到最近的那一个安全版本，中间可能还隔着几个功能变更。
3. 准备回退点。 不是"有备份"，是"这一台坏了，四十分钟之内能回到今天这个状态"。
4. 试。 哪怕只试两件事：服务能起来，主流程能走通一条。跳过这一条的代价，通常是在生产窗口里当场付。
5. 约窗口并通知业务方。 这一条要提前，因为它依赖别人的日历。等第五天再约，通常约不到。
6. 修完验证，然后换凭据。 后半截在下一节，它是大多数人漏掉的那一半。

这六件事里，没有一件是"下载补丁"。 这就是为什么窗口排不下的根因不在技术上——瓶颈从来不在那五分钟。

还有一件很多老板不知道的事："停用"是官方给的合法选项之一。 那份限期要求写的是"修补或停用"。也就是说，如果你判断这台东西既不修也停不起，那这是一个需要有人签字接受风险的决定，不是一个"技术团队还没排到"的状态。这两种写法在事故之后是完全不同的两件事：前者有一份带名字和日期的记录，后者只有一串聊天记录。

五、打完补丁不等于修完：最容易被省掉的那半截

那一个满分漏洞最值得学的地方，不是它的分数，是它的后果。

公开报道里的描述是：这个洞本身只给到只读权限，但它可以批量导出配置与密钥。解读里那句警告值得抄进你自己的处置流程里——拿到仓库源码、流水线里的变量、部署用的密钥，就等于拿到了一条通往软件供应链内部的路，所以处置动作里除了升级，还要立即全面轮换相关凭证。

这就是"打完补丁"和"修完了"之间的差距。三件事必须跟着做，一件都不能省：

第一件：换凭据。 密钥、令牌、部署账号、流水线里那些加密变量、能登进这台机器的所有账号。这一件要有明确的清单、责任人和时限，因为它的失败方式极其安静——三个月后你换了机器、打了补丁，而那个被导出过的令牌还在正常干活。

第二件：回查改动。 谁在公告日之前建过账号？谁改过那台机器上的配置、定时任务、信任关系？这一件的前提是你的日志留得够长。这里有一句最好用的判据，可以原样拿去问技术团队：

"我们能不能说出公告日之前七天，谁访问过这台机器？"

答得出，你的回溯是有底的。答不出，那这一台机器上今天发生的一切，你只能靠信任。

第三件：把这次的时间线写下来。 什么时候看到的公告、什么时候清点完、什么时候约到窗口、什么时候修的、什么时候换完凭据。这份东西不是为了应付检查，是为了下一次那九天里你不用现场想流程——流程只在写下来之后才存在。

六、不能停的那一些，走哪四条不体面但有用的路

真实情况是：每一家都有那么两三台"绝对不能停"的机器。业务在跑、接口在对接、没人敢动、版本还老。这些洞不会因为你排不下就消失，所以要有明确的缓释路径，而不是默认它不存在。

四条路按体面程度往下排：

一、收暴露面。 把挂在公网上的那一台挪回内网，或者关掉那一个不必要的高危端口，或者在前面加一层只允许指定地址访问的限制。这一条几乎不花钱、不需要停机，而且它直接改的是第一问的答案——一个原本"外面能戳到"的洞，变成"外面戳不到"。这是性价比最高的一条，却最少被优先想到。

二、降级功能。 漏洞在插件里，就把那个插件关掉；在某个不常用的接口上，就把那个接口下线；在某个默认开启的能力上，就把它关掉。代价是业务少一个功能，好处是整条攻击路径没了。 很多公司宁可冒风险也不愿意少一个功能，这一格值得摆到桌面上让业务方选一次。

三、前置拦截。 也就是所谓"虚拟补丁"——在流量进来之前，用网关或防护设备把那一类请求特征挡掉。必须写清楚它是缓释不是修复，因为它的绕过成本通常远低于真补丁，而且它保护的是"已知的这一种打法"。它能给你换来的是时间，不是安全。

四、加监控，并书面接受风险。 前面三条都做不到时，只剩这一条：把这台机器的日志和异常行为盯紧，同时让具体某一个人签字承认"我知道这台机器有这一条风险，我接受到某月某日"。

这一条的关键词是"有到期日"。 一份没有到期日的风险接受书，等于一张永久免检牌，两年后它会变成事故报告里最难看的那一行。"暂缓"必须有名字、有到期日、有到期复评的人。

顺带补一句和上一篇连读的那一格：那些"不能停"的机器往往也是最难修的，所以它们同时也是最该有一份能带走的副本的那一批——修不了、停不起、换不掉，这三件事同时成立的那一台，才是你真正的软肋。

七、你卖出去的那一侧，同一周规则也变了

前面六节都是"你买的系统要修"。还有另一半：如果你是给别人交付系统的那一方，"你多久告诉客户有漏洞"这件事，今年也开始有数字了。

欧盟那套新的产品网络安全要求（《网络弹性法案》，简称 CRA），它的报告义务部分从 2026 年 9 月 11 日起适用。时限链条写得很具体：被积极利用的漏洞或者重大安全事件，要在 24 小时内提交预警、72 小时内提交完整通报，等到补丁或者缓解措施可用之后，14 天内提交最终报告；这些数据要汇入欧盟网络安全局那台单一报告平台；条文明确点名的责任主体是制造商；而且范围包括已经上市的产品——老产品不在这条规则之外。

国内这一侧不是空白。工信部、网信办、公安部三部门那份 2021 年 9 月 1 日施行的《网络产品安全漏洞管理规定》，第七条写的是：网络产品提供者发现或者获知产品存在漏洞后，应当在 2 日内向工信部的网络安全威胁和漏洞信息共享平台报送相关漏洞信息；并且要及时组织修补，对需要用户（含下游厂商）采取软件、固件升级等措施的，应当及时把漏洞风险和修补方式告知可能受影响的产品用户，并提供必要的技术支持。

这两段放在一起，对国内做交付的人来说是一句很实际的话："发现漏洞之后多久通知客户"这一格，正在从合同里的软话变成有数字的硬话。 你今年去翻一些甲方新加的安全问卷，会看到这一格被问出来——谁在几天内通报、有没有一份产品所用第三方组件的清单、出问题找谁。

反过来，你是买的那一方，这一节给你一个最好用的采购问题："你们发现漏洞之后，多久告诉我？" 这个问题不需要你懂技术，而答案的质量极其好分辨：

• 答"看情况""我们一般会尽快" ⇒ 这一格没有流程。
• 答得出一个数字、并且说得出通知给谁、以什么形式 ⇒ 这一条被设计过。

还有一条供给侧的信号，说明为什么买方要开始问这一格。 厂商那边修得越来越快，快到需要用机器来修：2026 年 7 月那一次例行补丁日一次处理了 622 个漏洞，被报道为刷新了历史记录；6 月那一次是 206 个、其中三个已经公开为零日；9 月还有技术媒体直接用"借助 AI，单月修补超千个安全漏洞"做标题转述厂商口径。修得越来越快的是卖方，被要求越来越快的是买方——你的客户会把你交付出去的东西按同一把尺量。

八、给管理层的一页：现在就定六个动作

这一篇的结论不是"要更重视安全"，那句话说不出谁在什么时候做什么。下面六条都能在本周落到人。

动作一：把清单那一列补齐。 一份能对上数的资产台账，除了机器名和用途，必须多两列："外面能不能被碰到"、"这台打穿了赔多少"。前者的活是网络那一侧的，后者的活是业务方的。清单不全，后面五条全部作废。

动作二：把三问写成一行公司规则。 明文写出来，贴在漏洞处置流程的第一页：先看暴露面，再看有没有人在打，最后看打穿了赔多少；分数只是第三问的一半。 这一行存在的意义是：下一次两份报告打架的时候，不用重新吵一遍优先级。

动作三：把窗口日历放到业务方的日历上。 每季度预留两个可停机窗口，提前一个季度定死，让技术团队按这个日历去排修哪一些。这一条是唯一真正能解开"排不下"的动作——因为它把"每次都要临时谈判"变成"一年只谈判四次"。

动作四：指定一个人每周看"已知被利用"那一类清单。 不需要买新东西，需要的是看到之后几小时内启动一条流程的那个触发权。这一格没人管，是绝大多数公司在满分漏洞那天早上才开始找人的原因。

动作五：写一份凭据轮换预案。 换哪些、谁批、多久换完、怎么确认换干净了。这一格是所有处置流程里最容易在半夜现场想的一件事，而它恰恰是"打完补丁不等于修完"的那半截。

动作六：暂缓必须签字带到期日。 一张表：机器名、风险描述、缓释措施、接受人姓名、到期日、到期复评人。没有这一张表，你的"暂缓"和"没人管"在事故报告里长得一模一样。

最后回到开头那一句。"我们上周刚打过补丁。" 下一次听到这一句，请接着问那一句更值钱的：

"那上周那一批里，最该补的那一个，是哪一个？谁定的？"

如果答得出，你的排产是有规则的，规则是有人认的。如果答不出——那三百二十个高危项里，真正的风险不是那些还没修的，是你们到现在还不知道该先修哪一个这一件。