2. Expectations.
u History of Dependency Check
u Importance of Dependency Check.
u Why to care about the Dependencies which we use in our daily coding.
u To understand what is Dependency Checker by
u Supported Languages/tech.
u Relation to OWASP top 10.
u Reviewing How it works.
u Vulnerability Data Source.
u Library Identification and issues.
u Evidence based identification, issues and Remediation.
u Using Dependency Check.
u Components of Dependency Check.
u Use Cases of Dependency Check.
u Enterprise Deployments.
u How to read the reports.
u Demo.
3. History of Dependency Check
u Dependency-Check is developed by a team of volunteers. The primary
contributors to date have been:
u Jeremy Long
u Steve Springett
u Will Stranathan
4. Relation to OWASP top 10.
u Most critical web application risks
u A9 – Using components with known vulnerabilities
u Prevalence: Widespread
u Detectability: Difficult
u Difficult for 3 reasons
u Awareness
u Visibility
u Lack of tooling in 2012/2013
5. Importance of Dependency Check
u CVE-2018-2815 – JAVA SE DOS via Serialization.
u CVE-2016-5000 - Apache POI Information Disclosure via External Entity
Expansion (XXE)
u CVE-2016-4216 - Adobe XMP Toolkit for Java Information Disclosure via
External Entity Expansion (XXE)
u CVE-2016-3081 - Remote code execution vulnerability in Apache Struts when
dynamic method invocation is enabled
u CVE-2015-8103 - Remote code execution vulnerability in Jenkins remoting;
related to the Apache commons-collections
u 95% of applications include open source
u 67% of applications contained open source vulnerabilities
u Average age of open source vulnerability identified: 1,894 days
6. Patching Programs
u Generally do not cover application dependencies
u Lack of awareness of 3rd party or FOSS application dependencies
u Patching teams cannot push patches
u Patching application dependencies requires
u Possible code changes
u Full regression testing
7. Supported Languages/tech.
u Fully supported: Java & .NET
u Experimental Analyzers:
u CocoaPods
u Swift Package Manager
u Python
u PHP (composer)
u Node.js
u Ruby
9. How it works.
u National Vulnerability Database (NVD)
u https://nvd.nist.gov
u Contains a listing of Common Vulnerability and Exposures (CVE)
u Each CVE entry contains
u A description of the vulnerability or exposure
u A Common Vulnerability Scoring System (CVSS) score
u A list of the affected platforms identified by their Common Platform Enumeration
(CPE)
Vulnerability Data Source.
10. Steps to run
u Extract the bat file obtained from link.
u Go to bin.
u Execute the command :
Dependency.bat --format <HTML or PDF> --out “<Location for extracting report>” --scan
“<location of jar/dependent files>” --project <name of report.>
e.g.
Dependency.bat --format HTML --out “C:UsersAdministratorDesktopSecurity Testing” --scan
“C:UsersAdministratorDesktopSecurity Testing*.*” --project SecurityScannerToolCommand
12. Evidence based identification, issues
and Remediation.
u Identification :
u Evidence is extracted from dependencies
u File name, manifest, POM, package names, etc.
u Evidence is grouped into Vendor, Product, and Version collections
u Local copy of the NVD CVE is maintained
u Lucene Index of the CPE information is created
u Evidence collected is used to search the index and identify the library by CPE
13. Evidence based identification, issues
and Remediation.
u Issues :
u False Positives
u Evidence extracted may cause incorrect identification
u False Negatives
u If key elements are not included in the dependency (e.g. jar,
dll) the library will not be identified and may result in un-
reported risk
14. Library Identification and issues.
u Identification :
Reporting on known/published vulnerabilities requires the correct identification of the libraries used
u Issues :
u Development & Security use different identifiers
u Development (GAV coordinates):
u org.springframework:spring-core:3.2.0.RELEASE
u Security uses Common Platform Enumeration (CPE):
u cpe:/a:springsource:spring_framework:3.2.0
u cpe:/a:pivotal:spring_framework:3.2.0
u cpe:/a:pivotal_software:spring_framework:3.2.0
u No publicly available database exists to map between the two
15. Dealing with False Positives
u Invalid dependency identification can be resolved using a suppression file:
<suppress>
<notes><![CDATA[
This suppresses false positives identified on spring security.
]]></notes>
<gav regex="true">org.springframework.security:spring.*</gav>
<cpe>cpe:/a:mod_security:mod_security</cpe>
<cpe>cpe:/a:springsource:spring_framework</cpe>
<cpe>cpe:/a:vmware:springsource_spring_framework</cpe>
</suppress>
16. Enterprise Deployments.
u Use a centralized database to maintain the local copy of the NVD
u Single instance of dependency-check used to update
u Scanning instances do not need to update
u Use an internal Nexus instead of Maven Central
u Run dependency-check within their CI
u Continuous monitoring/reporting using OWASP dependency-check sonar plugin,
OWASP dependency-track, or ThreadFix
17. Use Cases for dependency-check
u Prove the existence of the problem
u Baseline test when conducting POCs with commercial solutions
u OWASP dependency-check is used as the primary tool to identify known
vulnerable components
21. Getting Involved
u Involvement in the development and promotion of dependency-check is actively
encouraged! You do not have to be a security expert in order to contribute. How you can
help:
• Use the tool
• Provide feedback via the mailing list or by creating github issues (both bugs and feature
requests are encouraged)
• The project source code is hosted on github - if you are so inclined fork it and provide
push requests!