TFiR

How Enterprise Teams Must Rethink Java Patch Management Now | Simon Ritter, Azul

Duration: 4:15 763 transcript words EN summary

Video summary

The shift from a quarterly to a monthly update cycle for Java applications significantly increases the operational workload for DevOps and security teams within enterprises. Previously, these teams could review updates every three months, carefully evaluating which systems required patches based on the severity of vulnerabilities, such as deciding whether to deploy critical zero-day fixes immediately or postponing medium-level issues until the next quarter. Moving to a monthly cadence effectively triples the volume of work required for updating Java environments, although the fundamental strategy remains unchanged; the process of delivering and installing updates stays the same, but the frequency at which teams must execute these tasks becomes much more demanding. To manage this increased pressure, enterprise teams must adjust their patch management and testing processes to maintain security without overwhelming their resources. The industry adage that "the more sweat you spend during peace, the more blood you'll save" underscores the importance of being prepared for rapid response times. While the core methodology for applying patches does not need to change, organizations must scale their capacity to handle potential monthly releases rather than quarterly ones. This adjustment ensures that critical security vulnerabilities are addressed promptly while allowing teams to strategically manage lower-priority updates, preventing a backlog of maintenance tasks that could lead to system instability or delayed security improvements. Collaboration within the broader Java open-source ecosystem plays a vital role in supporting these enhanced security efforts through the OpenJDK Vulnerability Group. Established around 2019, this specialized subgroup brings together engineers from major distributors like Oracle, Red Hat, Microsoft, Amazon, SAP, and Azul to ensure that all binary distributions receive timely access to security patches. When vulnerabilities are identified, the group works collectively to develop fixes and upstream changes to the OpenJDK source code, but they operate under strict confidentiality protocols because the information involves unresolved security risks. Unlike the general OpenJDK project where mailing lists are public, this vulnerability group functions as a closed circle accessible only by invitation to maintain the integrity of sensitive data. All communications between members are encrypted to prevent any accidental exposure of vulnerability details before official updates are released, ensuring that organizations have adequate time to apply necessary security patches. This rigorous approach to collaboration and information protection demonstrates how the Java community prioritizes collective security, balancing open-source principles with the critical need to keep sensitive vulnerability data hidden until it is safe for public disclosure.

Read the full video transcript

Now, let's look at the the impact on the lives of DevOps and security teams. What does the operational schedule look like for DevOps and security teams? How should enterprise teams adjust and prepare their patch management and testing process to keep up with this? >> I mean, effectively what this is going to do is it's going to increase the workload for the DevOps teams and the IT teams who are handling Java applications. If you think about it, right now we're doing a quarterly cycle for our updates, which means that every 3 months the team can look at what's being delivered in that update. They can make their decision about which systems need to be updated, if there are certain particular security patches, the level at which that security patch is, then they can decide whether they want to deploy it or how quickly they want to deploy it. If, for example, there's a critical vulnerability reported, then you need to deploy that very quickly, especially if it's one that's tagged as a zero-day vulnerability. Or if you've got ones where there's only maybe a medium that's the highest-level one in that particular update, they may decide to postpone that for a few months or to the next quarter. But essentially moving to a a monthly cadence is in essence going to triple the amount of work that any IT or DevOps team has to do specifically for updating their Java. It won't really change anything in terms of the the overall strategy that they use because it'll still be the same idea. You deliver the update, you will install that on your machine in exactly the same way. It's just you're going to be faced with having to do it potentially every month rather than every 3 months. >> And there's a saying also, the more sweat you spend during peace, the more blood you'll save. So, it's it's also it's better to be ready for that. Now, can you talk about how do you folks Do you know what I mean? Azul collaborate with the broader Java open source ecosystem on security? >> Yes, as I say, there is this um subgroup within OpenJDK. It's called the OpenJDK Vulnerability Group. And that was established um several years ago now. I think it was maybe 2019, so it's been around for uh 7 years, maybe. Um it was established to help make sure that the binary distributions that are made available of OpenJDK outside of Oracle had access to those security patches, so they could again make sure that those distributions are as secure as possible. So, the group works together collaboratively. There are people representing most of but not all of the major OpenJDK distributions. There are engineers from Oracle, there are engineers from Red Hat, Microsoft, Amazon, SAP, Azul, obviously, um and so on. And what we do is we work together as a group when vulnerabilities are identified in Java, we will receive the information about that. We will then look at what we need to do to make changes to the the software itself. We will develop those patches, and then we will, at some point when the update is released, we will upstream the changes to the OpenJDK source code. Now, the important thing about that is because we're working on sensitive information, because these are vulnerabilities which haven't yet been resolved, it is critical that we don't expose any of that information before an update is released, so that people have the chance to to use the security patches. So, we do work in, even though it's an open source project, it is a closed group, meaning that it's not open to anybody to join. You have to be invited, you have to be part of the the group that um works on these distributions. And we make sure that none of the email between members of this group is published. Again, that's different to OpenJDK, where you can look at the mailing list and you can look at what people are saying. We don't publish any of that. And we even go to the level where all of the email between the the members of the group is encrypted, so even if that information was um, you know, seen on the on the net, then it wouldn't be exposed so that people could try and sniff packets and and expose information that way. So, it is taken very seriously in terms of that collaboration to make sure that we keep everything secure.