Finding vulnerabilities in third party libraries

I’ve already blogged about OWASP Dependency Check as a Jenkins plug-in a little while ago. With SRC:CLR, a new web based alternative might be available.

To use it, simply register via GitHub login and follow the installation instructions for your operating system. After installation, execute a scan via command line: srcclr scan --url https://github.com/dschadow/JavaSecurity.git

The results are uploaded to SRC:CLR and can be examined on their website. For my repo, the report looks like this:

vuln-scanner-srcclr

As you can see, only one critical vulnerability is reported. Lets compare this to OWASP Dependency Check for the same repository and the same version. This scan was executed via dependency-check --project JavaSecurity --scan ./**/*.jar on command line, the result (on my own machine) looks like this:

vuln-scanner-dependency-check

OWASP Dependency Check identified three critical vulnerabilities; one being identical with SRC:CLR (Apache Common BeanUtils, CVE-2014-0114), and two more: JSTL (CVE-2015-0254) and Xalan (CVE-2014-0107). OK, a little difference, and both vulnerabilities are there (the dependencies are identified by SRC:CLR, but listed green with no vulnerability). At least both identified the critical one in Apache Common BeanUtils.

Second try, this time with my Application Intrusion Detection repository. SRC:CLR identified no vulnerable dependency, OWASP Dependency Check one (tomcat-embed-core-8.0.33.jar with four vulnerabilities); none of them matters for my application and/or Tomcat version.

By simply looking at the sheer numbers it is an OWASP Dependency Check victory. Both tools reported the critical vulnerability, but SRC:CLR skipped the more controversial ones. OWASP Dependency Check has the tendency to report more (everything), including false positives or CVEs that only may affect your application. And therefore forces the developer to decide about the relevance.

What I extremely like about SRC:CLR is their way of presenting the analysis. Especially the Dependency Path column which shows you whether it is a direct dependency or a transitive one. But of course it is an online tool, uploading everything to the cloud. Which in my case doesn’t matter because of my public GitHub repos. This might be different in an enterprise environment.

Which one to choose? I’ll stick to OWASP Dependency Check on my Jenkins, the reports are fine, and false positives can be excluded. And it keeps everything local. Without a local Jenkins build server I strongly recommend SRC:CLR, directly integrated in your GitHub repo. Vulnerable third party dependencies are a great risk, scanning every (web) application is an absolute must.

Finding vulnerabilities in third party libraries auf Twitter teilen
Finding vulnerabilities in third party libraries flattrn
Finding vulnerabilities in third party libraries auf Digg teilen
Finding vulnerabilities in third party libraries auf Delicious teilen
Finding vulnerabilities in third party libraries auf Xing teilen
Finding vulnerabilities in third party libraries auf LinkedIn teilen
Finding vulnerabilities in third party libraries auf Pinterest teilen
Finding vulnerabilities in third party libraries auf StumbleUpon teilen
Finding vulnerabilities in third party libraries auf Tumblr. teilen
Finding vulnerabilities in third party libraries auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren