Finding Security Vulnerabilities in your Dependencies with Dependency-Check

The Open Web Application Security Project (OWASP) may be best known for its top 10 list of the most critical web application security risks. However, the project not only talks about problems; they offer a wide range of documentation to fix those problems (like the .NET Security Cheat Sheet) and publish tools like the OWASP Dependency-Check. This tool can help you to address number 9 of the top 10 list – using components with known vulnerabilities.

Known security vulnerabilities are published on sites like CVE and NVD. You could visit those sites and check for updates manually, but those sites publish so many vulnerabilities that this task is futile. It is therefore down to two options:

1. ignore it
2. automate the checks

While option 1 is tempting, it is no solution for your application. This post is about option 2 using one of the freely available tools.

 
This post is part one of a small series on finding security vulnerabilities in your project dependencies:

1. Finding Security Vulnerabilities in your Dependencies with Dependency-Check
2. Using Dependency-Check with VSTS and SonarQube
3. Finding Security Vulnerabilities in your Project Dependencies with Audit.Net

Installation

You find the code of Dependency-Check on GitHub and the pre-compiled binaries on Bintray. Download the *.zip file, extract it in a suitable directory and you are done.

Check for vulnerabilities

Open a terminal window, change into the root folder of your project and execute the dependency-check.bat script:

This command will search for *.dll in your packages folder and check them against known security vulnerabilities. You find the list of all command line arguments in the official documentation.

The resulting HTML report lists all your dependencies and shows which one have known problems:

Fix false-positives

There is one big problem with Dependency-Check: It lists an awful lot of false-positives. We use Hangfire with a SQLServer module and get a vulnerability reported for the SQLServer package of Node.js. Same target system, two completely different libraries.

At least the HTML report offers a nice help to supress such false-positives. You find on every reported vulnerability a supress button:

You can click on it to get the snipped to supress the message:

For the first supress entry, you should click on the button called Complete XML Doc. This gives you the whole file with the XML header and the correct namespace where you then can past in the other supress snippets:

It still requires a lot of manual work, but you can do that once and then only work with the real vulnerabilities.

The next time you run the checker you can add a --suppression flag and add your XML file with the snippets from above:

Next

This manual approach works, but it will not last for long. A better approach is to integrate it into your quality workflow and automate the execution of the scanner. The next post will explain how you can use Visual Studio Team Services and SonarQube to automate the scanning.