Swapnil Bhartiya: You may think that your Java state is safe because you patch every quarter, but AI is compressing the gap between vulnerability, discovery and active expiration to days, not months. That 90 day window is becoming a door for attackers and Azul is closing that door. Is starting August 2026, they are delivering monthly critical security patches, updates across all supported Java LTS versions. And today we have with us once again Simon Ritter, Deputy CTO at Azul, to break down what this means for enterprise Java teams. Simon, first of all, it’s great to have you back on the show.

Simon Ritter: Great to be back. Thank you.

Swapnil Bhartiya: It’s my pleasure. Let’s talk about this quarterly update cycle. Why is the quarterly update cycle no longer sufficient? How is AI changing the threat landscape to make a 90 day window too risky for enterprise Java states? I feel even weekly window is not enough for AI.

Simon Ritter: Yes, I mean, as you say, what we’ve seen in the last sort of six months or so is a real radical shift in terms of the way that AI is being applied to the field of IT security. And the real kind of, I guess, game changing moment was when Anthropic announced Mythos, which was a frontier model. And that was one which had been trained and developed specifically to look at the ideas of identifying security vulnerabilities and also finding ways of exploiting those vulnerabilities. And they were actually so successful that they decided not to make this model generally available because they were worried that people who had malicious intent might actually use it in that way. And so they didn’t want people breaking into systems and causing all sorts of problems. But essentially what’s happened is that the, the use of AI models, LLMs and so on, has really changed the speed at which we can identify and then exploit vulnerabilities. So we’ve had this idea of a quarterly update for many types of software. Java is one of them. There are lots of other pieces of software which use a quarterly update schedule. But with AI now having a big impact on the ability to develop those exploits, what the decision that’s been made is that we do need to move to a faster cadence. As you rightly said, in August we will see a monthly update come out. We’re not going to see a monthly update every month yet. We’ll see August will be one, then we’ll have a break in September, and then in October we’ll have the usual quarterly one. But Oracle, who sort of have control over the way that these things happen for Java, have said publicly that they want to shift to a monthly cadence starting from next calendar year. So really the idea of this August release is to help people get used to the idea of a more frequent cadence for this, because this does have a huge impact on IT teams. On DevOps teams in the past they’ve thought, okay, we can deal with this every three months because we have the schedule of January, April, July and October. Great rate, we can work towards that. Now what they’re being told is every month you’re going to potentially get a set of security patches and you’ve then got to decide which ones, or if you think this is worth rolling out and patching your systems. And then you’ve got to figure out the resources you need to do that, which machines need to be updated, and so on. So there’s a lot of work that needs to go into this. And I get what you’re saying about maybe a weekly cycle or a daily cycle, but I think that then pushes things too far and it overloads the DevOps teams and the IT teams. So there needs to be a sort of balance between a cadence of a quarterly and a daily cadence.

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 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, 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 1215 would be a very large number of security patches. 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 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.

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 SVA 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 that’s 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 are going to be supported and whether they will receive those monthly updates when they’re made available.

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. 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 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, yes,

Simon Ritter: 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 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, Azure, obviously, and so on. And what we do is we work together as a group. When vulnerabilities are identified in Java, 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 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 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.

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. 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 vulnerability, it may be within two weeks or three weeks. If it’s a medium or low vulnerability, it could be, you know, 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 if, 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.

Swapnil Bhartiya: I’m pretty sure that you folks work with your partners, customers, you told them that this is the shift that is going to happen or not. But what kind of feedback you have received from early customers since announcing this shift?

Simon Ritter: Yeah, I mean, it’s been very positive because again, coming back to this change that we’re seeing in terms of using AI, I’ve spoken to a number of customers where we’re not just talking about Java here, we’re talking about IT software across the board, all of the enterprise software. They’ve literally started what they call a Mythos team who’s studying what the impact is going to be on their IT infrastructure, how they can respond in terms of these faster updates, how they can respond in terms of making sure that they install the patches in a timely manner, and making sure that they’ve got that maximum level of security. So there’s definitely a lot going on generally in terms of that strategy around patching. That’s the big thing that I’m seeing, is that people are really taking this seriously and thinking about how they can change their patching strategy.

Swapnil Bhartiya: If I ask you in general, how does the software lifecycle looks like after

Simon Ritter: I think what we’re seeing there is just a real acceleration in terms of the way that we need to respond to changes that are required in terms of software, and that’s both bug fixing and security patches. Security patches is obviously the big thing because, as you say, it’s that approach where we have to adapt to the fact that there is going to be, and some people call it a tsunami of security vulnerabilities that are identified. AI is finding things that haven’t been found before and even things that have been existing or have existed in software for a long time. I think the example that I read about was that Mythos had found one vulnerability in the OpenBSD operating system that had been around for 27 years. So it hadn’t been. The source code had been there for 27 years, the vulnerability hadn’t been identified. So it’s going to be finding things that have been there for a while, not new things, but have been around for a while, and it’s just finding those and exposing them. Now, we certainly got the idea of being able to then use AI to figure out how to resolve those problems as well. But it means that IT teams are facing quite a prolonged period of time where we’re going to have to be much more on the ball and much more focused on figuring out how to roll out those patches so that we can keep our system secure. Because as you say, bad actors are as well. We’ll be using the same tools. Maybe not Mythos, but you know, we’ve got the open weight models, things like Qwen and so on that they can use. And even those open weight models, they’re not as good as Mythos at the moment. But again, the prediction I’ve seen is that they are only somewhere between 3 and 12 months behind. So those open weight models will develop and people who are malicious actors can then start using those. So we really need to focus on making sure that we are delivering all of those updates and our customers are installing them in a timely manner.

Swapnil Bhartiya: Simon, thank you so much for joining us and walking us through the and of course those who are watching. If you are running Java in production, please do check out azul.com to learn more about these changed security update cycle. Get prepared based on Simon’s suggestions and I’ll see you in the next one. Simon, thank you.

Simon Ritter: Thank you very much.