Automate dependencies checking

An application is like an iceberg. During a security code review, the focus will always be on the code written by the development team. It is easy to forget that most of the code running in production will be framework, libraries, the web server and the operating system.

(Credits robynm pixabay)

Keeping an operating system and its web server up to date might be a relatively simple task but, keeping track of all of the dependencies of an applications (framework and libraries) can be much harder. A complex application can easily have hundred of dependencies. Reviewing all the code of the libraries used is beyond possible for most company. On the other hand, making sure that at least all the libraries used don't have known vulnerabilities seems reasonable.

Tools available

I will present in this blog post two tools that can support this task for Java applications.

1.  OWASP Dependency Check (Java, .NET, Ruby, node.js, ..)
2. Victims (Python, Java)

Although the tools target the same objective, they used two different approachs.

1. OWASP Dependency Check

Dependency check extract various keywords including the filename, artifactid (if Maven) and META-INF properties. It than search those keywords in the NIST Natial Vulnerability Database feed.

At first, it might sound like an effective solution but in practice this approach is very approximate. A lot of false positive generated by this tool. The NIST feed include tons of applications that are not Java libraries. Application sharing common keyword in their name is really common,
The NIST feed is not a perfect source of information because not all libraries affected are documented in the database. The search will

Bottom line, it can still be use to do some automate research instead of googling each libraries one by one.

Example of report generated from OWASP Dependency Check

2. Victims CVE Project

Victims is taking a white list approach where all Java CVE are extracted from the NIST feed, documented and mapped to their respective Maven artifactId.

Unfortunately, the detection of many vulnerable artifact because of some missing hash. To still benefit from this source of information, I have start building an alternative client for maven that avoid the intermediary step of creating hash for each vulnerable jars. I did a short demonstration of the first release version at JavaOne last week.

Demo of the Maven Security Versions plugin (Click to zoom)

Clarification : The demonstration above use maven-security-versions. The official maven integration is called victims-enforcer.

Report generated from Maven Security Versions

Closing Thoughts

Just like static analysis tools, it is generally better to use more than one dependency checker. Using both tools allow you to have a better coverage.

References

OWASP Dependency Check : Official Dependency Check page
Victims : Official Victims Github project
RubySec: Ruby advisory database