This document describes OWASP Dependency-Track, a tool for continuous component analysis to reduce open source risk. It integrates with vulnerability databases and monitors applications to identify vulnerabilities. Dependency-Track is designed for automated DevOps environments to accelerate development while monitoring component usage and risk. It supports ingesting software bills of materials during CI/CD to analyze components continuously and provide notifications.

1. OWASP
Dependency-Track
https://dependencytrack.org
Sergey Sotnikov1@epam.com

2. OWASP Dependency-Track Promo
2
Reduce Open Source Risk
Steve Springett
Built for DevOps – API first, API everything

3. OWASP Dependency-Track
Continuous Component Analysis Platform to reduce Open Source Risk (aka Software Composition Analysis)
Continuous analysis of third-party and open source components provides greater visibility on inherited risk.
It integrates with multiple vulnerability databases including the National Vulnerability Database (NVD), NPM Public Advisories, Sonatype OSS Index,
and VulnDB from Risk Based Security. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in
components that are placing your applications at risk.
Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested
during CI/CD. Use of the Dependency-Track Jenkins Plugin is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such
an environment, Dependency-Track enables DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

4. Bill-of-Material (BOM)
In supply-chains, a bill of material (BOM) defines and
describes the contents of what is used in the
manufacturing and packaging of the deliverable. In
software supply chains, this refers to the contents of all
components bundled with the software including, authors,
publishers, names, versions, licenses, and copyrights.
4

5. Dependency-Track Features
• Dashboard - Provides high-level metrics and trends on the inherited risk for all projects and components in the portfolio
• Auditing Workflow - Quickly review findings for accuracy and make analysis decisions and comments on a per-project basis, or globally
• Supply Chain Risk - Expands traditional Software Composition Analysis (SCA) by recognizing hardware/IoT as components with potential
vulnerabilities
• Vulnerability Aggregation - Native integration with multiple application risk platforms providing organizations a consolidated view of prioritized
findings
• Out-of-Date Detection - Identifies components that are not the most recent available which indirectly impact project health and risk
• API and Integration - Well documented API-first design integrates easily with other systems providing endless possibilities
• Bill of Materials - Promotes Software Transparency with support for the automatic ingestion of CycloneDX, SPDX BOM formats and Dependency-
Check XML
• Notifications - Supports notifications to Slack, Microsoft Teams, outbound webhooks (respond, create Jira tickets, etc), and email, enabling new
levels of collaboration and automation
• Vulnerability Data Sources - Mirrors data from multiple sources of vulnerability intelligence providing more coverage on a wider range of
components
• Enterprise Integrations - Supports Active Directory/LDAP authentication and multiple commercial and open source database engines
5

6. Dependency-Track Features
• Flexible data model supporting an unlimited number of projects and components
• Tracks vulnerabilities and inherited risk
• by component
• by project
• across entire portfolio
• Tracks usage of out-of-date components
• Supports standardized SPDX license ID’s and tracks license use by component
• Easy to read metrics for components, projects, and portfolio
• Provides a reliable mirror of the NVD data feed
• API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
6

7. Dependency-Track Integrations
7
• Ingest BoM during CI/CD
• Analyzes Continuously
• Notifications on
• New vulnerability
• New vulnerable dependency
• Audit decision changes
• Outdated versions
• Monitor Activity (Slack, Teams)
• Automate response (webhooks)
• Part of organizations risk metrics

8. Dependency-Track Analysis Types
• Known Vulnerabilities
• National Vulnerability Database (NVD)
• NPM Public Advisories NPM Audit API
• Sonatype OSSIndex
• VulnDB (Risk Based Security)
• Outdated Components
• Ruby Gems
• Maven
• NPM
• Nuget
8

9. CycloneDX
CycloneDX is a lightweight software bill-of-material (BOM) specification designed for use in application security contexts and software
composition analysis (SCA).
CycloneDX was originally designed for use with OWASP Dependency-Track. Research into existing specifications such as SWID and SPDX
revealed that neither specification was robust enough for application security contexts nor did these projects meet the basic
requirements for wide-spread adoption within both enterprise build systems and the open source community.
CycloneDX incorporated SPDX license IDs as they were widely adopted and recognized within the community. Adoption for the emerging
Package URL (purl) specification was also included to provide CycloneDX a reference to the native ecosystem metadata about the
component.
https://cyclonedx.org

10. CycloneDX
Project Goals
• Define a vendor agnostic specification independent of language or ecosystem
• Specification should be simultaneously human and machine readable
• Specification should be simple to implement with minimal effort
• Specification should provide lightweight schema definitions for JSON and XML
• Specification should reuse parts of existing specs where beneficial
• Specification should be decentralized, authoritative, and security focused
• Specification should promote continuous component analysis
• Specification should support hardware, libraries, frameworks, applications, and operating systems
10

11. CycloneDX
Achievable Use Cases
• Vulnerability analysis (software and hardware)
• Outdated component analysis
• License identification and compliance
• File verification
• Track component usage and risk with optional hierarchical representation
• Generate automatically from multiple development ecosystems
• Portable, single file which can be supplied by development teams, business partners, and vendors
Coming Soon
• Document a components pedigree including ancestors, descendants, and variants, representing a components lineage from
any viewpoint
• Analyze modified open source libraries without any loss of fidelity

12. CycloneDX: Example BOM
12

13. CycloneDX: Implementations
Build plugins for a number of ecosystems have been created which support the automatic identification of all project dependencies and automatically
generate CycloneDX BOMs. The resulting BOMs may contain many of the elements above including group, name, version, description, file hashes,
license, and PackageURL. Additionally, a standalone Java API was created for the programmatic creation and validation of CycloneDX BOMs.
• CycloneDX .NET Core
• CycloneDX Node.js Module
• CycloneDX Maven Plugin
• CycloneDX Python Module
• CycloneDX Java API
• Additional build plugins are planned…
13

14. Package URL (purl)
Package URL was created to standardize how software package metadata is represented so that packages could universally be located regardless of
what vendor, project, or ecosystem the packages belong. Package URL conforms to RFC-3986.
The syntax of Package URL is:
• Scheme: Will always be ‘pkg’ to indicate a Package URL (required)
• Type: The package “type” or package “protocol” such as maven, npm, nuget, gem, pypi, etc. Required.
• Namespace: Some name prefix such as a Maven groupid, a Docker image owner, a GitHub user or organization. Optional and type-
specific.
• Name: The name of the package. Required.
• Version: The version of the package. Optional.
• Qualifiers: Extra qualifying data for a package such as an OS, architecture, a distro, etc. Optional and type-specific.
• Subpath: Extra subpath within a package, relative to the package root. Optional.
14

15. Package URL (purl)
• Decentralized URI describing component and its place within ecosystem
• Support virtually unlimited number of ecosystems
• Maven, Docker, NPM, RPM, etc.
• Identifies all relevant component metadata
• Ecosystem type (type)
• Group (namespace)
• Name
• Version
• Key/Value pairs (qualifiers)
15

16. CycloneDX Execution Flow
2 Steps process:
• Generate Bill of Material file (bom.xml)
• Manually, running a command
cyclonedx-bom –o bom.xml
• Use Jenkins plugin
• Example: Maven plugin
mvn -Dmaven.test.skip=true clean install org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
• Upload bom.xml to Dependency-Track project
• From Dependency-Track front-end or
• Using Dependency-Track Jenkins plugin
16

17. Dependency-Track Project Dependencies
17

18. Dependency-Track Results in Jenkins
• Synchronous publishing mode option enabled in Dependency-Track plugin
18

19. Dependency-Track Analysis (Triage)
19

20. CycloneDX + Dependency-Track on Jenking
20

21. DEMO
21