SBOM ist die Abkürzung für Software Bill of Materials und bezeichnet ein strukturiertes Inventar aller Software-Komponenten eines Produkts oder Systems. Für Unternehmen schafft SBOM Transparenz in der Software-Lieferkette und macht Schwachstellen, Updates und Pflichten besser beherrschbar.
Was ist eine SBOM?
Eine SBOM listet auf, welche Bibliotheken, Frameworks, Pakete und Abhängigkeiten in einer Software oder in einem vernetzten Produkt enthalten sind. Sie funktioniert wie eine Stückliste in der Industrie: Statt Bauteilen dokumentiert sie Software-Komponenten, Versionen, Hersteller, Lizenzinformationen und Abhängigkeitsbeziehungen.
Für die Praxis ist entscheidend, dass eine SBOM kein Audit-Dokument allein ist. Sie ist ein operatives Werkzeug für Entwicklung, Einkauf, Produktsicherheit und Compliance. Gängige Formate sind SPDX und CycloneDX. Beide sind maschinenlesbar und passen zu den vom NTIA beschriebenen Minimum Elements wie Lieferant, Komponentenname, Version und eindeutige Identifikatoren.
Warum ist SBOM für NIS2-betroffene Unternehmen relevant?
Im Rahmen des Beitrags zur NIS2-Lieferkettensicherheit ist SBOM relevant, weil Art. 21 Abs. 2 lit. d der Richtlinie (EU) 2022/2555 Maßnahmen zur Sicherheit der Lieferkette und der sicherheitsbezogenen Beziehungen zwischen Einrichtungen und ihren unmittelbaren Anbietern verlangt. Eine SBOM hilft genau an dieser Stelle, weil sie Abhängigkeiten in Software und digitalen Produkten sichtbar macht, statt Lieferkettenrisiken nur abstrakt zu beschreiben.
Für NIS2-betroffene Unternehmen bedeutet das konkret: Ohne Transparenz über eingesetzte Komponenten wird Cybersicherheits-Governance schnell lückenhaft. Wenn eine kritische Open-Source-Bibliothek oder ein Drittanbieter-Modul eine Schwachstelle enthält, muss Ihr Unternehmen kurzfristig feststellen können, ob Sie betroffen sind und welche Maßnahmen Priorität haben. Eine gepflegte SBOM verkürzt diese Analyse erheblich und stärkt damit Incident Response, Risikobewertung, Informationssicherheit und Meldepflichten.
Auch der CRA verschärft die praktische Relevanz. Der Cyber Resilience Act, also die Verordnung (EU) 2024/2847, verlangt in Anhang I Teil II die Dokumentation von Schwachstellen und enthaltenen Komponenten einschließlich einer Software Bill of Materials in einem gängigen, maschinenlesbaren Format. Wer Produkte mit digitalen Elementen entwickelt oder unter eigenem Namen in Verkehr bringt, sollte SBOM daher als belastbaren Compliance-Baustein im Zusammenspiel mit dem CRA behandeln.
Wie sieht ein Praxisbeispiel aus?
Ein deutsches Maschinenbauunternehmen aus Baden-Württemberg entwickelt vernetzte Steuerungseinheiten für Produktionsanlagen und integriert eigene Software, Linux-Komponenten, Open-Source-Bibliotheken und Zukaufmodule. Ohne SBOM müsste das Unternehmen bei einer neu veröffentlichten Schwachstelle erst mühsam prüfen, ob die betroffene Bibliothek überhaupt in einem ausgelieferten Produkt enthalten ist.
Mit einer aktuellen SBOM lässt sich derselbe Fall deutlich schneller bearbeiten. Das Security- oder DevOps-Team sieht sofort, welche Produktlinien betroffen sind und ob ein Update oder Hotfix notwendig ist. Gleichzeitig kann das Unternehmen gegenüber Kunden und Auditoren nachvollziehbar dokumentieren, welche Komponenten eingesetzt wurden und wie der Vorfall behandelt wurde.
Wie wird eine SBOM in der Praxis erstellt?
Am wirksamsten ist SBOM, wenn sie automatisiert im CI/CD-Prozess erzeugt und bei jedem Build aktualisiert wird. Dann entsteht keine veraltete Excel-Liste, sondern ein belastbarer Datenbestand, der Release-Management, Schwachstellenanalyse und regulatorische Nachweise unterstützt.
Ein pragmatischer Einstieg besteht aus vier Schritten:
- Erfassen Sie alle Build-Artefakte und relevanten Open-Source- sowie Drittkomponenten.
- Erzeugen Sie SBOM-Dateien automatisiert in SPDX oder CycloneDX.
- Verknüpfen Sie die SBOM mit Vulnerability Scans, Ticketing und Freigabeprozessen.
- Aktualisieren Sie die SBOM bei jedem Release und nutzen Sie sie aktiv in Incident- und Patch-Prozessen.
Häufige Fragen zu SBOM
Was ist SBOM?
SBOM ist ein strukturiertes Verzeichnis aller relevanten Software-Komponenten und Abhängigkeiten eines Produkts. Es macht sichtbar, welche Bausteine enthalten sind und erleichtert dadurch Sicherheitsbewertungen, Updates und regulatorische Nachweise.
Welche Rolle spielt SBOM unter NIS2?
SBOM unterstützt NIS2, weil Lieferkettenrisiken ohne Komponenten-Transparenz schwer steuerbar sind. Art. 21 Abs. 2 lit. d NIS2 adressiert genau diese Lieferkettenperspektive und macht SBOM zu einem praktischen Instrument für Risikomanagement und Reaktionsfähigkeit.
Wenn Sie SBOM, Lieferkettenrisiken und regulatorische Pflichten für Ihr Unternehmen praxisnah einordnen möchten, finden Sie in unserer NIS2-Schulung für Berlin einen belastbaren Einstieg für Führungskräfte, IT und Compliance.