按严重性打补丁已死:AI时代,F5引领软件加固新范式

今年七月，我曾撰文介绍F5转向月度加固发布和月度安全通知的决定。我当时表示，这一节奏与我们当时所处的阶段相匹配，而推动我们摆脱季度发布的同一种纪律，也将在行业格局需要时再次推动我们向前迈进。

一个发布周期过去，我们学到了很多。我们从客户、合作伙伴那里汲取了经验，也观察了月度节奏在生产环境中的实际落地情况。其中一些认知正在改变我们的策略。

从 9 月 2 日的 HR2 开始，加固发布将以六周为周期发布，而非按月发布。同时，我们也将暂停原计划与加固发布同步发布的常规安全通知。

我想解释一下我们是如何走到这一步的，因为背后的逻辑比日期本身更重要。

图 1：F5 加固发布节奏的演变——从季度到月度，再到六周

客户告诉了我们什么

我们在7月15日发布了HR1，然后践行了我们的承诺：倾听。

我们听到的反馈高度一致，而且并不完全是针对F5的。在我们产品运行于最关键路径上的组织告诉我们，月度节奏没有给他们留出足够的时间来测试、预发布和部署——不一定是因为我们的发布本身难以消化，而是因为我们的发布与所有其他厂商的发布同时到达。每个严肃的厂商都在应对同样的变化，而这些累积的重量最终落在了每个企业内部同一个有限的团队身上。

六周是一种承认：没有人能部署的修复就不是修复。客户能够吸收变更的速度现在已成为安全方程式本身的一部分，一个超出吸收能力的节奏会创造暴露风险，而非减少风险。

组织将 F5 部署在用户与应用之间、智能体与API之间。正是这一位置决定了我们发现和修复的速度、我们测试的方式，以及我们在信息披露上做出的决定。

我们学到的另一件事则指向相反的方向。在集群管理和自动化方面投入了资源的客户，正在看到更新速度的显著提升。一位拥有大型F5 BIG-IP集群的全球客户，将更新时间从超过六个月缩短到了大约两周。

图 2：某全球客户通过集群管理和自动化将BIG-IP更新时间从约6个月缩短至约2周

为什么我们暂停安全通知

第二个变化更加艰难，我想直接说明背后的逻辑。

当我们宣布月度安全通知时，我们的假设是：加固发布与信息披露之间大约30天的延迟，会给客户一个可行的窗口，让他们在细节公开之前完成更新。这一假设反映了我们当时的最佳判断。

这一假设已不再成立。过去几周与客户及行业其他各方的对话，改变了我们对「构建可用漏洞利用究竟需要多少信息」的评估。前沿模型在从有限信号——一个 diff、一段部分描述、一个版本范围——推理出可运行的攻击链方面的能力持续提升。我们以为为防御者创造的窗口，在实践中也为攻击者提供了窗口，而且这个窗口正在缩小。

因此，我们暂停常规通知，同时行业各方共同探讨在这种环境下负责任的信息披露应该是什么样的。也会有例外情况：当漏洞正在被积极利用时，当我们与研究人员或政府机构协调时，或者当法规或合同义务要求时，我们将以不同的方式处理信息披露。这不是关于透明度的永久立场。这是一个在「保护客户优先」约束下做出的决定，我们将持续评估。

我理解这令人不安。作为前CISO，这对我来说也不舒服。信息披露规范的存在有充分的理由，安全社区在数十年的艰辛经验中建立了这些规范。然而，这些规范是在一个「细节发布」到「可用漏洞利用」之间的差距以周计量的世界中校准的。如今这个差距已经坍缩，每个发布漏洞信息的组织都将不得不思考这意味着什么。

更难的问题：没有严重性评级的分级

这是我认为行业尚未完全面对的部分。

大多数漏洞管理程序建立在严重性之上。严重级别 24 小时内修补，高危三天内修补，中危一个迭代周期内修补，低危有空再修。这个模型假设了两件事：严重性评级能有意义地预测风险，以及你有严重性评级可用。

两个假设都在被侵蚀。

第一个假设被侵蚀，是因为使用前沿模型的攻击者不需要严重漏洞。他们会链接。三个低危问题——单独看可能排在分级队列底部——当一个模型能够同时推理这三个问题时，就变成了通往入侵的可执行路径。当我们扫描自己的代码时，我们正在发现这类问题：可以链接的低危问题。系统地消除它们才能真正加固软件。按严重性逐个分级则会将它们留在原处。

图 3：低危漏洞链接——AI 模型可将多个低危问题组合成完整攻击路径

第二个假设被侵蚀，是因为厂商——包括我们——将发布更少的细节，且更晚。这对安全团队来说会像是一种失控感，我理解原因。

那么，你应该怎么做？

1)按暴露面优先，而非按评级。可达性、互联网暴露、暴露半径和业务关键性，比你可能收不到的CVSS评分更持久的输入。一个暴露且未修补的资产，无论安全公告怎么说，都是风险。

2)将「保持最新」作为纪律。在这种环境中表现出色的组织，是那些将「运行最新的加固版本」视为一项长期运营承诺的组织，而非由严重性评级触发的事件。这既是技术转变，也是文化转变，需要高管层面的支持才能持续。

3)立即投资于吸收能力。自动化、集群可见性、可重复的维护窗口和经过测试的回滚，是让更快的节奏变得可生存的关键。这些投资现在看起来是可选的。一年后就不会了。

4)假设差距会存在并加以防御。没有组织能即时修补。运行时保护——行为检测、虚拟补丁、不依赖于了解特定漏洞的控制措施——可以帮助弥合「修复已存在」与「修复已部署」之间的窗口。这个窗口不会消失。为它做计划，而不是绕过它。

图 4：漏洞分级模式对比——从传统按严重性分级转向按暴露面优先

关于改变我们的想法

我们在七月基于当时掌握的最佳信息做出了决定。我们将其付诸实践，从客户和合作伙伴那里学习，然后做出了调整。另一种选择——因为我们已经宣布了某个立场就坚持不变——对客户和合作伙伴来说会更糟。

我在七月说过，我们将随着行业格局和你们需求的变化持续适应。这就是它在实践中的样子。对于当前任何厂商来说，诚实的立场是：既定的做法正在整个行业中实时重新评估，任何声称已经完全解决这个问题的人都没有在认真关注。

不变的是我们对自己的标准。组织将F5部署在用户与应用之间、智能体与API之间。正是这一位置决定了我们发现和修复的速度、我们测试的方式，以及我们在信息披露上做出的决定。感谢塑造了这一决策的反馈。请继续提供，并保持最新。

关于作者