Software Bill of Materials operationalisieren: Was Dependency-Track leistet — und wo es still versagt
Vor einigen Monaten fiel in einem Cluster ein zentrales Schwachstellen-System für rund zwanzig Minuten aus. Kein Alarm, kein Ticket, kein Anruf. Erst beim genaueren Hinsehen kam das eigentliche Problem ans Licht — und das war deutlich unangenehmer als der kurze Ausfall: Das System hatte über Wochen brav weitergearbeitet, nur eben in die falsche Datenbank geschrieben. Statt in die vorgesehene, extern gesicherte PostgreSQL floss alles in eine eingebettete Datenbank, die niemand gesichert und niemand überwacht hat. Nichts war kaputt. Alles war blind.
Genau dieser Fall ist der Grund für diesen Artikel. Denn er zeigt in Reinform, was Software-Bill-of-Materials-Management (SBOM steht für Software Bill of Materials — die maschinenlesbare Stückliste aller Komponenten einer Anwendung) in der Praxis so tückisch macht: Ein solches System läuft auch dann scheinbar, wenn es längst nichts mehr schützt. Und ein Schwachstellen-Management, dessen Betriebszustand niemand überwacht, ist gefährlicher als gar keines — weil es Sicherheit vortäuscht.
Was Dependency-Track eigentlich löst
Dependency-Track ist eine Plattform für Software Composition Analysis (SCA — die Analyse der Fremd- und Open-Bausteine in eigener Software), betrieben unter dem Dach der OWASP Foundation. Das Prinzip ist schnell erklärt: Jede Build-Pipeline lädt pro Anwendung eine SBOM im Format CycloneDX hoch. Dependency-Track zerlegt diese Stückliste in ihre Einzelkomponenten und gleicht jede davon gegen Schwachstellendatenbanken ab — die National Vulnerability Database (NVD), OSV und GitHub Advisories.
Soweit klingt das nach einem gewöhnlichen Scanner. Der eigentliche Wert steckt aber woanders: in der kontinuierlichen Neubewertung. Ein klassischer Scan à la Trivy ist eine Momentaufnahme im Build. Ist der Build durch, ist die Aussage eingefroren. Wird morgen eine kritische CVE (Common Vulnerabilities and Exposures — der öffentliche Katalog bekannter Schwachstellen) für eine Bibliothek veröffentlicht, die vor drei Monaten sauber durch die Pipeline gelaufen ist, so erfährt der klassische Scan davon nichts — bis zum nächsten Build.
Dependency-Track dreht diese Logik um. Die SBOM liegt zentral, die Schwachstellendaten werden fortlaufend aktualisiert, und jede neue CVE wird gegen den gesamten Bestand gerechnet — ohne einen einzigen neuen Build. Wer Log4Shell miterlebt hat, weiß, warum das zählt: Die Frage in der Nacht der Veröffentlichung lautete nicht „ist unser Code sauber?", sondern „wo überall steckt diese eine Bibliothek?". Genau diese Frage beantwortet ein gepflegter SBOM-Bestand in Minuten statt in Tagen.
Warum das ein Governance-Thema ist, kein Werkzeug-Thema
Für die Leitungsebene ist der interessante Teil nicht die Technik, sondern der regulatorische Rahmen, in den sie fällt. Mit der Umsetzung von NIS2 in nationales Recht — in Deutschland über das novellierte BSIG, dessen Kern in §30 BSIG die Pflicht zu angemessenen Risikomanagementmaßnahmen für die Lieferkette festschreibt — ist Schwachstellenmanagement über die Software-Supply-Chain keine Kür mehr. Und §38 BSIG nimmt die Geschäftsleitung ausdrücklich in die Pflicht: Sie muss diese Maßnahmen billigen und ihre Umsetzung überwachen.
Hinweis: §30 BSIG nennt den Begriff „SBOM" nicht wörtlich. Ein SBOM-Prozess ist also kein Selbstzweck und keine Pflicht per Gesetzestext — er ist eine der naheliegendsten, prüffähigen Antworten auf die geforderte Lieferketten-Sorgfalt. Dependency-Track unterstützt damit die Umsetzung von NIS2-Anforderungen; es „erfüllt" sie nicht auf Knopfdruck.
Die zweite Regulierungslinie zieht der Cyber Resilience Act (CRA) auf europäischer Ebene: Ab dem 11. Dezember 2027 gehört eine SBOM für viele Produkte mit digitalen Elementen zum Pflichtprogramm. Wer heute anfängt, SBOMs zu operationalisieren, baut also nicht auf Verdacht, sondern auf einen festen Termin hin.
Alles schön und gut — kontinuierliche Bewertung, Compliance-Bezug, klarer Nutzen. Aber genau hier beginnt der Teil, den die Hochglanz-Feature-Liste verschweigt.
Der stille Ausfallmodus: Wenn „läuft" nicht „schützt" heißt
Zurück zum eingangs beschriebenen Vorfall. Dependency-Track bringt eine eingebettete Datenbank namens H2 (eine schlanke, in Java geschriebene Datenbank, die im Prozess selbst mitläuft) mit — praktisch für den ersten Start, ungeeignet für den ernsthaften Betrieb. Für Produktion ist eine externe PostgreSQL vorgesehen, verbunden über eine Konfiguration in den Deployment-Manifesten.
Der Fehler entstand nicht im Programm, sondern im Zusammenspiel mit Helm (dem Paketmanager für Kubernetes). Helm ersetzt bei der Wertüberlagerung Arrays komplett, statt sie zu vereinen. Wurde also an einer Stelle eine Liste von Umgebungsvariablen überschrieben, so verschwanden genau die Einträge, die auf die externe PostgreSQL zeigten. Und was tut Dependency-Track, wenn die PostgreSQL-Konfiguration fehlt? Es startet trotzdem — und fällt still auf die eingebettete H2 zurück. Kein Fehler, keine Warnung, keine Statusmeldung. Der Dienst meldet sich als gesund.
Das ist der Kern der Sache: Ein Wächter, dessen Ausfall so leise ist, dass niemand ihn bemerkt, ist eine schwer heilbare Krankheit im Sicherheitsapparat. Über Wochen liefen Uploads, Auswertungen und Dashboards weiter — nur eben auf einer Datenbank, die nicht gesichert war und deren Inhalt beim nächsten Neustart des Pods verloren gehen konnte. In diesem Fall traf es rund 1.275 Projekte und einen Bestand von etwa zehn Millionen Zeilen, der später mühsam migriert werden musste. Diese Zahlen stammen aus einem einzelnen realen Projekt und sind kein Benchmark — sie zeigen aber die Größenordnung, in der solche stillen Ausfälle Schaden anrichten.
DT 5 erzwingt die Hausaufgaben
Es gibt eine gute Nachricht für alle, die diese Falle bisher offen hatten: Mit Dependency-Track 5.0 (allgemein verfügbar seit dem 9. Juni 2026) verschwindet die eingebettete H2 als Produktionsoption. Die neue Hauptversion setzt PostgreSQL voraus — der stille Rückfall ist damit strukturell nicht mehr möglich.
Der Preis dafür ist ein echter Migrationsaufwand, denn DT 5 bringt weitere Breaking Changes mit: getrennte Container-Images für die API und die Weboberfläche, Umstellungen an der API-Paginierung und an internen Datenformaten. Wer heute noch auf 4.x mit eingebetteter Datenbank läuft, kommt an einer geplanten Migration nicht vorbei. Ich sehe das weniger als Last denn als willkommenen Zwang: Die Version erledigt eine Hausaufgabe, die viele Betriebe sonst immer weiter vor sich herschieben.
Governance-Konsequenzen: die stillen Ausfälle laut machen
Die eigentliche Lehre aus dem Vorfall ist nicht „PostgreSQL statt H2". Sie ist grundsätzlicher: Ein Sicherheits-System muss über seinen eigenen Betriebszustand Alarm schlagen können. Aus der Projektpraxis empfehle ich der Leitungsebene, für jedes SBOM-System vier Fragen verbindlich beantworten zu lassen:
- Verankern Sie die Konfiguration im GitOps. Wenn der gewünschte Zustand — inklusive Datenbankanbindung — im Versionskontrollsystem als einzige Wahrheit steht, so kann eine Fehlkonfiguration nicht unbemerkt in der Live-Umgebung entstehen. Handänderungen am Cluster fallen beim nächsten Abgleich auf.
- Alarmieren Sie auf Stille. Ein SBOM-Bestand, in den seit Tagen nichts mehr hochgeladen wurde, ist ein Warnsignal — entweder klemmt die Pipeline, oder ein API-Schlüssel wird abgelehnt. Beides muss ein Ticket erzeugen, nicht erst der Zufallsfund.
- Überwachen Sie den Datenpfad, nicht nur die Verfügbarkeit. Ein „grüner" Health-Check sagt nur, dass der Prozess lebt. Er sagt nichts darüber, ob er in die richtige Datenbank schreibt. Prüfen Sie explizit, gegen welche Datenbank das System arbeitet.
- Testen Sie das Backup, nicht nur seine Existenz. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Plan.
Das macht Ausfälle nicht unmöglich. Es macht sie aber laut — und ein lauter Ausfall ist ein beherrschbarer Ausfall.
Fazit
Unter dem Strich bleibt für mich ein klares Bild: Dependency-Track ist ein starkes, frei verfügbares OWASP-Projekt, das die richtige Antwort auf ein reales Problem gibt — die kontinuierliche Neubewertung der eigenen Software-Lieferkette statt der Momentaufnahme im Build. Für regulierte Unternehmen unter NIS2/§30 BSIG und mit Blick auf den CRA ist das kein „nice to have", sondern ein prüffähiger Governance-Baustein.
Aber ein Werkzeug aufzustellen ist nicht dasselbe wie es zu operationalisieren. Der stille H2-Fallback ist die Lehrstunde dafür: Nicht der laute Ausfall ist gefährlich, sondern der leise. SBOM-Operationalisierung heißt, die stillen Versagensmodi hörbar zu machen — durch GitOps-Verankerung, Alarme auf abgelehnte Schlüssel und veraltete Uploads, überwachte Backups. Wer das versäumt, kauft sich Scheinsicherheit. Und Scheinsicherheit ist im Ernstfall teurer als eine ehrliche Lücke, weil man sie zu spät bemerkt.
30 Minuten, unverbindlich — wir ordnen Ihren Status quo ein.
Anhang: Der technische Migrationspfad (für Platform-Engineering)
Dieser Anhang skizziert den Weg von der eingebetteten H2 zur externen PostgreSQL unter Kubernetes für alle, die die Migration operativ verantworten. Die Beispiele stammen aus einer real erlebten Azure-Umgebung; das Vorgehen überträgt sich sinngemäß auf andere Plattformen.
Ausgangslage prüfen. Zuerst wird geklärt, gegen welche Datenbank die laufende Instanz tatsächlich arbeitet — nicht, welche konfiguriert sein sollte. Ein Blick in die aktiven Umgebungsvariablen des Pods (kubectl exec in den API-Container, Prüfung der ALPINE_DATABASE_*-Werte) zeigt, ob der stille H2-Fallback bereits eingetreten ist.
Die Helm-Array-Falle entschärfen. Ursache des Fallbacks ist das Ersetzungsverhalten von Helm bei Arrays. Sämtliche Umgebungsvariablen für die Datenbankanbindung gehören in eine einzige, vollständige Definition — Teil-Overlays, die nur einzelne Einträge setzen wollen, löschen den Rest. Die Konfiguration gehört anschließend ins GitOps-Repository als einzige Wahrheit.
Daten extrahieren. Der Bestand liegt in der H2-Datei im persistenten Volume. Für den Export wird der JDBC-Treiber (die Java-Datenbankschnittstelle) aus dem laufenden Container extrahiert; über ein Migrationsskript werden die Tabellen ausgelesen und im Batch in die Ziel-PostgreSQL geschrieben (ps.executeBatch() in überschaubaren Blöcken statt Zeile für Zeile).
Reihenfolge und Fremdschlüssel beachten. Die Tabellen müssen in einer Reihenfolge geladen werden, die Fremdschlüsselbeziehungen respektiert — andernfalls scheitert der Import an verwaisten Referenzen. Ein zehn Millionen Zeilen umfassender Bestand braucht hier Geduld und ausreichend Speicher im Migrations-Pod.
Auf DT 5 gehen. Da Dependency-Track 5 PostgreSQL ohnehin voraussetzt, lohnt es sich, Migration und Versionssprung zusammenzudenken. Beachten Sie die getrennten Images für API und Frontend sowie die geänderte API-Paginierung, falls eigene Integrationen daran hängen.
Hinweis: Sichern Sie den H2-Stand, bevor Sie migrieren — und testen Sie das Rückspielen in eine leere PostgreSQL, bevor Sie die Produktion umschalten.