What Is OWASP Dependency-Check and How It Can Improve Application Security
OWASP Dependency-Check is a Software Composition Analysis (SCA) tool that actively scans through a project’s dependencies to detect and report on publicly disclosed vulnerabilities, thereby improving application security.
Open source projects often suffer from security vulnerabilities. If left unchecked, these vulnerabilities can compromise entire systems that rely on these open source tools. According to a recent security report by Open Source Security and Risk Analysis (OSSRA), an average of 528 open source components were found per application in 2020.
It is critical for organizations to focus on the software supply chain, including third-party components. Developers need a solution integrated with the application code and used to track vulnerabilities in external dependencies. OWASP Dependency-Check is an open-source solution created by the OWASP project, famous for its OWASP Top 10 list of vulnerabilities, designed to help developers mitigate open-source security threats, thereby securing the application.
OWASP Dependency-Check is a Software Composition Analysis (SCA) tool that actively scans through a project’s dependencies, detects and reports publicly disclosed vulnerabilities, ensuring application security.
Get the free OWASP Dependency-Check tool here.
In this article:
- Benefits of OWASP Dependency-Check
- How Dependency-Check Detects Vulnerabilities
- 11 Different File Type Analyzers
- Dependency-Check Report
Benefits of OWASP Dependency-Check
OWASP Dependency-Check enables developers to track and eliminate any known vulnerabilities in open source projects.
1. Free tool
As OWASP Foundation is a non-profit organization, the Dependency-Check tool is free. Developers can download the tool and start using it as part of their security stack.
2. Ease of use
Dependency-Check is easy to get started and does not require reviewing documentation, training, or certification.
3. Lightweight
Dependency-Check is relatively small in size, using a simple process to scan the code. The only maintenance it requires is a regular update of a local copy of its vulnerability data.
4. Extensive Reporting
Dependency-Check offers multiple reporting options for developers to check and rectify open source vulnerabilities. The tool’s export features allow teams to create vulnerability reports that focus on their key metrics.
5. Compatibility
Dependency-check is compatible with many popular languages, technologies, and platforms, including:
- Complete support for Java and .NET-based products
- Experimental support for Node.js, Ruby, and Python projects
- Partially compatible with C and C++
- Intergrates with Maven, Jenkins, and Gradle via plugins and can run through the CLI as an Ant task
How Dependency-Check Detects Vulnerabilities
OWASP Dependency-Check identifies vulnerabilities using Analyzers. These are dedicated open source projects that execute the entire dependency scanning process. Essentially a sniffing tool, analyzers are responsible for examining every data packet to verify its relevancy and record its information. They can be used for data retrieval and error scanning.
How Analyzers Work
Dependency-Check scans through files and collects information about project dependencies through a series of analyzers. This information collected – known as evidence – is bucketed into three categories: vendor, platform, and version information. It is then tagged with a confidence level (low, medium, high, and highest). The confidence rating is a method of flagging the potential vulnerability that must be verified.
For example, the Jar analyzer accumulates data from the Manifest, pom.xml, and the package names within the JAR files scanned. After gathering the necessary information, it employs a process to place this information into one or more buckets of evidence.
The Common Platform Enumeration (CPE) of the dependency is determined, and the result is assigned a level of confidence. This level of confidence is based on the lowest confidence rating of the evidence used. The identified CPE is recorded in the Lucene Index and subsequently cross-checked against the Common Vulnerabilities and Exposures (CVE) entries in the National Vulnerability Database (NVD), a free-to-use database of known information-security vulnerabilities.
Dependency-Check automatically updates itself with the NVD data as soon as it is run. These updates ensure that the reports show only the most recent data.
The results are compared and made available in various formats like HTML, XML, CSV, and JSON for developers to take appropriate action. However, the Dependency-Check tool doesn’t take the context of your dependencies when reporting the vulnerability scores. So, developers must verify if the vulnerability exposes their code.
Here is a list of the Analyzers currently available as part of the Dependency-Check tool.
11 Different File Type Analyzers
The tool contains the following analyzers, each of which is able to scan a specific type of file:
- Archive – extracts and scans archive content
- Assembly – needs .NET framework or Mono runtime
- Jar – scans archive manifest metadata, and Maven Project Object Model files
- RetireJS – examines JavaScript files
- Node.js – gathers a bill-of-materials after parsing a package.json
- Node Audit – requires internet access and uses APIs to expose vulnerable node.js libraries
- NugetConf – parses specification XML using XPath
- Nuspec – parses specification XML using XPath
- OpenSSL – parses OPENSSL_VERSION_NUMBER macro definition
- OSS Index – similar to Node Audit, it uses internet to use APIs and report vulnerabilities not listed in the NVD
- Ruby bundler-audit – responsible of executing bundle-audit reports and adding the results in final report
Experimental Analyzers
Dependency-Check offers several experimental analyzers, which are still in development and thus might generate a large number of false positives and false negatives.
- Autoconf – scans project configuration files for AC_INIT metadata
- CMake – extracts project initialization and version setting commands
- CocoaPods – Scans specification file to extract dependency information
- Composer Lock – Extract exact version of dependencies by parsing PHP Composer Lock files
- Go lang mod – Determines dependencies used
- Go lang dep – Parses dependency file directly from the lock file
- PE Analyzer – Obtains dependency information from PE Headers
- Python – Scans Python source files for setuptools metadata
- Pip: Regex – Scans Python Pip requirements.txt files
- Ruby Gemspec – Scans Gemspec initialization blocks for metadata
- SWIFT – analyzes Swift package file
Dependency-Check Report
Dependency-Check provides the following data in its report about vulnerabilities it discovers:
- Dependency – filename of the dependence scanned
- CPE – Common Platform Enumeration identifiers
- CVE Count – number of associated CVEs
- CPE Confidence – reliability of CPE identified
- Evidence count – data extracted from dependency that was used to identify CPE
Dealing with False Positives and False Negatives
Once developers receive the report after the dependency check, they need to verify if the CPE was identified correctly by identifying false positives and false negatives.
False Positives
The Dependency-Check methodology is likely to raise false positives in the reports, which can be suppressed using the suppress button next to each CPE identified in the HTML report. By clicking the button, you can copy the XML into a suppression XML file. This helps Dependency-Checks avoid the false positives in future scans.
False Negatives
To identify false negatives, you can use the ‘Display: Showing Vulnerable Dependencies’ feature to review the dependencies that do not have a CPE match. Upon identifying a vulnerable dependency without a CPE match, you can create evidence to determine the CPE.
Once developers address the false positives and false negatives, they need to review if the identified CVEs are vulnerable to their software environment. However, one key thing to note is even if a CPE is found multiple times, the report will list it only once. This offloads the responsibility onto the developers to determine the locations where vulnerability mitigation is needed.
