By Enterprise Java estates accumulate unpatched runtimes across years of deployments, including versions that free OpenJDK distributions no longer support. Without a documented baseline of current exposure, security teams cannot sequence remediation or respond rationally to newly disclosed CVEs. Legacy desktop deployment technologies including applets and Java Web Start add further risk that most vulnerability programs do not account for.
In this interview on TFiR, Simon Ritter, Deputy CTO at Azul, covers how point-in-time vulnerability assessment creates the baseline that makes Java remediation planning possible, who owns that responsibility inside an enterprise, and how Azul provides security coverage for JDK versions that the broader OpenJDK ecosystem has abandoned.
Guest: Simon Ritter, Deputy CTO at Azul
Show: TFiR
Here is what every DevOps engineer, platform team, and security architect managing Java infrastructure needs to know.
Technical Deep Dive
Q: What does a point-in-time risk assessment actually give a DevOps team that continuous monitoring does not?
Simon Ritter, Deputy CTO at Azul, explains that a point-in-time assessment provides a concrete baseline of what the organization is exposed to right now across its entire installed estate, which may span systems deployed five, ten, or twenty years ago. That baseline is the prerequisite for everything that follows. Without it, teams have no reference point from which to measure the impact of subsequent patches or to identify which systems carry the highest exposure. Ritter notes that most organizations genuinely do not know what their current vulnerability landscape looks like until they run this kind of assessment.
“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.” — Simon Ritter, Deputy CTO, Azul
Q: How does a vulnerability baseline help teams prioritize remediation when patches arrive on a quarterly schedule?
Ritter describes the baseline as a working foundation that teams can compare against each new patch release. Because Java security updates follow a predictable quarterly schedule except in emergency cases, teams can use the baseline to identify which systems have the highest exposure and sequence remediation accordingly. When a new update is released, teams can map newly addressed vulnerabilities against their documented baseline to determine whether any high or critical issues require immediate action. This structured approach replaces reactive, ad hoc patching with a planned cadence.
“You’ve got systems that have been installed for maybe 20 years, five years, whatever, but a long period of time. What the baseline gives you is a very clear picture in terms of what you’re exposed to right now.” — Simon Ritter, Deputy CTO, Azul
Q: Who should own Java security inside an enterprise, DevOps, SecOps, or leadership?
Ritter argues that security is everybody’s responsibility from individual contributors through to the executive layer. DevOps carries the primary operational responsibility for monitoring and patching systems. All employees need training to avoid behaviors that introduce risk, including downloading software from unverified sources, which is a common vector for rogue runtimes entering an estate. At the leadership level, the CIO, CEO, and CFO must ensure the right strategies are in place and lead the organizational posture from the top.
“Security should be everybody’s responsibility from the bottom to the top.” — Simon Ritter, Deputy CTO, Azul
Q: What does a realistic Java remediation path look like after an assessment identifies significant exposure?
Ritter explains that Azul produces a remediation priority roadmap from the assessment findings, which the DevOps team can use to schedule and sequence work based on which systems need to be addressed first. The roadmap provides a structured order of operations rather than leaving teams to self-prioritize against an undifferentiated list of vulnerabilities. This allows organizations to work systematically through their exposure rather than attempting to address everything simultaneously or defaulting to the easiest fixes first.
“The remediation priority roadmap that we create allows the DevOps team to schedule things and prioritize based on what systems they need to address first.” — Simon Ritter, Deputy CTO, Azul
Q: What Java versions does Azul support that free OpenJDK distributions do not cover?
Ritter states that all free OpenJDK distributions go back to JDK 8 at most, with Azul being the sole exception that extends coverage to JDK 7 and JDK 6. Many enterprise customers Azul works with are still running these older versions in production. Azul includes security updates for JDK 6 and JDK 7 as part of its core product, meaning organizations that need to remain on those versions are not forced to choose between staying on the version and having no security coverage.
“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.” — Simon Ritter, Deputy CTO, Azul
Q: How does Azul address security for legacy desktop deployment technologies like Java applets and Java Web Start?
Ritter identifies applets and Java Web Start, which he groups under the term desktop deployment technologies, as a category that still appears frequently in enterprise environments running older applications. Azul provides solutions for these technologies that enable organizations to maintain the highest possible level of security for those deployments rather than leaving them to run with accumulated, unpatched vulnerabilities. This coverage is particularly relevant for desktop systems tied to older application stacks that cannot easily be migrated.
“For desktop systems with very old applications, we can provide solutions for those to enable you to have the maximum level of security, rather than just running them with potentially many vulnerabilities.” — Simon Ritter, Deputy CTO, Azul
Resources & Documentation
- Azul JVM Security, Azul’s security assessment and extended support offering for enterprise Java environments including legacy JDK versions
- Azul Platform Prime, Azul’s core product providing security updates for JDK 6, JDK 7, JDK 8, and later versions
***
👇 Click to Read Full Raw Transcript
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: 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, you know, maybe 20 years, you know, 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, you can, you know, 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 in 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. What. 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: 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, you know, randomly, which is again, where we see the idea of how do these runtime 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 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 what role does Azool 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 JDK6 and JDK7 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.
“`
**Meta Description:** Java estates running JDK 6 or JDK 7 have no free OpenJDK support. Simon Ritter of Azul explains how baseline assessment and remediation roadmaps close that gap.
**SEO Title:** Java Vulnerability Baseline and Legacy JDK Remediation, Simon Ritter, Azul | TFiR
**Permalink:** /java-vulnerability-baseline-legacy-jdk-remediation-azul/
**Focus Keywords:** Java vulnerability baseline, JDK 6 JDK 7 security, OpenJDK extended support, Java remediation roadmap
**Category:** Security
**Tags:** Java Security, JVM Security, OpenJDK, Legacy Java, Vulnerability Management, Azul, DevSecOps, Patch Management
**Excerpt:** Simon Ritter of Azul explains how a point-in-time Java vulnerability assessment creates a remediation baseline, who owns security across DevOps and SecOps, and why Azul is the only provider extending security patches to JDK 6 and JDK 7.
