Dependency-Track ist eine Open-Source-Plattform von OWASP zur Überwachung und Analyse von Software-Abhängigkeiten. Sie nutzt CycloneDX-SBOMs und VEX-Dokumente, um Sicherheitslücken, Lizenzrisiken und veraltete Komponenten frühzeitig zu erkennen. Durch den Abgleich mit Datenquellen wie NVD, GitHub Advisories oder Snyk bietet das Werkzeug einen umfassenden Überblick über Risiken in der Software-Lieferkette.

Übersicht

Was ist eine SBOM?

Notwendigkeit eines SCA-Werkzeugs

Moderne Softwareprojekte bestehen zu einem erheblichen Teil aus Open-Source-Komponenten – oft zu 80 % oder mehr. Was Entwicklungszyklen beschleunigt, schafft gleichzeitig Abhängigkeiten, die weit über den eigenen Code hinausreichen. Ein durchschnittliches Node.js-Projekt lädt hunderte transitive Pakete in den node_modules-Ordner, von denen die wenigsten je manuell geprüft werden.

Software Composition Analysis (SCA) adressiert diese Intransparenz auf mehreren Ebenen: Sie identifiziert bekannte Schwachstellen in Abhängigkeiten, bevor diese ausgenutzt werden können, und deckt Lizenzkonflikte auf, die rechtliche Konsequenzen nach sich ziehen könnten. Mit dem EU Cyber Resilience Act und der NIS2-Richtlinie wird SCA zudem zum regulatorischen Muss – SBOM-Bereitstellung ist keine Option mehr, sondern Pflicht.

Auch aus rein technischer Sicht überzeugt der Einsatz: Verwaiste Pakete, veraltete Major-Versionen und deprecated Dependencies lassen sich systematisch erfassen und abbauen. Die nahtlose Integration in CI/CD-Pipelines ermöglicht automatisierte Prüfungen bei jedem Commit, während standardisierte SBOM-Exporte Kundenanforderungen im B2B-Kontext bedienen.

Doch all diese Aspekte verblassen neben der vielleicht gravierendsten Bedrohung: Supply Chain Attacks. Hier werden nicht einzelne Schwachstellen ausgenutzt, sondern ganze Pakete kompromittiert – mit potenziell katastrophalen Kaskadeneffekten über tausende Projekte hinweg.

Die Gefahr der Supply Chain Attacks

Software-Lieferketten sind zu einem primären Angriffsvektor für Cyberkriminelle geworden. Anstatt Endanwendungen direkt anzugreifen, zielen Akteure zunehmend auf die Abhängigkeiten, die Entwickler täglich in ihre Projekte integrieren. Ein kompromittiertes Paket kann sich innerhalb von Stunden über tausende Downstream-Projekte verbreiten – oft unbemerkt, bis der Schaden bereits angerichtet ist.

Was ist eine Supply Chain Attack?

Bei der Entwicklung von Software wird häufig bereits existierender Quellcode von Dritten (in Form von Bibliotheken, Frameworks, etc.) genutzt um sich beim Entwickeln nicht auf bereits gelöste Probleme zu konzentrieren, sondern sich ganz den spezifischen Anforderungen der neuentwickelten Software zu widmen. Solche eingebundenen Bibliotheken oder Frameworks werden als Abhängigkeiten (engl. Dependencies) zusammengefasst.

Allerdings greifen häufig auch die Entwickler dieser Abhängigkeiten auf Quellcode von Dritten zurück und sind dementsprechend von diesem Quellcode auch wieder abhängig. Im Folgendem werden erste Art von Abhängigkeit direkt und zweite Art als indirekt bezeichnet.

Den Überblick über alle Abhängigkeiten einer Software zu behalten ist sehr herausfordernd, insbesondere wenn die Anzahl der indirekten Abhängigkeiten hoch ist, bzw. sogar wächst. Diese Abhängigkeiten sind nicht direkt mit den herkömmlichen Werkzeugen (z.B. Paketmanagern wie npm) einsehbar. Bei einer Supply Chain Attack wird genau dieses Problem ausgenutzt. Es wird Schadsoftware an einer Stelle in die Abhängigkeiten eingeführt. Dies kann zum Beispiel durch die Infizierung eines beliebten Frameworks/Bibliothek passieren. Es kann aber auch eine neue scheinbar harmlose Bibliothek veröffentlicht werden, welche dann von nichts ahnenden Entwicklern als Abhängigkeit genutzt wird. Die so eingeführte Schadsoftware kann dann im schlimmsten Fall willkürlich beliebigen Programmcode auf der Maschine eines Entwicklers oder sogar beim Kunden der Software ausführen.

Sha1-Hulud: The Second Coming: Eine Supply Chain Attack im NPM-Ökosystem

Am 24. November 2025 wurde das npm-Ökosystem von einer der aggressivsten Supply Chain Attacken der letzten Jahre getroffen: Shai-Hulud 2.0 (auch „Sha1-Hulud: The Second Coming“ genannt). Innerhalb weniger Stunden kompromittierte der selbstreplizierende Wurm ~700 npm-Pakete über ~25.000 GitHub-Repositories hinweg! Zu den initial infizierten Paketen (Patient Zero) gehören populäre Bibliotheken/SDKs wie posthog-js, @ensdomains/ensjs und zapier-platform-core.

Die Malware hat Umgebungsvariablen und Konfigurationsdateien in lokalen Entwicklungsumgebungen nach GitHub-PATs, npm-Tokens sowie AWS-, GCP- und Azure-Credentials durchsucht. Diese wurden dann clever über öffentliche GitHub-Repositories nach dreifacher base64-Kodierung veröffentlicht. Dort konnten sie dann zu einem späteren Zeitpunkt von den Akteuren der Attacke „geerntet“ werden.

Warum SBOMs Teil der Lösung sind

Gegen Supply Chain Attacks können vorrangig robuste Abhängigkeitsverwaltungssysteme mit SBOM-Generierung eingesetzt werden. Diese bieten aus mehreren Perspektiven einen Vorteil im Schutz gegen solche Attacken:

1. Transparenz: Eine aktuelle Software Bill of Materials macht alle direkten und indirekten (transitiven) Abhängigkeiten sichtbar
2. Versionskontrolle: Pinning auf bekannte sichere Versionen verhindert das automatische Einschleusen kompromittierter Updates
3. Schnelle Reaktion: Bei Bekanntwerden einer Kompromittierung ermöglicht die SBOM die sofortige Identifikation betroffener Projekte
4. Audit Trail: Die dokumentierte Abhängigkeitskette unterstützt forensische Analysen

Die CISA empfiehlt in ihrem Advisory zum Shai-Hulud-Vorfall (betrifft hier sogar schon Version 1 des Wurms vom September 2025) explizit die Nutzung von SCA-Tools (Software Composition Analysis) und die Erstellung von SBOMs als präventive Maßnahme.

Integration

Dependency Track besteht im Kern aus einem API-Server. Zusätzlich wird ein Frontend mitgeliefert, um die Funktionen des API-Servers zu nutzen und die Einrichtung leicht durchführen zu können. Aufgrund des API-First-Designs bietet das Werkzeug verschiedene Möglichkeiten zur Integration in den Softwareentwicklungsablauf.

Um Dependency Track verwenden zu können, gibt es zwei Möglichkeiten, es aufzusetzen. Zum einen mittels Docker Compose durch eine vorkonfigurierte docker-compose.yaml Datei. Damit kann Dependency Track einfach und schnell ausprobiert werden durch die beiden Befehle:

# Downloaded die neuste Docker Compose Datei
curl -LO https://dependencytrack.org/docker-compose.yml

# Startet den Stack
docker compose up -d

Zum anderen kann es auf einem Kubernetes-Cluster deployed werden. Die Installation kann durch das Dependency-Track-Repository über den Paketmanager Helm.sh erfolgen. Dabei sollte die Resourcennutzung nicht vernachlässigt werden:

API Server:

Frontend:

Im laufenden Betrieb kann Dependency Track neben der Integration mit verschiedenen CVE-Scannern für verschiedene Technologien auch mit bestimmten Nachrichtendiensten und CVE-Analyse Plattformen integriert werden. Erstere dienen der Benachrichtigung bei Auffälligkeiten, etwa durch einen neuen CVE-Fund oder Regelverletzungen. Die Anbindung an CVE-Analyseplattformen wird durch ein eigenes Dateiformat, das Finding Packaging Format (FPF) ermöglicht. Dadurch können CVE-Funde noch tiefgehender oder anders analysiert werden, als das durch Dependency Track selbst möglich ist. Die Dependency Track API ist durch den OpenAPI Standard spezifiziert, wodurch auch verschiedene Erweiterungen durch die Community möglich sind und auch bereits bestehen.

Manuelle Bedienung

Aufgrund des mitgelieferten Frontends kann Dependency Track rein darüber genutzt werden. Etwa durch manuelles hochladen einzelner SBOMs und anschließende Auswertung der CVE-Funde und Lizenzen.

Weiterhin können über das UI Regeln konfiguriert werden. Regeln enthalten Bedingungen zu erlaubten (oder verbotenen) Lizenzen, zu CVSS-Werten, ab welchen eine CVE als relevant angesehen wird, sowie zu erlaubten Komponenten. Bei einer Regelverletzung wird die betroffene Komponente in dem UI markiert und gegebenenfalls eine Benachrichtigung an das Entwicklungsteam gesendet.

Regelverletzungen und CVE-Funde können weiterhin bewertet werden. Das erfolgt direkt an der Komponente. Es kann ein Status ausgewählt werden, welcher beispielsweise aussagt ob eine Komponente wirklich betroffen ist, der CVE-Fund ein falsch-positiver Fund ist oder ob die CVE-schon behoben ist. Zusätzlich kann ein Kommentar verfasst werden zur besseren Nachvollziehbarkeit.

Automatisierte Bedienung

Typischerweise wird jedoch der automatisierte Weg durch die Einbindung in die CI/CD Pipeline gewählt. Dabei wird die SBOM, während des bauens des Codes, generiert und anschließend per API an Depndency Track gesendet. Dependency Track führt dann eine CVE-, sowie die Regelanalyse aus. Überschreitungen einzelner Regeln können automatisch Nachrichten an die konfigurierten Nachrichtendienste senden. Bei Bedarf kann diese Funktionen genutzt werden um das Team automatisch zu informieren. Anschließend können die Funde direkt in dem Dependency Track UI ausgewertet/bewertet werden oder dafür an ein externes Werkzeug weitergeleitet werden. In der folgenden Abbildung ist dieser automatisierte Prozess als BPMN-Diagramm dargestellt.

Vergleich zu anderen Tools

Quellen

• https://sbom.observer/comparison/sbom-observer/vs/dependency-track
• https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
• https://cyber-resilience-act.de/cra/kapitel-2/artikel-13/
• https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
• https://helixguard.ai/blog/malicious-sha1hulud-2025-11-24
• https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
• https://github.com/anchore/syft?tab=readme-ov-file
• https://github.com/anchore/grype
• https://owasp.org/www-project-dependency-track/
• https://trivy.dev/docs/latest/guide/
• https://docs.dependencytrack.org/
• https://github.com/DependencyTrack/dependency-track
• https://www.ibm.com/de-de/think/topics/sbom