首个安全加固发布周期：经验总结与改进方向

Kunal Anand首席产品官 | F5

编者注（2026 年 10 月 14 日）：F5现将“强化版本”称为“关键版本”。这一术语变更体现了此类版本的重要意义，以及尽快部署最新版本的重要性。

今年7月，我曾撰文介绍我们改为每月发布加固版本和安全通知。当时我表示，这一节奏符合我们所处的阶段；正如严谨的工作方式推动我们从按季度发布转为按月发布一样，当形势需要时，它也会再次推动我们调整节奏。

经过一个发布周期，我们收获颇多。我们听取了客户和合作伙伴的反馈，也观察了每月发布节奏在生产环境中的实际效果。其中一些经验正在促使我们调整方法。

从9月2日发布的HR2开始，强化版本将由每月发布调整为每6周发布一次。我们还将暂停原计划随这些版本一同发布的定期安全通知。

我想解释一下我们为何会做出这一调整，因为背后的考量比具体日期更重要。

客户向我们反馈的情况

我们于7月15日发布了HR1，随后兑现承诺：倾听客户的声音。

我们听到的反馈高度一致，而且问题其实并不在于F5。在最关键业务路径中运行我们产品的组织告诉我们，每月一次的发布节奏没有给他们留出足够的时间进行测试、预发布和部署。这不一定是因为单独采用我们的版本有多困难，而是因为我们的版本与其他所有供应商的版本接踵而至。所有负责任的供应商都在应对同样的变化，而累积的工作压力最终都落在每家企业内部同一支人力有限的团队身上。

将周期调整为6周，是因为我们认识到：无法部署的修复方案就不能算真正的修复。如今，客户消化变更的速度本身已成为安全考量的一部分；如果发布节奏超出客户的消化能力，非但不能降低风险，反而会带来安全隐患。

我们了解到的另一点则呈现出相反的趋势。已投资于设备群管理和自动化的客户，其更新速度正得到显著提升。一家拥有大规模F5 BIG-IP设备群的全球客户将更新时间从6个多月缩短至约2周。

我们为何暂停安全通知

第二项变更更为艰难，我想直接说明其中的原因。

当我们宣布每月发布安全通知时，我们原本认为，从加固版本发布到披露相关信息之间间隔约30天，可以让客户在详细信息公开前有一段切实可行的更新时间。这一假设反映了我们当时基于现有信息作出的判断。

这一假设已不再成立。过去几周，我们与客户及业内其他人士的交流改变了我们对构建可用漏洞利用程序实际所需信息量的判断。前沿模型根据有限线索（例如差异、部分描述或版本范围）推导出可用攻击链的能力仍在不断提升。我们原以为这是为防御者争取的时间窗口，但实际上，攻击者也能利用这一窗口，而且它正在缩短。

因此，在我们共同探讨如何在当前环境下负责任地披露信息期间，将暂停常规通知。但也会有例外情况。如果漏洞正遭到主动利用、我们正在与研究人员或政府机构协调，或者法规或合同义务要求披露，我们将采取不同的披露方式。这并不意味着我们对透明度持永久立场，而是在优先保护客户这一前提下作出的决定，我们也将持续评估这一决定。

我知道这会让人感到不安。作为一名前首席信息安全官，我也对此感到不安。披露规范的存在有充分理由，也是安全社区历经数十年的实践与教训逐步建立起来的。然而，这些规范所适用的环境是，从“详细信息发布”到“漏洞利用程序出现”之间通常相隔数周。如今，这一时间差已不复存在，所有发布漏洞信息的组织都必须认真思考这意味着什么。

更棘手的问题：没有严重性信息，如何确定处置优先级

我认为，这正是业界尚未充分正视的问题。

大多数漏洞管理计划都以严重性为基础。严重级别为“严重”的漏洞会在24小时内修补，“高危”漏洞在3天内修补，“中危”漏洞在一个冲刺周期内修补，“低危”漏洞则在有时间时修补。这种模式基于两个假设：严重性评级能够有效预测风险，并且有可用的严重性评级。

这两个假设都在逐渐失去依据。

第一个假设正在失效，因为使用前沿模型的攻击者并不需要严重漏洞。他们会将多个问题串联起来。当模型能够同时分析三个低严重性问题时，这些单独来看可能排在分类处置队列末尾的问题，就会形成一条可行的入侵路径。扫描自己的代码时，我们发现了这类问题：可被串联利用的低严重性问题。系统性地消除这些问题，才能增强软件的安全性；如果仅按严重性逐一分类处置，这些问题就会继续存在。

第二个假设也在逐渐失效，因为包括我们在内的供应商将减少披露的细节，并推迟披露时间。这会让安全团队感到失去掌控，我理解其中的原因。

那么，应该如何应对？

按暴露程度确定优先级，而非按评分。可达性、互联网暴露程度、影响范围和业务关键性，比可能无法获得的CVSS评分更适合作为长期可靠的评估依据。无论安全公告如何说明，已暴露且未修补的资产都存在风险。

将保持最新作为一项准则。 在这种环境中，能够从容应对的组织会将“运行最新的安全强化版本”视为一项持续的运营承诺，而不是由严重性评级触发的一次性事件。这不仅是技术层面的转变，也是文化层面的转变，需要管理层持续支持。

立即投资提升变更承载能力。自动化、设备群可见性、可重复执行的维护窗口以及经过测试的回滚机制，是确保更快节奏可持续的关键。这些投入目前看似可有可无，但一年后将不再如此。

正视防护空窗期，并做好防御。任何组织都无法即时完成补丁部署。运行时保护，包括行为检测、虚拟补丁以及不依赖于已知特定漏洞的控制措施，有助于在修复方案发布到实际部署之间的空窗期提供防护。这个空窗期不会消失。应提前做好应对规划，而不是试图绕开它。

关于改变看法

我们在7月根据当时掌握的充分信息作出了决定。我们将其付诸实践，听取客户和合作伙伴的反馈，并据此作出调整。另一种做法是仅仅因为已经宣布就坚持原有立场，但这会给客户和合作伙伴带来更不利的影响。

我在7月曾表示，随着行业形势和客户需求不断变化，我们也会持续调整。这正是我们将这一承诺付诸实践的体现。当前，任何供应商都应坦诚承认：整个行业都在实时重新审视既有做法。任何声称已彻底解决这一问题的人，都没有真正关注行业动态。

不变的是我们始终坚持的标准。各组织将F5部署在用户与应用之间，以及智能体与API之间。正因为处于这一关键位置，我们才会以当前的速度发现并修复问题，采用现有方式开展测试，并作出此次披露决定。感谢大家提出反馈，帮助我们不断调整。欢迎继续提供意见，并及时了解最新动态。

关于作者

Kunal Anand首席产品官 | F5

Kunal Anand担任首席产品官，负责领导F5产品组织。他负责产品愿景、战略和执行，推动开发突破性解决方案，以应对关键挑战，并为客户打造卓越体验。在此前担任首席技术与AI官期间，Kunal制定了公司的技术与AI战略和愿景。 加入F5之前，Kunal曾在Imperva同时担任首席技术官和首席信息安全官。2018年，Imperva收购了他于2013年联合创立的应用安全初创公司Prevoty，他也由此加入Imperva。在加入Prevoty之前，他曾担任BBC Worldwide技术总监。Kunal拥有深厚的创新经验和技术专长，曾在Gravity、MySpace和NASA Jet Propulsion Lab担任领导职务，负责安全、数据、技术和工程团队。 Kunal在AI和机器学习领域拥有超过15年的经验，涵盖模型训练、运用AI驱动的算法增强产品，以及设计和实施AI架构。 Kunal拥有Babson College计算机科学理学学士学位。

Kunal Anand 的更多博客文章