OWASP Dependency-Track is an SBOM platform rather than a scanner. It does not look at your code. It ingests software bills of materials, mainly CycloneDX, tracks the components in them, and checks those against vulnerability data over time. Something else must produce the SBOM first.
What the project describes
The project site calls it the open source platform for inventorying software components, finding vulnerabilities and enforcing policy across the software supply chain, built around the SBOM. It names CycloneDX as its native standard. SBOMs arrive through a REST API, CI plugins or the web interface. The page references version 5.2.
Scanner versus platform
A scanner reads a repository or an image, builds a component list, and reports findings once. A platform keeps a store of component lists and re-evaluates them as new advisories appear.
That difference changes how you buy and run them:
- A scanner answers: what is vulnerable right now in this build?
- A platform answers: which of the hundreds of applications I track are affected by the advisory published this morning?
Many teams need both, and the project is built to take the output of a scanner or build step as input.
What it draws on
The site lists NVD, GitHub Advisories and OSV among its vulnerability intelligence sources, plus other feeds, and EPSS for prioritization. Features include an inventory covering libraries, applications, containers, operating systems, firmware, hardware and services, an expression based policy engine, license compliance checks, automatic triage, build breaking on policy failure, and alerts through webhooks, chat and email.
What it takes to run
It scales horizontally with active/active high availability, and PostgreSQL is the only database it supports. That is a real operational commitment: you host it, patch it, back it up and secure it. The site calls it free and open source but does not name a license on that page, so confirm the license in the repository before adoption.
Questions to ask before adopting any SBOM platform
- Which SBOM formats and spec versions does it accept?
- How does it handle components without a package identifier?
- How quickly do new advisories show up in results?
- Who maintains the host, and what is the upgrade path?
- Can findings be exported if you leave?
For SBOM quality, see evaluating SBOM quality before you buy.
When a platform is the right shape
A platform fits best when you have many applications, several teams and a need to answer portfolio questions quickly. If you have three repositories and one team, a scanner in CI may be all you need. If you have three hundred, the question "where do we use this library?" matters more than any single scan result.
Be honest about hidden work too. A platform is only as good as the SBOMs it receives. If half your applications never send one, the dashboard shows a comfortable picture of the half it knows about. Set a rule that a build without an SBOM upload fails a check, and report coverage as a number: applications reporting, out of applications total.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a stored inventory is re-checked when new data arrives, instead of only at scan time.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning along with asset discovery. A free scan is at gold.safeguard.sh/scan.
Quick check
Does Dependency-Track generate an SBOM from my code?
The project describes ingesting SBOMs, not generating them. You need another tool or build step to produce one.
Sources
Last reviewed: 19 October 2026.
