OWASP Dependency Check as a Continuous Security tool
In my Continuous Testing post I introduced
you with an idea of Continuous Security. Those are automatic and repeatable tests which look for vulnerabilities in your
application. They should be run as often as possible (ideally after each commit). In case of failure build pipeline
should be stopped and person who introduced breaking changes should investigate what went wrong.
OWASP Dependency Check is one of the most popular continuous security tool. It takes your dependencies as an input,
compares them with local vulnerabilities database and produces vulnerability report as a output. Integration is pretty
easy and potential benefits significant - you may be surprised how often even most popular open source libraries have
OWASP Top 10 A9 - Using components with known vulnerabilities
According to OWASP Top 10 using components with known
vulnerabilities is widespread. Almost every application has those issues because most development teams don’t pay much
attention to project dependencies. Libraries are often added to speed up development and never updated. This obviously
creates risks. Even famous Spring wasn’t an exception
allowing remote code execution in it’s Security OAuth.
Full range of weaknesses is possible (XSS, injections, broken access control, etc) and this subject shouldn’t be
OWASP Dependency Check Maven plugin
Let’s get down to business. I’ll show you how to integrate OWASP Dependency Check using
my AwesomeTesting GitHub projectwhere I store and maintain every
line of code ever written on this blog.
All you need to do is to add Dependency Check to your pom and run one command. For a start it’s better to not integrate
it into Continuous Delivery pipeline. That’s why I’m keeping it in separate security profile.
In order to start scanning run:
mvn -P security dependency-check:check
This is how console output should look like (first run would be significantly longer, because whole database
of National Vulnerability Database has to be downloaded).
As you can see few libraries I use in a project have known vulnerabilities. In addition, OWASP Dependency Check creates
nicely formatted .html report which you can see in full
Every single vulnerability is nicely explained with full description and links which contain detailed info. Affected
versions are also included. As a tester you would probably be interested in testing it - try upgrading
commons-collections to 3.2.2 and you would observe that vulnerability is no longer reported.
Ignoring False Positives
Unfortunately as almost every test automation tool Dependency Check isn’t free from false positives. After reading
detailed report you may conclude that your application doesn’t use vulnerable code and suppress reporting for given
library. Here are two simple steps to ignore commons-collections 3.1 from reporting.
a) You need to create ignore file (it’s created automatically by clicking suppress
on .html report)
b) Provide a path in pom.xml
OWASP Dependency Check in Continuous Integration
After full vulnerable dependencies investigation and ignoring false positives you can integrate OWASP Dependency Check
into Continuous Delivery pipeline. Let’s say you want to be notified if new vulnerability had been discovered. Just add
_mvn dependency-check:check_as a build step and set failBuildOnCVSS value. Build would now fail if something new pops
reporting can be nicely integrated into your CI tool. Here is example screenshot from TeamCity.
OWASP Dependency Check is a quick win tool. With ever growing security concerns and free powerful hacking tools testers
would be pushed more and more into pentesting. You can start doing it today with my easy to adopt guide.