Who Owns Java Security When Your Estate Has Thousands of CVEs? | Simon Ritter, Azul
Watch on YouTubeVideo summary
The video addresses the critical challenge of managing security risks in enterprise environments where legacy systems accumulate thousands of Common Vulnerabilities and Exposures (CVEs). The core argument presented is that a point-in-time risk assessment serves as an essential baseline for DevOps teams, allowing them to move beyond reactive measures against automated threats. By scanning current systems, organizations can clearly identify which assets are most exposed versus those that are least vulnerable, creating a structured foundation for future updates. This baseline approach transforms the chaotic nature of patching into a regimented process, enabling teams to prioritize critical vulnerabilities and track exactly what new security gaps are addressed in subsequent quarterly updates or emergency patches.
Regarding ownership of this complex security landscape, the discussion emphasizes that responsibility is shared across all levels of an organization rather than resting solely on specific departments like DevOps or SecOps. While DevOps teams hold the primary duty for monitoring systems, applying patches, and managing infrastructure, every employee must be educated to avoid downloading random software that could inadvertently introduce runtimes into the estate. Furthermore, leadership roles such as the CIO, CEO, and CFO are expected to lead by example, ensuring that comprehensive security strategies are implemented from the top down. This collective approach ensures that security is not just a technical hurdle but a cultural priority involving everyone from entry-level staff to executive management.
For organizations discovering significant exposure through these assessments, the transcript outlines a realistic remediation path supported by specific technological capabilities, particularly those offered by Azul Systems. A major hurdle in securing legacy environments is the lack of support for older Java versions; most free distributions of the OpenJDK only support back to JDK 8, leaving many enterprises running on JDK 6 or JDK 7 without security updates. Azul distinguishes itself by providing core product support that extends security patches to these ancient versions, allowing customers to continue using their legacy systems safely. Additionally, solutions are available for desktop technologies like Java Web Start and applets, ensuring that even older applications can operate with maximum security rather than remaining vulnerable due to a lack of official updates. Ultimately, the conclusion is that combining a clear risk baseline with specialized support for outdated runtimes allows enterprises to maintain security posture without forcing an immediate and often disruptive migration away from critical legacy applications.
Read the full video transcript
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.
>> As you say, it's it's a point in time uh
where you 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, 5 years, whatever, but a long
period of time that has all these
systems installed. So, what it gives you
is 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 on a quarterly basis unless
there's an emergency one but um 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 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 uh move forward
with individual updates and keep up to
date in terms of seeing what's actually
being rolled out in terms of patches.
>> 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?
>> I think it's everybody's responsibility.
I mean security it 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. Um all employees should have a
responsibility in terms of security.
they should be educated that they
shouldn't download software you know uh
randomly which is again where we see the
idea of uh how do these runtimes sneak
into an estate uh so they should have
the the correct training for that to
make sure they don't do that kind of
thing but obviously at the higher level
your CIO and your CEO CFO even um then
you should be looking at them to lead
from from the front and make sure that
the right strategies are in place for
for everything
>> 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 a Google play
beyond the assessment itself?
>> Having viewed the remediation uh
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 of how Azour
can help with that is because we can
provide uh support for older systems and
this this is again quite important
because um if you look at free
distributions of open JDK most of them
only go back to JDK well in fact all of
them only go back to JDK8 with the
exception of Azour. 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 um product. So it's it's that
ability to address those things.
Similarly um 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 uh potentially
many vulnerabilities.