Dependency-Track: OWASP SBOM Risk Analysis Platform

What Dependency-Track is

OWASP Dependency-Track is an Apache-2.0 licensed component analysis platform that helps organizations identify and reduce risk in the software supply chain. It is built around the Software Bill of Materials (SBOM): you feed it CycloneDX BOMs for your applications, and it tracks component usage across every version of every project in your portfolio, surfacing known vulnerabilities, policy violations and licensing risk as they emerge. Its API-first design is meant to slot into CI/CD pipelines, where a single API call uploads a BOM and creates the project and version on first upload.

The key difference from a one-off scanner is continuity. Dependency-Track re-analyses the whole portfolio on a schedule, so a vulnerability disclosed next month shows up against the projects that use the affected component without anyone uploading a new BOM. It is aimed at application security teams, platform teams and anyone who has to answer "which of our services ship this library?" quickly.

The project is in the middle of a major version change. Dependency-Track v5, developed under the codename Hyades, is now the main line, with 5.2.1 released on October 25, 2026. v4 is in maintenance mode on the 4.14.x branch and, per the README, reaches end-of-life in December 2026.

How it works

A v5 deployment has four components behind an ingress. The API server is a Java service exposing the REST API on port 8080 and running background workers, with a separate management server on port 9000 for health checks and Prometheus metrics. PostgreSQL is the single source of truth for product data, workflow records and node coordination. File storage, either a shared volume or an S3-compatible bucket, holds short-lived files such as uploaded BOMs. The frontend is a Vue.js single-page app served by Nginx; the browser calls the API server directly.

API server instances coordinate only through PostgreSQL, with no peer-to-peer protocol, so instances can be added or removed without reconfiguration. Long-running work such as BOM processing, vulnerability analysis and notification delivery runs on an embedded durable execution engine: tasks resume after a crash from their last recorded step and failed steps retry with exponential backoff. Notifications are written to a transactional outbox in the same transaction as the change that triggered them, giving at-least-once delivery. Search runs directly against PostgreSQL, caches live in UNLOGGED tables, and metrics are stored as a time series.

Key features

• Multiple vulnerability sources: mirrored data from NVD, GitHub Advisories and OSV, combined with analyzers such as Sonatype OSS Index, Snyk, Trivy and VulnDB.
• Risk-based prioritisation: rank findings by CVSS severity, EPSS exploit prediction and known-exploited catalogs from CISA, ENISA and VulnCheck.
• Portfolio inventory and search: projects with versions, hierarchies and tags, plus portfolio-wide search for every project using a component or affected by a vulnerability.
• Outdated and tampered components: checks repositories such as Maven Central, npm and PyPI for newer versions, and flags components whose hashes diverge from what the upstream repository publishes.
• Policies in CEL: component policies for licence, security and operational rules, with Common Expression Language conditions when built-in ones are not enough, and vulnerability policies to audit or suppress findings automatically.
• Triage and disclosure: per-finding analysis state, justification and comment history, plus VEX exchange and vulnerability disclosure reports.
• Notifications and integrations: alerts to Slack, Microsoft Teams, Mattermost, Webex, email, Jira, webhooks and Kafka, and forwarding to DefectDojo, Fortify SSC and Kenna Security.
• Access control: OIDC and LDAP sign-in, team permissions, portfolio access control, service accounts, and workload identity federation for GitHub Actions, GitLab CI, Kubernetes and SPIFFE workloads.

Getting started

The quickstart needs Docker or Podman and Compose v2. Download the Compose file and start the stack:

curl -O https://raw.githubusercontent.com/DependencyTrack/docs/main/docs/tutorials/docker-compose.quickstart.yml
docker compose -f docker-compose.quickstart.yml up

This pulls the images, initialises the database and starts all services. Open the frontend at http://localhost:8081 and sign in with the default admin / admin credentials; Dependency-Track asks you to change the password on first login. From there the docs suggest creating a component policy, setting up notifications and uploading BOMs from your pipelines.

For production, the docs recommend pinning every container to a full X.Y.Z tag or digest, starting at 2 GB of memory and 4 CPU cores per API server instance, and giving PostgreSQL its own host with around 8 GB and 4 cores. PostgreSQL's max_connections must cover every instance's connection pool (default 30 each) plus headroom. Run at least two instances against the same database for rolling restarts, and probe /health/ready on port 9000.

To opt out of telemetry before the first startup, set:

DT_TELEMETRY_SUBMISSION_DEFAULT_ENABLED=false

Use cases

• SBOM ingestion from CI: every pipeline uploads a CycloneDX BOM, and projects and versions appear automatically.
• Incident response: when a new vulnerability lands, portfolio-wide search shows every affected project and version.
• Licence compliance: flag components with licences the organization does not allow, and record approvals or suppressions with a reason.
• Customer and supplier assurance: exchange VEX documents and export disclosure reports.
• Restricted environments: run behind an HTTP proxy, with an internal certificate authority, or air-gapped with internal NVD or OSV mirrors.

How it compares

Dependency-Track is less a scanner than a system of record that sits above scanners. Its own documentation lists Trivy, Snyk and Sonatype OSS Index as analyzers it can use, and DefectDojo, Fortify SSC and Kenna Security as platforms it can forward findings to. Point-in-time tools like Trivy answer "what is wrong with this artifact now"; Dependency-Track keeps the inventory and answers that question continuously across the portfolio, adding policy, triage history and access control on top. Teams already using a commercial software composition analysis product will find overlapping features, so the decision often comes down to self-hosting preference and SBOM-centred workflow.

Things to know before adopting

• v4 to v5 is a real migration: v5 supports PostgreSQL only (H2, MySQL and Microsoft SQL Server are dropped), ships container images only (no bundled image or WAR), moves notification subjects to Protobuf with renamed fields, changes REST API v1 responses and enforces pagination, removes Lucene fuzzy matching and the /mirror/nvd/* endpoint. A one-shot data migration procedure is documented.
• Tag policy: :latest keeps resolving to v4 until v4 end-of-life, then jumps to v5 in one pull, so pin exact versions or digests. No floating major or minor tags are published.
• Telemetry is on by default: an anonymous data point (random cluster ID, Dependency-Track version, database type and version) goes to metrics.dependencytrack.org at most once every 24 hours. It can be turned off in the UI, via the API or before first startup.
• PostgreSQL is the bottleneck and your responsibility: the docs say it saturates before the API server does, and its high availability is up to the operator.
• Secrets setup: all instances must share the same key encryption key for the database secret provider and refuse to start on a mismatch.
• Default credentials: local managed users are for evaluation only; production should use OIDC or LDAP.
• Licence: Apache-2.0.

Project activity

As of October 2026 the repository has about 4,370 stars and 843 forks. It was created in July 2013, is written in Java and is licensed under Apache-2.0. Releases 5.2.1 and 4.14.6 both shipped on October 25, 2026. The frontend, documentation and Helm charts live in separate repositories, and maintainers hold a monthly community meeting. Source is at github.com/DependencyTrack/dependency-track, the website at dependencytrack.org and documentation at dependencytrack.github.io/docs.