By Established patch SLA tiers built on CVSS severity bands are failing. AI tooling can now develop working exploits from published vulnerability data within hours, and it can chain medium and low severity findings together into attack paths that produce data breaches or denial of service outcomes. The window between disclosure and active exploitation is no longer measured in weeks.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, covers how organizations running large Java estates across hybrid environments need to rethink patch rollout timelines, how the OpenJDK embargo model creates distribution lag, and how Azul delivers security patches to customers within one hour of Oracle releasing an update.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every platform engineer and security team managing enterprise Java estates needs to know.
Technical Deep Dive
Q: How are large organizations currently structuring Java patch SLAs by vulnerability severity?
Simon Ritter, Deputy CTO at Azul, explains that financial institutions and banks typically operate tiered SLA structures tied to CVSS severity. Critical vulnerabilities may require patch rollout within seven days, high severity within two to three weeks, and medium or low severity findings may be permitted to remain unpatched for a full quarter or longer. This model made sense under the assumption that lower-severity vulnerabilities carried limited exploitability risk in isolation.
“If there’s a critical vulnerability, they will have an SLA where they say we have to roll out that security patch within seven days.” — Simon Ritter, Deputy CTO, Azul
Q: Why are existing Java patch SLA tiers no longer adequate against modern threats?
Ritter identifies AI-accelerated exploit development as the forcing function that invalidates legacy SLA assumptions. AI tools can consume published vulnerability data and generate working exploits significantly faster than human researchers previously could. This compresses the safe response window across all severity tiers, not just critical findings, meaning that timelines once considered conservative for medium and low vulnerabilities are now operationally dangerous.
“Because of the changes that AI are making in terms of how quickly we can develop an exploit, the time that people are going to have to look at in terms of rolling out those patches is going to shorten.” — Simon Ritter, Deputy CTO, Azul
Q: What is vulnerability chaining and how does AI use it to escalate low-severity Java findings?
Vulnerability chaining is the technique of combining multiple lower-severity vulnerabilities into a compound attack path that produces a high-impact outcome such as a data breach or denial of service. Ritter points to Mythos as a specific example of an AI tool observed doing this in practice. Rather than requiring a single critical vulnerability, Mythos assembles chains of medium and low severity findings into attack sequences that achieve the same destructive result.
“It’s chaining together those lower grade vulnerabilities, putting them together in a way that can then result in a data breach or a denial of service attack.” — Simon Ritter, Deputy CTO, Azul
Q: What revised patch rollout timelines should Java teams be targeting given AI-driven exploit acceleration?
Ritter recommends that organizations recalibrate their SLA targets downward across all severity tiers. High-severity vulnerabilities should be targeted for patch rollout within one week rather than two to three. Medium-severity vulnerabilities, which AI tooling can now exploit through chaining, should be addressed within two to three weeks rather than being deferred to a quarterly cycle. The underlying principle is that any severity finding now carries a materially shorter safe deferral window than it did before AI-accelerated exploit tooling became widely available.
“If a high vulnerability comes out, we should be thinking about rolling out the patch for that within a week.” — Simon Ritter, Deputy CTO, Azul
Q: How does the OpenJDK embargo model work and where does patch distribution lag originate?
When Oracle releases a Java update, an embargo is lifted simultaneously, which permits all other OpenJDK distributions to release their corresponding updates. However, each downstream distribution requires its own build, testing, and release cycle after that embargo lifts. Ritter notes that depending on the distribution, the lag between Oracle’s release and customer availability of the patched build from that distribution can range from one day to potentially two weeks.
“There will be some kind of delay between when Oracle release theirs and when you get access to the patches from that distribution. That could be a day. It could be a week. If you’re using some distributions, it may be a couple of weeks.” — Simon Ritter, Deputy CTO, Azul
Q: What is Azul’s patch delivery commitment and how does it reduce exposure for enterprise Java customers?
Azul makes security patches available to its customers within one hour of Oracle releasing each update. Ritter frames this as eliminating the window during which systems are exposed after public disclosure but before a patch is accessible to deploy. For organizations operating under compressed SLA targets driven by AI threat acceleration, reducing distribution lag to under one hour is a structural advantage over distributions that may take days or weeks to ship their equivalent update.
“In terms of those security patches, we’ve had those available to our customers within one hour of Oracle releasing every update. There is literally no time when people can attack systems before you can deploy those patches.” — Simon Ritter, Deputy CTO, Azul
Q: What does a realistic Java patch rollout look like for organizations running large hybrid estates?
Ritter acknowledges that rolling out patches across mixed environments is a meaningful operational change from prior practice. The shift is not primarily a tooling problem but a process and prioritization problem: teams accustomed to treating medium and low vulnerabilities as low-urgency work items must now treat them as time-sensitive. Access to patches within one hour of Oracle’s release, as Azul provides, removes distribution lag as a bottleneck and shifts the constraint entirely to internal deployment processes.
“It is going to become a lot more important that people look at ensuring that they get those patches rolled out more quickly than they have been in the past.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul’s security-focused Java distribution and patch delivery platform
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: And for those organizations who are running large Java states across mixed environments, because everybody is rolling hybrid, what does the rollout actually look like in practice? How much, of course, overhead, challenge, complexity, and once again, how Azul can help them as well.
Simon Ritter: I think this is one of the things that people are going to have to realize is going to be a change. Because certainly if you think about the past with a quarterly release cadence, we’ve sort of thought to ourselves, okay, well, yes, if there’s security vulnerabilities which are identified and they’re serious ones, then we need to patch our systems. But if it’s not where we’ve got critical vulnerabilities, then we don’t need to address those too quickly. And I certainly, if I look at some of the financial institutions and banks and so on, if there’s critical vulnerability, they will have an SLA where they say, yes, we have to roll out that security patch within seven days. If it’s a high vulner, it may be within two weeks or three weeks. If it’s a medium or low vulnerability, it could be a quarter, it could even be longer than that. I’ve certainly seen some banks where low vulnerabilities don’t have to be addressed for quite some time because of the changes that AI are making in terms of how quickly we can develop an exploit. That means that the time that people are going to have to look at in terms of rolling out those patches is, is going to shorten. So they’re really going to have to think carefully about, okay, if a high vulnerability comes out, we should be thinking about rolling out the patch for that within a week, for example. You know, it depends on what they’re doing. But they may think, yes, we need to roll that patch out within a week. And even if it’s a medium, we might want to go two weeks or three weeks because AI can use that information and very quickly develop an exploit. We’ve seen that with Mythos, where not only is it using individual exploits to try and attack systems, it’s chaining together those and taking those lower grade vulnerabilities, putting them together in a way that can then result in a data breach or a denial of service attack or something like that. So it is going to become a lot more important that people look at ensuring that they get those patches rolled out more quickly than they have been in the past. From Azul’s perspective, what we try to do is to make sure that the customers we have have access to those patches as quickly as possible. As I said, Oracle release the update. And once Oracle have released the update, what’s called the embargo is lifted, and any other distribution is then able to release their update. But there will be some kind of delay between when Oracle release theirs and when you get access to the patches from that distribution. That could be a day. It could be a week, maybe, if you’re using some distributions, it may be a couple of weeks. That’s going to be significant from Azul’s perspective, in terms of those security patches, we’ve had those available to our customers within one hour of Oracle releasing every update. So there’s literally no time when people can attack systems before you can deploy those patches.
