Quite a few years ago I first heard of OWASP: the Open Web Application Security Project. They have become particularly known for their top 10: a list of the ten riskiest vulnerabilities found in web applications. This list aims to increase awareness within organizations and especially within development teams. But they do much more than publish and maintain this top 10.

They develop various applications and tools in the field of security. The OWASP Dependecy Checker is an example of this. This allows you to check for all dependencies of your project whether any vulnerabilities are known in the NVD (National Vulnerabilities Database) and what they entail. And which version you need to upgrade to to no longer be susceptible to it. Until recently, I have made no effort to examine the dependencies of my projects in a structured manner. The use of dependencies with known vulnerabilities ranks 9th in the OWASP top 10 of 2017.

During Devoxx Antwerp last November I saw this presentation by Julien Topçu entitled: “Find and Track the hidden vulnerabilities inside your dependencies”. And I was sold. How is it possible that I have not previously used such an important tool in our build street? When I got home, I immediately started experimenting with the simplest, first step: let the maven plugin see which vulnerabilities are in our dependencies. Documentation about the plugin was a bit difficult to find, but just persevere and you will find a few things. Experimentally, I discovered that version 4.x is intended for use with Java 8 and newer, while 3.x runs on older Java versions. And you need internet in your build street, because the plugin will periodically download the NVD.

Deploying the plugin turns out to be a piece of cake, the real work is determining to what extent your software is affected by a security problem found. You must analyze the vulnerability and estimate how a hacker can take advantage of it. It is not inconceivable that you estimate this incorrectly. It is therefore my preference to upgrade each vulnerable dependency to a version, if available, that fixes this. This may require adjustments to your own code if the new version has API changes.

Dependency checker tries to determine the name, vendor and version of each dependency. The way this is done can cause errors. I noticed at a customer that a number of libraries, which the company itself creates and only distributes internally, were recognized as an open source dependency that contains vulnerabilities. So a 'false positive'. You can provide the maven plugin with a list of these false positives to help the process. Using the HTML report that the dependency checker produces, you can easily generate an entry for this list from a false positive.

When you use the tool for a new project and you have cleared a backlog of vulnerable dependencies, it is important to think about how you want to structurally use this tool in your build street. Keep in mind that this plugin will quickly add a few minutes to the feedback loop for multi-module projects. In addition, you must realize that the vulnerabilities found depend not only on the dependencies that the project uses, but also on the bugs that are published in the NVD. This can ensure that vulnerabilities in legacy applications, which are only subject to occasional maintenance, can remain unnoticed for a long time. It is therefore advisable to run the dependency check for each project daily in its own job.

Especially in larger organizations, it happens that the vulnerabilities found have to be reported outside the development team, for example to a security department. If the team estimates that the vulnerability found in the dependency cannot be abused in any way, then the security department might also want to know the reasoning. This administrative task can be handled with e.g. the Dependency-Track application or via a SonarQube plugin. Both tools are Open Source projects from OWASP.

If your project does not yet use a tool to check its dependencies for known vulnerabilities from the NVD database, then I recommend that you definitely try out OWASP dependency checker. “Protect yourself at all times” is always good advice.