DependencyCheck v5.0.0-M3 releases: detects publicly disclosed vulnerabilities in application dependencies

Dependency-Check

Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies. It does this by determining if there is a Common Platform Enumeration (CPE) identifier for a given dependency. If found, it will generate a report linking to the associated CVE entries.

OWASP dependency-check is an open source solution for the OWASP Top 10 2013 entry: A9 – Using Components with Known Vulnerabilities. Dependency-check can currently be used to scan Java and .NET applications to identify the use of known vulnerable components. Experimental analyzers for Python, Ruby, PHP (composer), and Node.js applications; these are experimental due to the possible false positive and false negative rates. To use the experimental analyzers they must be specifically enabled via the appropriate experimental configuration. In addition, dependency-check has experimental analyzers that can be used to scan some C/C++ source code, including OpenSSL source code and projects that use Autoconf or CMake.

How does dependency-check work?

Dependency-check works by collecting information about the files it scans (using Analyzers). The information collected is called Evidence; there are three types of evidence collected: vendor, product, and version. For instance, the JarAnalyzer will collect information from the Manifest, pom.xml, and the package names within the JAR files scanned and it has heuristics to place the information from the various sources into one or more buckets of evidence.

Within the NVD CVE Data (schema can be found here) each CVE Entry has a list of vulnerable software:

<entry id="CVE-2012-5055">
  ...
    <vuln:vulnerable-software-list>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:3.1.2</vuln:product>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:2.0.4</vuln:product>
      <vuln:product>cpe:/a:vmware:springsource_spring_security:3.0.1</vuln:product>
    </vuln:vulnerable-software-list>
  ...
  </entry>

 

 

 

 

These CPE entries are read “cpe:/[Entry Type]:[Vendor]:[Product]:[Version]:[Revision]:…”. The CPE data is collected and stored in a Lucene Index. Dependency-check then uses the Evidence collected and attempt to match an entry from the Lucene CPE Index. If found, the CPEAnalyzer will add an Identifier to the Dependency and subsequently to the report. Once a CPE has been identified the associated CVE entries are added to the report.

One important point about the evidence is that it is rated using different confidence levels – low, medium, high, and highest. These confidence levels are applied to each item of evidence. When the CPE is determined it is given a confidence level that is equal to the lowest level confidence level of evidence used during identification. If only highest confidence evidence was used in determining the CPE then the CPE would have the highest confidence level.

Changelog

Version 5.0.0-M3

Breaking Changes

  • OWASP dependency-check now uses the NVD Meta files in addition to the *.json.gz files. If you have a local mirror of the NVD you must now mirror the meta data files. The nist-data-mirror has been updated to include these files.

Changes

  • Several bug fixes and minor enhancements have been made; see the related issues and pull requests.
  • Multiple report formats can be specified; if you wanted just two of the reports you no longer need to use ALL.
  • A new JUNIT formatted report has been added; this provides a different way to integrate with Jenkins builds; the following example creates a JUNIT report with failures for any CVE with a CVSS score greater than or equal to 7.0 the Jenkins pipeline script shows how to publish the report: pom.xml

Download && Tutorial

Dependency-Check is Copyright (c) 2012-2017 Jeremy Long. All Rights Reserved.

Source: https://github.com/jeremylong

Share