Tools

DependencyCheck v3.3.1 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 v3.3.1

Bug Fixes

  • Fixed error handling with regard to invalid manifest files contained within JAR files; see #1024.
  • Fixed parsing of pom.xml files, in some cases a SAX Exception would be thrown; see #1400.
  • Fixed bug that caused dependency-check to crash if the temporary directory and data directory were on different drives; see #1394.
  • Fixed bug in dependency-check-maven where an aggregate analysis did not scan all files defined in the ScanSet; see #1421.
  • Fixed NPE in dependency-check-gradle that occurred when artifacts where included using implementation files("./lib/some.jar"); see #91.

Enhancements

  • An Nuget Packages.config Analyzer was added; see #1412.

Download && Tutorial

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

Source: https://github.com/jeremylong

 

Read more…

Anastasis Vasileiadis

PC Technical || Penetration Tester || Ethical Hacker || Cyber Security Expert || Cyber Security Analyst || Information Security Researcher || Malware analyst || Malware Investigator || Reverse Engineering

Leave a Reply