过去二十年，企业做漏洞管理，几乎都有一套耳熟能详的“标准动作”。
扫描漏洞、计算CVSS分数、生成工单、通知资产负责人、测试补丁、申请变更窗口、安装更新、重新扫描、关闭漏洞。
如果漏洞等级足够高，就标红处理，要求7天、15天或30天内完成整改。
这套机制曾经非常有效。它让企业能够在庞大复杂的信息系统中，将“漏洞”转化为可以分派、追踪、验收和汇报的管理事项。很多组织的漏洞管理能力，也正是在这样的流程中建立起来的。
但今天，游戏规则正在发生变化。
SecurityWeek近期在文章《Is Patching Dead?Vulnerability Management in the Post-Mythos Era》中提出了一个颇具冲击力的问题：“打补丁”是不是已经死了？
答案当然不是。
补丁依然是消除漏洞最直接、最彻底的手段之一。真正开始失效的，并不是补丁本身，而是那种把“发现漏洞—人工判断—排期—打补丁”视为漏洞管理全部核心的传统模式。
因为攻击者已经开始以“小时”为单位行动，而很多企业依旧在以“周”甚至“月”为单位完成修复。
当漏洞披露20小时后，互联网上已经出现真实攻击；当部分漏洞的平均利用时间甚至早于补丁发布；当企业修复一个关键漏洞的中位时间仍然长达43天——我们不得不重新审视一个问题：企业真正需要管理的，究竟是漏洞数量，还是攻击者能够抵达关键资产的路径？
这不是概念上的包装，而是正在发生的现实。
一、20小时：漏洞公告刚刚发布，攻击已经抵达现场
2026年3月17日，一个影响开源AI工作流平台Langflow的严重漏洞CVE-2026-33017被公开。
这是一个无需身份认证即可触发的远程代码执行漏洞。对于企业安全团队而言，面对这类漏洞，通常需要走完一条相对完整的处置链路：先接收漏洞情报，确认企业内部是否使用了Langflow；再通过扫描和资产盘点定位受影响版本；随后由业务团队评估升级影响，开发和运维人员搭建测试环境；测试通过后，申请变更窗口，最终完成升级或补丁部署。
即使整个流程运行顺畅，也很难以“小时”来计算。
攻击者却没有这些流程负担。
Sysdig威胁研究团队在多个存在该漏洞的蜜罐节点上观察到：从漏洞公告公开，到第一次真实攻击尝试出现，间隔大约只有20小时。
这个时间窗口已经足够令人警惕。但更值得关注的是，当时公开渠道中还没有可直接使用的PoC代码。
这意味着，攻击者并非只是下载并运行他人写好的利用脚本，而是根据漏洞公告中披露的接口信息、注入机制等技术细节，自行构造出能够工作的利用代码，并快速开始针对互联网暴露目标进行扫描。
攻击的演进同样非常典型。
最初，攻击者只是执行简单命令，以确认漏洞是否存在、目标是否可被利用；随后，攻击行为迅速升级为系统侦察、目录读取、配置文件探查和外部服务器调用；紧接着，攻击者开始寻找.env文件、读取环境变量，并尝试窃取数据库连接信息、API Key、云凭证等高价值敏感数据。
从防守者视角看，这起事件最值得关注的，不只是Langflow这个具体产品，也不只是一个RCE漏洞本身。
真正值得警惕的是一条被急剧压缩的攻击时间线：
漏洞公开→生成利用代码→自动化扫描→获取Shell→搜索凭证→横向移动
过去，这条攻击链可能需要数天，甚至更长时间。
如今，它可能在一天内完成。
而20小时，可能还不是最极端的情况。
Mandiant在《M-Trends 2026》中给出的数据更加值得安全团队深思：其估算的平均漏洞利用时间已经降至-7天。
“负7天”意味着什么？
意味着对于部分高价值漏洞，攻击行为平均已经出现在补丁发布之前。
也就是说，安全团队面对的，可能不再只是“补丁发布之后能否快速部署”的问题，而是一个更残酷的现实：当补丁还不存在时，企业能不能先活下来？
这正是传统补丁管理模型遇到的第一次真正逻辑挑战。
二、43天对20小时：攻防失衡，已不再是个别企业的问题
如果说20小时的真实攻击窗口让人感受到威胁速度，那么把它与企业实际修复效率放在一起看，问题会更加直观。
Verizon发布的《2026 Data Breach Investigations Report》显示，漏洞利用已经成为其调查数据中最常见的初始入侵方式，占比达到31%；与此同时，过去长期占据重要位置的凭证滥用，占比降至13%。
这意味着，攻击者越来越倾向于直接从技术暴露面进入企业，而不是单纯依赖盗取账号和密码。
更值得关注的是修复侧的数据。
Verizon统计发现，在其观察范围内，被纳入CISA已知遭利用漏洞目录（KEV）的关键漏洞中，2025年最终被完整修复的比例只有26%，而上一年这一数字还是38%。
完成修复所需时间的中位数，则从32天进一步延长至43天。
与此同时，中位企业需要处理的关键漏洞数量，比上一报告周期增加约50%。
于是，攻防双方形成了一幅极度不对称的图景：
攻击者正在从“按天行动”进入“按小时行动”；
部分攻击甚至发生在补丁发布之前；
企业完成一个关键漏洞的整体修复，却仍然需要数十天；
漏洞总量仍在持续膨胀，安全团队的待办事项越来越多。
FIRST在2026年漏洞预测中预计，全年公开CVE数量的中位预测值约为59,427个，行业可能首次跨过“每年5万个CVE”的门槛；而其90%置信区间更给出了约3万至11.7万个的宽幅范围。
漏洞数量增长的背后，是软件供应链、云原生环境、开源组件、SaaS应用、网络设备、OT设备和AI应用共同扩张的攻击面。
对于拥有数万乃至数十万资产的大型企业而言，漏洞管理团队面对的，早已不是几百条待办事项，而可能是数万、几十万条Finding。
在这样的背景下，继续强调“所有高危漏洞必须在7天内完成修复”，看上去很严格，也很符合安全制度的语言习惯。
但在实际执行中，它很容易演化成一种形式主义。
因为真正的问题不是：“我们是否能够把所有高危漏洞都按最高优先级处理？”
而是：“哪十个漏洞最可能让攻击者明天进入生产环境？”
这两种提问方式，决定了两种完全不同的漏洞管理体系。
三、Cisco的变化：从逐CVE处置，转向批量化、风险化管理
行业的变化，已经不只是安全团队内部的感受。
Cisco在2026年7月进一步转向基于风险的漏洞披露模式，就是一个具有代表性的信号。
Cisco并没有简单地选择“发布更多CVE”，而是试图重新设计漏洞发现、披露和更新之间的关系。例如，对于具有相同CWE弱点的一批问题，Cisco尝试将其整合到“umbrella CVE”体系中；同时，围绕IOS XE、IOS XR、NX-OS、Secure Firewall以及ASA等主要平台，推出安全加固版本。
这一变化的表面，是漏洞披露方式的调整。
其深层逻辑则是：当漏洞数量已经超过组织逐个处理的能力时，企业必须从“逐漏洞管理”走向“批量化、风险化和工程化管理”。
Cisco还建立了相对固定的漏洞披露节奏，通常每月两次，并计划提前7天通知客户哪些技术和平台即将进入安全更新范围。这样一来，企业可以提前安排实验室验证、变更审批和维护窗口。
当然，如果出现正在被利用的高危漏洞，Cisco仍会进行紧急、计划外的披露和修复。
这套机制背后，透露出一个非常值得企业借鉴的思路：过去，漏洞管理系统最重要的对象是一个个CVE编号。
未来，企业真正需要管理的对象，可能是：
某一类产品族；
某一个互联网攻击面；
某一类共性弱点；
某一条从边界通向核心资产的攻击路径；
某一个业务系统所承载的整体风险。
Cisco也明确指出，AI推动的漏洞发现正在增加漏洞数量和漏洞发现速度，传统临时式、逐漏洞处置的方式，越来越难以匹配现实需求。
对于甲方安全团队来说，这意味着漏洞管理部门不能再只是一个“CVE工单转发中心”。
真正成熟的漏洞管理能力，应该能够帮助业务判断：哪些问题必须立刻处理，哪些问题需要加速修复，哪些问题可以在标准维护窗口中消化。
四、从“看漏洞”到“看风险”：CISA释放的信号
政府监管侧同样在发生变化。
2026年6月，美国CISA推出BOD 26-04，取代此前的BOD 22-01框架，其核心方向是：根据风险决定安全更新的优先级。
这并不意味着CISA已知遭利用漏洞目录KEV失去了价值。
恰恰相反，KEV仍然是判断漏洞风险的重要依据。真正变化的是，企业不能只看“某个CVE是否进入了目录”，还需要进一步分析：
漏洞是否存在于企业真实环境中；
该资产是否暴露在互联网；
攻击者是否可以自动化利用；
利用成功后能获得什么权限；
该资产后面连接着哪些业务系统；
企业现有控制措施是否真正有效。
CISA的公开实施说明，也将KEV、攻击自动化能力和技术影响等因素纳入风险判断。
举一个简单但极具现实意义的例子。
假设安全团队同时发现两个CVSS评分为9.8的漏洞。
第一个漏洞位于一台互联网直接暴露的VPN设备上，已经存在真实利用迹象，攻击者成功利用后可以接管设备，而设备后方连接的正是企业核心办公网络。
第二个漏洞的CVSS同样是9.8，但对应组件部署在一个完全隔离的内部测试环境中，外部无法访问，也不存在可行的攻击路径。
如果两个漏洞仅仅因为“分数一样”，就被赋予同样的修复SLA，那么这个漏洞管理系统实际上并没有理解风险。
CVSS描述的是漏洞本身有多严重。
但企业真正需要管理的是：这个漏洞在“我的环境里”，到底有多危险。
两者从来不是一回事。
五、AI Agent带来的新攻击面：权限本身就是风险
进入Agentic AI时代，暴露面也在扩展。
过去谈攻击面，安全团队通常会想到IP地址、开放端口、Web服务、VPN、API接口、云主机和外部SaaS应用。
今天，还必须加上一项：机器身份到底拥有多少权限。
2026年7月，Hugging Face披露了一起具有代表性的安全事件。其后续技术复盘显示，一个自主AI代理在数天内执行了大量自动化动作，并通过数据处理链路中的问题进入生产环境。
攻击链涉及数据处理管道、生产Kubernetes Pod、环境变量和令牌，并进一步开展侦察、建立通信、向内部环境移动。官方在事件重建过程中记录了约17,600个相关操作。
这起事件提醒企业：风险不再只是“某个软件是否存在漏洞”。
更重要的是：一个自动化主体一旦获得初始权限后，它究竟能走多远？
传统攻击者需要逐步输入命令、分析返回结果、思考下一步行动。
AI Agent则可以连续执行大量细粒度决策：读取数据、发现令牌、尝试访问、判断权限、切换路径、建立通信、继续横向移动。
当攻击速度被自动化提升后，企业降低风险的关键，未必是无限压缩补丁部署时间，而是尽可能控制攻击成功后的“爆炸半径”。
例如：
一套AI数据处理服务不需要访问生产数据库，就不应持有数据库凭证；
一个仅用于读取文档的Agent不需要调用云管理API，就不应授予Cloud Admin权限；
一个CI/CD机器人只需要读取单个仓库，就不应让其Token拥有整个组织的写权限；
一个容器工作负载不需要访问云元数据服务，就应通过网络与身份策略限制访问；
一个服务账号只需访问特定Secret，就不应默认拥有整个Secrets空间的读取能力。
“最小权限原则”并不是新概念。
但在AI Agent时代，它正在从一条基础安全常识，重新成为决定攻击损失上限的核心防御能力。
六、补丁没有死，但“只靠补丁”的时代正在结束
因此，“Is Patching Dead?”这个标题真正想表达的，不是“以后不用打补丁”。
而是：不要把漏洞管理等同于补丁管理。
补丁解决的是“漏洞存在”的问题。
漏洞管理要解决的，则是“风险是否正在形成可被利用的攻击路径”的问题。
一个已经被WAF有效阻断、网络不可达、没有敏感权限、缺乏横向移动条件的漏洞，当然仍然应当进入维护计划；但它通常不应该和一个互联网暴露、已被活跃利用、成功后可能直接接管核心系统的漏洞争夺同一个最高优先级。
反过来，当企业面对没有补丁的0day时，也不能因为“厂商尚未发布更新”就只能等待。
关闭互联网入口、禁用高风险功能、增加身份认证、调整ACL、切断横向访问、部署虚拟补丁、启用行为检测、轮换凭证、隔离高风险服务——这些都属于漏洞管理的一部分。
换句话说：补丁是风险处置手段之一，而不是风险管理本身。
七、最佳实践一：建立“三桶漏洞管理模型”
对于大多数企业来说，与其设计几十个复杂难懂的漏洞等级，不如先建立一个简单、明确、可真正运行的三桶模型。
Bucket 1：事件级响应
典型场景包括：互联网暴露、已被利用或高度可利用、影响重大业务系统、成功后可获得高权限或形成横向移动路径。
这类问题不能再按普通漏洞工单处理，而应按安全事件管理。
核心动作包括：
立即确认资产是否已遭入侵；
搜索异常账号、Webshell、可疑进程和计划任务；
检查异常外联、凭证访问和横向移动痕迹；
必要时隔离系统、关闭入口或下线服务；
部署缓解措施并尽快修补；
对可能暴露的令牌、密码、API Key和云凭证进行轮换。
这里最关键的一点是：先确认是否失陷，再谈漏洞是否修复。
如果一台互联网边界设备存在已被大规模利用的RCE漏洞，补丁安装成功、扫描结果显示“已修复”，并不代表风险已经消失。
攻击者可能在三天前就已进入系统，并留下后门、账号、计划任务或凭证窃取链路。
漏洞关闭了，事件却并没有结束。
Bucket 2：加速修复
这类问题通常具有较高危害，存在现实攻击路径，但暂未发现明确入侵证据。
企业应将其纳入紧急变更流程，缩短测试、审批和上线时间，同时部署补偿控制，例如WAF规则、访问限制、网络隔离、身份认证强化、临时关闭高风险功能等。
它们不一定需要像安全事件一样全面启动应急响应，但绝不能按普通月度补丁节奏慢慢等待。
Bucket 3：标准维护
这类漏洞通常位于内部资产、可达性较低、已有有效防护措施、现实攻击风险相对有限的环境中。
对于此类问题，企业可以通过自动化补丁、版本升级、周期性整改和标准运维窗口进行消化。
三桶模型的价值，不在于给漏洞重新命名，而在于帮助组织把有限的人力、审批资源和变更能力，投入最可能造成真实损失的地方。
八、最佳实践二：管理攻击路径，而不是管理漏洞数量
未来几年，安全负责人或许应该少问一个问题：“我们还有多少高危漏洞？”
因为这个数字很容易制造管理错觉。
10万个漏洞，未必一定比100个漏洞危险。
真正重要的是，其中有多少漏洞能够形成有效攻击路径。
企业可以将以下因素放在一起，形成自己的风险判断框架：资产暴露程度×真实利用情况×自动化利用能力×技术影响×业务重要性×现有控制有效性
这不是一个固定的行业标准公式，而是一种风险思考方法。
仍以互联网VPN设备为例。假设它存在一个RCE漏洞，且已经被威胁情报确认存在真实利用；漏洞无需认证、容易自动化；设备可访问内部网段；设备缺乏传统EDR防护；攻击者成功利用后还可能进一步获取身份凭证。
那么，即使这个漏洞的CVSS评分只有8分，它也可能远比一个CVSS 10分、但完全不可达的内部组件更危险。
现代漏洞管理平台真正应该回答的问题，不再只是“哪些资产上存在漏洞”，而应是：
攻击者能从哪里进入？
他们会利用什么进入？
进入后下一跳可以去哪里？
最终能抵达哪些关键资产？
企业现有控制能否中断这条路径？
漏洞只是攻击路径上的一个节点，而不是风险的全部。
九、最佳实践三：不要用制度SLA代替真实修复时间
许多企业都有一套看起来非常成熟的漏洞修复SLA：
严重漏洞，24小时；
高危漏洞，7天；
中危漏洞，30天。
但制度SLA是愿望，真实MTTR才是能力。
SecurityWeek提出了一个非常务实的建议：企业应当统计过去90天里，关键漏洞从发现到真正完成部署，实际花了多少时间，而不是只看制度要求是什么。
把一条漏洞处置链路拆开，企业往往会看到更真实的情况：
安全团队发现漏洞用了1天；
确认资产负责人用了2天；
补丁兼容性测试用了4天；
业务部门申请变更用了5天；
等待统一维护窗口又用了14天；
最终上线，总计26天。
当攻击者20小时后就已开始利用，而企业真实修复周期是26天时，问题不在于某位员工是否严格遵守了制度。
问题在于，整个组织的响应架构与威胁速度已经不再匹配。
因此，企业应进行一次真正的“漏洞修复时间审计”，详细拆解：
从首次获知漏洞到资产定位，需要多久；
从资产定位到确认业务影响，需要多久；
从风险确认到变更批准，需要多久；
从批准到测试上线，需要多久；
从修复上线到验证关闭，需要多久。
很多企业最终会发现，最大的漏洞并不在服务器上。
而在流程里。
十、最佳实践四：建立“战时授权”，别让审批链成为攻击路径的一部分
真正严重的漏洞，往往不会在最方便的时候出现。
如果某个严重RCE漏洞在周日下午被确认正遭受大规模利用，安全负责人希望立即升级互联网边界设备，但生产部门要求主管审批，主管要求业务负责人确认，业务负责人要求风险部门签字，风险部门又要求厂商正式说明……
那么，再好的漏洞情报也无法挽回时间差。
SecurityWeek建议企业通过桌面推演，真正测试紧急补丁决策能力：
工作日下午两点，完成紧急处置需要多久？
周日凌晨两点，完成同样的处置又需要多久？
谁可以决定隔离系统？
谁可以启用紧急变更？
什么情况下可以先处置、后补审批？
哪些关键业务负责人必须具备随时响应能力？
成熟企业需要提前建立“战时授权机制”。
当满足互联网暴露、真实利用、高业务影响等条件时，组织应明确权限边界和决策路径，避免关键时刻陷入“所有人都有责任、但没有人有权决定”的困境。
在AI加速攻击的时代，审批链本身也存在MTTR。
十一、最佳实践五：补丁来不及时，运行时检测必须顶上去
Langflow事件还有一个值得安全运营团队重点关注的地方。
攻击者利用的可能是刚刚披露、甚至尚未被安全产品完全识别的新漏洞；但攻击成功之后的行为，往往并不新鲜。
执行Shell命令、读取敏感文件、搜索环境变量、调用curl、连接外部服务器、窃取凭证、访问云元数据服务、探测内部网络——这些行为都具有可观测性。
Sysdig指出，即使安全产品尚未认识CVE-2026-33017，也可以通过运行时行为检测发现攻击活动。
这揭示了一条关键防御原则：漏洞可以是0day，攻击行为通常不是0day。
企业可能无法预先知道攻击者会从哪个漏洞进入；但当一个Web服务突然启动Shell、一个业务容器开始读取凭证文件、一个普通服务账号突然批量访问Secrets、一个边界设备向陌生地址建立长连接时，安全运营团队仍然有机会发现异常。
这也是为什么漏洞管理必须与SOC、资产管理、身份管理和云安全真正打通。
漏洞平台告诉SOC：“这里可能存在入口。”
SOC告诉漏洞平台：“这个入口已经出现攻击行为。”
资产管理系统则告诉双方：“这个入口后面连接着核心数据库、生产集群或高价值身份系统。”
当这几类信息汇聚起来，风险优先级才真正具备业务意义。
结语：从“补漏洞”走向“经营暴露面”
未来安全做得好的组织，未必是“补丁打得最快”的组织。
更可能是那些能够持续做到以下几件事的组织：
看清真正暴露在互联网和攻击者面前的资产；
准确判断哪些漏洞在自身环境中现实可利用；
在补丁来不及时，快速限制攻击路径；
验证EDR、WAF、身份控制和网络隔离是否真正有效；
严格约束服务账号、API Key和AI Agent能够触达的范围；
将已被利用的漏洞作为安全事件，而非普通工单处理；
通过自动化、紧急授权和工程化能力缩短真实修复时间；
在代码进入生产之前，尽可能减少下一批漏洞的产生。
这正是漏洞管理从VM，即Vulnerability Management，走向Exposure Management的根本原因。
企业关注的对象，正在从：“我有多少个CVE没有修复？”
逐渐变成：“攻击者现在能够利用什么进入我的环境？”
并进一步变成：“如果攻击者从这里进入，最终能够拿到什么？”
补丁没有死。
真正走向终结的，是“只要比攻击者更快安装补丁，就能解决漏洞风险”的旧假设。
在漏洞披露20小时后已出现真实攻击、部分利用发生在补丁发布之前、关键漏洞完整修复中位时间仍长达43天的现实中，企业必须承认：仅仅依靠补丁竞赛，已经越来越难赢。
看见暴露面，识别攻击路径，控制权限边界，建立运行时检测，缩短决策链条，并在没有补丁时依然具备生存能力——这才是AI时代漏洞管理真正需要进化的方向。
当攻击者已经进入“机器速度”，防守者最大的风险，不是补丁慢了几个小时。
而是组织仍在用十年前的方法，决定今天什么最重要。
