How to Find and Fix Known Vulnerabilities in Your Java Software Supply Chain

Both cybercrime and cyber security legislation are on the rise—which means it’s more important than ever to keep your applications secure. The majority of software is built on open-source libraries, and unfortunately, these components are often riddled with known, exploitable vulnerabilities. And fixing them can be a time-consuming process.

Fortunately, our software composition analysis tool lets you quickly find and prioritize vulnerabilities in your Java projects. Our developer guidance makes it far easier to patch vulnerabilities once they’re detected.

Here’s how it works:

How to find security vulnerabilities in your Java software supply chain

When you select a Java project in MergeBase, you’ll immediately see how many known vulnerabilities have been detected in the project, as well as the level of risk your project is currently exposed to.

Additionally, MergeBase lists every component the Java project incorporates, along with the risk levels associated with any known vulnerabilities in these components.

In this example, we see that our project has about a dozen known vulnerabilities lurking in our components—and at least two of them expose us to an extremely high level of risk.

How to prioritize fixes with MergeBase

An important problem plaguing the world of application security is vulnerability fatigue: developers report feeling overwhelmed with the number of issues their various AppSec tools report. Sifting through all these vulnerabilities and then prioritizing fixes can be exhausting—which leads to many vulnerabilities simply going unaddressed.

However, MergeBase helps relieve this fatigue by showing you where the high-risk, fix-it-right-now vulnerabilities reside in Java projects. By default, MergeBase sorts all project components by risk level, so the vulnerabilities that need to be addressed right away show up first.

In this example, we can immediately see that two components are housing some very high-risk vulnerabilities.

Let’s fix these first.

How to fix vulnerabilities using MergeBase developer guidance

Most vulnerabilities that you find in an SCA tool can be fixed by using one of two treatments:

1. Updating the vulnerable component library to a later, more secure version—which we’ll call a “simple fix.”
2. Updating the vulnerable library and updating your application so that the new library is compatible—which we’ll call a “complex fix.”

Good news: MergeBase’s developer guidance helps you understand right away whether a vulnerability requires a simple fix or a complex fix!

How to make a simple fix using MergeBase

In our example, we can see that the “log4j-core 2.15.0” component contains a high-risk known vulnerability. If we click on that component, MergeBase shows us all the known vulnerabilities at play in this library.

Looks like we have not one, but three CVEs hiding in log4j! But lucky for us, if we toggle over to the “Guidance” tab, we’ll see how to fix all three.

The first thing we see when we look at the Guidance tab is a version graph that shows us where we are now with our current version of log4j, along with a lineup of more recent versions we can update to, and what risk levels we face with each of them.

All we need to do is select a version based on three criteria:

1. Compatibility with the rest of our Java project
2. The level of risk the new version represents
3. How widely trusted the new version is (the more popular, the better)

Right off the bat, we can see that all of these versions are 100% compatible with our project—which means we’re looking at a simple fix. Three of these versions contain vulnerabilities (and have very high risk scores), so we can rule those out immediately.

That leaves us with three remaining options to choose from—but this isn’t a hard choice. Version 2.17.1 is used by about 2,050 other projects at the time of the scan, which means far more developers are relying on it than the later versions. So we’ll trust it too.

Now it’s time to implement the patch. All we have to do is select version 2.17.1, click that “Patch Info” button on the top right, and MergeBase will tell us how to move to the new version of this log4j library.

We’ll click that copy icon below the code snippet and open our “pom.xml” file. First, we find the dependency that references the vulnerable version of log4j:

Then all we have to do is replace the old log4j dependency with the code we copied from MergeBase:

And just like that, we’re all green on log4j! Using MergeBase, we were able to quickly find, prioritize, and patch a serious vulnerability in just a few minutes.

How to make a complex fix using MergeBase

Sometimes a new version of a component will require you to make some updates to your own application in order for it to work right. While this is more time-consuming than a simple fix, MergeBase’s developer guidance can help you choose versions that will cause the least amount of breakage in your application.

To illustrate, let’s fix that other high-risk vulnerability we found earlier—the one in the tomcat library. If we click on the “tomcat-embed-core 9.0.30” component, we see that we’re dealing with eight CVEs—one of which has a very high risk score.

Just like we did with the simple fix, we’ll move over to the “Guidance” tab to see what our remediation options are.

MergeBase shows us a lineup of tomcat versions with no known CVEs at all—awesome! But if we look at the compatibility scores, we can see that not all of these will play equally nice with our own application.

For example, if we select version 10.0.23 (which has a compatibility score of 88%) and hit “Patch Info,” MergeBase will again give us some guidance and an easy copy-paste snippet of code to add to our “pom.xml” file:

Once again, we’ll locate the relevant dependency …

… and replace it with our code from MergeBase:

But if we do this, it breaks our application! Look at all those red error lines on the left—this won’t do. If we want to work with this version of tomcat, we will need to revise our proprietary code to accommodate the changes in this library.

But what happens if we update to a library that’s more compatible with our application?

If we go back to the MergeBase Guidance panel, we can see an earlier version of tomcat that’s a lot more compatible with our application (97% instead of 88%). Let’s see what happens if we try implementing this patch.

If we copy and paste in the code that MergeBase gives us for this version, the application still runs smoothly:

By using MergeBase’s compatibility score, we’ve secured ourselves against known vulnerabilities and kept our application running smoothly.

However, we can’t always count on mostly-compatible versions. Sometimes a tiny difference in compatibility will require us to tweak our application so that it works with the new component version. When this happens, it’s important to check the open-source library’s documentation around updates. If they’ve done their homework, they can provide further guidance on making your application compatible with their latest updates.

Protect your Java applications from security vulnerabilities with MergeBase

We built the MergeBase SCA tool to help DevSecOps teams find, prioritize, and patch vulnerabilities that threaten their codebases. One of the ways we do this is by offering best-in-class developer guidance—so you have an informed idea of what solutions are available, how compatible they are with your application, and how to implement them.

If you want to find, prioritize, and fix known vulnerabilities in your software, we’d love to show you how we can help. To see how MergeBase can protect your application from known vulnerabilities, start your free trial today.