OWASP Dependency-Track ist die Open-Source-Plattform, die ich empfehle, wenn Teams einen echten Dependency-Tracker suchen. Es ist kein einmaliger Scan-Report. Es ist ein System für kontinuierliche Software Bill of Materials (SBOM) Analyse: Du speist CycloneDX-SBOMs aus CI oder von Lieferanten ein, es hält ein lebendiges Inventar der Komponenten, und es matcht dieses Inventar neu, wenn CVEs in Quellen wie der National Vulnerability Database (NVD), Sonatype OSS Index, GitHub Advisories und OSV auftauchen. Für Engineers und Architekten mit mehr als einem Service wiegt dieser Unterschied schwerer als ein weiteres grünes Häkchen in einer einzelnen Pipeline.
Illustration zu SBOM-Inventar und Portfolio-Impact. Erstellt mit GPT Image.
Warum ein CI-Scan allein nicht reicht
Die meisten Teams scannen Dependencies schon beim Build. Das ist sinnvoll. Es ist auch unvollständig. Ein Scan sagt dir, was im Moment des Jobs wahr war. Er beantwortet nicht die Fragen, die Wochen später kommen: Welche freigegebenen Versionen enthalten diese Library noch? Welches kundennahe Produkt trifft das CVE von heute? Welche License-Policy ist gerade über die Hälfte des Portfolios gerissen?
Dependencies hören nach dem Ship nicht auf, sich zu ändern. Vulnerability-Datenbanken aktualisieren sich. Neue Advisories landen. Transitive Pakete verschieben sich, wenn jemand einen alten Branch neu baut. Architekten brauchen einen Ort, an dem das Inventar nach dem Build weiterlebt. Genau diese Lücke schließt OWASP Dependency-Track. Es behandelt die SBOM als Vertrag darüber, was du shipped hast, und analysiert diesen Vertrag weiter.
Mir ist das wichtig als Builder und als jemand, der Systeme entwirft. Eine Plattform-Sicht schlägt einen Stapel HTML-Reports in CI-Artifacts, die nach dem Merge niemand mehr öffnet. Wenn am Freitagnachmittag ein kritisches Advisory kommt, willst du deinen Stack nicht neu erfinden. Du willst eine Suche über das, was du schon shipped hast.
Dependency-Track ist nicht Dependency-Check
Die Namen verwirren. Beide sind OWASP-Projekte. Sie lösen unterschiedliche Schichten desselben Problems.
OWASP Dependency-Check ist ein Software Composition Analysis (SCA) Scanner. Er schaut in Projektdateien und Artefakte, versucht Komponenten zu erkennen und verknüpft sie mit bekannten Schwachstellen, oft über CPE-Matching gegen die NVD. Du startest ihn in Maven, Gradle, CLI oder CI. Du bekommst eine Punktaufnahme. Du kannst den Build failen. Für ein einzelnes Repo und ein klares Gate reicht das oft.
OWASP Dependency-Track ist eine dauerhafte Plattform. Der Haupteingang ist nicht dein Source Tree. Es ist eine SBOM, idealerweise CycloneDX. Track speichert Projekte und Versionen, analysiert Komponenten fortlaufend auf Security-, License- und Operational-Risiko, unterstützt Policies, Triage und Vulnerability Exploitability eXchange (VEX) und hilft bei Portfolio-Fragen. Welche Apps nutzen dieses Paket? Wo sitzt dieses CVE heute?
Andere Open-Source-Tools wie Trivy, Syft mit Grype oder OSV-Scanner sind stark darin, SBOMs zu erzeugen oder Findings in der Pipeline zu finden. Sie ersetzen kein Portfolio-Gehirn. In einem ernsthaften Setup speisen sie Dependency-Track. Scanner-Qualität schützt den Build. Dependency-Track schützt das Software-Portfolio danach.
Nimm Dependency-Check oder einen anderen Scanner, wenn du schnelles Feedback in einem Repo brauchst. Nimm Dependency-Track, wenn du viele Services betreibst, Lieferanten-SBOMs annimmst, Audit-Spuren brauchst oder Impact-Fragen unter Zeitdruck beantworten musst.
So funktioniert der Ablauf
Denk in vier Schritten.
Erstens: Erzeuge eine CycloneDX-SBOM dort, wo Dependency Resolution schon gelaufen ist. In Java kann das ein CycloneDX Maven- oder Gradle-Plugin sein. In Node helfen Ecosystem-Exporter oder ein Container-Scan. Tools wie Syft und Trivy passen gut, wenn du eine Filesystem- oder Image-SBOM willst. Erzeuge in CI, nicht per Hand auf dem Laptop, damit die Bill dem entspricht, was du wirklich shippst.
Zweitens: Publiziere die SBOM an Dependency-Track. Die Plattform ist API-first. CI kann die Bill per POST an den BOM-Endpoint mit API-Key schicken, oder du nutzt das Jenkins-Plugin oder einen manuellen Upload zum Lernen. Jeder Upload hängt an Projekt und Version. Über die Zeit entsteht eine Historie dessen, was jedes Release enthielt.
Drittens: Lass Analyzer das Inventar anreichern. Dependency-Track matcht Komponenten gegen Vulnerability Intelligence und Repository-Metadaten. Package URLs (PURLs) zählen hier stark. Saubere PURLs verbessern Treffer gegen OSS Index und GitHub Advisories. CPEs helfen weiter bei OS und Nicht-App-Komponenten. Schalte die Analyzer ein, die du brauchst, statt Defaults blind zu vertrauen.
Viertens: Policy und Triage. Security-Policies können kritische CVEs markieren. License-Policies fangen GPL dort, wo du MIT brauchst. Operational-Policies zeigen veraltete Komponenten. EPSS (Exploit Prediction Scoring System) hilft zu priorisieren, was eher ausgenutzt wird, damit nicht jedes CVE gleich laut schreit. Audit-Entscheidungen können zu VEX für Kunden oder Regulatoren werden, die mehr brauchen als eine rohe Finding-Liste.
Das ist das Betriebsmodell: SBOM rein, kontinuierliches Risiko raus, Entscheidungen festgehalten.
So startest du
Der schnellste Einstieg ist Docker Compose mit dem offiziellen Stack.
curl -LO https://dependencytrack.org/docker-compose.yml
docker compose up -d
Typisch bekommst du Frontend und API-Server als getrennte Container. Gib dem API-Server genug RAM. Die Docs empfehlen mehr als ein Spielzeug-Setup, wenn ein echtes Portfolio geplant ist. Produktiv sollte eine externe Datenbank wie PostgreSQL laufen, nicht dauerhaft nur Quickstart-Defaults.
Nach dem Login: Projekt anlegen, API-Key mit BOM-Upload-Rechten erzeugen, CI verdrahten. Ein minimaler Upload sieht ungefähr so aus:
curl -X "POST" "https://dtrack.example/api/v1/bom" \
-H "X-Api-Key: YOUR_KEY" \
-F "project=PROJECT_UUID" \
-F "bom=@sbom.cdx.json"
Je nach Setup kannst du Projekte auch per Name und Version mit autoCreate=true anlegen. Secrets gehören in den CI-Vault. Keine API-Keys committen.
Danach die Intelligence-Feeds einschalten, denen du vertraust. Internal Analyzer, OSS Index, NVD-Mirroring und GitHub Advisories sind die übliche Basis. Ohne gute Feeds ist Track nur ein hübsches Inventar. Mit Feeds wird es der Ort, an dem gestriges Release gegen heutige Advisories geprüft wird.
Als Nächstes Notifications. Slack, Teams, Webhooks oder E-Mail machen Findings sichtbar. Ein Dashboard, das niemand öffnet, ist kein Risikomanagement. Fang klein an: ein Team, ein paar Services, eine Severity-Policy, die du wirklich durchsetzt. Erweitere erst, wenn Triage tatsächlich passiert.
Was Architekten davon haben, und was nicht
Für Architekten ist der Nutzen Klarheit unter Druck. Du kannst eine verwundbare Komponente über Services mappen, ohne zwanzig Repos zu öffnen. Du kannst License-Regeln als Policy erzwingen statt als Hörensagen. Du kannst SBOMs für Releases halten und Inventar-Views aus dem regenerieren, was Track schon weiß. Du kannst VEX erzeugen, wenn ein Finding in deinem Kontext nicht exploitbar ist. Das wird wichtiger für Kunden und für Rahmen wie U.S. Executive Order 14028 und die europäische Cyber Resilience Act (CRA). Track macht dich nicht allein compliant. Es liefert maschinenlesbares Inventar und Entscheidungshistorie, die Compliance-Arbeit braucht.
Es gibt Grenzen. Du betreibst einen Server: RAM, Datenbank, Backups, Upgrades, Feed-Gesundheit. False Positives bleiben. Ohne Triage-Disziplin wird die Plattform Alert-Lärm. Dependency-Track beweist Reachability nicht von allein. Ein CVE in einer Dependency ist nicht automatisch ein CVE auf deinem Angriffspfad. Die Qualität der SBOM begrenzt alles andere. Unvollständige Bills erzeugen unvollständige Risikobilder. Die Scanner-Wahl bleibt wichtig. Track analysiert, was du ihm gibst.
Wenn du nur eine kleine App hast und keinen Portfolio-Druck, reicht ein CI-Scanner eine Weile. Wenn du eine Platform, mehrere Produkte oder Zuliefer-Software verantwortest, ist open-source Dependency-Track für mich weiterhin die stärkste self-hosted Antwort auf kontinuierliches SBOM-Risikomanagement. Kombiniere es mit sauberer CycloneDX-Erzeugung in CI, halte Policies klein und durchsetzbar, und behandle Triage als Teil der Architektur, nicht als optionales Aufräumen.
Sei auch ehrlich zu Stakeholdern. Dependency-Track macht Arbeit sichtbar. Das ist der Punkt. Die Alternative ist stilles Risiko, das erst auftaucht, wenn Kunde, Auditor oder Incident die Frage erzwingen.
Diese Kombination ist einfach zu beschreiben und schwer zu faken: wissen, was du shippst, weiter zuschauen, und absichtlich entscheiden, wenn Risiko auftaucht.