1. OWASP Dependency-Check
Jeremy Long

2. Jeremy Long 10 years information security experience
24 April 2017
Jeremy Long
10 years information security experience
10 years software development experience
Senior Information Security Engineer at a large financial institution
Northern Virginia OWASP Chapter board member
Lead developer/architect for OWASP Dependency-Check
type here level of Sensitivity "Unrestricted", Internal Use Only" or "Confidential"

3. Steve Springett 19 years software development experience
24 April 2017
Steve Springett
19 years software development experience
4 years information security experience
Principal application security engineer at
Provide direction, best practices & education
Contributor to OWASP Dependency-Check
type here level of Sensitivity "Unrestricted", Internal Use Only" or "Confidential"

4. Vulnerabilities in 3rd Party Libraries
88% of code in today’s applications come from libraries and frameworks
113 million downloads analyzed for the 31 most popular Java frameworks/libs
26% had known vulnerabilities
Most vulnerabilities are undiscovered
Jeff Williams & Arshan Dabirsiaghi
The Unfortunate Reality of Insecure Libraries
Aspect Security (March 2012) 4

5. OWASP Top Ten 2013 A9 – Using components with known vulnerabilities
Prevalence: Widespread
Detectability: Difficult
The 2013 OWASP Top 10 added A9 – Using components with known vulnerabilities. Many applications rely on 3rd party components. Many times these components have not undergone rigorous security reviews and these components may introduce security vulnerabilities into the applications using these components. 5

6. Dependency-Check Simple answer to the A9 problem Project Team:
Identifies libraries and reports on known/published vulnerabilities
Currently limited to Java & .NET libraries
Project Team:
Jeremy Long – lead developer/architect
Will Stranathan - contributor
Steve Springett - contributor
Dependency-Check is a tool that can be used to help solve the identification/detection portion of A9 – using components with known vulnerabilities. 6

7. Library Identification
Reporting on published/known vulnerabilities requires the correct identification of the libraries used 7

8. Problems w/ Library Identification
No standard labeling mechanism for identifying
CPE identifiers are used in NVD CVE:
cpe:/a:springsource:spring_framework:3.0.0
cpe:/a:vmware:springsource_spring_framework:3.0.0
cpe:/a:apache:struts:1.2.7
cpe:/a:apache:struts:2.1.2
File hashes could be used to aid in identification
Hash database must be maintained
Hashes may change if library is built from source
Components bundled via one jar, maven-shade-plugin, etc.
There is no standard labeling mechanism used by development groups that maps into the available vulnerability databases. The most common library identification used by developers would be the group, artifact, and version number within a pom.xml. However, vulnerability databases such as the Common Vulnerability and Exposure (CVE) database hosted by NIST in the National Vulnerability Database (NVD) utilize the Common Platform Enumeration (CPE) for product identification; there is no linkage between identifiers used by the development community to the CPE.
As we can see in the above list of CPE identifiers there may be multiple CPEs for a single product. In the case of Struts 1 vs. Struts 2 – these are different platforms yet the “product” is labeled as struts; this is in contrast to something like Axis and Axis2: “cpe:/a:apache:axis:[version]” vs. “cpe:/a:apache:axis2:[version]”. New entries appear to be added in an ad-hoc fashion when they are needed.
When we get into identifying a single library one might consider using file hashes. However, if the library is downloaded in source format and compiled the file hash of the resulting JAR will likely be different from the official published file hashes (such as those maintained within Maven Central or hosted on the libraries download page to validate file integrity).
The factors above make it difficult to maintain a database mapping libraries to published vulnerabilities. Dependency-check takes a slightly different approach to identification rather then attempting to maintain an all-inclusive list. 8

9. Library Identification: Evidence Based Identification
Local copy of the NVD CVE is maintained
Evidence collected is used to search the local database to identify the library and vulnerabilities
Data extracted from libraries
File name, manifest, POM, package names, etc.
Mapping of library to CPE/CVE not needed
Future enhancements may include a file hash analyzer – this is not currently available
Dependency-check maintains a local copy of the National Vulnerability Database’s (NVD) Common Vulnerability and Exposure (CVE) data by downloading and processing the data feeds from the NVD hosted by NIST. The files analyzed, currently only Java libraries are analyzed: EAR, WAR, and JAR files. Support for other languages and files can be added by implementing new analyzers to collect evidence from the files.
The data extracted from the files analyzed is grouped into three buckets: vendor, product, and version. This evidence is then used to search the local copy of the NVD CVE to identify the Common Platform Enumeration (CPE) and then generate a list of known CVEs.
By using this evidence based identification a mapping of library to CPE/CVE is not needed. This makes the tool more flexible then others; however… 9

10. Evidence Based Identification: Problems
False Positives
Evidence extracted may cause incorrect identification
False Negatives
If key elements are not included in the JAR the library will not be identified and may be a risk
It is possible for both false negatives and false positives to exist. In some cases, the evidence collected, such as the description from the manifest, may reference other open source libraries and cause an incorrect identification. Many of these false positives have already been handled by minor changes to the way the evidence is processed – but there will likely be more. If you use this tool and find an incorrectly identified library please submit an issue here:
Regarding false negatives, if there is insufficient evidence within the library for correct identification, such as a missing or blank manifest, any associated weaknesses within the library may present a risk to your organization.
However, the problem with maintaining a mapping of library to CPE/CVE is labor intensive and problematic because hash values of the same source compiled may result in different hashes due to minor differences in the computers compiling the source. Additionally, if the library is not present in the mapping database a false negative may exist. It is likely that a blended approach, utilizing a more concrete list of hashes for several of the more popular libraries in addition to the evidence based mechanism will likely prove to be the most effective long term solution. As stated earlier, a future hash analyzer and hash database may be constructed for to aid in identification. 10

11. False Positives Suppression Filters – added in 1.0.7
Provides a simple way to remove false positives
<?xml version="1.0" encoding="UTF-8"?> <suppressions xmlns=" ession"> <suppress> <notes><![CDATA[ file name: spring-core RELEASE.jar ]]></notes> <sha1>4F FF53FB7B28AECA24FB28D5A439D95</sha1> <cpe>cpe:/a:vmware:springsource_spring_framework:3.0.0</cpe> </suppress> </suppressions> 11

12. Dependency-Check: Current State
Identifies CVE’s in Java and .NET libraries
Useful for inventorying and monitoring
Developed in Java
Current Interfaces: CLI, Ant Task, Maven Plugin, and Jenkins plugin.
Easily extendable to analyze other file types/languages 12

13. Dependency-Check: Roadmap
Sonar Plugin
IDE plugins (such as Netbeans)
Possible integration with Apache Archiva
Additional analyzers for JavaScript (jquery, Node libraries, etc.)
The primary problem that will be tackled first is the fact that upon initial use of dependency-check it can take 15 minutes or more to download and process the NVD CVE data feeds. We will be looking for someone to host the resulting data files so that the initial use of the tool is a better experience.
Once that problem is solved additional plugins and analyzers will be built. Additionally, we will look into integration with tools like Apache Archiva. 13

14. Dependency-Check License – Apache 2.0 Important Links:
OWASP Project Page:
SCM:
Mailing List: 14