The Open Web Application Security Project (OWASP) releases a list every few years of the top ten application vulnerabilities. Over the years, “Using Known Vulnerable Components” has been number nine on this list. This vulnerability covers the use of any dependency in an application that contains a vulnerability. On the surface it may seem easy to fix: Just update the dependency. However, this is often more difficult than it would seem. Today’s applications use a plethora of open-source libraries. It’s the nature of modern development. Keeping track of all the dependencies and known vulnerabilities is a full-time job. Since a vulnerability in a dependency can open your application to compromise, how can an organization deal with this?
This article introduces Sonatype’s GitHub application DepShield. DepShield scans your GitHub repository and analyzes your dependencies for known vulnerabilities. The vulnerability information is based on Sonatype’s OSS Index, which contains vulnerability information for open-source software. The best part is that it’s free!
Read on to learn how to install the application in your GitHub repository and get started.
Running the Vulnerable Application
To demonstrate the process of installing the DepShield application, we need a repository. For this reason, I’ve created a bare-bones Java Spring Boot application that uses Apache Maven for dependency management. While the application doesn’t do much, it does have a few dependencies that have known vulnerabilities. You can find the application repository here.
Go ahead and fork the depshield-demo repository so you have your own copy to install DepShield into. Since DepShield is a marketplace application, you can’t just clone my repository to follow along. You have to create your own fork.
First, clone the fork of the repository that you made:
$ git clone git@github.com:[your-github-username]/depshield-demo.git && cd depshield-demo
If you want to run the project locally, run the following from the command line:
depshield-demo $ mvn package && java -jar target/depshield-demo-0.1.0.jar
This will run the embedded Spring Boot Tomcat server. It’ll take a few seconds to boot up. Once it does, open your browser and point it to http://localhost:8080. You’ll see the following:
This means everything is working and you’re good to go!
Examine the Project’s Dependency Tree
If you look at the Maven build file, pom.xml, you’ll see that most of this is boilerplate. Of particular note are the parent and dependencies blocks, where we specify a few dependencies:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.0.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.1</version>
</dependency>
</dependencies>
You’ll see we’re using the 2.0.0.RELEASE version of Spring Boot. This has a dependency on version 5.0.4.RELEASE of the Spring Framework. This version has a known vulnerability: CVE-2018-1272.
We’re also using an old version of the Apache Log4j logging framework, 2.8.1, which also has a known vulnerability: CVE-2017-5645. We’ll expect to see these in the DepShield output.
Installing Sonatype DepShield
Installing the DepShield GitHub app is straightforward and is done directly from the GitHub marketplace. The DepShield app can be found here. Go ahead and click the big green “Install” button.
The next screen will ask you to select which account you want to install DepShield in (assuming you have more than one). Select whichever one you have your repository fork in.
After selecting which account to use, you’ll need to either select all your repositories or a specific one. In this example, I’m only installing DepShield into the caseydunham/depshield-demo repository. Note that in order for DepShield to work it needs read access to code and metadata. It also needs read and write access to checks and issues. This is because DepShield will automatically create GitHub issues for your project for each identified vulnerable dependency.
If the above all looks good, click the “Install” button one last time and you’ll be greeted with a congratulatory screen. That’s it! Sonatype DepShield is in your repository, identifying your issues.
What’s DepShield Doing?
Behind the scenes, the DepShield application periodically extracts the dependencies and compares this information with the Sonatype OSS Index of known vulnerabilities. The information in the OSS Index includes publicly known vulnerabilities. It doesn’t include curated intelligence or expert remediation that you can access from the Nexus Platform.
It may take a few minutes for DepShield to scan your dependencies, but if you go back to your repository, you’ll see there are now four new issues created. But wait a second—why four? We only specified two dependencies with known vulnerabilities. Well, the answer to this is what’s known as transitive dependencies, which we’ll get to later. For now, let’s click on the “Issues” tab and take a look at what DepShield has found.
DepShield Creates Issues for You
As mentioned, DepShield creates an issue for each dependency that’s determined to have a known vulnerability for it. Let’s take a look at the issue for org.springframework:spring-core:5.0.4.RELEASE.
Digging into this issue we see that DepShield has added some useful information to the issue. For each library, it lists the known Common Vulnerability Exposure (CVE) identifier along with the Common Vulnerability Scoring System (CVSS) score.
For this library, it indicates that CVE-2018-1272 is a known vulnerability and has a CVSS score of 7.5. CVSS scores range from 0.0 to 10.0, so this is pretty high! While there’s more to judging the risk that a vulnerability poses to the application than just the CVSS score, this does help prioritize issues.
The other useful piece of information that DepShield provides are the occurrences of the vulnerable library. It also includes the dependency tree to show how the dependency made it into the project. Here it shows that the spring-core:5.0.4.RELEASE library is a transitive dependency of spring-boot-starter-web.
What actually is a transitive dependency? Glad you asked.
What’s a Transitive Dependency?
When building an application it’s not uncommon for our dependency list to grow pretty wild. Each dependency generally has its own dependencies. This is especially true for frameworks like Spring and Spring Boot. A transitive dependency is one that we don’t explicitly specify, but is required by one of the libraries we need. That transitive dependency may also bring other dependencies and so on, until it’s dependencies all the way down.
Looking at the above issue list again, the com.fasterxml.jackson.core:jackson-databind:2.9.4 is a transitive dependency with a vulnerability that has the very high CVSS score of 9.8. This is a serialization vulnerability that an attacker could use to gain remote code execution on the server. This is a major issue and one that deserves attention.
Remediate the Vulnerability
DepShield conveniently gave us a link to the vulnerability information about jackson-databind at OSS Index. We can click through to see a summary that explains that the vulnerability was fixed in version 2.9.5. For the most minimal fix, we can pin the transitive dependency on jackson-databind to version 2.9.5 (or newer, if we want) by declaring this dependency explicitly in our pom.xml:
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.5</version>
</dependency>
Once we verify that our application still builds and works as expected with the new version of jackson-databind, we can commit the change and close the issue that DepShield gave us in GitHub. If there’s another vulnerability around this version of jackson-databind, DepShield will add another issue to our project.
Alternatively, we could have considered upgrading the spring-boot-starter-web dependency in our application that transitively required jackson-databind, instead of pinning jackson-databind. Library maintainers will often update dependencies as they release newer versions.
Update Your Dependencies!
Dependencies can grow to the point where they get out of hand. Developers can be following all the right security best practices, but due to a single vulnerable dependency, their application can still be susceptible to exploitation. Keeping dependencies up-to-date can present a huge problem if left unmanaged.
If the frameworks in your application aren’t up-to-date, the application can be a massive undertaking that costs time and money, for development as well as testing to bring it current.
What Are You Waiting For?
DepShield will periodically scan your repository to keep tabs on new vulnerabilities so you don’t have to. Whether you’re working on an open-source, or close-sourced, project, DepShield is a great tool to add to your defensive arsenal.
Written by Casey Dunham
Casey, who recently launched his own security business, is known for his unique approaches to all areas of application security, stemming from his 10+ year career as a professional software developer. His strengths include secure SDLC development consulting; threat modeling; developer training; and auditing web, mobile, and desktop applications for security flaws.