This is a presentation I gave at OWASP Summit 2017 talking about the Dependency-Check ecosystem, including Jenkins, SonarQube, and Dependency-Track. The presentation focused on the progress made over the course of the projects life, demos of currently unreleased features, and the future of the platform.

1. Dependency-Check Ecosystem
OWASP Summit 2017

2. Introduction
 20+ years software development experience
 8 years software security experience
 Principal Application Security Architect
 Core contributor to OWASP Dependency-Check
 Leader of Jenkins & SonarQube plugins
 Leader of OWASP Dependency-Track
about.me/stevespringett
steve.springett@owasp.org

3.  Open Source – Licensed under Apache 2.0 license
 Identify component using evidence-based analysis
 Component name, vendor, version, etc.
 Determines if evidence matches CVEs in National Vulnerability Database
 Output report in HTML, JSON, CSV, and XML formats
Introduction

4. Primary Use Cases
 Continuous Security in CI/CD
 Execution of CLI, Ant, Maven, Gradle, and/or Jenkins plugin during
CI/CD with automatic visibility of newly discovered vulnerabilities
 Software Security Assessment and Audit
 Execution of Command Line interface against an installed application
for the purpose of reconnaissance during security assessments

5. 2013 (1.0)
Java only
Command line interface
Ant plugin
Maven plugin
2017 (2.0)
15+ languages/platforms
Command line interface
Ant plugin
Maven plugin
Gradle plugin
Jenkins plugin
SonarQube plugin
Progress

6.  Open Source – Licensed under GNU GPLv3
 Track third-party components across multiple applications and versions
 Asset management application for components
 Integrates Dependency-Check core engine
 Can use asset database as sole source of evidence
 Access to files or build system not required
Introduction

7. Primary Use Cases
 Project, Component, License, and Vulnerability Tracking
 Source of truth for software BOM, component usage, & vulnerabilities
 Ingestion of Dependency-Check results and BOM formats
 Proactively monitor projects using vulnerable components
 Increase efficiency of vulnerability intelligence & incident response

8. 2013 (1.0)
Static component management
Partial Dependency-Check integration
2017 (3.0-dev)
Static/dynamic component management
Full Dependency-Check Integration
Full mirror of the NVD
API-first design with Swagger 2.0
Supports BOM via SPDX and CycloneDX
Full SPDX license support
Progress

9. The Ecosystem
Defect Tracker
CLI
ResultsResults
Results, BOM
Evidence
Ticket(s)

10. The Ecosystem
Defect Tracker
CLI
Improved Visibility to Development Team
Results, BOM
Evidence
ResultsResults
Ticket(s)

11. The Ecosystem
Defect Tracker
CLI
Improved Accuracy of Analysis
Improved Visibility Across Portfolio
Results, BOM
Evidence
ResultsResults
Ticket(s)

12. Demo

13. Shortcomings
 Evidence-based analysis will generate false positives and negatives
 Metadata quality provided by component author is critical
 NVD may not always be up-to-date
 Doesn’t track security commits made without associated CVE published
 Older components not usually tested by security researchers
 Doesn’t track EOL/EOS

14. Contributing
 Use and improve experimental analyzers
 Create new analyzers for emerging languages and platforms
 Help us improve developer visibility (IDE plugins, build plugins, CI servers)
 Help us improve runtime visibility (Java/.NET/Node agents)
 Define and implement algorithms for determining component age
 Implement metrics and dashboards to measure risk and improvement
 License identification and compliance

15. Contributing
https://github.com/jeremylong/DependencyCheck
https://groups.google.com/forum/#!forum/dependency-check
https://github.com/stevespringett/dependency-track
https://groups.google.com/forum/#!forum/dependency-track

16. Improve the Open Source Community
 Use Dependency-Check or similar solution in your projects
 Hold open-source projects accountable for self-reporting
 Notify NVD of errors or omissions
 Verify accuracy of component metadata
 Use SPDX license IDs for all projects
 Use SPDX or CycloneDX for defining software BOM for all projects

17. Feedback
 Do you use Dependency-Check (or similar) if your projects/orgs?
 What existing or in-progress features do you like/dislike?
 What functionality is missing?
 Areas of improvement?

18. Thank You

19. Q&A