By Enterprise security teams running SBOMs and static code analyzers are operating with a significant blind spot. Neither tool inventories the JVM runtimes actually executing in production, which means unpatched Java installations, including those exposed to Known Exploited Vulnerabilities, remain invisible until an attacker finds them first. Across large estates, the problem compounds because JVMs have been installed by teams, contractors, and automated build processes over more than three decades, with no central record of where they are or what version they are running.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, breaks down exactly what SBOMs and static analyzers miss at the JVM runtime layer, how unmanaged runtimes accumulate in enterprise environments, and how Azul’s runtime security assessment delivers a prioritized remediation roadmap across an entire estate.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every platform engineer and security practitioner needs to know.
Technical Deep Dive
Q: What does SBOM-based security miss about JVM runtime vulnerability exposure?
Simon Ritter, Deputy CTO at Azul, explains that SBOMs address supply chain security by tracking what software components are in use and whether those components have been tampered with or injected with malicious code through compromised pull requests or commits. Static code analyzers, meanwhile, focus on application source code and do not examine the JVM runtime itself. Neither tool tells you which versions of Java are actually deployed across your estate, at what update level, or which CVEs those specific versions are exposed to.
“SBOMs and static code analysis are useful tools, but there is still the issue of, in terms of deployments of Java runtimes, what are you potentially missing? None of those tools are going to show you exactly what the problem is.” — Simon Ritter, Deputy CTO, Azul
Q: How does Azul’s JVM runtime security assessment work technically?
Ritter describes the assessment as scanning every system across an enterprise estate to identify all installed Java Virtual Machines and JDKs, capturing version, update level, platform, and provider for each. That inventory is then cross-referenced against the full history of CVEs identified and remediated in subsequent Java updates. For any installation that has not been updated past a certain date, the tool produces a specific list of vulnerabilities to which that instance is currently exposed. All of that data is surfaced in a centralized dashboard with a high-level view suitable for CXO reporting and a detailed risk-by-version breakdown for engineering teams.
“We look at all the vulnerabilities that have been identified and fixed in various updates. If you have an update which was a year or two years ago, we know all the vulnerabilities that have been identified and remediated since then, and we can provide a list of the ones you are exposed to in that instance.” — Simon Ritter, Deputy CTO, Azul
Q: What are Known Exploited Vulnerabilities (KEVs) and why do they matter more than standard CVEs?
Ritter distinguishes KEVs from standard CVEs by noting that a KEV is not merely an identified vulnerability but one that has already been used in an active attack resulting in a confirmed data breach or denial of service. The Azul assessment flags any Java runtime on the estate that carries a KEV exposure, separating those instances from machines that carry only theoretical CVE risk. This distinction allows security teams to direct immediate remediation effort toward the highest-probability attack surfaces rather than treating all vulnerabilities equally.
“Known exploited vulnerabilities are where it is not just a vulnerability that has been identified. It is one that has actually been used to attack a system, which has resulted in a data breach or a denial of service.” — Simon Ritter, Deputy CTO, Azul
Q: How does the assessment produce a prioritized remediation roadmap across thousands of machines?
Rather than delivering a flat list of vulnerable machines, Ritter explains that the assessment ranks systems by the severity and number of vulnerabilities they carry, with KEV-exposed and critical-CVSS-rated instances surfaced at the top. Teams managing thousands of machines have a sequenced starting point instead of an undifferentiated remediation backlog. The roadmap also highlights runtimes that are no longer on any supported update track, which carry permanent exposure because no future patch will address their vulnerabilities.
“If you have got thousands of machines, the prioritized remediation roadmap tells you where to start. These are the ones that need to be updated quickly because they are exposed to the most vulnerabilities, and they may have critical or known exploited vulnerabilities sitting there.” — Simon Ritter, Deputy CTO, Azul
Q: How do unmanaged and embedded JVMs enter enterprise production environments without being detected?
Ritter identifies several mechanisms. Because Java is now 31 years old, runtimes were installed to support applications over multiple decades, often by staff who no longer work at the company and with no documentation left behind. During periods when Java was entirely free, organizations routinely bundled JDKs into standard desktop builds without tracking them as managed software assets. Individual contributors also download Java runtimes directly from Oracle or Azul to support personal productivity applications, bypassing any central approval process. Unless an organization actively blocks Java download pages at the firewall or flags JDK installer signatures in endpoint security software, those installations proceed silently.
“The people who installed those runtimes may not even work for your company anymore. It may not be documented anywhere. That sort of sneaking in is partly because the platform is so old that people have installed things over decades.” — Simon Ritter, Deputy CTO, Azul
Q: Why are enterprise teams reluctant to patch legacy Java runtimes, and is that fear justified?
Ritter acknowledges the concern is not unfounded. There are documented cases where a Java update fixed one bug but introduced a regression that affected application behavior, and those incidents have contributed to a lasting reluctance to update runtimes in production. However, he frames the decision as a risk balance: the stability risk of applying a Java update must be weighed against the security risk of leaving known vulnerabilities unpatched. At the critical end of the CVSS scale, specifically scores at 9.6 or 10.0, or where KEVs are present, the calculus shifts decisively toward patching. The Log4Shell remote code execution vulnerability is the example Ritter uses to illustrate that some unpatched exposures allow complete machine takeover, which far outweighs the risk of a runtime update.
“If you are exposed to critical vulnerabilities where it is a 9.6 or 10.0 on the CVSS scale, you are going to want to say, I really need to fix those machines. That far outweighs the nervousness about updating your systems.” — Simon Ritter, Deputy CTO, Azul
Q: How does the Azul assessment dashboard communicate risk to CXO-level stakeholders?
Ritter describes a tiered dashboard design. The top-level view is built for CIO, CTO, or CEO consumption, presenting total vulnerability exposure, machine counts, and severity distribution in a form that does not require deep technical context to interpret. Below that, engineering teams get the risk-by-version breakdown, the KEV-flagged machine list, and the prioritized remediation sequence. The design separates the communication layer from the operational layer without requiring two separate reports or manual summarization.
“You have a high-level view which you can provide to a CXO type of individual. It gives them a very clear picture very quickly of what your vulnerability exposure is.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security Assessment, runtime vulnerability scanning and prioritized remediation roadmap for enterprise Java estates
***
👇 Click to Read Full Raw Transcript
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 security. 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 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 none 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 kind of 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 sort of a high level view which you can provide to a CXO type of individual, whether it’s cio, cto, CEO, 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 in 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, you know, 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, you know, personal productivity application and it needs a Java runtime. So what they 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 would 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, or, I mean, not wrongfully, but they are 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: 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. 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 CBSS 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 Log4J 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.
