Our first hardened release cycle: What we learned and how we’re changing

Kunal AnandChief Product Officer | F5

In July, I wrote about our move to monthly hardened releases and monthly security notifications. I said at the time that the cadence was right for where we were, and that the same discipline that moved us off quarterly would move us again when the landscape demanded it.

One release cycle in, we have learned a lot. We have learned from customers, from partners, and from watching how a monthly cadence lands in production environments. Some of what we’ve learned is changing our approach.

Starting with HR2 on September 2, hardened releases will ship on a six-week cadence rather than monthly. And we are pausing the regular security notifications we planned to publish alongside them.

I want to explain how we got here, because the reasoning matters more than the dates.

What customers told us

We shipped HR1 on July 15 and then did what we said we would do: we listened.

What we heard was consistent, and it was not really about F5. Organizations running our products in their most critical paths told us that a monthly cadence did not give them enough room to test, stage, and deploy—not necessarily because our releases were hard to absorb in isolation, but because ours were arriving alongside everyone else's. Every serious vendor is responding to the same shift, and the cumulative weight lands on the same finite team inside every enterprise.

Six weeks is an acknowledgment that a fix nobody can deploy is not a fix. The speed at which customers can absorb a change is now part of the security equation itself, and a cadence that outruns absorption creates exposure rather than reducing it.

The other thing we learned points in the opposite direction. Customers who have invested in fleet management and automation are seeing significant improvements in the speed they are able to update. A global customer with a large F5 BIG-IP fleet reduced the update times from more than six months to approximately two weeks.

Why we are pausing security notifications

The second change is harder, and I want to be direct about the reasoning.

When we announced monthly security notifications, our assumption was that a roughly 30-day delay between the hardened release and the disclosure would give customers a workable window to update before details became public. That assumption reflected our best judgment at the time.

It no longer holds. Conversations with customers and with others across the industry over the past several weeks have changed our assessment of how much information is actually required to build a working exploit. Frontier models continue to improve at reasoning from limited signals—a diff, a partial description, a version range—to a functioning attack chain. The window we thought we were creating for defenders is, in practice, a window for attackers too, and it is narrowing.

So, we are pausing regular notifications while we collectively work through what responsible disclosure looks like in this environment. There will be exceptions. When a vulnerability is being actively exploited, when we're coordinating with researchers or government agencies, or when regulatory or contractual obligations require it, we will handle disclosure differently. This is not a permanent position on transparency. It is a decision made under the constraint that protecting customers comes first, and it is one we will keep evaluating.

I recognize this is uncomfortable. It is uncomfortable for me, as a former CISO. Disclosure norms exist for good reasons, and the security community built them over decades of hard experience. However, those norms were calibrated for a world where the gap between "details published" and "exploit available" was measured in weeks. That gap has collapsed, and every organization that publishes vulnerability information is going to have to reckon with what that means.

The harder question: Triage without severity

This is the part I think the industry has not fully confronted.

Most vulnerability management programs are built on severity. Critical gets patched in 24 hours, high in three days, medium in a sprint, low when there is time. That model assumes two things: that severity ratings meaningfully predict risk, and that you have severity ratings to work with.

Both assumptions are eroding.

The first is eroding because attackers using frontier models do not need a critical vulnerability. They chain. Three low-severity issues that individually may sit near the bottom of a triage queue become a working path to compromise when a model can reason across all three simultaneously. When we scan our own code, we are finding this class of issues: lower-severity issues that could be chained. Removing them systematically is what hardens software. Triaging them individually by severity is what leaves them in place.

The second assumption is eroding because vendors—us included—are going to publish less detail, later. That is going to feel like a loss of control to security teams, and I understand why.

So, what do you do instead?

Prioritize by exposure, not by rating. Reachability, Internet exposure, blast radius, and business criticality are more durable inputs than a CVSS score you may not receive. An asset that is exposed and unpatched is a risk regardless of what the advisory says.

Stay current as the discipline. The organizations that will do well in this environment are the ones that treat "running the latest hardened release" as a standing operational commitment rather than an event triggered by a severity rating. That is a cultural shift as much as a technical one, and it requires executive air cover to sustain.

Invest in absorption capacity now. Automation, fleet visibility, repeatable maintenance windows, and tested rollback are what make a faster cadence survivable. These investments look optional right now. They will not look optional in a year.

Assume the gap will exist and defend it. No organization patches instantly. Runtime protection—behavioral detection, virtual patching, controls that do not depend on knowing the specific vulnerability—can help cover the window between a fix that exists and a fix that’s deployed. That window is not going away. Plan for it rather than around it.

On changing our minds

We made a decision in July based on the best information we had. We put it into practice, learned from customers and partners, and adjusted. The alternative—holding a position because we announced it—would have been worse for customers and partners.

I said in July that we would keep adapting as the landscape and your needs evolve. This is what that looks like in practice. The honest position for any vendor right now is that established practice is being reassessed in real time, across the industry, and anyone claiming to have this fully solved is not paying attention.

What does not change is the standard we hold ourselves to. Organizations put F5 between their users and their applications, their agents and their APIs. That position is why we find and fix at the pace we do, why we test the way we do, and why we made the call we made on disclosure. Thank you for the feedback that shaped this. Please keep it coming and stay current.

About the Author

Kunal AnandChief Product Officer | F5

Kunal Anand leads the F5 product organization as Chief Product Officer. Responsible for product vision, strategy, and execution, he ensures development of breakthrough solutions that solve critical challenges and create exceptional experiences for customers. In his previous role as Chief Technology and AI Officer, Kunal charted the company’s technology and AI strategy and vision. Prior to F5, Kunal held the dual role of Chief Technology Officer and Chief Information Security Officer at Imperva. His journey to Imperva began in 2018 with the acquisition of Prevoty, an application security startup he co-founded in 2013. Before joining Prevoty, he was the Director of Technology at BBC Worldwide. Kunal has a deep history of innovation and technical expertise, and has held roles leading security, data, technology, and engineering teams at Gravity, MySpace, and the NASA Jet Propulsion Lab. Kunal has over 15 years of experience in AI and machine learning, ranging from model training, employing AI-driven algorithms to enhance products, and designing and implementing AI architectures. Kunal holds a Bachelor of Science degree in computer science from Babson College.

More blogs by Kunal Anand