



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 security flaws.

2) OWASP Top 10 A9 - Using components with known vulnerabilities



Why bother?



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 ignored.

3) OWASP Dependency Check Maven plugin Why bother?





Let's get down to business. I'll show you how to integrate OWASP Dependency Check using my AwesomeTesting GitHub project where 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: 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 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 details here





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.









4) 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









4) Ignoring False Positives5) OWASP Dependency Check in Continuos Integration6) Conclusions7) Further Reading