By A Java quarterly update does not deliver 10 security fixes. It delivers up to 500 changes, of which only a small fraction are security patches. The rest are bug fixes and performance modifications that have never been validated against your application stack. That untested surface area is where production regressions originate, and most teams do not discover the problem until after the update is already deployed.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, breaks down why bundling security patches with broader updates creates avoidable stability risk, how the CPU and PSU update model separates those concerns, and what a shift to monthly security-only patching means for enterprise Java teams.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every platform engineer and Java operations team needs to know.
Technical Deep Dive
Q: Why does a Java quarterly update contain so many changes beyond security patches?
Simon Ritter, Deputy CTO at Azul, explains that a quarterly release is not scoped to security alone. It bundles security patches together with bug fixes, minor performance improvements, and other modifications, meaning a single quarterly update can include anywhere from 300 to 500 individual changes. Of those, only 6 to 15 are typically security-related patches. The remaining changes are the source of regression risk because they have not been validated against every downstream application.
“If you look at the number of changes that are included in that full update, because it is those bug fixes and performance improvements and so on, that could be anywhere between three and 500 changes.” — Simon Ritter, Deputy CTO, Azul
Q: What is the difference between a CPU and a PSU in Java patch releases?
Ritter describes two distinct update tracks used by both Oracle and Azul. The CPU, or Critical Patch Update, contains only security changes. The PSU, or Patch Set Update, contains all changes including bug fixes and performance improvements. Teams that apply the PSU accept a larger change surface and therefore a higher regression risk. Teams that apply only the CPU limit exposure to a small, well-scoped set of security modifications that have not historically caused application instability.
“You get just the security changes or you get all of the changes.” — Simon Ritter, Deputy CTO, Azul
Q: Has a Java security-only patch update ever broken application software?
According to Ritter, Azul has not observed a case where a security-only update caused an application to break. The instability pattern consistently traces back to the non-security changes included in full PSU updates, not to the security patches themselves. This track record is a core justification for recommending the CPU path to teams that prioritize application stability alongside vulnerability remediation.
“We’ve never seen a change in the security update that’s broken software.” — Simon Ritter, Deputy CTO, Azul
Q: What happens when a Java update introduces a regression after release?
Ritter notes that because updates are released on a quarterly cadence, it is not possible to pre-validate every software package against an update before it ships. After release, teams may discover that a change included to fix one bug has introduced another bug in a specific software package. When this happens, the update must be reworked, re-validated against the affected software, and reissued as a corrected release, adding operational overhead and delay for teams waiting on a stable update.
“We’ve had to go back and do a reworking of that, make sure it doesn’t break the software, and then issue another update.” — Simon Ritter, Deputy CTO, Azul
Q: What does the shift to monthly Java security patches change for operations teams?
Ritter explains that in the new monthly model, the months falling between existing quarterly releases will deliver security-only patches with no bug fixes or other changes included. This keeps the change surface small and predictable, reducing the chance of a patch requiring a reissue. Quarterly releases will continue to carry the full update including bug fixes and performance changes for teams that choose to consume them. The monthly cadence is designed to give teams a lower-risk path to staying current on security without absorbing the full regression risk of a complete update.
“Moving to a monthly cycle, what we’re going to be doing is for those months in between the quarterly updates, those will only be security patches.” — Simon Ritter, Deputy CTO, Azul
Q: Why is the open source patching model not sustainable for enterprise IT teams?
The open source model releases patches as they become available, without a fixed cadence. While this minimizes the time-to-patch for individual vulnerabilities, enterprise IT teams cannot absorb an unpredictable stream of updates because each one requires testing, staging, and validation before production deployment. That testing overhead makes continuous patching operationally impractical at scale. Structured cadences, paired with security-only update tracks, are designed to balance rapid vulnerability remediation against the operational cost of deployment cycles.
“That is not sustainable for IT teams because you have to test a lot of things, you have to prepare a lot of things, things may break.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul’s resource hub covering JVM security, patch management, and Java runtime support
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: I come from the pure Linux and open source world and we are used to getting patches whenever it’s ready. We patch things, but that is not sustainable model for IT teams because you have to test a lot of things, you have to prepare a lot of things, things may break. So just also talk about that. What is the reason behind the quarterly then you know, the whole monthly. And are you aiming for a situation where we can send patches as soon as the patch is ready without breaking things? Or you’re like, no, that is still far fetched. That is not going to be realistic.
Simon Ritter: Yes, I mean that’s one of the things that we face. And if we look at the quarterly releases, specifically a quarterly release has a certain number of security patches, but it also has a large number of other changes. There will be bug fixes, there may be some minor performance improvements and things like that. So it actually encompasses a lot more changes than just those security things. Now what we’ve done is we’ve kind of broken that into two distinct updates. So if you look at what Oracle do and what Azul does, there’s what’s called a CPU and a PSU version of each update. The CPU is the critical patch update, the PSU is the patch set update. And essentially what that means is you get just the security changes or you get all of the changes. Now the reason that’s very significant is because when you look at the number of security patches you get in a typical quarterly update, it is going to be somewhere around maybe 6 to 12, 15 would be a very large number of security patches. But, but if you look at the number of changes that are included in that full update, because it is those bug fixes and performance improvements and so on, that could be anywhere between three and 500 changes. So it’s a much bigger set of changes. The significance of that is that there’s a lot more chance that one of those changes may impact the stability of your application. So coming back to what you said about, you know, maybe things don’t work the way you expect them to. So what we need to be doing is very careful about that because we’ve seen a number of situations where we’ve had an update which has been released. Now because it happens on a quarterly basis, we can’t test all software against that update before it’s released, the update is released and then suddenly somebody will discover that a particular software package is being impacted by a change that’s been included, fixes one bug, but actually introduces another bug. And we’ve had to go back and do a reworking of that, make sure it doesn’t break the software, and then issue another update. So that’s the benefit of having the security only update or CPU versus the full update, because we’ve never seen a change in the security update that’s broken software. So moving to a monthly cycle, what we’re going to be doing is for those months in between the quarterly updates that we have at the moment, those will only be security patches. There won’t be any bug fixes or anything like that. The idea behind that is to try and help more in terms of stabilizing the software. So you’re not going to get this problem of having to reissue a patch once you’ve done that.
