Mit Dependency-Track aus SBOMs verwertbare Governance machen

Viele Teams erzeugen heute bereits eine SBOM, also eine Software Bill of Materials. Sie wird im Build erstellt, als Artefakt abgelegt und erfüllt auf dem Papier einen wichtigen Zweck. Operativ ändert sich dadurch aber oft wenig. Es bleibt unklar, welche Projekte bei einer neuen Schwachstelle betroffen sind, wo problematische Lizenzen auftauchen und welche Abhängigkeiten über mehrere Produktversionen hinweg besondere Aufmerksamkeit brauchen, obwohl genau daraus erst eine belastbare Grundlage für Priorisierung, Compliance und Governance entsteht.

Genau an dieser Stelle wird es interessant, SBOMs nicht nur zu erzeugen, sondern systematisch auszuwerten. Dependency-Track verbindet dafür SBOMs, Vulnerability Intelligence und Policy-Prüfungen zu einer belastbaren Grundlage für Priorisierung, Compliance und Governance in der Software Supply Chain. Die Plattform setzt zwischen SBOM-Erstellung und operativer Nutzung an, reichert BOM-Daten mit Schwachstellen- und Policy-Informationen an und macht daraus eine Sicht, mit der Entwicklung, Architektur und Betrieb tatsächlich arbeiten können.

Was Dependency-Track eigentlich löst

Dependency-Track beschreibt sich selbst als Component Analysis Platform. Das ist ein wichtiger Unterschied zu der Vorstellung, dort einfach nur CycloneDX-Dateien abzulegen. Die SBOM ist in diesem Modell nicht das Endprodukt, sondern der Ausgangspunkt für eine laufende Bewertung von Komponenten, Projekten und Portfolios.

Der praktische Mehrwert entsteht vor allem dann, wenn du mehr als eine einzelne Anwendung betrachtest. Ein isolierter Scan im Build beantwortet dir, ob ein bestimmter Stand heute Auffälligkeiten hat. Eine Plattform mit Portfolio-Sicht beantwortet dir zusätzlich, in welchen Anwendungen dieselbe Bibliothek steckt, welche Versionen parallel im Umlauf sind und wo dieselben Governance-Regeln verletzt werden.

Damit wird aus einem statischen Nachweis ein Arbeitsinstrument. Entwicklungsteams sehen auf einen Blick, ob ihre Pakete bekannte Sicherheitslücken enthalten und welche Maßnahmen nötig sind. Architekturverantwortliche erkennen Lizenzverstöße über mehrere Produkte hinweg, bevor sie in der Lieferkette zum Problem werden. Produktverantwortliche können nachvollziehen, welche ausgelieferten Versionen von einer neu bekannt gewordenen Schwachstelle betroffen sind und wo ein Hotfix nötig ist. Laut offizieller Dokumentation ist genau diese Verbindung aus API-First-Ansatz, CI/CD-Anbindung, also Continuous Integration und Continuous Delivery, und Portfolio-Sicht ein Kernbestandteil der Plattform.

Dependency-Track organisiert Projekte in einer Portfolio-Hierarchie. Auf oberster Ebene steht das Portfolio als zentrale Sicht auf alle Anwendungen. Darunter liegen Projekte, die typischerweise einem Produkt oder Service entsprechen. Jedes Projekt kann mehrere Versionen haben, sodass du beispielsweise nebeneinander verfolgen kannst, welche Version deines Produkts welche Schwachstellen enthält. Über Parent-Child-Beziehungen lassen sich zusammengehörende Anwendungen gruppieren, etwa eine E-Commerce-Plattform mit ihren einzelnen Services als Kindprojekten.

Quelle: Screenshot aus der offiziellen Dependency-Track-Dokumentation.

Auf Komponentenebene, also bei den einzelnen Paketen und Bibliotheken, greift dann die eigentliche Analyse. Dependency-Track zeigt pro Komponente die bekannten Schwachstellen, Policy-Verstöße und Metadaten in einer durchsuchbaren Inventarübersicht.

Quelle: Screenshot aus der offiziellen Dependency-Track-Dokumentation.

Nicht jede Anwendung bringt eine eigene BOM mit. Für kommerzielle Produkte, eingekaufte Komponenten oder Zulieferersoftware empfehlen die Best Practices ausdrücklich, CycloneDX-BOMs von Lieferanten einzufordern oder selbst zu erstellen. Dependency-Track unterstützt dabei auch den manuellen Upload und die direkte Eingabe von Projekten und Abhängigkeiten über die UI oder die API, sodass auch Drittkomponenten ohne eigene Pipeline-Integration in das Portfolio aufgenommen werden können.

Welche Daten für gute Ergebnisse entscheidend sind

Dependency-Track arbeitet zentral mit CycloneDX als BOM-Format. Je sauberer diese Daten sind, desto belastbarer werden die Ergebnisse. Das klingt banal, ist in der Praxis aber oft der Unterschied zwischen nützlicher Priorisierung und einer unvollständigen Trefferliste.

Die Plattform kann laut Dokumentation nicht nur klassische Bibliotheken betrachten, sondern auch Container, Betriebssysteme, Firmware, Services und Hardware-Bezüge verarbeiten. Wie belastbar das in deinem Kontext funktioniert, hängt aber stark davon ab, wie vollständig und konsistent deine BOM-Daten modelliert sind. Dazu kommen Schwachstellendatenquellen wie NVD, GitHub Advisories, OSV, OSS Index, Snyk, Trivy und VulnDB, die Dependency-Track kontinuierlich auswertet. Zusätzliche Konzepte wie EPSS zur Einschätzung der Ausnutzbarkeit, VEX für Aussagen zur Betroffenheit und VDR für die Weitergabe von Befunden helfen dabei, Erkenntnisse besser einzuordnen oder weiterzugeben.

Für die Qualität der Analyse sind Metadaten entscheidend. Die Best Practices empfehlen insbesondere saubere Package URLs, also purl, für Anwendungsabhängigkeiten und CPEs, also Common Platform Enumeration, für Komponenten, die nicht sauber über klassische Paketmanager erfasst werden. Wenn diese Angaben fehlen oder uneinheitlich sind, sinkt die Zuverlässigkeit bei Zuordnung, Anreicherung und späterer Priorisierung.

Ein kleiner Ausschnitt aus einer CycloneDX-BOM zeigt, worauf es ankommt:

<component type="library">
  <name>log4j-core</name>
  <version>2.23.1</version>
  <purl>pkg:maven/org.apache.logging.log4j/log4j-core@2.23.1</purl>
  <!-- Gute Metadaten verbessern die Zuordnung zu Advisory-Quellen -->
  <cpe>cpe:2.3:a:apache:log4j:2.23.1:*:*:*:*:*:*:*</cpe>
</component>

Das Beispiel ist bewusst klein gehalten. Wichtig ist weniger die Länge der BOM als ihre Präzision. Wenn du beim Thema SBOM-Erzeugung noch am Anfang stehst, schau auch in unseren Artikel zur Governance mit Software Bill of Materials. Er schafft die Grundlage, auf der Dependency-Track erst richtig wirksam wird.

So passt Dependency-Track in CI/CD

Dependency-Track ersetzt nicht die Erzeugung einer SBOM. Die Plattform dockt an einen bestehenden Build- oder Release-Prozess an, in dem bereits eine CycloneDX-BOM entsteht. Der entscheidende Schritt ist dann, diese BOM nach dem Build oder Release zuverlässig zu veröffentlichen.

Die CI/CD-Dokumentation beschreibt dafür mehrere Wege, zum Beispiel über REST API, cURL, Jenkins oder eine GitHub Action. Für einen pragmatischen Start reicht oft schon der Upload per API. Dabei kannst du Projekte über UUID adressieren oder über Namen und Versionen arbeiten. Mit autoCreate=true lassen sich neue Projekte bei Bedarf automatisch anlegen, was für erste Pilotierungen sehr hilfreich ist.

Ein minimales Beispiel für einen Upload aus einer Pipeline kann so aussehen:

# Veröffentlicht eine zuvor erzeugte CycloneDX-BOM in Dependency-Track
curl -X POST "$DEPENDENCY_TRACK_URL/api/v1/bom" \
  -H "X-Api-Key: $DEPENDENCY_TRACK_API_KEY" \
  -F "autoCreate=true" \
  -F "projectName=shop-api" \
  -F "projectVersion=1.4.2" \
  -F "bom=@target/bom.xml"

Damit ist die Arbeit nicht beendet. Gerade das ist einer der wichtigen Unterschiede zu punktuellen CLI-Scans. Nach dem Upload bleibt die BOM im System und wird weiter ausgewertet. Die Dokumentation weist darauf hin, dass Dependency-Track Komponenten auch außerhalb des ursprünglichen Build-Zeitpunkts erneut analysiert. Dadurch liefert die Plattform auch dann neue Hinweise, wenn sich zwischen zwei Releases die externe Bewertungslage ändert. Für produktive Setups solltest du aber zusätzlich klären, wie Projektzuordnung, Versionierung, Retry-Verhalten und die Verarbeitungslatenz nach dem Upload gehandhabt werden.

Policies, Lizenzen und Governance statt nur CVE-Listen

Wer nur eine Liste offener CVEs, also standardisierter Schwachstellenkennungen, sucht, findet dafür viele Tools. Der eigentliche Governance-Mehrwert von Dependency-Track liegt in wiederholbaren Regeln. Die Plattform unterscheidet laut Policy-Compliance-Dokumentation zwischen License, Security und Operational Policies.

Damit lassen sich sehr unterschiedliche Anforderungen abbilden. Ein Security-Team kann Mindestschweregrade oder bestimmte Advisory-Typen als kritisch markieren. Architektur- und Plattformteams können veraltete Komponenten oder unerwünschte Package-Muster adressieren. Im Compliance-Umfeld lassen sich Lizenzen bewerten, wobei SPDX-License-Expressions relevant sind, wenn Komponenten mehrere Lizenzpfade oder komplexere Angaben mitbringen.

Ein realistisches Policy-Set für den Einstieg ist meist unspektakulär, aber wirkungsvoll:

• Copyleft-Lizenzen in bestimmten Produktlinien blockieren
• Komponenten mit bekanntem kritischem Risiko zur Behebung von Sicherheitslücken priorisieren
• stark veraltete Bibliotheken früh markieren
• ausgewählte Pakete oder Hersteller bewusst ausschließen

Solche Regeln helfen nicht nur bei Security-Reviews. Sie schaffen eine gemeinsame Sprache zwischen Entwicklung, Einkauf, Architektur und Governance. Wichtig ist dabei, klein anzufangen. Ein überambitioniertes Regelwerk erzeugt schnell Widerstand, wenn Datenqualität, Zuständigkeiten und Eskalationswege noch nicht geklärt sind. Wenn du dagegen vor allem schnelles Feedback pro Build brauchst, reicht für den Anfang oft auch ein schlankerer SCA- oder Registry-Ansatz ohne zentrale Plattform.

Dependency-Track entfaltet seinen vollen Nutzen nicht nur als passive Inventarplattform. Entscheidend ist außerdem, wie die Plattform auf neue Erkenntnisse reagiert. Dependency-Track analysiert alle hochgeladenen BOMs nicht nur beim Upload, sondern auch dann erneut, wenn neue Schwachstellen bekannt werden. Über Notifications und Webhooks können Alerts direkt an Ticketsysteme, ChatOps-Kanäle oder Team-Workflows weitergeleitet werden. So erfährt ein Team nicht erst beim nächsten Build, dass eines seiner bereits ausgelieferten Produkte von einer neu entdeckten Schwachstelle betroffen ist, sondern wird proaktiv benachrichtigt.

Lebenszyklus einer Schwachstelle

Sobald Dependency-Track eine Schwachstelle in einem Projekt meldet, beginnt ein Bewertungsprozess. Die Plattform unterstützt diesen Prozess mit einem integrierten Audit-Workflow, der es ermöglicht, Findings zu kommentieren und ihren Status zu verwalten.

Typischerweise durchläuft eine gemeldete Schwachstelle folgende Schritte:

1. Bewertung: Trifft die Schwachstelle die eigene Anwendung tatsächlich zu? Nicht jede CVE ist in einem konkreten Deploymentkontext relevant. Hier hilft VEX dabei, Nicht-Betroffenheit formal zu dokumentieren.
2. Priorisierung: Wie dringend ist eine Behebung? Der EPSS-Score gibt einen Hinweis auf die Wahrscheinlichkeit aktiver Ausnutzung, ergänzend zum klassischen CVSS-Score.
3. Behebung: Gibt es ein Update? Ist ein Workaround möglich? Oder wird das Risiko bewusst akzeptiert?
4. Dokumentation: Im Audit-Workflow kann der Status pro Finding festgehalten werden, etwa ob es behoben, unterdrückt oder als nicht zutreffend markiert ist.
5. Abschluss: Sobald die gepatchte Version als neue BOM hochgeladen wird, aktualisiert Dependency-Track den Status automatisch.

Betrieb und sinnvolle erste Schritte

Zum realistischen Bild gehört auch das Betriebsmodell. Die Distributionsübersicht nennt API Server, Frontend und Bundled als verfügbare Varianten. Die Bundled-Variante ist weiterhin unterstützt, aber offiziell als deprecated markiert. Für einen belastbaren Betrieb solltest du das in deiner Zielarchitektur von Anfang an berücksichtigen.

Für den Betrieb zählen außerdem Integrationspunkte wie OIDC für Single Sign-on, LDAP für Verzeichnisdienste, Notifications und Webhooks. Eine Plattform dieser Art entfaltet ihren Nutzen nicht isoliert im Browser. Die Best Practices empfehlen ausdrücklich, Ergebnisse über APIs, Benachrichtigungen und bestehende Kommunikationskanäle weiterzugeben. Erst wenn Findings in Tickets, ChatOps oder Team-Workflows auftauchen, entsteht aus Transparenz tatsächliches Handeln.

Für den Einstieg ist ein kleiner Pilot in der Praxis oft der sinnvollste Start. Starte mit wenigen Kernprojekten, sorge zuerst für saubere BOMs und etabliere dann nur einige wenige Policies, die im Team unstrittig sind. Wenn diese Kette stabil läuft, kannst du Portfolio-Strukturen, Parent-Child-Beziehungen und weitergehende Regeln gezielt nachziehen. Das ist meist sinnvoller als ein sofortiger Vollausbau mit lückenhaften Daten.

Wann sich der Einsatz wirklich lohnt

Dependency-Track lohnt sich besonders dann, wenn aus einzelnen Anwendungen ein Portfolio wird. Sobald mehrere Teams dieselben Komponenten einsetzen, Nachweispflichten wachsen oder Lieferkettenrisiken zentral bewertet werden sollen, wird eine bloße Sammlung von SBOM-Artefakten schnell zu wenig. Dann brauchst du ein System, das Beziehungen, Wiederverwendung und Regelverstöße übergreifend sichtbar macht.

Für sehr kleine Umgebungen kann der Aufwand dagegen höher sein als der Nutzen. Wenn du nur wenige Services betreibst, SBOMs erst gerade stabil erzeugst und noch keine abgestimmten Governance-Regeln hast, kann ein schlanker Zwischenstand sinnvoller sein. Dann ist es oft klüger, zunächst die BOM-Qualität und den Veröffentlichungsprozess zu härten, bevor du eine zentrale Auswertungsplattform einführst.

Der Punkt ist nicht, möglichst schnell ein weiteres Tool einzuführen. Der Punkt ist, aus vorhandenen SBOM-Daten belastbare Entscheidungen abzuleiten. Dependency-Track ist dafür ein passendes Werkzeug, wenn du genau diese Lücke zwischen Nachweis, Priorisierung und Governance schließen willst.

Vom SBOM-Artefakt zur operativen Steuerung

Der eigentliche Unterschied liegt nicht zwischen mit oder ohne SBOM. Er liegt zwischen einer SBOM als Datei und einer SBOM als Arbeitsgrundlage. Dependency-Track ist interessant, weil die Plattform diesen zweiten Schritt unterstützt, mit kontinuierlicher Auswertung, Portfolio-Sicht und wiederholbaren Regeln statt einer einmaligen Momentaufnahme.

Wenn du den Einstieg planst, stabilisiere zuerst die Erzeugung sauberer CycloneDX-BOMs. Danach lohnt sich ein kleiner Pilot mit wenigen Projekten, klaren Projektversionen und einem überschaubaren Policy-Set. So erkennst du schnell, ob dein Engpass eher in der Datenqualität, im Betriebsmodell oder in fehlenden Zuständigkeiten liegt.

Wie nutzt ihr SBOMs heute bereits operativ, und wo fehlen euch noch Transparenz oder durchsetzbare Regeln? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.