SBOM-Praxischeck: Wie Ihr Unternehmen die Software-Stückliste bis September 2026 umsetzt

12 Min. Lesezeit

500.000 Software-Stücklisten verwaltet allein die Deutsche Bahn. Was nach Bürokratie klingt, wird ab September 2026 für jeden Hersteller digitaler Produkte in der EU zur Pflicht. Wer sich nicht vorbereitet, riskiert Bussgelder bis 15 Millionen Euro – und den Ausschluss vom europäischen Markt.

Das Wichtigste in Kürze

• 🔒 Der EU Cyber Resilience Act macht Software-Stücklisten (SBOMs) ab Dezember 2027 zur Pflicht. Erste Meldepflichten gelten ab September 2026 (EU-Verordnung 2024/2847).
• 📊 75 Prozent aller Unternehmen wurden 2024 Opfer eines Supply-Chain-Angriffs. Gartners Prognose von 45 Prozent war zu konservativ (BlackBerry, 2024).
• 🛡️ Das BSI fordert in TR-03183-2 konkret CycloneDX ab 1.6 oder SPDX ab 3.0.1 als SBOM-Format (BSI, 2024).
• 🏭 Die Deutsche Bahn verwaltet 500.000 Stücklisten mit Open-Source-Tools und eigener Logik (FOSDEM 2026).
• ⚙️ Drei Wege zur Umsetzung: vollautomatisch in der CI/CD-Pipeline, hybrid mit Review, oder manuell für Legacy-Software.

September 2026: Der Countdown läuft

Ihr Security-Team steht vor einem konkreten Problem: Ab dem 11. September 2026 müssen alle Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden. Ohne eine aktuelle Software-Stückliste ist das schlicht unmöglich. Denn wer nicht weiß, welche Komponenten in der eigenen Software stecken, kann auch nicht bewerten, ob eine neue Schwachstelle das eigene Produkt betrifft.

Die durchschnittliche Erkennungszeit für Supply-Chain-Infiltrationen liegt aktuell bei 287 Tagen. Fast zehn Monate, in denen Angreifer unbemerkt in kompromittierten Systemen operieren. Eine SBOM verkürzt diese Zeitspanne drastisch, weil sie eine sofortige Abfrage ermöglicht: Nutzen wir die betroffene Bibliothek? In welcher Version? In welchem Produkt?

Was eine SBOM ist – und was nicht

Eine Software Bill of Materials dokumentiert sämtliche Komponenten, Bibliotheken und Abhängigkeiten in einem Softwareprodukt. Vergleichbar mit der Zutatenliste auf einer Lebensmittelverpackung, nur für Code. Der CRA definiert sie als „formale Aufzeichnung, die Details und Lieferkettenbeziehungen der in den Softwareelementen enthaltenen Komponenten enthält“.

Wichtig: Eine SBOM ist kein Sicherheits-Audit. Sie macht transparent, was verbaut wurde – nicht, ob es sicher ist. Aber ohne diese Transparenz ist eine systematische Schwachstellenbewertung nicht möglich. Erst die Kombination aus SBOM und VEX (Vulnerability Exploitability eXchange) ergibt ein vollständiges Bild: Die SBOM listet die Komponenten, VEX bewertet, ob eine bekannte Schwachstelle im konkreten Einsatzkontext tatsächlich ausnutzbar ist.

Die regulatorischen Deadlines im Überblick

Der EU Cyber Resilience Act staffelt die Pflichten in zwei Stufen:

Ab 11. September 2026: Meldepflicht für aktiv ausgenutzte Schwachstellen an die ENISA innerhalb von 24 Stunden. Das gilt auch für Produkte, die bereits auf dem Markt sind. Ohne SBOM und automatisiertes Vulnerability-Tracking ist diese Frist praktisch nicht einzuhalten.

Ab 11. Dezember 2027: Vollständige SBOM-Pflicht für alle Produkte mit digitalen Elementen, die in der EU vermarktet werden. Die Stückliste muss in einem maschinenlesbaren Format vorliegen und mindestens die Top-Level-Abhängigkeiten abdecken. Bei Nichteinhaltung drohen Bussgelder bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Parallel dazu hat das BSI als künftige Marktüberwachungsbehörde die Technische Richtlinie TR-03183-2 veröffentlicht. Sie geht über die EU-Mindestanforderungen hinaus und fordert unter anderem kryptografische Prüfsummen, Lizenz-Identifikatoren und Signaturmechanismen.

„Der CRA ist ein Gamechanger für die Sicherheit digitaler Produkte!“

– Claudia Plattner, Präsidentin des Bundesamts für Sicherheit in der Informationstechnik (BSI)

Drei Wege zur SBOM: Der Praxischeck

Für IT-Leiter und CISOs stellt sich eine sehr konkrete Frage: Wie setzen wir das um? Die Antwort hängt von der eigenen Softwarelandschaft, dem Reifegrad der CI/CD-Pipelines und dem verfügbaren Budget ab. Drei Optionen haben sich in der Praxis etabliert.

Option 1: Vollautomatisiert in der CI/CD-Pipeline

Für wen: Unternehmen mit modernen Entwicklungsprozessen, Container-basierten Deployments und bestehender DevSecOps-Kultur.

So funktioniert es: Tools wie Syft, Trivy oder cdxgen werden direkt in die Build-Pipeline integriert. Bei jedem Build wird automatisch eine SBOM im CycloneDX- oder SPDX-Format generiert, versioniert und zentral gespeichert. Die SBOM aktualisiert sich mit jedem Release automatisch.

Pro: Geringster laufender Aufwand, höchste Aktualität, skaliert mit der Anzahl der Produkte. Laut ENISA der empfohlene Ansatz für Unternehmen mit mehr als zehn Softwareprodukten.

Contra: Initiale Integrationsarbeit (2-4 Wochen pro Pipeline), erfordert DevOps-Kompetenz, Legacy-Systeme ohne CI/CD bleiben aussen vor.

Option 2: Hybrid mit manuellem Review

Für wen: Mittelstand mit gemischter Softwarelandschaft. Einige Produkte laufen in modernen Pipelines, andere sind gewachsene Systeme ohne Automatisierung.

So funktioniert es: Moderne Produkte werden automatisiert erfasst (wie Option 1). Für Legacy-Software werden SBOMs per Binary-Analyse-Tools wie FOSSA oder Mend erzeugt, die fertige Binaries scannen. Ein Security-Analyst reviewed und ergänzt die Ergebnisse manuell.

Pro: Deckt die gesamte Produktlandschaft ab, realistisch umsetzbar mit bestehenden Teams, erfüllt BSI TR-03183-2 vollständig.

Contra: Höhere laufende Personalkosten, manuelle Schritte sind fehleranfällig, Review-Zyklen verlangsamen Releases.

Option 3: Manuell mit Template-Ansatz

Für wen: Kleine Softwarehersteller mit wenigen Produkten, die keine eigene DevOps-Abteilung haben.

So funktioniert es: SBOMs werden manuell erstellt, basierend auf ENISA-Templates und BSI-Vorgaben. Entwickler dokumentieren verwendete Bibliotheken und Versionen in einer strukturierten Tabelle, die dann in CycloneDX oder SPDX konvertiert wird.

Pro: Kein Tool-Investment nötig, schneller Einstieg möglich, erfüllt die Mindestanforderungen des CRA.

Contra: Skaliert nicht, hohe Fehlerquote bei komplexen Dependency-Trees, wird bei mehr als drei Produkten unhandlich. ENISA warnt ausdrücklich, dass manuell erstellte SBOMs häufig nicht die Mindestqualität erreichen.

Wie die Deutsche Bahn es macht

Dass SBOMs auch im Grossmassstab funktionieren, zeigt die Deutsche Bahn. Auf der FOSDEM 2026 präsentierte das Unternehmen seinen Ansatz: 500.000 SBOMs, verwaltet mit einer Kombination aus Open-Source-Tools und eigenentwickelter Logik, eingebettet in die bestehende Enterprise-Architektur.

Drei Erkenntnisse aus dem DB-Projekt sind auch für kleinere Unternehmen relevant:

SBOMs sind kein Selbstzweck. Die DB behandelt SBOMs als unterstützende Methode für verschiedene Use Cases – von Vulnerability-Management über Lizenz-Compliance bis hin zur Lieferantensteürung. Wer SBOMs nur als regulatorische Checkbox betrachtet, verschenkt den operativen Nutzen.

Open Source reicht – mit Eigenlogik. Die DB setzt auf FOSS-Tools wie Syft und Trivy, ergänzt um eigene Logik für die Integration in SAP und interne Systeme. Teure kommerzielle Plattformen waren nicht nötig, aber die Integrationsarbeit war erheblich.

Menschen machen den Unterschied. Technische Tools allein genügen nicht. Die DB betont, dass dediziertes Personal nötig ist, um SBOMs in Pipelines zu integrieren und die Qualität der generierten Stücklisten kontinuierlich zu überwachen.

Die Kehrseite: Warum SBOMs kein Allheilmittel sind

Bei aller Euphorie über regulatorische Fortschritte: SBOMs lösen nicht alle Probleme der Software-Supply-Chain-Sicherheit. Drei Einschränkungen sollten IT-Leiter kennen.

Fragmentierung der Standards. CycloneDX und SPDX sind die beiden dominanten Formate, aber sie sind nicht vollständig kompatibel. Viele Unternehmen erzeugen beide Formate parallel – CycloneDX für das Security-Team, SPDX für die Rechtsabteilung. Das verdoppelt den Aufwand ohne Sicherheitsgewinn.

Qualitätsproblem. Nicht jede automatisch generierte SBOM erreicht die Mindestqualität. Die ENISA warnt in ihrem SBOM Landscape Report (Dezember 2025), dass Softwareanbieter relevante Daten häufig nicht einbinden, weil sie schlicht nicht verfügbar sind. Eine SBOM, die 60 Prozent der Abhängigkeiten erfasst, wiegt in falscher Sicherheit.

Angreifer passen sich an. Supply-Chain-Angriffe haben sich 2025 verdoppelt, mit durchschnittlich 26 Vorfällen pro Monat ab April 2025. Angreifer zielen zunehmend auf die Build-Pipelines selbst – also genau die Infrastruktur, die SBOMs erzeugt. Ein kompromittierter Build-Prozess kann auch eine korrekt aussehende, aber manipulierte SBOM produzieren.

CycloneDX oder SPDX? Die Format-Entscheidung

Das BSI akzeptiert beide Formate, empfiehlt aber CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Für die Praxis gilt:

CycloneDX ist die bessere Wahl für Security-Teams. Das Format bietet native Unterstützung für VEX, Hashing und Dependency-Trees. Version 1.7 (Oktober 2025) bringt zusätzlich Patent-Metadaten und erweiterte kryptografische Transparenz. CycloneDX unterstützt neben Software-SBOMs auch Hardware- (HBOM), KI/ML- und kryptografische Stücklisten (CBOM).

SPDX ist stärker im Bereich Lizenz-Compliance und IP-Dü-Diligence. Als ISO/IEC 5962:2021-zertifizierter Standard geniesst SPDX höhere regulatorische Akzeptanz, besonders bei Unternehmen mit internationalem Geschäft.

Pragmatische Empfehlung: Starten Sie mit CycloneDX für den operativen Sicherheitsbetrieb. Wenn Ihre Rechtsabteilung SPDX fordert, nutzen Sie Konvertierungstools wie cyclonedx-cli oder spdx-tools. Beide Formate lassen sich ineinander umwandeln, auch wenn dabei Detailverluste möglich sind.

Checkliste: SBOM-Readiness in 90 Tagen

Für IT-Leiter, die jetzt starten wollen, hier der konkrete Fahrplan:

Woche 1-2: Bestandsaufnahme

• Alle Produkte mit digitalen Elementen inventarisieren (auch Firmware, Embedded Software, IoT-Geräte)
• Bestehende CI/CD-Pipelines und Build-Prozesse dokumentieren
• Verantwortlichen benennen (SBOM-Owner pro Produktlinie)

Woche 3-4: Pilotprojekt

• Ein Produkt auswählen (idealerweise mit moderner CI/CD-Pipeline)
• SBOM-Generator integrieren (Syft für Container, cdxgen für Applikationen)
• Erste SBOM erzeugen und gegen BSI TR-03183-2 validieren

Woche 5-8: Ausrollen

• Erfolgreichen Piloten auf weitere Produkte übertragen
• Vulnerability-Monitoring einrichten (OSV, NVD oder kommerzieller Feed)
• Prozess für 24-Stunden-Meldepflicht definieren und testen

Woche 9-12: Härten

• SBOM-Qualitätsmetriken definieren (Abdeckungsgrad, Aktualität)
• Lieferanten-SBOMs einfordern und in eigene Stückliste integrieren
• Audit-Trail und Dokumentation für Marktüberwachung aufbaün

Der nächste Schritt

Die SBOM-Pflicht kommt. Die Frage ist nicht ob, sondern wie gut Ihr Unternehmen vorbereitet ist, wenn im September 2026 die erste Meldepflicht greift. Der pragmatischste erste Schritt: Installieren Sie Syft oder Trivy in einem Testprojekt und erzeugen Sie Ihre erste SBOM. Das daürt 30 Minuten und zeigt Ihnen sofort, wie viele Abhängigkeiten in Ihrer Software stecken, von denen Sie nichts wussten.

Häufige Fragen

Müssen auch Unternehmen, die Software nur einsetzen (nicht herstellen), SBOMs erstellen?

Nein. Der CRA richtet sich an Hersteller, also an Unternehmen, die Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen. Reine Anwender müssen keine eigenen SBOMs erstellen, sollten aber von ihren Lieferanten SBOMs einfordern. Die NIS2-Richtlinie verlangt zudem, dass kritische Infrastrukturen ihre Software-Supply-Chain im Rahmen des Risikomanagements dokumentieren.

Welches SBOM-Format soll ich wählen – CycloneDX oder SPDX?

Für die meisten Security-Teams ist CycloneDX ab Version 1.6 der pragmatischere Einstieg, weil es native Vulnerability- und VEX-Unterstützung bietet. SPDX ist stärker bei Lizenz-Compliance. Das BSI akzeptiert in TR-03183-2 beide Formate. Viele Unternehmen erzeugen parallel beide und konvertieren bei Bedarf.

Was kostet die SBOM-Einführung für ein mittelständisches Unternehmen?

Die reinen Tool-Kosten können bei null liegen, da Open-Source-Tools wie Syft und Trivy produktionsreif sind. Der Hauptaufwand liegt in der Integration: Rechnen Sie mit 2-4 Wochen Integrationsarbeit pro CI/CD-Pipeline und einem halben FTE für laufendes Monitoring und Qualitätssicherung. Kommerzielle Plattformen wie FOSSA oder Mend starten bei circa 15.000 Euro pro Jahr.

Gilt die SBOM-Pflicht auch für Open-Source-Projekte?

Jein. Open-Source-Software, die als Hobby-Projekt ohne kommerzielle Absicht entwickelt wird, ist vom CRA ausgenommen. Sobald ein Unternehmen Open-Source-Komponenten in ein kommerzielles Produkt integriert, trägt es die SBOM-Pflicht für das Gesamtprodukt – einschliesslich aller Open-Source-Abhängigkeiten.

Muss die SBOM öffentlich zugänglich sein?

Nein. Der CRA stellt ausdrücklich klar, dass Hersteller nicht verpflichtet sind, ihre SBOM zu veröffentlichen. Sie muss Teil der technischen Dokumentation sein und auf Anfrage den Marktüberwachungsbehörden vorgelegt werden können. Einige Unternehmen veröffentlichen ihre SBOMs freiwillig als Vertraünssignal gegenüber Kunden.

Weiterführende Artikel

• Supply Chain Security 2026: So schützen Unternehmen ihre Software-Lieferkette (SecurityToday)
• NIS2 in Deutschland: Was Unternehmen jetzt wissen und umsetzen müssen (SecurityToday)
• DORA und NIS2 gleichzeitig: Compliance-Doppeldruck für Finanzdienstleister (SecurityToday)

Aus dem MBF-Media-Netzwerk

• DORA, AI Act, MiCA gleichzeitig: Warum RegTech 2026 zur Pflichtinvestition wird (MyBusinessFuture)
• Cloud-Trends 2026: Was IT-Entscheider jetzt auf dem Radar haben müssen (cloudmagazin)
• Digital Dü Diligence: Warum M&A-Deals an der IT scheitern (Digital Chiefs)

Quelle Titelbild: Pexels / cottonbro studio

Hier schreibt Benedikt Langer für Sie

Mehr Artikel vom Autor Benedikt Langer