Monthly Java Security Patches: The Cost of Not Moving Faster | Simon Ritter, Azul

You may think that your Java estate is safe because you patch every quarter, but AI is compressing the gap between vulnerability discovery and active exploitation to days, not months. That 90-day window is becoming a door for attackers, and Azul is closing that door. Starting August 26th, 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. >> Great to be back. Thank you. >> 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 >> estates. I feel even weekly window is not enough for AI. >> Yes, I mean, as you say, what we've seen in the last sort of 6 months or so is a real radical shift in terms of the way that AI has been applied to the field of of IT security. And the real kind of, I guess, game-changing moment was when Anthropic announced Mythos, which was a 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 and causing all sorts of problems. But essentially, what's happened is that the the use of AI models, LLMs, and so on has has really changed the speed at which we can identify and then exploit vulnerabilities. So, we've we've had this idea of a quarterly update for for many types of software. Java is one of them. There are lots of other pieces of software which use a a quarterly update schedule. But, with AI now having a big impact on 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. Um 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. Um it 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 um have control over the 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 a a huge impact on IT teams, on DevOps teams. In the past, they thought, "Okay, we can deal with this every 3 months because we have the schedule of January, April, July, and October. Great, 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 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 the DevOps teams and the IT teams. So, there needs to be a sort of balance between a a cadence of a quarterly and and a daily cadence. >> 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 a sustainable model for IT team because you have to test a lot of things, you have to prepare a lot of things, and things may break. So 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 like no, that is still far-fetched, that is not going to be realistic. >> Yes, I mean that 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 secure 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 is all 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 six to 12. 15 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 one changes may impact the stability of your application. So, come 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 do is 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 the security only update or CPU versus the 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 uh 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 to try and help more in terms of stabilizing the the software. So, you're not going to get this problem of uh having to reissue a patch once you've you've done that. >> And how do these monthly CSPUs protect against regression risks uh in production? How How is Azure's uh security only patch uh more isolate kind of targeted SUV fixes from unrelated code change so that developers do know what we're touching and what we don't have to worry about? >> Yes. So, as I said, the fact that we have a much smaller number of changes and they're only related to the security patch side of things, um means that there's a significantly lower chance any of those changes will have an impact on existing applications. And again, I 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 the full update where we got bug fixes and so on, but we've never seen that with the security patches. So that that means that uh customers can be much more um happy about how these things are going to work. They can roll them out, um deploy them as quickly as they need to because there may be patches which are required to address a a you know, 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. >> 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 8 LTS or legacy versions will receive these updates including Java 6, Java 7? >> Right. So the the way this works in terms of the the initial security patches 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 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 them and bundling them into the uh 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 back port them to those older versions. Often that's not too difficult because it's just um the same piece of code, it's just older um 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. I I'm 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. Um 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 back-ported 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 um distributions, um they won't support those older versions. Nobody except Azul supports JDK 6 and JDK 7 anymore. That includes Oracle. Uh if you look at people like Microsoft, they've never had long-term support directly for JDK 8. Red Hat have um a different set of um versions they support. So, JDK 11, for example, um is out of support unless you pay extra money for that. So, there there's a 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 old 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. >> Now, let's look at uh 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? >> 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 3 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 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 the overall strategy that they use, because it'll still be the same idea. You deliver the 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 3 months. >> And there's a 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 by you Azul collaborate with the broader Java open source ecosystem on security? >> Yes, as I say, there is this um subgroup within OpenJDK. It's called the OpenJDK Vulnerability Group, and that was established um several years ago. Now, I think it was maybe 2019, so it's been around for 7 years, maybe. Um 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, um 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 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 the group that um works on these distributions. And we make sure that none of the email between members of this group is published. Again, it's 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 um you know, seen on the on the net, then it wouldn't be exposed so that people could try and sniff packets and and expose information that way. So it is taken very seriously in terms of that collaboration to make sure that we keep everything secure. >> And for those organizations who are running large Java estates 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. >> I think this is one of the things that 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 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 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 7 days." If it's a high vulnerability, it may be within 2 weeks or 3 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 the time that people are going to have to look at in terms of rolling out those patches is going to shorten. So, that 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." Um, 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 it even if it's a medium, we might want to go 2 weeks or 3 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 things 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 released 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 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, uh in terms of those security patches, we've had those available to our customers within 1 hour of Oracle releasing every update. So, there's literally no time when people can attack systems before you can deploy those patches. >> I'm pretty sure that you folks working with your partners, uh 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 the shift? >> Yeah, I mean, it's been very positive because um again, coming back to this this change that we're seeing in terms of uh using AI, I've spoken to a number of customers where not 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 um in a timely manner and making sure that they've got that maximum level of security. So, there there's definitely a lot going on um generally in terms of that strategy around patching. That's 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. >> Uh if I ask you in general, how does the software life cycle looks like after AI? >> I think what we're seeing there is is just uh a real acceleration in terms of the way that we we need to respond to changes uh that are required in terms of software. Now, that's both bug fixing and and security patches. Security patches is obviously the big thing because uh as as you say, I mean it's it's that approach where we we have to adapt to the fact that um there is going to be and some people call it a 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. Um I think the example that I read about was that um 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 that have been there for a while, not new things, but but have been around for a while and it's just finding those and exposing them. Now, we could 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 um 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 systems secure because as you say, bad actors as well will be using the same tools. um Maybe not Mythos, but you know, we've got the open weight models, things like Quen 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 on making sure that we are delivering all of those updates, and our customers are installing them in a timely manner. >> Simon, thank you so much for joining us and walking us through the end. Of course, those who are watching, if you're running Java in production, please do check out azul.com to learn more about these change security update cycle. Get prepared based on Simon's suggestions, and I'll see you in the next one. Simon, once again, thank you. >> Thank you very much.