Why Every Software Team Needs an SBOM Strategy in 2026
Warum jedes Software-Team ab 2026 eine SBOM-Strategie braucht
Der Moment, der alles verändert hat
Es war ein Dienstagmorgen im April 2024. Eine Mail vom Risikomanagement landet in meinem Postfach: „Stefan, seid ihr von der XZ-Utils-Backdoor betroffen? Wir brauchen bis heute Mittag eine Antwort."
Ich kenne Kollegen aus anderen Unternehmen, die in diesem Moment schweißgebadet vor ihren Laptops saßen und händisch durch ihre Repo-Landschaft gegraben haben. Bei uns: ein einziger Bericht in TrustSource, Filterung auf das betroffene Package, Abgleich gegen unsere SBOM-Snapshots – keine drei Minuten, und ich hatte eine vollständige Antwort für alle 120 aktiven Produkte.
Das ist der Unterschied zwischen SBOM als lebendigem Betriebsmittel und dem klassischen „wir haben da irgendwo eine Inventarliste als Excel". Als XZ einschlug, waren CRA und NIS2 für viele noch abstrakte Brüsseler Konzepte. Heute sind sie Realität. Und wer kein strukturiertes SBOM-Management hat, hat ab 2026 nicht nur ein Compliance-Problem - er hat ein operatives Problem.
Der Paradigmenwechsel, den wir in unserem OSPO durchgemacht haben: SBOM ist kein PDF für den Auditor. Es ist das Nervensystem unserer Supply-Chain-Hygiene.
Was die Regulierung konkret verlangt - und was sie nicht sagt
Der Cyber Resilience Act macht maschinenlesbare SBOMs für alle „Products with Digital Elements" zur Pflicht - und zwar ab Markteintritt, nicht erst wenn der Auditor anklopft. Das ist ein fundamentaler Unterschied zu dem, was viele noch erwarten. Es geht nicht um eine einmalige Dokumentationsübung, sondern um einen kontinuierlichen Nachweis.
NIS2 erhöht den Druck auf kritische Lieferketten nochmals: Betroffene Organisationen müssen nachweisen können, welche Komponenten sie einsetzen und wie deren aktueller Vulnerability-Status aussieht. Ohne SBOM ist das schlicht nicht skalierbar.
Eine gute, erste Orientierung gibt die BSI TR-03183, die konkret definiert, was in einer SBOM stehen sollte: von SPDXID und Lizenzinformationen bis hin zu Relationship-Typen zwischen Komponenten. Praktisch hilfreich – aber in unserem Setup ist das längst automatisiert. TrustSource erzeugt SBOMs, die diese Anforderungen out-of-the-box erfüllen. Kein manueller Nachbau erforderlich.
SBOM-Inhalte nach BSI TR-03183 – was wirklich drinsteht
Die Pflichtfelder laut TR-03183 Tier 1 und 2 klingen zunächst überschaubar: Package Name, Version, Supplier, Unique Identifier (PURL oder CPE), Declared License, Copyright. Trivial? In der Praxis fehlen bei Legacy-Komponenten regelmäßig 30 bis 40 Prozent dieser Felder – das sehe ich in jedem SBOM-Audit, den wir bei Neuprojekten durchführen.
Deshalb haben wir ein hartes Quality-Gate eingeführt: Kein Merge ohne grünes Häkchen in TrustSource. Die Pipeline prüft automatisch, ob alle TR-03183-relevanten Felder befüllt sind. Was früher eine manuelle Compliance-Prüfung war, die Wochen gedauert hat, ist heute ein automatisierter Check, der Sekunden braucht.
Das SBOM als lebendiges Betriebsmittel – nicht als Momentaufnahme
Das größte Missverständnis, das ich immer noch höre: „Wir machen das einmal pro Release." Das ist ungefähr so hilfreich wie ein Feuerlöscher, den man am Eingang eines großen Gebäudes positioniert.
In unserem Setup erzeugt jeder CI/CD-Build einen neuen SBOM-Snapshot, der automatisch in TrustSource abgelegt wird. Das hat zwei unmittelbare Vorteile:
Erstens erkennen wir Komponentendrifts sofort. TrustSource schlägt sogar Alarm bei unerwarteten Version-Jumps – genau das Muster, das bei Dependency-Confusion-Attacks auftritt. Dieser Angriffsvektor ist subtil und ohne automatisierte SBOM-Überwachung kaum zu entdecken.
Zweitens ist die Vulnerability-Korrelation in Echtzeit möglich. Neue CVEs werden automatisch gegen unsere SBOM-Daten geprüft. Bei Log4Shell hatten wir innerhalb von 5 Minuten eine vollständige Betroffenheitsliste – für alle 120 Produkte gleichzeitig. Exakt klar, ab bzw. Bis zu welcher Version Produkte betroffen waren. Kein manuelles Durchsuchen, kein Raten.
Ein weiterer Effekt, den ich anfangs unterschätzt habe: Wir liefern unseren OEM-Kunden heute maschinenlesbare CycloneDX-Files on-demand. Was als Compliance-Overhead begann, ist inzwischen ein echtes Verkaufsargument geworden. Kunden aus dem Automotive- und Industrieumfeld fragen aktiv danach.
Supply-Chain-Risiko greifbar machen – Zahlen aus unserem Setup
Nach drei Jahren produktivem Einsatz von TrustSource haben wir belastbare Daten. Ein paar Zahlen, die ich regelmäßig im Management-Reporting verwende:
- 68 % unserer Komponenten sind transitiv. Wer nur die direkten Dependencies kennt, ist blind für den größten Angriffsvektor. Ohne vollständigen Dependency-Graph ist Supply-Chain-Security eine Illusion.
- Lizenz-Compliance-Findings sind um über 80 % gesunken, seit wir Policy-as-Code im SBOM-Workflow betreiben. Entwickler bekommen das Feedback direkt in der Pipeline – nicht sechs Wochen später im Legal-Review.
- Time-to-Detect bei kritischen Findings (CVSS ≥ 9.0 mit bekanntem Exploit) ist von durchschnittlich 12 Tagen auf unter 4 Stunden gesunken. Das ist der Unterschied zwischen einem kontrollierten Incident-Response-Prozess und einer Krisennacht.
Häufige Stolpersteine beim SBOM-Aufbau – und wie wir sie gelöst haben
„Wir haben zu viele Repos." Das höre ich oft als Argument, warum der Start zu komplex sei. Meine Antwort: Fang nicht mit dem gesamten Portfolio an. SBOM-Abdeckung von 20 % der richtigen Assets – also produktionskritische Services, alles was nach außen exponiert ist – bringt mehr als 100 % Coverage auf internen Testprojekten.
Tool-Fragmentierung ist ein echtes Problem. Unterschiedliche Scanner erzeugen inkonsistente PURLs, und wenn du SBOMs aus drei verschiedenen Tools konsolidieren willst, hast du schnell Chaos. Normalisierung ist Pflicht, bevor du anfängst zu aggregieren. TrustSource übernimmt das automatisch – wer es ohne Plattform lösen will, kann auch ts-scan auf GitHub als Open-Source-Basis nutzen.
Organisatorischer Widerstand ist ein oft unterschätzter Stolperstein. Der klassische Fehler: Das SBOM-Thema ins Compliance-Team schieben und hoffen, dass es von dort aus skaliert. Bei uns hat es erst funktioniert, als wir das Thema ins Security-Champion-Programm integriert haben. Wenn Entwickler sehen, dass sie dank SBOM eine Vulnerability-Triage in Minuten statt Tagen durchführen können, braucht es keine Überzeugungsarbeit mehr.
Fazit & nächste Schritte: Dein SBOM-Fahrplan für 2026
Drei Maßnahmen, die ich jedem Team empfehle – und die sich alle drei in einem einzigen Sprint umsetzen lassen:
- BSI TR-03183 als Qualitätsmaßstab adoptieren. Nicht als bürokratische Pflichtübung, sondern als konkretes Qualitätskriterium für jede erzeugte SBOM.
- SBOM-Erzeugung in jede CI/CD-Pipeline integrieren. Jeder Build, jeder Snapshot, automatisch abgelegt. Keine Ausnahmen.
- Vulnerability-Matching automatisieren. Manuelles CVE-Tracking ist 2026 keine Option mehr.
2026 wird das Jahr, in dem Kunden und Behörden SBOMs nicht mehr nett finden, sondern aktiv einfordern – als Vertragsbestandteil, als Lieferbedingung, als regulatorischen Nachweis. Wer jetzt in seine SBOM-Infrastruktur investiert, liefert dann auf Knopfdruck. Wer wartet, wird unter Zeitdruck nachrüsten müssen.
Der beste Zeitpunkt, mit einer SBOM-Strategie anzufangen, war vor zwei Jahren. Der zweitbeste ist jetzt.
Wenn du deinen eigenen SBOM-Reifegrad einschätzen willst, ohne monatelange Evaluierung: Eine TrustSource-Demo dauert 30 Minuten und zeigt dir konkret, wo du stehst und was der nächste realistische Schritt ist. Genau das hätte ich mir gewünscht, bevor ich selbst angefangen habe.
Anwender-Erfahrungsbericht. Endkunde von TrustSource. Nicht vergütet.
