What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current list of enabled vulnerability data sources: verify against project documentation
- Integration list beyond the commonly used CI systems: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Dependency-Track inverts the usual scanning model. Instead of analyzing source code on a schedule, it consumes CycloneDX software bills of materials that your build pipeline produces and stores them as the authoritative inventory for each project and version. It then continuously re-evaluates every component in that inventory against vulnerability intelligence, drawing on the National Vulnerability Database, the OSV database, the GitHub Advisory Database and OSS Index, among others. When a new advisory lands for a component you shipped months ago, the finding appears without anyone rebuilding or rescanning anything.
On top of the inventory sits a policy engine that evaluates conditions beyond severity: license restrictions, component age, coordinate bans, and inherited risk scores. It supports VEX documents, so triage decisions such as "not affected, vulnerable code is not in the execution path" are recorded as structured data and survive the next SBOM upload rather than being re-litigated. The portfolio view aggregates across projects, which is how you answer the question that matters during an incident: which of our applications contains this component, and which versions.
Where it fits
This is security team infrastructure. You run the API server and frontend yourself, typically in containers backed by a database, and wire your pipelines to upload an SBOM on every build. The prerequisite is that something generates those SBOMs, whether cdxgen, Syft, a build plugin or a commercial scanner exporting CycloneDX. Dependency-Track does not produce them. It is the natural aggregation point when teams use different generators, because CycloneDX is the common format.
Strengths
- Continuous re-evaluation against new advisories without rescanning is what most distinguishes it from pipeline scanners.
- Portfolio-wide component search answers incident response questions in seconds rather than through a repository sweep.
- First-class VEX and audit trail support means triage decisions persist instead of resurfacing every scan.
Limitations
- It generates nothing. You own the SBOM production problem separately, and inventory quality is entirely determined by your generator's accuracy.
- It is real infrastructure to operate: database sizing, mirror synchronization for vulnerability feeds, upgrades and access control all fall to you.
- Matching is version-based against public feeds, so false positives from imprecise affected-version data, particularly from NVD, are common and must be handled through policy and VEX rather than by the tool getting smarter.
Who it suits
A strong fit for security teams with the operational capacity to run a service and a clear commitment to CycloneDX, particularly where SBOM retention and portfolio-wide search are requirements. Not the right choice for a small team without infrastructure capacity, or for anyone expecting a turnkey scanner, because half the work here is upstream of the tool.
Used OWASP Dependency-Track? Recommend it under your own name and title.
Recommend this tool