Swapnil Bhartiya: As autonomous AI threat actors make software vulnerabilities easier than ever to exploit, security teams are racing to secure their hidden, unmanaged Java runtimes. Today we have with us Simon Ritter, Deputy CTO at Azul, to talk about how a new free assessment helps enterprises instantly map and secure these invisible blind spots. Simon, it’s good to have you back on the show.

Simon Ritter: Great to be here again.

Swapnil Bhartiya: Thank you, Simon. Let’s set the stage for our audience. Azul just launched a free JVM vulnerability risk assessment. Before we get into what it is, what it does, can you help us understand the threat landscape that you are responding to, specifically how autonomous AI changes the urgency around Java runtime security?

Simon Ritter: Yes, I mean, as we’ve seen, the growth of AI and how much it’s being used has really kind of just taken everybody by surprise. I think that’s fair to say. And we’ve seen over the last few months that the idea of cybersecurity has become very, very relevant. Because if you look at Anthropic, who are one of the big companies behind the AI models, they announced what they called Mythos. And Mythos was a new model for them which they had determined had very powerful cybersecurity detection, vulnerability detection, and also exploit capabilities. And so they actually have kept it fairly under wraps. And there’s been a lot of issues around the American government deciding that they don’t want people to access it and various things like that that I won’t go into. But essentially the model that they’ve created now has capabilities which allows it to look at software and find vulnerabilities that haven’t been found before and do it in such a way that we can find many more than we had before. If you look at some of the statistics, I think one of the oldest vulnerabilities that it detected in an open source piece of software was like 27 years old. So the code that was responsible for that was like 27 years old. And that vulnerability hadn’t been detected in all that time. But in terms of the impact, it is huge. Because we can look at the fact that again, from what Anthropic have said, because they’re keeping it under wraps, they have this thing called Project Glasswing, they’re keeping it under wraps, but they have said that they’ve basically detected vulnerabilities in every operating system, every web browser. They pointed it at all the sort of commonly used pieces of software. Now Java from that perspective is also a very commonly used piece of software. And again, to sort of give you some idea of how important it is from a Java security perspective. One sort of data point, if you like, which is not specific to the Java runtime, but if we look at the libraries which also sit on top of Java, there’s an interesting statistic that I saw related to another language model, so not actually Mythos, but somebody used another one. And again, this is why it’s very important, because even today I’ve seen announcements about OpenAI, they’ve announced GPT 5.5 cyber. So it’s not just about Mythos, it’s about other models catching up. And specifically, the article that I read said that they had pointed the model that they were using at certain things which were known vulnerabilities and ones that have been exploited in the past. And the one that kind of caught my eye was one that we’ve seen a few years ago, which was Log4Shell based on the Log4J library. And they basically took the model and they said, right, pointed at Log4J, which was the library, but without the information that had been published about the vulnerability. So it didn’t have any prior knowledge of that. And it went and it tried to see whether it could determine a vulnerability and whether it could create an exploit and it did. Okay, so that’s very concerning. What’s even more concerning is the fact that it took 18 minutes and 53 seconds to do that. So from pointing at a piece of software to having a usable exploit, 18 minutes and 53 seconds. So what is important is understanding that the threat landscape is changing. It’s changing a lot in terms of the perspective of thinking that we are going to see quite a lot of vulnerabilities being identified and having to be patched over. I would say the next year, 18 months, maybe two even longer years. And that’s going to be very important, is understanding that new threat landscape and what are the priorities when it comes to patching the critical software that you’ve got running in your estate.

Swapnil Bhartiya: Now, when it comes to enterprises, a lot of enterprise teams are already running SBOMs and static code scanners. They feel like they have full coverage, but that’s not the case. What does this assessment find at the JVM runtime layer that those tools completely miss?

Simon Ritter: You’re right. So a lot of companies are already using SBOMs. They’re already using static code and analyzers. And the thing with SBOMs is that that’s a supply chain and we’ve seen over the last few months, few years even, that there have been attacks on open source software where people have managed to get a pull request, a commit that’s been taken on board, which has basically injected a vulnerability into an open source code base and that’s then propagated. Because if you take something which is a very commonly used library that can then be propagated into other packages, other applications, and has a very serious effect. So SBOM is a very useful tool to minimize the amount of attack surface that you have in terms of those vulnerabilities. Similarly, if we look at static code analysis, certainly we’ve got static code analysis that we could run on the JVM itself and the JDK source code, but those tools from an end user perspective are much more about analyzing application code. So you’ve got this idea of supply chain management, you’ve got this idea of looking at end user applications, but there’s still the issue of, in terms of deployments of Java runtimes, what are you potentially missing? Because neither of those tools are going to show you exactly what is the problem. And if I kind of explain what we’re doing with this runtime analysis, it’s essentially saying, okay, you’re going to have various Java virtual machines and JDKs installed on lots of different systems all over your estate. What we’re going to do is we’re going to look at all of those and identify which versions of Java you have running, even down to which update level you have. And then based on that information, we can look at all the vulnerabilities that have been identified and fixed in various updates. And by saying, okay, well if you’ve got an update which was a year ago or two years ago, we know all of the updates since then, which vulnerabilities have been identified and remediated. We can then provide a list of the ones that you’re exposed to in that instance, because you haven’t updated since a particular date. What we then do is we say, okay, let’s run that across your entire estate. Look at all the different Java installations you have, because they’re going to be a wide variety of versions, updates, platforms, providers, all of those types of things. Bring all that information together into a centralized sort of dashboard view, which then allows you to see all of that information in much more digestible form so that you can see, okay, I’m exposed to this number of vulnerabilities on this number of machines, this level of vulnerability and so on. So it gives that sort of dashboard idea. You’ve got a high level view which you can provide to a CXO type of individual. Whether a CIO, CTO, CEO, it gives them a very clear picture very quickly of what your vulnerability exposure is there. We can also give you a risk by version breakdown, how many older versions you’ve got there, potentially ones that aren’t even supported anymore. We’ve also got the idea of identifying any Java runtimes which have what are called KEVs, known exploited vulnerabilities. And these are where it’s not just a vulnerability that’s been identified, it’s one that has actually been used to attack a system which has resulted in a data breach or a denial of service or whatever. And then the last part that we give you from that is the idea of a prioritized remediation roadmap. And it’s the idea that you can say, okay, if you had to address machines, you’ve got thousands of machines potentially, what are the ones you really need to go and hit first and say, okay, these are the ones that need to be updated quickly because they’re exposed to the most vulnerabilities. They may have critical vulnerabilities, they’re exposed to that may be these known exploited vulnerabilities that are sitting there. So if you’ve got that list in a sort of prioritized order, you know where to start and then gradually work your way down that list.

Swapnil Bhartiya: And that’s a critical gap. So how does these unmanaged and embedded JVMs sneak into production in the first place without security or platform teams even knowing they are there?

Simon Ritter: Yeah, there’s a couple of ways that this happens. The first is simply the fact that Java is over 30 years old now. In fact, it’s 31 years old. And that means that Java’s been around for a long time, which means that it’s been used to deploy applications for decades, literally decades. And that means that people have installed Java virtual machines and Java runtimes in different places to support different applications. And the people who did that may not even work for your company anymore. It may not be documented anywhere, it may not be recorded anywhere. So that sort of sneaking in is partly because the platform is so old that people have installed things. Similarly, when Java was completely free back in the days of Sun, in the early days of Oracle’s stewardship, people would really just bundle it into a standard build and they’d say, okay, well there’s a desktop there. Let’s just include a JDK in the desktop build and put it on every machine. But there’s other things as well where people will go, okay, I’ve got this application I need to run. Maybe it’s a personal productivity application and it needs a Java runtime. So what they’ll do is they just go to the Oracle website or to a website like Azul’s, and they’ll say, right, I’m going to download a Java runtime. It’s free, I can just download it, put it on my machine and off I go. And so unless there is something in place in an organization which tracks downloaded software, and I certainly know of people more recently who have done things like disabling the access to Oracle downloads pages through their firewall software and even to the level of saying, okay, if you’re downloading an Oracle JDK, they put the signature of that Oracle JDK into their virus software and it will be detected as a virus. So there are various ways that the software can make its way into your estate without necessarily being spotted by the DevOps team.

Swapnil Bhartiya: Now, once you know what’s exposed, you still have to fix it. And that’s where a lot of teams get stuck. Enterprise teams are often terrified of patching legacy Java because they are afraid of breaking things in production. How does Azul’s assessment actually help overcome that operational friction?

Simon Ritter: Yeah, I mean, I think that when we look at that sort of situation, and I’ve certainly seen this with various customers I’ve spoken to where there is a reluctance to upgrade the Java runtime because there is a nervousness about it breaking application functionality. But the reality is that Java as a platform is very, very stable. I mean, I can certainly say, yes, there have been situations where we’ve seen that an update has come out and it’s had an impact because it’s included a change which has fixed one bug, but it’s then resulted in another bug which has impacted other applications. So we’ve certainly seen that. There’s no denying that. And that has probably led to some of this nervousness about implementing the updates. But I think the way that I would explain that is to say, well, if you have a very clear picture of what you’re exposed to in terms of those vulnerabilities in your estate, and you look at certain applications, then you have to then evaluate the balance of how much risk you are prepared to accept in terms of doing an update which potentially could impact the stability of your application. But that’s going to be the case even if you installed an update to the application itself. So it’s a little wrong to think that Java is going to be something which will break your application, but certainly it will give you a level of seeing what your potential is there versus the number of vulnerabilities you’re exposed to. So if you’re exposed to critical vulnerabilities where it’s like a 9.6 or 10.0 on the CVSS scale, then what you’re going to want to do is say, right, I really need to fix those machines. It’s critical that I fix those machines. Because again, going back to that Log4Shell example, if you haven’t patched that, you are exposed to a very, very simple remote code execution vulnerability, which means people can take over your machine. That far outweighs the nervousness about updating your systems. So it’s knowing that balance between what level of vulnerabilities you’re exposed to versus the nervousness about updating your application runtimes.

Swapnil Bhartiya: You mentioned patching. I want to talk a bit about that. There is a distinction you make between security only critical patch updates or CPUs, and standard patch set updates or PSUs. Why does that distinction matter so much when it comes to regression testing burden for platform teams?

Simon Ritter: Yes, and this is very important as well, because as you quite rightly point out, we have what’s called the CPU and the PSU essentially when an update is issued for Java, and that happens four times a year. So it’s very regular, it’s very well organized, very well documented. We know that on the second Tuesday of the month of January, April, July and October, there will be an update to the Java platform. Great. But what’s delivered is an update that contains the security patches, but it also contains lots of other stuff as well. There’ll be bug fixes, there’ll be some performance improvements, some other code changes. And if we look at the number of changes that you have in terms of security patches, that’s typically around about 10, less than 10. If you look at the total number of changes in a full update, that’s going to be of the order of 3 to 500. So there’s a lot more chance that the nervousness about the update breaking your applications comes true. If you’ve got a very large number of changes, there’s more chance of that happening. Very small set of changes, less chance of it happening. So if you look at what Oracle and Azul deliver. So Oracle started this idea and Azul has followed this, which is that we provide our customers with both what’s called the CPU, the critical patch update, and the PSU, which is the patch set update. Now, the CPU is only the security changes, so that’s 10 changes. The PSU is the sort of 3, 4, 500 changes. When it comes to deploying that update, it’s much easier to go, right, we’ll deploy the CPU because only small set of changes, get the system secure, everything works nicely, great. Then we can do more testing with the full update. Once we’re happy that the application works the way we expect it to, then we can roll that out. If there is a problem, go back to the support organization of Azul, say our application is not working the way we expect it to. We can fix that, issue a new patch, and then get that system up and running again. So it’s giving you that flexibility. That means you can get your system secure as possible by using the CPU versus the PSU. And it’s worth saying that Azul is the only company that provides OpenJDK distributions other than Oracle that provides both of those CPU and the PSU.

Swapnil Bhartiya: Let’s zoom back on the threat model. How does a point in time risk assessment help DevOps teams actually outpace an automated threat? Something that can scan and exploit at machine speed?

Simon Ritter: Yeah, so the thing with, as you say, it’s a point in time where you scan your systems and you find out what you’re exposed to in terms of vulnerability. Essentially what that’s doing is giving you a baseline that you can work from. So as I said, you’ve got systems that have been installed for maybe 20 years, five years, whatever, but a long period of time that has all these systems installed. So what it gives you is a very clear baseline in terms of what you’re exposed to right now. Then you can look at that. And as I said, you can go through the list and see what are the most exposed systems and the least exposed systems. You can then work on those when it comes to subsequent updates, because we know that they come out on a regular basis, only on a quarterly basis, unless there’s an emergency one. But they are very sort of regimented and scheduled. That then allows you to go, okay, well, I’ve got my baseline, then I work from that to see what new vulnerabilities have been addressed in this particular update. If there are things that I need to then say, okay, well, there’s a high or critical vulnerability that I need to look at, then you can work on that. But it’s that idea of having a baseline because most people have no idea what they’re exposed to in terms of their current estate. Once you’ve got that picture, you can then move forward with individual updates and keep up to date in terms of seeing what’s actually being rolled out in terms of patches.

Swapnil Bhartiya: Now, when it comes to these challenges, these problems, who should own this problem inside an enterprise? Is it a DevOps responsibility? Is it SecOps responsibility? Or does it fall somewhere in between? Or is it everybody’s responsibility?

Simon Ritter: I think it’s everybody’s responsibility. I mean, security should be everybody’s responsibility from the bottom to the top. So yes, DevOps will have the major responsibility from the point of view of monitoring systems, patching systems and so on. All employees should have a responsibility in terms of security. They should be educated that they shouldn’t download software randomly, which is again where we see the idea of how do these runtimes sneak into an estate? So they should have the correct training for that to make sure they don’t do that kind of thing. But obviously at the high level, your CIO and your CEO, CFO even, then you should be looking at them to lead from the front and make sure that the right strategies are in place for everything.

Swapnil Bhartiya: For those organizations that go through this assessment and discover they have significant exposure, what does a realistic remediation path actually look like? And what role does Azul play beyond the assessment itself?

Simon Ritter: Having viewed the remediation priority roadmap that we create, that would then allow the DevOps team to schedule things and prioritize based on what systems they need to address first. From the point of view of how Azul can help with that is because we can provide support for older systems. And this is again quite important because if you look at free distributions of OpenJDK, most of them only go back to JDK. Well, in fact, all of them only go back to JDK 8 with the exception of Azul. So there are lots of customers that we come across who are still running JDK 7, JDK 6. So if there are people out there who want to continue using JDK 6 and JDK 7 with relevant security updates, then we can provide that for them as part of our core product. So it’s that ability to address those things. Similarly, for desktop systems with very old applications, often we see things like applets, we see Java Web Start, the what we call desktop deployment technologies. Again, we can provide solutions for those to enable you to have the maximum level of security for those as well, rather than just running them with potentially many vulnerabilities.

Swapnil Bhartiya: Simon, thank you so much for joining us today. The Java runtime security blind spot is one of those risks that is easy to overlook precisely because it has been hiding in plain sight for so long. And conversations like this are exactly what enterprise teams need to hear. Thank you so much for your time and I look forward to our next conversation. And for those who are watching, if your organization runs Java at scale and you are not sure what’s lurking in your runtime layer, go check out azul.com and if you find this valuable, please subscribe to TFiR, give it a like and share it with your team. Thanks for watching and see you in the next episode.

Simon Ritter: Thank you very much.