TFiR

Separate Security From Bug Fixes to Protect Java App Stability | Simon Ritter, Azul

Duration: 3:15 603 transcript words EN summary

Video summary

The speaker highlights the inherent risks associated with traditional IT patching models, particularly the quarterly release cycle common in Java ecosystems like Oracle and Azul. In this standard approach, updates are bundled together, containing not only essential security patches but also a wide array of bug fixes, performance improvements, and other changes. While this consolidation seems efficient, it introduces significant instability because testing every single software component against such a massive volume of simultaneous changes is practically impossible before release. Consequently, organizations often face situations where an update intended to fix issues inadvertently breaks existing functionality or introduces new bugs, forcing teams into a reactive cycle of reworking and issuing corrective patches after the damage has already occurred. To address these stability challenges, the presentation advocates for a strategic separation of security updates from general bug fixes, a model already successfully implemented by Oracle and Azul through their Critical Patch Updates (CPU) and Patch Set Updates (PSU). Under this refined strategy, the CPU delivers only the necessary security patches, typically ranging from six to twelve changes per quarter, while the PSU contains the full suite of hundreds of potential modifications including bug fixes. The core argument is that by isolating security patches into a smaller, focused update, IT teams can apply them with much higher confidence that application stability will not be compromised. This distinction ensures that the critical security updates rarely, if ever, cause software breakage, whereas the larger PSU updates are reserved for times when organizations have the capacity to thoroughly test and validate the extensive list of non-security changes. Looking toward the future, this approach extends to a proposed monthly release cycle designed specifically to maintain system stability between the quarterly events. In these interim months, releases will consist exclusively of security patches with no accompanying bug fixes or performance tweaks, effectively eliminating the risk of unexpected regressions during routine maintenance windows. This disciplined method allows organizations to keep their systems secure without the fear that a standard update will disrupt operations or require emergency rollbacks. By decoupling the urgency of security from the complexity of feature changes and stability testing, companies can achieve a more sustainable and predictable patching environment that protects Java applications from the volatility often caused by large, all-encompassing updates.

Read the full video transcript

I come from the pure Linux and open source world and they are used to getting patches whenever it's ready. You patch things, but that is not sustainable model for IT team because you have to test a lot of things, you have to prepare a lot of things, things may break. So so just also talk about that what is the reason behind the quarterly then you know the whole monthly and are you aiming for a situation where we can send patches as soon as the patch is ready without breaking things or you like no, that is still far fetched, that is not going to be realistic. >> Yes, I mean that's one of the things that we face and if we look at the quarterly releases specifically, a quarterly release has a certain number of security patches, but it also has a large number of other changes. There will be bug fixes, there may be some minor secure minor performance improvements and things like that. So actually encompasses a lot more changes than just those security things. Now what we've done is we've kind of broken that into two distinct updates. So if you look at what Oracle do and what is all does, there's what's called a CPU and a PSU version of each update. The CPU is the critical patch update, the PSU is the patch set update. And essentially what that means is you get just the security changes or you get all of the changes. Now the reason that's very significant is because when you look at the number of security patches you get in a typical quarterly update, it is going to be somewhere around maybe six to 12. 15 would be a very large number of security patches, but if you look at the number of changes that are included in that full update because it is those bug fixes and performance improvements and so on, that could be anywhere between three and 500 changes. So it's a much bigger set of changes. The significance of that is that there's a lot more chance that one of those changes might impact the stability of your application. So come back to what you said about you know maybe things don't work the way you expect them to. So, what we need to be doing is is very careful about that because we've seen a number of situations where we've had an update which has been released. Now, because it happens on a quarterly basis, we can't test all software against that update before it's released. The update is released and then suddenly somebody will discover that a particular software package is being impacted by a change that's been included, fixes one bug, but actually introduces another bug. And we've had to go back and do a reworking of that, make sure it doesn't break the software, and then issue another update. So, that's the benefit of having the the security only update or CPU versus the the full update because we've never seen a change in the security update that's broken software. So, moving to a monthly cycle, what we're going to be doing is for those uh months in between the quarterly updates that we have at the moment, those will only be security patches. There won't be any bug fixes or anything like that. The idea behind that is to to try and help more in terms of stabilizing the the software. So, you're not going to get this problem of uh having to reissue a patch once you've you've done that.