Dependency-Track and a hosted alternative: which records each one keeps

Last updated: 2026-09-29

Dependency-Track is an open-source component analysis platform from OWASP® that teams deploy and run themselves. DevKit Dossier is a hosted service with a narrower job: it keeps per-release records that a manufacturer may want to show under the Cyber Resilience Act. Both watch the components of an SBOM for known vulnerabilities; they differ in what they store and in who runs the server.

What the text says

The text here is Dependency-Track's own documentation for version 5, read on 29 September 2026.

What it is (documentation home):

"Dependency-Track is an intelligent component analysis platform that allows organizations to identify and reduce risk in the software supply chain."

Formats (File Formats):

"CycloneDX is the only format supported for uploading SBOMs to Dependency-Track."

Uploaded files (File storage):

"Dependency-Track uses file storage for intermediate data during background processing, including uploaded BOMs, vulnerability analysis results, and large notifications. Files are short-lived and automatically cleaned up after processing."

Triage records (About vulnerability findings):

"The history records who made the change, when, and what changed, and it includes the free-form comments reviewers add as they work. The audit history is permanent."

Operation (About changes in v5):

"v5 ships container images only, and drops the bundled image."

"PostgreSQL high availability remains your responsibility."

What this means in practice

What Dependency-Track keeps, as its documentation describes it:

A component inventory for every version of every project, read from CycloneDX BOMs in JSON or XML.
Findings with an analysis state, a justification and a permanent audit history.
Policy violations and time-series metrics, and exports as CycloneDX BOM, VEX and VDR.
License risk: its documentation says it "surfaces known vulnerabilities, policy violations, and licensing risk".
The uploaded file itself is intermediate data. A BOM exported later reflects "the current component inventory of a project". Because each version is usually its own project, that export reflects the inventory last uploaded for the version, not the original file byte for byte.

What it does well: it follows components across a whole portfolio and matches them against the NVD, GitHub Advisories and OSV, plus OSS Index, Snyk, Trivy and VulnDB. It adds EPSS and, from version 5.1, the known exploited vulnerabilities catalogues of CISA and ENISA. Its policy engine can fail a build, and its alerts reach chat, email and webhooks. It is free and open source under Apache 2.0, and an OWASP Flagship Project. Its site presents it as a way to "Maintain the complete, current inventory the EU Cyber Resilience Act expects."

What running it takes: container images, a PostgreSQL database, file storage, backups and upgrades. The production guide names 2 GB of memory and 4 CPU cores per API server instance as a starting point, and 8 GB and 4 cores for the database.

What DevKit Dossier keeps:

The SBOM file of every release, byte for byte, with a hash and an upload timestamp, as CycloneDX or SPDX JSON.
Findings per release, with the times they were first and last seen.
Article 14 clock records: the moment of awareness, the due times, and each step with its time.
A license inventory and an evidence pack.

What DevKit Dossier does not do: it has no policy engine and never fails a build over its findings; its upload step fails only when the SBOM does not reach DevKit Dossier or is refused, and it says why. Teams that want a policy engine are well served by Dependency-Track. The version 5 documentation of Dependency-Track, searched on 29 September 2026, mentions neither an Article 14 clock nor an Annex VII export. The two can run side by side, since the same CycloneDX file from CI can go to both.

What to keep as evidence

Whichever tool you use:

The SBOM file of each release as generated, with a hash, kept outside any tool that reads it into a database.
The findings and triage decisions as they stood at each release, exported and dated.
The dates: when a vulnerability was first seen, when you decided, when the fix shipped.

Where DevKit Dossier fits

DevKit Dossier is hosted in the EU, so there is no server, database or backup for you to run. Your CI generates a CycloneDX or SPDX JSON file with Syft or Trivy and uploads it to the SBOM archive per release; DevKit Dossier is not a scanner. It checks each release's current SBOM every day against OSV and GitHub advisories, CISA KEV, EPSS and NVD scores, and runs the Article 14 reporting clock with a checklist; it keeps a license inventory and exports an evidence pack (a ZIP with pack.json, pack.pdf, the SBOMs byte for byte and a README.txt) and, in the Business plan, an FDA 524B export. It does not submit anything to ENISA's single reporting platform, gives no legal advice and does not certify anything. It is self-serve, at a flat price per organisation of 49, 99 or 249 EUR per month with a 14-day trial.

Join the waitlist

Dependency-Track is a project of the OWASP Foundation. DevKit Dossier is not affiliated with, sponsored or endorsed by the OWASP Foundation or the Dependency-Track project.

Sources

This guide is general information, not legal advice.