yayabobiWhile the big benefit of open source is the large developer community around it, that can also be its flaw. Open source projects have vulnerabilities that plague projects that are not well-maintained. If left unchecked, these vulnerabilities can compromise entire systems that rely on these open source tools. In the following, we will talk about securing the application stack against such vulnerabilities and how to use OWASP Dependency-Check.
According to the 2021 security report by Open Source Security and Risk Analysis (OSSRA), an average of 528 open source components were found per application in 2020, a surge from 84 components in 2016.
Although well-documented, developers tend to overlook the application security challenges that such vulnerabilities adopt from third-party libraries and frameworks. This enables hackers to compromise the project.
Hence, it became critical that organizations focus on the software supply chain, including third-party components. Therefore, developers need a solution that can be integrated with the application code and be used to track vulnerabilities in the external dependencies. One such solution is OWASP Dependency-Check, an open-source solution designed to help developers manage and ensure security in applications.
OWASP Dependency-Check empowers development teams to mitigate open-source security threats, thereby securing the application.
Understanding OWASP Dependency-Check
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. Unfortunately, the number of published open source software vulnerabilities shot up by over 50% in 2020, as per a report by White Source. This is alarming, considering over 95% of developers lean on open-source components for their projects.
As applications use libraries throughout the execution, they are given absolute freedom to access and transfer any data and write to any file. Therefore, a vulnerable library exposes the entire application to a hacker -- to execute transactions, access, and transfer data to the internet.
Dependency-Check was built by The Open Web Application Security Project (OWASP), a non-profit organization formed for application security. The solution is free to use, easy to integrate, and quick to report actionable information to ensure the security of your application.
Dependency-Check: Determining Vulnerabilities
Before we understand how Dependency-Check determines vulnerabilities, let us understand what Analyzers are.
Analyzers are dedicated projects that execute the entire dependency scanning process. Also known as 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.
OWASP Dependency-Check provides two types of analyzers -- File Type Analyzers and Experimental Analyzers.
11 Different File Type Analyzers
The tool contains multiple file type analyzers that executes a specific task:
1. Archive
Extracts and scans archive content
2. Assembly
Needs .NET framework or Mono runtime
3. Jar
Scans archive manifest metadata, and Maven Project Object Model files
4. RetireJS
Examines JavaScript files
5. Node.js
Gathers a bill-of-materials after parsing a package.json
6. Node Audit
Requires internet access and uses APIs to expose vulnerable node.js libraries
7. NugetConf
Parses specification XML using XPath
8. Nuspec
Parses specification XML using XPath
9. OpenSSL
Parses OPENSSL_VERSION_NUMBER macro definition
10. OSS Index
Similar to Node Audit, it uses internet to use APIs and report vulnerabilities not listed in the NVD
11. Ruby bundler-audit
Responsible of executing bundle-audit reports and adding the results in final report
Experimental Analyzers
In addition to these, Dependency-Check also features some experimental analyzers. These are not widely used due to the high probability of generating false positives and false negatives. The development team needs to be mindful of the following analyzers:
1. Autoconf
Scans project configuration files for AC_INIT metadata
2. CMake
Extracts project initialization and version setting commands
3. CocoaPods
Scans specification file to extract dependency information
4. Composer Lock
Extract exact version of dependencies by parsing PHP Composer Lock files
5. Go lang mod
Determines dependencies used
6. Go lang dep
Parses dependency file directly from the lock file
7. PE Analyzer
Obtains dependency information from PE Headers
8. Python
Scans Python source files for setuptools metadata
9. Pip: Regex
Scans Python Pip requirements.txt files
10. Ruby Gemspec
Scans Gemspec initialization blocks for metadata
11. SWIFT
Takes care of swift package file
Dependency-Check scans through the file and collects information about the 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.
Example: The JarAnalyzer of the Dependency-Check 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.
Dependency-Check Report
Familiarity with the following terms will help you read the Dependency-Check report:
● 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
Once developers receive the report after the dependency check, they need to verify if the CPE was identified correctly by sorting false positives and false negatives. This sorting is explained below:
False Positive
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.
False Negative
To identify false negatives, you can use the 'Display: Showing Vulnerable Dependencies' feature of the database 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.
OWASP Dependency-Check: Advantages
OWASP Dependency-Check enables developers to track and eliminate any known vulnerabilities onboarded from an open source.
It ensures application security by safeguarding the software supply chain. Therefore, Dependency-Check has become a go-to tool for developers because of the following advantages:
1. Free tool
As OWASP Foundation is a non-profit organization, the Dependency-Check tool is free. The development team does not have to go through an approval cycle or face budget constraints. They can download the tool from the internet and start using it without hassle to counter external threats when building applications.
2. Ease of use
Since there is no Proof of Concept (POC) process involved, getting started with the Dependency-Check tool is a three-step process -- download, install, and execute. Developers don't have to go through any documentation to deploy it. As long as you have a good internet connection, it'll take around ten minutes to get it running.
However, developers will have to download a periodic JSON file to update the local copy of the data if the Dependency-Check tool is used weekly. Meanwhile, the tool will update the NVD feed every time the National Institute of Standards and Technology (NIST) hosts the information.
3. Lightweight
Although the Dependency-Check tool brings a massive support ecosystem for developers to manage their open source security, it is very lightweight. It is relatively smaller in size with a simple process to scan the code. Like mentioned earlier, a regular update of local copy is all the maintenance time it demands of the developers.
4. Reporting
Dependency-Check offers multiple reporting options for developers to check and rectify any open source vulnerabilities effectively. The tool's export features allow teams to focus on key metrics and review their vulnerability management plan. Instead of collecting every metric available, the development teams can pick the solid vulnerability metrics to mitigate security threats.
The Dependency-Check tool constantly updates the database information to ensure no vulnerability goes unreported.
5. Compatibility
Compatibility of the tool with various languages, technologies, and platforms ensures seamless software security management. It also offers complete support for Java and .NET-based products, experimental support for Node.js, Ruby, and Python projects, and is partially compatible with C and C++ languages. It can be integrated with Maven, Jenkins, and Gradle via plugins and also run through the CLI as an Ant task. Other OWASP tools or third-party solutions can complement the Dependency-Check to make a holistic security management offering. Developers can also have an automation add-on as the tool runs manually.
Summary
OWASP Dependency-Check is a crucial tool for developers to manage application security. It is considered as a minimal or first-level checkpoint against software supply chain threats. This tool can be integrated with other paid tools that provide additional security against vulnerabilities and release a secure product.
