DependencyCheck v4.0.2 releases: detects publicly disclosed vulnerabilities in application dependencies
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:
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.
Version 4.0.2 (2019-01-01)
- Added the ability for the dependency-check-maven plugin to scan the dependencyManagement section of the pom.xml. Note that in the default configuration the dependency management section is skipped. To enable this feature set <skipDependencyManagement>false</skipDependencyManagement>.
- If using a local Nexus server (v2 or v3 pro) it is now possible to provide authentication credentials.
- Previous versions only worked with anonymous/unauthenticated access.
- See issue #977
- Updated fix for transitive dependencies with known vulnerabilities (guava and commons-collections) so that the upgrade occurs correctly in other integrations that utilize core; see issue #1562.
- Resolved several false positives
Dependency-Check is Copyright (c) 2012-2017 Jeremy Long. All Rights Reserved.