By Oracle‘s move from a quarterly to a monthly Java security update cadence is not a minor scheduling change. For DevOps and IT teams managing Java in production, it means fundamentally more triage cycles, more deployment windows, and more testing overhead every single month. Teams that have not restructured their patch management processes will fall behind, and in a world of zero-day vulnerabilities, falling behind carries real risk.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, breaks down what the new monthly Java patch cadence means for operational workloads, how teams should adjust their triage and deployment strategies, and how Azul participates in the OpenJDK Vulnerability Group to ensure secure, coordinated disclosure across all major Java distributions.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every DevOps engineer, platform team, and enterprise security practitioner managing Java in production needs to know.
Technical Deep Dive
Q: How does the shift to monthly Java security updates change the operational workload for DevOps and IT teams?
Simon Ritter, Deputy CTO at Azul, explains that moving from a quarterly to a monthly Java patch cadence will effectively triple the amount of work DevOps and IT teams must perform specifically for Java updates. The core patch management strategy remains the same — evaluate what is delivered, assess which systems need updating, and decide deployment priority based on severity — but teams now face that full process every month rather than every three months. The overall volume of decision-making, testing, and deployment activity increases proportionally.
“Moving to a monthly cadence is in essence going to triple the amount of work that any IT or DevOps team has to do specifically for updating their Java.” — Simon Ritter, Deputy CTO, Azul
Q: How should enterprise teams prioritize and triage Java security patches under the new monthly schedule?
Ritter describes a severity-based triage model that teams should apply to every update cycle. If a critical vulnerability is present, particularly a zero-day, it must be deployed immediately. If the highest-severity issue in a given monthly update is only medium-level, teams may choose to defer that deployment by a month or until the next cycle. The decision framework itself does not change with the new cadence, but the frequency with which teams must apply it does, requiring tighter internal processes and faster decision loops.
“If there’s a critical vulnerability reported, you need to deploy that very quickly. Especially if it’s one that’s a zero-day vulnerability.” — Simon Ritter, Deputy CTO, Azul
Q: What is the OpenJDK Vulnerability Group and why does it exist?
The OpenJDK Vulnerability Group is a subgroup within the OpenJDK community established around 2019 to ensure that binary distributions of OpenJDK produced outside of Oracle have access to security patches before those patches are publicly released. The group exists because multiple vendors independently distribute OpenJDK, and without coordinated access to vulnerability information, those distributions could lag behind Oracle’s own JDK in security coverage. The group coordinates patch development so all major distributions can release fixes simultaneously.
“It was established to help make sure that the binary distributions that are made available of OpenJDK outside of Oracle had access to those security patches so that they could make sure that those distributions are as secure as possible.” — Simon Ritter, Deputy CTO, Azul
Q: Which organizations participate in the OpenJDK Vulnerability Group?
Ritter notes that most, but not all, major OpenJDK distribution maintainers are represented in the group. Engineers from Oracle, Red Hat, Microsoft, Amazon, SAP, and Azul all participate. The group works collaboratively when vulnerabilities are identified, developing patches internally and then upstreaming those changes to the OpenJDK source code at the point of public release.
“There are engineers from Oracle, there are engineers from Red Hat, Microsoft, Amazon, SAP, Azul obviously, and so on. We work together as a group.” — Simon Ritter, Deputy CTO, Azul
Q: Why does the OpenJDK Vulnerability Group operate as a closed, invite-only group if OpenJDK is an open source project?
Ritter explains that because the group handles undisclosed vulnerability information, open access would directly expose the details of unpatched security issues before fixes are available, creating immediate exploitation risk. Membership requires an invitation and is limited to engineers who work on recognized OpenJDK distributions. Unlike the main OpenJDK mailing lists, which are publicly visible, communications within the vulnerability group are not published. This is a deliberate departure from the standard open source transparency model, justified by the sensitivity of the information involved.
“Even though it’s an open source project, it is a closed group, meaning that it’s not open to anybody. To join, you have to be invited, you have to be part of the group that works on these distributions.” — Simon Ritter, Deputy CTO, Azul
Q: How does the OpenJDK Vulnerability Group protect sensitive vulnerability communications from interception?
Ritter describes a layered approach to protecting internal group communications. All email between members of the vulnerability group is encrypted end-to-end, so even if communications were intercepted on the network, packet sniffing would not expose the content. No group communications are published or logged publicly. This level of operational security is applied specifically because the information being exchanged describes vulnerabilities that have not yet been patched or disclosed, making premature exposure a direct threat to Java deployments worldwide.
“All of the email between the members of the group is encrypted. Even if that information was seen on the net, it wouldn’t be exposed so that people could try and sniff packets and expose information that way.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul’s security resources and documentation for JVM deployments in enterprise environments
- OpenJDK, The open source reference implementation of Java SE, the upstream project coordinated by the OpenJDK Vulnerability Group
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Now let’s look at the impact on the lives of DevOps and security teams. What does the operational schedule look like for DevOps and security teams? How should enterprise teams adjust and prepare their patch management and testing process to keep up with this?
Simon Ritter: I mean, effectively what this is going to do is it’s going to increase the workload for the DevOps teams and the IT teams who are handling Java applications. If you think about it, right now we’re doing a quarterly cycle for our updates, which means that every three months the team can look at what’s being delivered in that update. They can make their decision about which systems need to be updated. If there are certain particular security patches, the level at which that security patch is, then they can decide whether they want to deploy it or how quickly they want to deploy it. If, for example, there’s a critical vulnerability reported, then you need to deploy that very quickly. Especially if it’s one that’s like a sort of zero day vulnerability, or if you’ve got ones where there’s only maybe a medium that’s the highest level one in that particular update. They may decide to postpone that for a few months or to the next quarter. But essentially moving to a monthly cadence is in essence going to triple the amount of work that any IT or DevOps team has to do specifically for updating their Java. It won’t really change anything in terms of the overall strategy that they use because it’ll still be the same idea. You delivered an update, you will install that on your machine in exactly the same way. It’s just, you’re going to be faced with having to do it potentially every month rather than every three months.
Swapnil Bhartiya: And they’re saying also the more sweat you spend during peace, the more blood you’ll save. So it’s, it’s also, it’s better to be ready for that. Now, can you talk about how do you folks Azul collaborate with the broader Java open source ecosystem on security?
Simon Ritter: Yes, as I say, there is this subgroup within OpenJDK, it’s called the OpenJDK vulnerability group and that was established several years ago. I think it was maybe 2019. So it’s been around for seven years. Maybe it was established to help make sure that the binary distributions that are made available of OpenJDK outside of Oracle had access to those security patches so that they could again make sure that those distributions are as secure as possible. So the, the group works together collaboratively. There are people representing most of, but not all of the major OpenJDK distributions. There are engineers from Oracle, there are engineers from Red Hat, Microsoft, Amazon, SAP, Azul obviously, and so on. And what we do is we work together as a group. When vulnerabilities are identified in Java, when we will receive the information about that, we will then look at what we need to do to make changes to the software itself. We will develop those patches and then we will, at some point when the update is released, we will upstream the changes to the OpenJDK source code. Now, the important thing about that is because we’re working on sensitive information, because these are vulnerabilities which haven’t yet been resolved, it is critical that we don’t expose any of that information before an update is released so that people have the chance to, to use the security patches. So we do work in, even though it’s an open source project, it is a closed group, meaning that it’s not open to anybody. To join, you have to be invited, you have to be part of the group that works on these distributions. And we make sure that none of the email between members of this group is published. Again, that’s different to OpenJDK, where you can look at the mailing list and you can look at what people are saying. We don’t publish any of that. And we even go to the level where all of the email between the, the members of the group is encrypted. So even if that information was, you know, seen on the, on the net, then it wouldn’t be exposed so that people could try and sniff packets and expose information that way. So it is taken very seriously in terms of that collaboration to make sure that we keep everything secure.
