depencencyCheck is an open source dependency security scanner. This kind of tools are also called SCA (Software Composition Analysis).

dependencyCheck identifies which dependencies (aka third party libraries) a software is using and indicates if any of them have known vulnerabilities.

It also shows some additional valuable information about the findings, as the severity of the flaws, and why it has concluded that a specific version of a package is present (for example due to the presence of a specific file).

In this article, I’m going to explain what dependencyCheck is, how to install it, basic usage, how to analyze its findings, and how to contribute to it.

How to manage dependencyCheck findings

dependencyCheck findings are not always vulnerabilities. Before stating that a codebase has a vulnerability, some analysis is needed. For example, the detection of the vulnerable package might be a false positive, and although dependencyCheck thinks a third party library of a specific version is present, it is not.

It might also happen that although a third party library is present, it is not used by the application. If this is the case, in my opinion, it is a risk,  and the package should be removed, but the severity would be much lower.

Another case is when the vulnerable package is present and is in use, but it is not using it in a vulnerable way. For example, it might use the third party library but not the vulnerable function. Or maybe it is using the vulnerable function, but the software is doing an additional check that is preventing the vulnerability.

If the vulnerable package is present, it is always a risk, but maybe not a vulnerability. In my opinion, it should be upgraded, however, the urgency and priority will depend on the real severity.

Don’t report dependencyCheck findings as vulnerabilities without proper analysis and without understanding the issue and, if possible, report them always with a PoC that demonstrates the impact.

Installation of dependencyCheck

Installation on Fedora 34 is trivial:

• Browse to https://owasp.org/www-project-dependency-check/
• Download the latest release by clicking the “Command Line” link on the right sidebar. In my case, it downloads this https://github.com/jeremylong/DependencyCheck/releases/download/v6.2.2/dependency-check-6.2.2-release.zip
• Decompress the file:

$ unzip dependency-check-6.2.2-release.zip

• Now you should be ready to execute it:

$ ./bin/dependency-check.sh -h

Basic usage

To show how to use it, I’m going to scan Keycloak codebase. Keycloak is an open source and free Identity and Access Management solution (IAM) for modern applications and services. It supports OpenID Connect and SAML 2.0 protocols.

First, I clone Keycloak codebase:

$ git clone https://github.com/keycloak/keycloak

Then, I execute dependencyCheck on the keycloak folder:

$ ./dependency-check/bin/dependency-check.sh -s keycloak --enableExperimental

During the scan, the first thing it does is downloading the latest CVEs:

[INFO] Checking for updates
[INFO] NVD CVE requires several updates; this could take a couple of minutes.
[INFO] Download Started for NVD CVE - 2002
[INFO] Download Started for NVD CVE - 2003
[...]

My first scan of Keycloak is not going well, I see some warnings and errors.

These are the warnings:

[WARN] No lock file exists - this will result in false negatives; please run `npm install --package-lock`
[WARN] Analyzing `/home/fcano/keycloak/distribution/adapters/js-adapter-npm-zip/src/main/resources/package.json` - however, the node_modules directory does not exist. Please run `npm install` prior to running dependency-check
[WARN] Analyzing `/home/fcano/keycloak/examples/cordova-native/package-lock.json` - however, the node_modules directory does not exist. Please run `npm install` prior to running dependency-check
[WARN] Analyzing `/home/fcano/keycloak/package-lock.json` - however, the node_modules directory does not exist. Please run `npm install` prior to running dependency-check
[WARN] Analyzing `/home/fcano/keycloak/themes/src/main/resources/theme/keycloak.v2/account/src/package-lock.json` - however, the node_modules directory does not exist. Please run `npm install` prior to running dependency-check

To solve this, I need to install npm on my new Fedora:

$ sudo dnf install npm

Then, I execute npm install on the suggested folders:

$ cd /home/fcano/keycloak/distribution/adapters/js-adapter-npm-zip/src/main/resources/ && npm install
$ cd /home/fcano/keycloak/examples/cordova-native/ && npm install
$ cd /home/fcano/keycloak/ && npm install
$ cd /home/fcano/keycloak/themes/src/main/resources/theme/keycloak.v2/account/src/ && npm install

For the first one, I get this error:

npm WARN Invalid version: "${project.version}"
npm WARN resources No description
npm WARN resources No repository field.
npm WARN resources No README data
npm WARN resources No license field.

up to date in 0.469s
found 0 vulnerabilities

I would need to research more to understand what this placeholder means on a package-lock.json, and how it is filled. I’m ignoring this warning by now.

The second one identified some packages with known vulnerabilities and recommended a fix. This is functionality included in npm, but I’m not going into detail in this article:

found 24 vulnerabilities (10 low, 8 moderate, 6 high)
run `npm audit fix` to fix them, or `npm audit` for details

About the third one, it throws an error because it doesn’t find a package.json file…as the present package-lock.json file does not include any dependencies, I’m ignoring this warning too by now.

Additionally to these warnings, I get these two errors:

[ERROR] Exception from bundle-audit process: java.io.IOException: Cannot run program "bundle-audit" (in directory "/tmp/dctemp24146e95-ae9f-47b5-b36f-825c64beb582"): error=2, No existe el fichero o el directorio. Disabling Ruby Bundle Audit Analyzer
[ERROR] Could not perform Node Audit analysis. Invalid payload submitted to Node Audit API.

I solve the first one by installing rubygems and the bundle-audit gem:

$ sudo dnf install rubygems
$ gem install bundle-audit

About the second, it is an error related to one of the package-lock.json files that seem to not be valid for some tools.

After repeating the scan, I get one more error that was hidden after the previous ones:

[WARN] The Yarn Audit Analyzer has been disabled. Yarn executable was not found.

I fix by installing yarn:

$ sudo dnf install yarnpkg

At the end, I get the results on the file dependency-check-report.html.

The results

These are the stats for the scan:

42 packages identified with known vulnerabilities! They seem too many, but as explained in the section “How to manage dependencyCheck findings” above, they are not vulnerabilities until we have verified them one by one.

This is a sample of the vulnerable packages identified. As you can see, it indicates the severity, the CVE count, the confidence of the finding, and the number of evidences. The confidence and number of evidences are related to how dependencyCheck knows that the package is present. Better numbers mean more confidence.

It has found some critical issues.

For the first critical finding on the screenshot above, dependencyCheck shows information about the issue, including the CWE, a brief description, CVSS, and in which file it discovered that the package is present.

In my opinion, very valuable information that can help to identify the most important packages to test and upgrade, and maybe discover hidden dependencies (e.g. dependencies of dependencies) which might be a risk.

How to contribute to dependencyCheck

Contributing to dependencyCheck is straightforward and I would say that although it is a great tool, there is much work to be done. His main maintainer, Jeremy Long, is really cool, and in my experience very open to contributions. I contributed to dependencyCheck once by implementing a Pipfile analyzer. This is the PR: https://github.com/jeremylong/DependencyCheck/pull/2877. Please, if you think or feel that dependencyCheck can be improved somehow, try to contribute to it.

Conclusions

dependencyCheck is a great open source SCA tool that gives very good results. In the past, I tested some commercial closed SCA tools that used to give me similar results, not better.

Think about including a tool like dependencyCheck in your build/deployment pipeline in a way that you automate the scanning and the triage of the results.

Also, consider giving priority to open source solutions like dependencyCheck versus similar free closed proprietary cloud solutions. By using and improving open source tools, we all improve and have more alternatives if something goes wrong.