Submind YouTube summaries
Thumbnail for Platform Teams: Deploy Java Security Patches Without the Fear | Simon Ritter, Azul

Platform Teams: Deploy Java Security Patches Without the Fear | Simon Ritter, Azul

Watch on YouTube

Video summary

The transcript highlights a critical distinction in Java maintenance between Critical Patch Updates (CPUs) and standard Patch Set Updates (PSUs), which significantly impacts the regression testing burden for platform teams. While major updates to the Java platform occur regularly four times a year, they typically bundle security patches with hundreds of other changes including bug fixes and performance improvements. This large volume of modifications in a full PSU increases the risk that an update might break existing applications, creating nervousness among developers about deploying such comprehensive packages without extensive testing. To mitigate this risk while maintaining high security standards, Azul follows Oracle's strategy by offering both CPU and PSU options to its customers. The approach involves first deploying only the CPU, which contains a very small set of changes—typically around ten or fewer—that are strictly focused on addressing security vulnerabilities. Because the scope is limited, the likelihood of introducing regressions is minimal, allowing systems to be secured quickly with confidence that core functionality remains intact. This initial step ensures that applications remain secure without immediately exposing them to the instability risks associated with a full suite of changes. Once the system has been stabilized using the CPU and confirmed to operate as expected, platform teams can proceed to deploy the PSU for additional bug fixes and performance enhancements. If issues arise during this second phase, such as an application not behaving correctly after the broader update is applied, organizations have the flexibility to revert or seek support without having compromised their security posture in advance. This two-step process provides a balanced workflow that allows teams to get systems up and running securely first, then gradually introduce further improvements while managing testing efforts effectively. Ultimately, Azul stands out as the only company besides Oracle providing open JDK distributions that offer both CPU and PSU options separately. By separating these updates, platform teams gain essential flexibility in their deployment strategies, enabling them to prioritize security through targeted patches before committing resources to broader feature sets. This method reduces the overall regression testing burden by isolating high-risk changes into a controlled second phase, ensuring that applications are robust against vulnerabilities while minimizing downtime and operational disruption during maintenance windows.
Read the full video transcript
You mentioned patching and I want to talk a bit about that. There is a distinction you make between security only critical patch updates or CPUs and standard patch set updates or PSUs. Why does that distinction matter so much when it comes to regression testing burden for platform teams? >> Yes. And and this is very important as well because as you quite rightly point out we have um what's called the CPU and the PSU. essentially when an update is issued for Java and that happens four times a year. So it's it's very regular. It's very well organized, very well documented. We know that on the second Tuesday of the month of January, April, July, and October, there will be an update to the Java platform. Great. But what's delivered is an update then contains the security patches, but it also contains lots of other stuff as well. There'll be bug fixes. There'll be some performance improvements, some other code changes. And if we look at the number of changes that you have in terms of security patches, that's typically, you know, round about 10, less than 10. If you look at the total number of changes in a full update, that's going to be of the order of 3 to 500. So there's a lot more chance that you know that nervousness about the update breaking your applications. If you've got a very large number of changes, there's more chance of that happening. Very small set of changes, less chance of it happening. So if you look at what Oracle and Azour deliver so Oracle started this idea and Azour has followed this which is that we provide our customers with both what's called the CPU the critical patch update and the PSU which is the patch set update. Now the CPU is only the security changes so that 10 changes the PSU is the sort of three four 500 changes. When it comes to deploying that update, it's much easier to go right, we'll deploy the CPU because only small set of changes, get that system secure, everything works nicely, great. Then we can do more testing with the full update. Once we're happy that the application works the way we expect it to, then we can roll that out. If there is a problem and go back to the support organization of Azour, say our application is not working the way we expect it to. We can fix that, issue a new patch, and then get that system up and running again. So, it's it's giving you that flexibility that means you can get your systems as secure as possible by using the CPU versus the PSU. And it's worth saying that Azul is the only company that provides open JDK distributions other than Oracle that provides both of those CPU and the PSU.