SBOM erklärt

Was ist eine SBOM?

Toni Menzel · Release Controls bei rebaze

Eine SBOM (Software Bill of Materials) ist die maschinenlesbare Liste der erfassten Komponenten einer Software mit ihren Versionen. Sie ist eine Grundlage für weitere Prüfungen, kein Nachweis von Sicherheit.

Die Zutatenliste für Software

Ein verpacktes Lebensmittel trägt eine Zutatenliste. Bei einem Rückruf lässt sich damit eingrenzen, wer betroffen ist, ohne jede Packung zu öffnen.

Eine SBOM macht das Gleiche für Software: Jede Bibliothek und jedes Framework wird mit Name, Version und Lizenz festgehalten. Der Vergleich hat allerdings eine Grenze. Die Zutatenliste erstellt der Hersteller aus eigener Kenntnis des Rezepts. Eine SBOM erzeugt ein Werkzeug aus dem, was es im Build sieht. Was es nicht sieht, steht auch nicht drin.

Wozu

Die Frage nach Log4Shell

Im Dezember 2021 wurde Log4Shell bekannt, eine kritische Schwachstelle in der weit verbreiteten Java-Bibliothek Log4j. Jede betroffene Organisation musste dieselbe Frage beantworten:

„Sind wir betroffen? Wo genau steckt Log4j in unseren Systemen?“

Wer eine gepflegte Komponentenliste je ausgeliefertem Stand hatte, konnte die Frage aus vorhandenen Daten beantworten. Wer keine hatte, musste die Antwort erst zusammensuchen: über Build-Systeme, Repositories und Rückfragen in den Teams. Der Unterschied liegt nicht im Wissen, sondern darin, ob es abrufbar festgehalten war.

Die Einschränkung gilt auch hier: Eine SBOM beantwortet die Frage nur so gut, wie sie die tatsächlich ausgelieferte Software beschreibt. Genau deshalb kommt es auf die Zuordnung zum richtigen Artefakt an.

Inhalt

Was in einer SBOM steht

Komponenten

Name, Version, Hersteller und Typ jeder erfassten Komponente. Direkte und transitive Abhängigkeiten.

Lizenzen

Der Lizenztyp je Komponente, etwa MIT, Apache-2.0 oder GPL. Grundlage für Lizenzprüfung und Legal Review.

Beziehungen

Welche Bibliothek bindet welche andere ein? Wie tief reicht der Baum transitiver Einbindungen?

Herkunft

Package URL (PURL), Repository- und Download-Quelle. Damit ist nachvollziehbar, woher eine Komponente stammt.

Prüfsummen

Kryptografische Hashes, etwa SHA-256. Sie zeigen, ob eine Komponente dem entspricht, was erwartet wurde.

Metadaten

Erzeugungszeitpunkt, verwendetes Werkzeug und Autor. Ohne diese Angaben lässt sich eine SBOM später schwer einordnen.

Formate

SBOM-Standards

CycloneDX

OWASP-Standard, JSON- und XML-basiert. Schwerpunkt auf Security: Schwachstellen-Referenzen, Lizenzausdrücke, Dependency Graph. Vom BSI in der TR-03183 berücksichtigt.

OWASP JSON / XML

SPDX

Standard der Linux Foundation, ISO/IEC 5962:2021. Stärker auf Lizenz-Compliance ausgerichtet, mit breiter Verbreitung in der Open-Source-Community.

ISO-Standard Linux Foundation

Der Open-Source Evidence Compiler rio von rebaze vereinheitlicht CycloneDX-SBOMs und prüft deklarierte Qualitätsanforderungen. Er ergänzt bereitgestellte Produkt- und Build-Angaben, liefert die SBOMs nativ an Dependency-Track oder OCI-Registries und schreibt je Lauf einen kompakten Beleg mit Digests und Empfängerantworten. rio ergänzt keine fehlenden Komponenten und sucht nicht selbst nach Schwachstellen.

Tooling

Verbreitete Werkzeuge

Eine Auswahl etablierter Open-Source-Werkzeuge. Welche zu Ihnen passen, hängt von Ihren Ökosystemen und Ihrer bestehenden Pipeline ab.

Syft

SBOM-Generierung aus Container-Images, Dateisystemen und Repositories

DependencyTrack

Plattform für SBOM-Verwaltung und fortlaufenden Schwachstellen-Abgleich

Grype

Scanner, der SBOM-Inhalte gegen Schwachstellendatenbanken abgleicht

Regulierung

Wo SBOMs gefordert werden

Eine allgemeine SBOM-Pflicht für jedes Unternehmen gibt es nicht. Ob und in welcher Form eine gefordert ist, hängt davon ab, welches Regelwerk für Sie gilt.

NIS2 / BSIG

Verlangt von betroffenen Einrichtungen Maßnahmen zur Lieferkettensicherheit und zum Umgang mit Schwachstellen. Eine SBOM kann diese Maßnahmen unterstützen; vorgeschrieben ist sie dort nicht.

Cyber Resilience Act

Für Hersteller von Produkten mit digitalen Elementen. Eine maschinenlesbare SBOM gehört zu den Produktanforderungen, die ab dem 11. Dezember 2027 gelten. Die Meldepflichten gelten bereits seit dem 11. September 2026.

BSI TR-03183

Eine technische Richtlinie, keine allgemein geltende gesetzliche Pflicht. Sie konkretisiert Formate, Mindestinhalte und Bereitstellungswege und eignet sich als Maßstab für die eigene Gestaltung.

NIS2 und Ihre Software-Lieferkette

Was eine SBOM nicht leistet.

Eine vorhandene SBOM garantiert keine vollständige Inventur. Ihre Abdeckung hängt davon ab, welche Eingaben das erzeugende Werkzeug gesehen hat. Sie bestätigt auch keine Sicherheit: Sie listet Komponenten, sie bewertet sie nicht.

Nutzbar wird sie erst in einem Ablauf: erzeugt zum richtigen Build, zugeordnet zum ausgelieferten Artefakt, ausgewertet gegen vereinbarte Kriterien, und verbunden mit einer Freigaberegel, die bei einem fehlenden Pflichtnachweis auch tatsächlich greift.

Wie Freigaberegeln in der Praxis greifen

Welche Frage soll Ihre SBOM beantworten?

Bringen Sie einen konkreten Fall mit: eine SBOM, der Sie nicht trauen, eine Prüfung ohne Wirkung auf die Freigabe, oder eine Anforderung, bei der unklar ist, wie Sie sie erfüllen.

Ihren Fall besprechen

30 Minuten mit Toni Menzel. Kostenlos und unverbindlich.