OWASP Dependency Check: How Does It Work?
Table of Contents
The Open Web Application Security Project (OWASP), is an online community that produces free, publicly-available articles, methodologies, documentation, tools, and technologies in the field of web application security.
Open source components have become an integral part of software development. According to Mend’s Risk Report, 96.8% of developers rely on open source components. The increasingly widespread use of open source components requires that developers take a more proactive approach to open source security management. They need to make sure throughout the development process that the software products that they are creating and maintaining don’t contain vulnerable components.
In hopes of making working with open source components more secure, the good folks at OWASP have released a free utility created for developers, that identifies project dependencies and checks if they contain any known, publicly disclosed, open source vulnerabilities.
We’ve taken a look at the OWASP Dependency-Check’s functionality, along with its features and integrations, and I’m here to share what we found.
Programming languages and integrations
The OWASP Dependency-Check currently supports five different programming languages. Java and .NET are fully supported and additional experimental support is provided for Ruby, Node.js, and Python.
The widespread adoption of open source requires developers concerned with the security of their software projects to integrate open source management tools into the Software Development Lifecycle (SDLC). Dependency-Check enables developers to stay on top of their open source components early in the development process with support for command-line integration. This allows seamless integration with other tools, build systems and APIs, helping developers to detect security vulnerabilities as early on in the CI/CD process as possible, without interfering with development time.
The OWASP’s tool also supports the Jenkins plugin, and can fail the build process, allowing you to make sure only approved code with no open source vulnerabilities is deployed to production.
Vulnerability database and updates
IBM XForce report, the average time between a vulnerability being reported and then exploited shrank from 45 days to 15 days between 2006 and 2015. Another study from Tenable calculated the vulnerability exploit window to be 5.5 days. In these situations, the ability to properly detect vulnerabilities and fix them swiftly becomes even more important.
The OWASP Dependency-Check currently only covers vulnerabilities taken from the NVD. While this is a well-respected and popular vulnerabilities database, the process of assessing and verifying vulnerabilities does take some time. This means a vulnerability could be in the wild for a while before being added to the NVD.
While vulnerabilities in commercial software are routinely reported to the NVD, vulnerability research and disclosure in the open source community are less centralized processes. This means that some disclosed open source vulnerabilities might be found in public bug trackers, security advisories or forums, rather than the NVD.
Another factor is that as is typical for free tools, the vulnerability database for the OWASP Dependency-Check is stored locally. This requires users make sure that they update the local database frequently. This differs from databases that are stored in the cloud, which can be updated automatically. This means, again, that there’s a risk of missing vulnerabilities when the local machine is not up to date.
Vulnerability scanning
Scanning is the process of running the tool on the user’s code, to identify any vulnerable open source component. This is usually done by conducting a comparison between the user’s code and known open source vulnerabilities in the vulnerabilities database.
The OWASP Dependency-Check uses a variety of analyzers to build a list of Common Platform Enumeration (CPE) entries. CPE is a structured naming scheme, which includes a method for checking names against a system. The analyzer checks a combination of groupId, artifactId, and version (sometimes referred to as GAV) in the Maven Project Object Model file (POM.XML file). This might lead to components being identified incorrectly and result in a high rate of false positives and false negatives, as opposed to calculating the SHA-1 of the file, which is a lot more accurate because each component gets a unique identifier.
Reporting is extremely important when dealing with vulnerability management, since it provides all security and development teams with actionable insights, as well as giving stakeholders the metrics that they need. The OWASP Dependency-Check can support these needs and can generate reports and exports in a variety of formats: XML, CSV, JSON, and HTML.
OWASP dependency-check: Pros & cons
Developers are extremely concerned about open source security vulnerabilities, and OWASP’s dependency-check goes a long way in providing them with an easy-to-use tool for scanning their code.
Clearly, the fact that it’s free for developers is a great advantage. Developers don’t need to wait for their managers to approve and purchase OWASP’s free tool. There is no need for a long POC process as they can simply download it for themselves.
Which brings us to another advantage. The OWASP Dependency-Check is lightweight and very easy to download, install, and run. Users don’t need to spend time wading through a lengthy deployment process, working out all the kinks that might come up when adopting a new development tool. Installing and using the Dependency-Check is an effortless process, as long as users remember to update their local copy often.
The variety of reporting and export options are also a great advantage for users that want to keep a close eye on open source vulnerabilities security alerts and stay on top of them. The ability to easily export reports also enables teams to collect metrics and get an overview of their open source vulnerability management capabilities over time.
The OWASP Dependency-Check provides development teams with a strong tool to start their journey towards managing their open source security. However, like most free tools, it doesn’t provide all of the capabilities that a Software Composition Analysis tool can provide.
Dependency-Check doesn’t provide users the option of creating automatic rules or workflows to remediate vulnerabilities. So, once users get their report listing all of the open source security vulnerabilities in their code, it’s up to them to determine how to address them and schedule the vulnerability remediation or patching tasks into their already-tight schedule.
While developers can use the OWASP Dependency-Check for a report in a number of formats, the content of the report isn’t very modular. Users can’t create special reports to produce high-level data like analyzing the number of alerts over time, or according to other specific parameters. Any higher level type of analysis would need to be collected manually from the reports and then analyzed by the team.
Another aspect of reporting that is missing from the Dependency-Check is dashboards. Users don’t have a resource in the tool where they can go and see an overview of the state of their open source security status, vulnerability alerts, timeframes, etc. This is data that they will have to collect and organize manually.
The OWASP dependency-check: Does it work?
The short answer to this question is yes. The OWASP Dependency-Check is great as a free tool for developers, providing them with some of the initial data that they need for open source vulnerability management.
That said, the tool’s scanning capabilities, the fact that it’s stored locally, and the number of false positives that its scans produce make it difficult to use for organizations that require a comprehensive open source security management solution.
Like all free tools, the OWASP Dependency-Check has its advantages and limitations. While we recommend that developers who are not using any technology to secure their open source usage to download it and try it for themselves, organizations seeking more automated controls and features that suit their specific needs may decide to look elsewhere for a solution.
