OWASP Dependency-Check Jeremy Long jeremy.long@owasp.org twitter: @ctxt

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"

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"

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

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

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

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

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

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

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: https://github.com/jeremylong/DependencyCheck/issues 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

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="https://www.owasp.org/index.php/OWASP_Dependency_Check_Suppr ession"> <suppress> <notes><![CDATA[ file name: spring-core-3.0.0.RELEASE.jar ]]></notes> <sha1>4F268922155FF53FB7B28AECA24FB28D5A439D95</sha1> <cpe>cpe:/a:vmware:springsource_spring_framework:3.0.0</cpe> </suppress> </suppressions> 11

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

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

Dependency-Check License – Apache 2.0 Important Links: OWASP Project Page: https://www.owasp.org/index.php/OWASP_Dependency_Check SCM: https://github.com/jeremylong/DependencyCheck Mailing List: Subscribe: dependency-check+subscribe@googlegroups.com Post: dependency-check@googlegroups.com 14