Jar Patching

Jar Patching

Automate updating to the latest version of each dependency across the fleet

Back to Solutions

The problem

When we first build a Java application, it’s easy to grab the latest dependencies from Maven or Gradle and include it in our software. A shiny new deployment on the latest server gets the software online and the business value achieved.

But over time as we add new features to the website, how often do we update dependencies or even look at previously built code?  After all, if we update to the latest version, we’d have to run the entire product validation sequence again.  We’d rely on unit tests if we had them, but does that catch all the corner cases in our libraries?

In time our system uses very out-of-date dependencies. Then what if a vulnerability is discovered in either a direct dependency or a linked dependency? How do we even know our system is vulnerable? For example, Log4j had a very public vulnerability that made nearly every Java app vulnerable, even if we didn’t directly use the library directly. Then they had multiple critical patches within days, causing a lot of churn as new holes were patched.

The solution

This Shoreline runbook allows the user to discover the jar libraries and versions consumed by the target application across the fleet of VMs where it is deployed. With this information, we query the public jar repositories for the current version, and identify libraries that are out-of-date. Then for the selected libraries, we automatically update the jars in each VM on the fleet. A quick reboot, and the patched dependencies are now in place across all the VMs and the application is now secure.


Customer experience impact
Potential hours of downtime
Occurrence frequency
Until the root cause is identified
Time to repair manually
4-5 manual hours
Shoreline time to repair
1-2 minutes
Attacker can exploit unpatched systems