OWASP Dependency-Track: Component Analysis from an SBOM, Not a Build Step

The gap Dependency-Track fills: analysis after the build, not during it

Most software composition analysis happens inside a build. A plugin scans the dependency tree, fails the pipeline on a critical finding, and the result lives in that pipeline's logs. That model breaks down once you have hundreds of applications, several build systems, and components that were already shipped. A build-time scanner answers one question: is this build clean right now? It cannot tell you that a library you shipped eight months ago in forty different services just got a new advisory.

Dependency-Track inverts this. It is a server that ingests Software Bills of Materials and keeps analysing them over time. The README states the platform "takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill of Materials (SBOM)". The audience is therefore not a single developer but a security or platform team responsible for a portfolio. You upload or push an SBOM per project or per version, and the server correlates every component in it against vulnerability sources, then keeps that correlation current as new advisories appear. The unit of work is the component, identified by package URL, not the build.

How the server is put together: Java modules, a CycloneDX core, pluggable data sources

The repository layout shows a multi-module Maven build. The top-level entries include apiserver, api, common, cache, dex, migration, notification, plugin, proto, secret-management, support, vuln-analysis, vuln-data-source, kev-data-source, package-metadata and file-storage. The README points at a separate frontend repository, so the server and the UI ship as distinct artifacts. The proto directory plus buf.yaml indicates Protocol Buffers are used for at least part of the internal or external API surface.

The interesting architectural signal is the split between vuln-analysis, vuln-data-source and kev-data-source. Vulnerability data is not hard-coded into the analysis engine; it arrives through data-source modules, and the topics list names NVD and OSS Index alongside KEV, the Known Exploited Vulnerabilities catalogue. That means the freshness and coverage of your findings depend on which sources you configure and whether they are reachable. The dex directory and its engine-migration resources suggest an engine component with its own database migration path, separate from the main migration module. The README's own topics list describes the project as component analysis, SBOM, CycloneDX, package-url and software-composition-analysis, which matches what the module names imply: parse a CycloneDX document, resolve components by purl, match them against advisories, and store the result.

One consequence worth stating plainly: because the engine is data-source driven, an air-gapped deployment is possible in principle but the documentation does not describe an offline mirroring workflow, and the repository does not advertise one. Treat connectivity to vulnerability feeds as an operational dependency until you find otherwise in the docs.

Installing Dependency-Track with Docker Compose and submitting a first SBOM

The README does not inline installation steps. It points to a Quickstart tutorial at dependencytrack.github.io/docs/next/tutorials/quickstart/, described as getting "a local instance running with Docker Compose in a few minutes". The published container image is dependencytrack/apiserver, which the README badge links on Docker Hub. Because the README gives no compose file, the block below reflects the image name and the documented approach rather than a copied manifest; check the Quickstart page for the authoritative compose file and port mapping before you rely on it.

docker pull dependencytrack/apiserver

The frontend is a separate repository and a separate image, so a working UI needs both the API server and the frontend container, plus a database. The Quickstart is the place to confirm the exact service names, ports and required environment variables. Do not assume a single container gives you a usable instance.

Once the instance is up, the practical first step is to get an SBOM into it. Dependency-Track consumes CycloneDX, and the topics list names CycloneDX 1.7, so a CycloneDX document is the expected input. The API is the integration point for automation, and the related searches around "dependency track api" and "dependency-track api documentation" reflect that. The documentation is rendered at dependencytrack.github.io/docs/ and maintained in a separate docs repository, which is where the API reference lives. The pattern is: create a project, upload its SBOM, then let the server match components. The README does not document the upload endpoint inline, so read the API docs rather than guessing a path.

If you prefer Helm, the README's "See also" section lists a helm-charts repository, and the search data shows people looking for "dependency track helm chart". That is the supported route for Kubernetes rather than hand-rolled manifests.

The v4 to v5 migration is the real upgrade cost

The README carries an important notice. Dependency-Track v4 is in maintenance mode on the 4.14.x branch, and v4 will reach end-of-life in December 2026, roughly six months after v5 general availability. A dedicated V5_MIGRATION.md sits at the repository root. Recent releases show 5.1.1 and 5.1.0 on the 5.x line alongside a 4.14.4 maintenance release, so both branches are receiving tags.

The cost here is not the container upgrade, it is the migration. A file named V5_MIGRATION.md at the root, combined with a separate migration module and a dex engine-migration directory in the source tree, tells you the project has changed things that require a documented transition rather than a drop-in image swap. Anyone running 4.14.x in production should read that file before scheduling an upgrade, and should treat the December 2026 end-of-life date as the deadline that makes the migration non-optional. The README does not document a rollback path from v5 to v4, so plan the upgrade as one-way until you confirm otherwise.

Where Dependency-Track is the wrong tool

Dependency-Track does not generate SBOMs. It consumes them. If your builds do not already emit CycloneDX, the platform has nothing to analyse, and you will spend your first weeks building SBOM generation into every pipeline before the server earns its keep. A team that wants a single command in one repository to fail the build on a vulnerable dependency is better served by a build-integrated scanner; the search data's "dependency track vs dependency check" query is exactly this fork in the road, and the two tools sit at different points in the lifecycle.

Second, the analysis is only as good as component identification. Components are matched largely by package URL, which is why purl is one of the project's topics. An SBOM whose components lack purls, or that describes vendored code without coordinates, will produce weak matches regardless of how many data sources you enable. That is a property of the input, not a bug in the server, but it means results degrade quietly rather than loudly.

Third, this is a server you operate. There is a database, there are vulnerability feeds to keep reachable, and there is a frontend to deploy alongside the API server. A small team with two applications and no dedicated platform owner will find the operational surface larger than the problem it solves. The README does not document a hosted offering, so self-hosting is the documented path.

Alternatives and how they differ in approach

The most direct comparison is OWASP Dependency-Check, which the search data pairs with Dependency-Track. Dependency-Check is a scanner: it examines a project's dependencies, often as a build plugin, and reports findings for that project at that moment. Dependency-Track is a server that holds SBOMs over time and re-evaluates them as new advisories land. The difference is state. Dependency-Check has no portfolio view and no persistent record of what you shipped last quarter; Dependency-Track's entire value proposition is that persistent, re-evaluated record. If you need a gate in CI, Dependency-Check fits. If you need to answer "which of our services contain this library" months later, Dependency-Track fits.

A second category is the SBOM-generating toolchains themselves, which produce the CycloneDX documents Dependency-Track reads. Those are complements, not competitors. The genuinely competing choice is between running a component-analysis server and relying on the vulnerability reporting built into a source-hosting platform or a package registry. Those integrated features require no deployment, but they are scoped to the repositories and ecosystems that platform hosts, and they do not give you a single inventory across build systems. Dependency-Track's cost is operational; the alternative's cost is coverage.

Licence, maintenance and what the repository tells you

The project is licensed under Apache-2.0, with LICENSE.txt at the root and SPDX headers in source files such as the Makefile. Apache-2.0 permits commercial and closed-source use and includes a patent grant; it also requires that you preserve notices and state changes you make. That is a summary of the licence text, not legal advice, and if you plan to redistribute a modified build you should read LICENSE.txt and the NOTICE handling yourself.

The repository is not archived, and the last push was on 2026-09-23, the same day as the most recent activity reflected in the release list, with 5.1.1 tagged on 2026-09-20. That is a current codebase on both the 5.x and 4.14.x branches. The README describes the project as "maintained by a community of contributors" and points to a monthly community meeting, which is the realistic support channel: there is no vendor SLA implied anywhere in the README. Upgrade cost is dominated by the v5 migration and by keeping vulnerability data sources reachable, not by the image itself.

Editorial conclusion

Adopt Dependency-Track if you already produce CycloneDX SBOMs and want continuous, portfolio-wide vulnerability analysis without wiring scanners into every build. Do not adopt it if you need build-time blocking of a single repository or you have no SBOM pipeline, because the platform consumes bills of materials rather than generating them. Before committing, verify the v5 migration notes in V5_MIGRATION.md against your current 4.14.x deployment, confirm which vulnerability data sources you will enable, and check that your SBOMs carry package URLs so components resolve correctly.

Frequently asked questions

Official sources

1. DependencyTrack/dependency-track on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases