OWASP Dependency-Track is the open-source platform I recommend when teams ask for a real dependency tracker. It is not a one-off scanner report. It is a continuous Software Bill of Materials (SBOM) analysis system: you feed it CycloneDX SBOMs from CI or suppliers, it keeps a living inventory of components, and it rematches that inventory when new CVEs appear in sources such as the National Vulnerability Database (NVD), Sonatype OSS Index, GitHub Advisories, and OSV. For engineers and architects who run more than one service, that difference matters more than another green check in a single pipeline.
Illustration of SBOM inventory and portfolio impact. Created with GPT Image.
Why a CI scan alone is not enough
Most teams already scan dependencies at build time. That is useful. It is also incomplete. A scan tells you what was true at the moment the job ran. It does not answer the questions that show up weeks later: which released versions still contain this library, which customer-facing product is affected by today's CVE, and which license policy just failed across half the portfolio.
Dependencies do not stop changing after you ship. Vulnerability databases update. New advisories land. Transitive packages shift when someone rebuilds an old branch. Architects need a place where the inventory lives after the build finishes. That is the gap OWASP Dependency-Track fills. It treats the SBOM as the contract of what you shipped, then keeps analyzing that contract over time.
I care about this as a builder and as someone who designs systems. A platform view beats a pile of HTML reports in CI artifacts that nobody opens after merge. When a critical advisory lands on a Friday afternoon, you do not want to rediscover your stack from scratch. You want a search box over what you already shipped.
Dependency-Track is not Dependency-Check
The names confuse people. Both are OWASP projects. They solve different layers of the same problem.
OWASP Dependency-Check is a Software Composition Analysis (SCA) scanner. It inspects project files and artifacts, tries to identify components, and links them to known vulnerabilities, often through CPE matching against the NVD. You run it in Maven, Gradle, CLI, or CI. You get a point-in-time report. You can fail the build. For a single repository and a clear gate, that can be enough.
OWASP Dependency-Track is a long-running platform. Its primary input is not your source tree. It is an SBOM, preferably CycloneDX. Track stores projects and versions, continuously analyzes components for security, license, and operational risk, supports policies, triage, and Vulnerability Exploitability eXchange (VEX), and helps you ask portfolio questions. Which apps use this package? Where does this CVE sit today?
Other open-source tools such as Trivy, Syft with Grype, or OSV-Scanner are excellent at producing SBOMs or finding issues in a pipeline. They do not replace a portfolio brain. In a serious setup they feed Dependency-Track. Scanner quality protects the build. Dependency-Track protects the software portfolio after the build.
Use Dependency-Check or another scanner when you need fast feedback in one repo. Use Dependency-Track when you manage many services, accept supplier SBOMs, need audit trails, or must answer impact questions under time pressure.
How the flow works
Think in four steps.
First, generate a CycloneDX SBOM where dependency resolution is already done. In Java that might be a CycloneDX Maven or Gradle plugin. In Node you can use ecosystem exporters or a container scan. Tools like Syft and Trivy work well when you want a filesystem or image SBOM. Generate during CI, not by hand on a laptop, so the bill matches what you actually ship.
Second, publish the SBOM to Dependency-Track. The platform is API-first. CI can POST the bill to the BOM endpoint with an API key, or you use the Jenkins plugin or a manual upload while you learn the system. Each upload attaches to a project and version. Over time you keep a history of what each release contained.
Third, let analyzers enrich the inventory. Dependency-Track matches components against vulnerability intelligence and repository metadata. Package URLs (PURLs) matter a lot here. Clean PURLs improve hits against OSS Index and GitHub Advisories. CPEs still help for OS and non-application components. Enable the analyzers you need instead of assuming defaults are enough.
Fourth, apply policy and triage. Security policies can flag critical CVEs. License policies can catch GPL where you need MIT. Operational policies can highlight outdated components. EPSS (Exploit Prediction Scoring System) helps you prioritize what is more likely to be exploited, so you do not treat every CVE as equal. Audit decisions can become VEX for customers or regulators who need more than a raw finding list.
That is the operating model: SBOM in, continuous risk out, decisions recorded.
How to run it
The fastest way to start is Docker Compose from the official stack.
curl -LO https://dependencytrack.org/docker-compose.yml
docker compose up -d
You typically get a frontend and an API server as separate containers. Give the API server enough memory. Official docs suggest more than a toy container if you plan a real portfolio. Production should use an external database such as PostgreSQL, not only the quickstart defaults forever.
After login, create a project, create an API key with BOM upload rights, and wire CI. A minimal upload looks like this shape:
curl -X "POST" "https://dtrack.example/api/v1/bom" \
-H "X-Api-Key: YOUR_KEY" \
-F "project=PROJECT_UUID" \
-F "bom=@sbom.cdx.json"
You can also create projects by name and version with autoCreate=true depending on your setup. Keep secrets in your CI vault. Do not commit API keys.
Then turn on the intelligence feeds you intend to trust. Internal analyzer, OSS Index, NVD mirroring, and GitHub Advisories are the usual baseline. Without good feeds, Track is only a pretty inventory. With feeds, it becomes the place where yesterday's release still gets checked against today's advisory.
Notifications matter next. Slack, Teams, webhooks, or email turn findings into something teams see. A dashboard nobody opens is not risk management. Start small: one team, a few services, one severity policy you are willing to enforce. Expand only after triage actually happens.
What architects get, and what they do not
For architects, the value is clarity under pressure. You can map a vulnerable component across services without opening twenty repos. You can enforce license rules as policy instead of tribal knowledge. You can keep SBOMs for releases and regenerate inventory views from what Track already knows. You can produce VEX when a finding is not exploitable in your context, which is increasingly useful for customers and for frameworks around software supply chain transparency, including conversations shaped by U.S. Executive Order 14028 and European Cyber Resilience Act (CRA) expectations. Track does not make you compliant by itself. It gives you machine-readable inventory and decision history that compliance work needs.
There are limits. You operate a server: RAM, database, backups, upgrades, feed health. False positives still exist. Without triage discipline, the platform becomes alert noise. Dependency-Track does not magically prove reachability. A CVE in a dependency is not always a CVE in your attack path. Your SBOM quality caps everything else. Incomplete bills produce incomplete risk views. Scanner choice still matters. Track analyzes what you give it.
If you only have one small app and no portfolio pressure, a CI scanner may be enough for a while. If you own a platform, multiple products, or supplier software, open-source Dependency-Track is still the strongest self-hosted answer I know for continuous SBOM risk management. Pair it with solid CycloneDX generation in CI, keep policies small and enforceable, and treat triage as part of the architecture, not as optional cleanup.
Also be honest with stakeholders. Dependency-Track will surface work. That is the point. The alternative is quiet risk that only appears when a customer, auditor, or incident forces the question.
That combination is simple to describe and hard to fake: know what you ship, keep watching it, and decide on purpose when risk appears.