Dependency-Track und eine gehostete Alternative: welche Aufzeichnungen beide jeweils führen

Zuletzt aktualisiert: 2026-09-30

Dependency-Track ist eine Open-Source-Plattform der OWASP® zur Komponentenanalyse, die Teams selbst bereitstellen und betreiben. DevKit Dossier ist ein gehosteter Dienst mit einer engeren Aufgabe: Es führt pro Release Aufzeichnungen, die ein Hersteller im Rahmen der Cyberresilienz-Verordnung unter Umständen vorzeigen möchte. Beide überwachen die Komponenten einer SBOM auf bekannte Schwachstellen; sie unterscheiden sich darin, was sie speichern und wer den Server betreibt.

Was der Text sagt

Der Text hier ist die eigene Dokumentation von Dependency-Track für Version 5, gelesen am 29. September 2026. Die Zitate bleiben englisch.

Was es ist (Startseite der Dokumentation):

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

Auf Deutsch, sinngemäß: Dependency-Track beschreibt sich als intelligente Plattform zur Komponentenanalyse, mit der Organisationen Risiken in der Software-Lieferkette erkennen und verringern können.

Formate (File Formats):

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

Auf Deutsch, sinngemäß: CycloneDX ist das einzige Format, in dem sich SBOMs in Dependency-Track hochladen lassen.

Hochgeladene Dateien (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."

Auf Deutsch, sinngemäß: Dependency-Track nutzt einen Dateispeicher für Zwischendaten der Hintergrundverarbeitung, darunter hochgeladene BOMs, Ergebnisse der Schwachstellenanalyse und große Benachrichtigungen; die Dateien sind kurzlebig und werden nach der Verarbeitung automatisch gelöscht.

Bewertungsverlauf (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."

Auf Deutsch, sinngemäß: Der Verlauf hält fest, wer die Änderung wann vorgenommen hat und was geändert wurde, samt den Freitext-Kommentaren, die Prüfende bei der Arbeit hinzufügen; der Prüfverlauf ist dauerhaft.

Betrieb (About changes in v5):

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

Auf Deutsch, sinngemäß: Version 5 wird nur noch als Container-Images ausgeliefert; das gebündelte Image entfällt.

"PostgreSQL high availability remains your responsibility."

Auf Deutsch, sinngemäß: Die Hochverfügbarkeit von PostgreSQL bleibt Sache des Betreibers.

Was das in der Praxis bedeutet

Was Dependency-Track laut seiner Dokumentation speichert:

Ein Komponenteninventar für jede Version jedes Projekts, gelesen aus CycloneDX-BOMs in JSON oder XML.
Befunde mit einem Analysestatus, einer Begründung und einem dauerhaften Prüfverlauf.
Richtlinienverstöße und Zeitreihen-Metriken sowie Exporte als CycloneDX-BOM, VEX und VDR.
Lizenzrisiken: Seine Dokumentation sagt, es „surfaces known vulnerabilities, policy violations, and licensing risk“, also dass es bekannte Schwachstellen, Richtlinienverstöße und Lizenzrisiken sichtbar macht.
Die hochgeladene Datei selbst gehört zu den Zwischendaten. Eine später exportierte BOM gibt „the current component inventory of a project“ wieder, also das aktuelle Komponenteninventar eines Projekts. Da jede Version meist ein eigenes Projekt ist, gibt dieser Export das zuletzt für die Version hochgeladene Inventar wieder, nicht die Originaldatei Byte für Byte.

Was es gut kann: Es verfolgt Komponenten über ein ganzes Portfolio und gleicht sie mit der NVD, den GitHub Advisories und OSV ab, dazu OSS Index, Snyk, Trivy und VulnDB. Es bezieht außerdem EPSS und, ab Version 5.1, die Kataloge bekannter ausgenutzter Schwachstellen der CISA und der ENISA ein. Seine Policy-Engine kann einen Build scheitern lassen, und seine Benachrichtigungen erreichen Chat, E-Mail und Webhooks. Es ist kostenlos und quelloffen unter Apache 2.0 und ein OWASP Flagship Project. Seine Website stellt es mit den Worten „Maintain the complete, current inventory the EU Cyber Resilience Act expects.“ vor, sinngemäß: das vollständige, aktuelle Inventar führen, das der Cyber Resilience Act der EU erwartet.

Was der Betrieb erfordert: Container-Images, eine PostgreSQL-Datenbank, Dateispeicher, Backups und Upgrades. Der Produktionsleitfaden nennt als Ausgangspunkt 2 GB Arbeitsspeicher und 4 CPU-Kerne pro API-Server-Instanz sowie 8 GB und 4 Kerne für die Datenbank.

Was DevKit Dossier speichert:

Die SBOM-Datei jedes Releases, Byte für Byte, mit Hash und Upload-Zeitstempel, als CycloneDX- oder SPDX-JSON.
Befunde pro Release, mit den Zeitpunkten, zu denen sie zuerst und zuletzt gesehen wurden.
Einträge der Fristenkontrolle nach Artikel 14: den Zeitpunkt der Kenntniserlangung, die Fälligkeiten und jeden Schritt mit seinem Zeitpunkt.
Ein Lizenzinventar und ein Nachweispaket.

Was DevKit Dossier nicht tut: Es hat keine Policy-Engine und lässt nie einen Build wegen seiner Befunde scheitern; sein Upload-Schritt schlägt nur fehl, wenn die SBOM DevKit Dossier nicht erreicht oder abgelehnt wird, und nennt dann den Grund. Teams, die eine Policy-Engine wollen, sind mit Dependency-Track gut bedient. Die Dokumentation von Dependency-Track Version 5, durchsucht am 29. September 2026, erwähnt weder eine Fristenkontrolle nach Artikel 14 noch einen Export für Anhang VII. Beide können nebeneinander laufen, da dieselbe CycloneDX-Datei aus der CI an beide gehen kann.

Was Sie als Nachweis aufbewahren sollten

Welches Werkzeug Sie auch nutzen:

Die SBOM-Datei jedes Releases, wie sie erzeugt wurde, mit Hash, aufbewahrt außerhalb jedes Werkzeugs, das sie in eine Datenbank einliest.
Die Befunde und Bewertungsentscheidungen, wie sie zu jedem Release standen, exportiert und datiert.
Die Zeitpunkte: wann eine Schwachstelle zuerst gesehen wurde, wann Sie entschieden haben, wann die Korrektur ausgeliefert wurde.

Wo DevKit Dossier ansetzt

DevKit Dossier wird in der EU gehostet, Sie müssen also weder Server noch Datenbank noch Backups betreiben. Ihre CI erzeugt mit Syft oder Trivy eine CycloneDX- oder SPDX-JSON-Datei und lädt sie in das SBOM-Archiv pro Release hoch; DevKit Dossier ist kein Scanner. Es gleicht die aktuelle SBOM jedes Releases täglich mit OSV und den GitHub-Advisories, CISA KEV, EPSS und NVD-Werten ab und überwacht die Meldefristen nach Artikel 14 mit einer Checkliste; es führt ein Lizenzinventar und exportiert ein Nachweispaket (eine ZIP-Datei mit pack.json, pack.pdf, den SBOMs Byte für Byte und einer README.txt) sowie, im Business-Tarif, einen FDA-524B-Export. Es übermittelt nichts an die einheitliche Meldeplattform der ENISA, leistet keine Rechtsberatung und nimmt keine Zertifizierung vor. Es funktioniert im Self-Service und kostet pauschal 49, 99 oder 249 EUR pro Monat und Organisation, mit einer 14-tägigen Testphase.

Auf die Warteliste

Dependency-Track ist ein Projekt der OWASP Foundation. DevKit Dossier steht in keiner Verbindung zur OWASP Foundation oder zum Projekt Dependency-Track und wird von ihnen weder gesponsert noch befürwortet.

Quellen

Dieser Leitfaden enthält allgemeine Informationen und ist keine Rechtsberatung.