By Applying a Java security patch in production carries two risks: leaving a critical vulnerability open longer than necessary, or introducing a regression that destabilizes running applications. Most quarterly JDK updates bundle security fixes together with bug fixes and unrelated code changes, making it impossible to isolate what changed and why a workload broke. For teams running older LTS versions, the problem compounds: the distribution they rely on may have already dropped support without a clear public notice.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, covers how Azul’s security-only monthly patch model works, which LTS versions from JDK 6 through JDK 25 receive backported fixes, and what engineering teams must evaluate when choosing a JDK binary distribution for production.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every Java platform engineer and security team needs to know.
Technical Deep Dive
Q: How do security-only Java patches reduce regression risk compared to full JDK updates?
Simon Ritter, Deputy CTO at Azul, explains that security-only patches contain a significantly smaller number of changes, all scoped exclusively to the security fix. Because unrelated bug fixes and code changes are excluded, the probability that any patch will affect the behavior of an existing application is materially lower. Ritter states that Azul has never observed a regression caused by a security-only patch against a customer application, whereas regressions from full updates that bundle bug fixes have occurred.
“We’ve never seen a situation where any of the security patches that have been issued have caused a regression against an application affecting its stability.” — Simon Ritter, Deputy CTO, Azul
Q: How does the monthly security patch cadence help teams respond to critical and high-severity CVEs faster?
Because the patches are narrowly scoped and carry a lower regression risk, teams can deploy them as quickly as a vulnerability severity demands rather than waiting for an approved maintenance window sized around a full update cycle. Ritter notes that when a critical or high-severity vulnerability is disclosed, the monthly model allows organizations to apply the fix immediately while maintaining application stability. The result is a stronger security posture without sacrificing production reliability.
“They can roll them out, deploy them as quickly as they need to, because there may be patches which are required to address a critical vulnerability or high vulnerability.” — Simon Ritter, Deputy CTO, Azul
Q: How does the OpenJDK vulnerability group develop and backport security patches to older Java versions?
Security patches are developed first against the current JDK release, which at the time of this interview is JDK 26. The OpenJDK vulnerability group, which includes contributors who maintain older versions, then backports those patches to supported LTS releases. Ritter explains that backporting is often straightforward because the fix targets the same code in an older source tree, but complexity increases with the age of the version due to differences in surrounding code and interactions between components.
“The further back you go, the more you have to be careful about how those security patches are integrated.” — Simon Ritter, Deputy CTO, Azul
Q: Which Java LTS versions does Azul support with monthly security patches?
Azul backports applicable security patches to JDK 6, JDK 7, JDK 8, JDK 11, JDK 17, JDK 21, and JDK 25. Ritter confirms that Azul is the only binary distribution that continues to support JDK 6 and JDK 7, including Oracle. Support breadth varies significantly across distributions, and teams running legacy versions must verify coverage with their specific vendor before assuming patches are available.
“Nobody except Azul supports JDK 6 and JDK 7 anymore. That includes Oracle.” — Simon Ritter, Deputy CTO, Azul
Q: How does JDK LTS support coverage differ across major binary distributions such as Microsoft, Red Hat, and Oracle?
Ritter outlines that each distribution makes independent decisions about which LTS versions to support and for how long. Microsoft has never provided direct long-term support for JDK 8. Red Hat supports a different subset of versions, and JDK 11 is out of standard support in their distribution unless customers pay for an additional support tier. Oracle does not support JDK 6 or JDK 7. Teams must audit their distribution’s support matrix explicitly rather than assuming coverage based on Java’s general LTS designations.
“You’ll see that in the case of certain distributions, they won’t support those older versions.” — Simon Ritter, Deputy CTO, Azul
Q: What should engineering and operations teams evaluate when selecting a JDK binary distribution for long-running or legacy Java workloads?
Ritter’s guidance is that teams must verify two things from their chosen distribution: which specific LTS versions are covered, and how long that coverage will continue. For organizations on older Java versions, the selection of the wrong distribution means no security patch delivery when a CVE is disclosed. The monthly patch cadence is only a benefit if the distribution the team is already running actually participates in backporting and publishing those patches for the version in use.
“If you’re using older versions, you need to look very carefully about how long those versions are going to be supported and whether they will receive those monthly updates when they’re made available.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul‘s security patch model, LTS version coverage, and distribution details
- OpenJDK, open source Java development kit and the upstream source for all binary distributions
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: And how do these monthly CSPUs protect against regression risks in production? How is Azul’s security only patch model isolate kind of targeted SV fixes from unrelated code change so that developers do know what we are touching and what we don’t have to worry about.
Simon Ritter: Yes. So as I say, the fact that we have a much smaller number of changes and they’re only related to the security patch side of things, means that there’s a significantly lower chance any of those changes will have an impact on existing applications. And again, as I said, we’ve never seen a situation where any of the security patches that have been issued have caused a regression against an application affecting its stability. We’ve seen that a number of times with the full update where we’ve got bug fixes and so on, but we’ve never seen that with the security patches. So that means that customers can be much more happy about how these things are going to work. They can roll them out, deploy them as quickly as they need to, because there may be patches which are required to address a critical vulnerability or high vulnerability. That way they can make sure that they get their systems as secure as possible, but also as stable as possible. It gives you the best of both worlds.
Swapnil Bhartiya: And can you talk about which Java versions are covered under this new monthly cadence? And if possible, can you kind of walk through which eight LTS or legacy versions will receive these updates, including Java 6, Java 7?
Simon Ritter: Right. So the way this works in terms of the initial security patch is that security patches are only developed for the current version of Java. So right now that’s JDK 26. Obviously people want to continue using older versions of Java and through the OpenJDK, which is the open source version of Java, what happens is that the OpenJDK vulnerability group, the group responsible for taking the vulnerabilities that are reported against Java, developing those security patches and then bundling and building them into the source code. What they will do is they will then amongst them, some people who support older versions of Java will then take the security patches and backport them to those older versions. Often that’s not too difficult because it’s just the same piece of code, it’s just older source code. What that means is we can do that very easily, but sometimes it’s more complicated because of the interaction between certain things. And really the further back you go, the more you have to be careful about how those security patches are integrated. So as you say, what we’re looking at here is different distributions of OpenJDK, the binary distributions that people are going to use it will depend on who you’re getting your binary distribution from, as to which of those LTS versions will be updated. Now, if we take Azul as an example, we go all the way back to JDK 6. Any applicable security patches will be backported all the way to JDK 6, JDK 7, 8, 11, 17, 21 and 25. So all of the LTS versions, other binary distributions of OpenJDK, will make a decision about which versions they support long term and how long they support those. And you’ll see that in the case of certain distributions, they won’t support those older versions. Nobody except Zool supports JDK6 and JDK7 anymore. That includes Oracle. If you look at people like Microsoft, they’ve never had long term Support directly for JDK8. Red Hat have a different set of versions they support. So JDK 11, for example, is out of support unless you pay extra money for that. So there’s a lot that needs to be considered from the point of view of when you’re using Java, you’re going to select a distribution that you want to run your applications on. If you’re using older versions, you need to look very carefully about how long those versions versions are going to be supported and whether they will receive those monthly updates when they’re made available.
