Video summary
Azul's security-only patch model is designed to mitigate regression risks in production environments by isolating targeted security fixes from unrelated code changes. Because these patches address only specific vulnerabilities rather than introducing broad bug fixes or feature updates, the likelihood of impacting existing application stability is significantly reduced. Azul has never observed a scenario where their security patches caused regressions, unlike full updates which often include various bug fixes that can inadvertently break functionality. This approach allows customers to deploy critical and high-priority security patches with confidence, ensuring their systems remain both secure and stable without the downtime or risk associated with traditional update cycles.
The process begins with the OpenJDK Vulnerability Group developing security patches for the current version of Java, currently JDK 26. To support older versions, Azul backports these same security fixes to legacy distributions, a task that is often straightforward since it involves applying identical code changes to older source bases. However, as developers move further back in time, integration becomes more complex due to potential interactions with older system components. Consequently, the availability of these updates depends heavily on the specific binary distribution chosen by the user, as different vendors have varying policies regarding which Long-Term Support (LTS) versions they maintain and for how long.
Azul distinguishes itself in this landscape by providing backported security patches all the way back to JDK 6 and JDK 7, covering every LTS version from JDK 8 through JDK 25. In contrast, major competitors like Oracle no longer support these older versions, while others such as Microsoft and Red Hat have limited or paid-only support for legacy releases like JDK 8. This means that organizations relying on older Java versions must carefully evaluate their distribution provider to ensure they will continue receiving monthly security updates. Ultimately, selecting the right distribution is crucial for maintaining long-term security posture, especially since many vendors have stopped offering direct support for early LTS versions unless additional fees are paid.
Read the full video transcript
And how do these monthly CSPs protect
against regression risks in production?
How How is Azul's
security-only patch
model 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
means there's a significantly lower
chance any of those changes will have an
impact on existing applications. And
again, 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 customers can be much
more um
uh 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
you know, critical vulnerability or a
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 eight 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 is that the 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
the group that's responsible for
taking the vulnerabilities that are
reported against Java, developing those
security patches, and then bundling them
and building them into the uh the source
code.
>> [snorts]
>> 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 backport 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. Uh and really
the further back you go, the more you
have to be careful about um 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 backported 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 uh 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 those
monthly updates when they're made
available.