Automatic checks for vulnerabilities in Java project dependencies

Security is a difficult topic to control for software projects, as is proven by the constant reports of data leaks in the media. For software developers, it is difficult to oversee the sort of influence that their daily work, which is not directly linked to security issues, has on the security of their applications.

The original article from the magazine “Java aktuell” is available here for download.

The Open Web Application Security Project (OWASP), a non-profit organisation which aims to improve web security, provides a Top Ten of the most common security problems. It shows that code written by someone else can also contain vulnerabilities. This, however, can be checked in just a few steps. The article shows how you can easily keep up to date with at least the publicly known vulnerabilities in third-party code.

The approach shown here bases on the National Vulnerability Database (NVD), a database for security vulnerabilities. The database is maintained by the National Institute of Standards and Technology (NIST), an American federal agency, which also standardises well-known encryption algorithms such as DES and AES.

The NVD contains the weaknesses recorded in the industry standard “Common Vulnerabilities and Exposures” (CVE), among others. The OWASP offers an application that checks JAR files with the NVD automatically. This so-called “OWASP Dependency-Check” (DChck) has been implemented for command lines as well as for Ant, Maven, Gradle, SBT, Jenkins and SonarQube.

The following text shows a solution concept to regularly scan Java application dependencies for new security vulnerabilities using Maven and Jenkins. Once set-up there is no need for any further steps. Information on newly discovered security vulnerabilities is then provided via e-mail. This could either contain information on newly discovered security vulnerabilities in existing dependencies or already known security vulnerabilities in newly added dependencies.

 

First step: Using Maven plug-in without configuration

An initial dependency check of the application can be initiated in just a few seconds without further configuration using the Maven plug-in (MVN) by executing this maven goal mvn org.owasp:dependency-check-maven:1.4.0:aggregate.
Note that the dependency-check-maven-plug-in first downloads a local copy of the CVE database as an H2 database and saves it in the local Maven repository. This results in a file containing several hundred megabytes due to the number of known security vulnerabilities. Depending on available bandwidth and computing power, the initial creation could take a few minutes. Once successfully completed, the report is found under target/dependency-check-report.html. You can find an example of such a report on the project website.

Automation with Jenkins

In order to be informed about newly found security vulnerabilities in your project without further assistance, a regular automatic check is self-evident. The OWASP offers a plug-in for the Jenkins CI-server which can carry out checks and evaluate the results. The found security vulnerabilities can be viewed in Jenkins, job results can be set depending on the number of found security vulnerabilities and the trend of the number of found security vulnerabilities for a job can be represented in a diagram. This evaluation is configured in a post build action in the Jenkins job. The dependency check itself can be completed through a build step provided by the Jenkins plug-in or via Maven.
As the check can take some time, it should not be done for each commit/push. A nightly build or a build carried out once a week is therefore appropriate. An advantage of running checks with Maven Goal instead of Jenkins Build Step is that the central configuration is done in the pom.xml, as shown in listing 1.

Practice

To end there are still a few details that could be relevant to daily work with the Dependency-Check.

It is recommended to run the Dependency-Check in the Maven module that creates the published artefact (.jar, .war, .ear etc.). This will mean that only the relevant dependencies will be checked for security vulnerabilities and not the dependencies of modules that are only used in tests. Dependencies in the Maven scope test are not checked by default in the current version of the Maven plug-in. Dependencies in the provided and runtime scopes, however, are checked by default. This behaviour can be unwanted particularly for the provided scope. If, for example, due to the customer environment you are bound to a certain servlet API, you are powerless against the security vulnerabilities contained within. In this respect it can be useful to exclude this scope. This can be adjusted in the Maven configuration (see listing 2).

Alternatively, you can suppress certain CVEs even for individual dependencies. These are defined in a special file. The XML-code for suppression can be copied directly from the HTML report created in the first step. This can be particularly useful for false positives, that is, security vulnerabilities that are not applicable to the dependency. An example for this is the general suspicion of CVE-2016-3270 against all Jackson framework modules, although a security flaw only occurs in one of them. It is therefore generally useful to check each found security flaw for correctness. In each case it should be explained as to why a CVE has been suppressed in order to be able to understand the reasons for the exclusion at a later point in time. The possibility for this exclusion is shown in listings 2 and 3.