Was eine SBOM ist

Die US-Behörde CISA beschreibt eine Software Bill of Materials als "nested inventory": eine Liste der Zutaten, aus denen eine Software zusammengesetzt ist, inklusive der Komponenten, die wiederum in Komponenten stecken [1]. Gemeint ist keine Prosa-Dokumentation, sondern ein maschinenlesbares Dokument.

Die zwei Formate

Dafür haben sich zwei Formate etabliert: SPDX, seit 2021 als ISO/IEC 5962 genormt [2], und CycloneDX, das seit Juni 2024 als ECMA-424 standardisiert ist. Die zweite Ausgabe vom Dezember 2025 beschreibt CycloneDX 1.7 im JSON-Format [3, 7].

Welches der beiden Formate Sie wählen, ist selten eine Grundsatzentscheidung. SPDX kommt aus der Lizenz-Compliance und transportiert neben Sicherheits- auch Herkunfts- und Lizenzinformationen [2].

CycloneDX ist als modulares Objektmodell angelegt, das neben Softwarekomponenten auch Dienste und Abhängigkeitsbeziehungen abbildet [3]. In der Praxis entscheidet meist, was Ihre Werkzeugkette und Ihre Abnehmer verlangen; Werkzeuge wie Syft können zwischen den Formaten konvertieren [5].

Was mindestens drinsteht

Was mindestens hineingehört, hat die NTIA in ihrem Bericht zu den "Minimum Elements" beschrieben: Datenfelder wie Lieferant, Komponentenname, Version, eindeutige Identifikatoren und Abhängigkeitsbeziehungen, dazu Anforderungen an Automatisierung sowie an die Prozesse rund um Erzeugung und Weitergabe [4].

Erzeugen: im Build, nicht hinterher

Eine SBOM sollte zusammen mit dem ausgelieferten Artefakt entstehen. Der Build ist dafür ein geeigneter Ausgangspunkt: Hier lassen sich Basis-Image, aufgelöste Abhängigkeiten und Systempakete erfassen und dem Release zuordnen. Wie vollständig das Ergebnis ist, hängt von den verwendeten Datenquellen und Werkzeugen ab.

Ein Beispiel für ein Werkzeug an dieser Stelle ist Syft, ein CLI-Tool, das SBOMs aus Container-Images und Dateisystemen erzeugt und sie unter anderem als SPDX- oder CycloneDX-JSON ausgibt [5].

In der Praxis heißt das: ein zusätzlicher Schritt in der Pipeline direkt nach dem Image-Build, der die SBOM als Artefakt neben dem Image ablegt. Wichtig ist die eindeutige Zuordnung: Jede SBOM gehört zu genau einem Artefakt in genau einer Version, sonst lässt sich später nicht mehr sagen, welche Auskunft für welches Release gilt.

Der häufigste Fehler

Ein häufiger Fehler ist, nur das Quell-Repository zu scannen. Ein Image-Scan erfasst auch Pakete des Basis-Images, garantiert aber keine vollständige Erkennung aller Abhängigkeiten. Quellcode-, Build- und Image-Analyse ergänzen sich; fehlende Komponenten müssen gegebenenfalls aus Build- oder Lieferantendaten ergänzt werden. Entscheidend ist die Zuordnung zum ausgelieferten Artefakt [9].

Prüfen: Abgleich mit Schwachstellendaten

Eine SBOM ist eine Momentaufnahme der Zusammensetzung, keine Aussage über Sicherheit. Ihr Wert entsteht beim Abgleich: Werkzeuge wie Grype, das auf Syft aufsetzt [5], gleichen die Komponentenliste gegen Schwachstellendatenbanken ab und melden, welche Einträge betroffen sind.

Zwei Bedingungen für ein brauchbares Ergebnis

Erstens die Identifikatoren. Nur wenn Komponenten eindeutig benannt sind, trifft das Matching, genau deshalb gehören eindeutige Identifikatoren zu den NTIA-Mindestelementen [4].

Zweitens die Wiederholung. Neue Schwachstellen betreffen alte Artefakte. Der Abgleich muss deshalb regelmäßig auch gegen die SBOMs von Releases laufen, die längst ausgeliefert sind, sonst erfahren Sie von einer betroffenen Komponente erst beim nächsten Deployment.

Ein Beispiel. In einer weit verbreiteten Bibliothek wird eine Schwachstelle bekannt. Die Frage, die dann innerhalb von Stunden beantwortet werden muss, lautet nicht, ob Sie betroffen sind, sondern in welchen ausgelieferten Versionen. Mit SBOMs pro Release ist das eine Abfrage über die abgelegten Dokumente: Welche Releases enthalten die Komponente in einer betroffenen Version. Ohne sie beginnt eine Suche durch Build-Protokolle und Repositories, während die Frage im Raum steht. Der Unterschied liegt nicht im Scanner, sondern darin, dass die Antwort schon vorliegt, bevor jemand fragt.

Wer die Arbeit macht

Der Abgleich erzeugt außerdem Arbeit, die organisiert werden will. Ein Treffer in der SBOM heißt zunächst: Die Komponente ist enthalten. Ob die Schwachstelle im konkreten Einsatz erreichbar ist, muss ein Mensch oder ein nachgelagerter Prozess bewerten.

Deshalb gehört der SBOM-Abgleich an das bestehende Vulnerability Management angebunden, mit denselben Wegen für Priorisierung und Nachverfolgung, statt als separater Report, den niemand liest.

Aufbewahren und weitergeben

Die Aufbewahrung ist der unspektakuläre Teil, an dem die Auskunftsfähigkeit hängt. Bewährt hat sich: pro Release eine SBOM, versioniert abgelegt neben dem Artefakt, etwa in der Registry oder im Artefakt-Store, so dass sich zu jeder produktiven Version nachschlagen lässt, was darin steckt.

Dazu gehört ein geregelter Zugriff: intern für Security- und Betriebsteams, extern auf Anfrage für Kunden, die eine SBOM zu Ihrer Software verlangen. Umgekehrt gilt dasselbe: Wer Software einkauft, sollte SBOMs vom Lieferanten anfordern und in die eigene Prüfung aufnehmen, statt die Zusammensetzung selbst zu rekonstruieren.

Für die Weitergabe zahlt sich die Formatdisziplin aus dem ersten Abschnitt aus: Eine SBOM in standardkonformem SPDX oder CycloneDX kann der Empfänger direkt in seine Werkzeuge laden, eine Excel-Tabelle nicht.

Wie lange

Klären Sie außerdem früh, wie lange Sie SBOMs vorhalten. Solange eine Version irgendwo produktiv läuft oder Support-Zusagen bestehen, muss die zugehörige SBOM abrufbar sein, und das ist bei langlebiger Unternehmenssoftware schnell eine Frage von Jahren.

Für Produkte im Anwendungsbereich des Cyber Resilience Act müssen Hersteller grundsätzlich ab dem 11. Dezember 2027 eine maschinenlesbare SBOM erstellen, die mindestens die obersten Abhängigkeiten erfasst [8]. Das BSI formuliert in der Technischen Richtlinie TR-03183 Teil 2 konkrete SBOM-Anforderungen als Vorbereitung darauf, inklusive einer Zuordnung der Datenfelder zu SPDX und CycloneDX [6].

Kernaussage

Eine SBOM, die einmal im Jahr von Hand entsteht, ist Dokumentation. Eine SBOM, die jeder Build erzeugt, die wiederkehrend gegen Schwachstellendaten läuft und die pro Release auffindbar bleibt, ist ein Werkzeug.

Was Sie danach entscheiden können

  • An welcher Stelle Ihrer Pipeline SBOMs entstehen und in welchem Format, SPDX oder CycloneDX.
  • Wie der wiederkehrende Abgleich gegen Schwachstellendaten an Ihr bestehendes Vulnerability Management anschließt.
  • Wo SBOMs pro Release abgelegt werden, wer Zugriff bekommt und wie lange sie vorgehalten werden.

Häufige Fragen

Reicht die SBOM aus dem Quellcode-Scan?

Nicht unbedingt. Bei Containern fehlen einem reinen Quellcode-Scan beispielsweise die Pakete des Basis-Images. Ein zusätzlicher Image-Scan verbessert die Abdeckung, garantiert aber ebenfalls keine Vollständigkeit. Ergänzen Sie bei Bedarf Build- und Lieferantendaten und ordnen Sie die SBOM dem ausgelieferten Artefakt zu.

SPDX oder CycloneDX?

Selten eine Grundsatzentscheidung. Es entscheidet, was Ihre Werkzeugkette und Ihre Abnehmer verlangen, und Werkzeuge wie Syft konvertieren zwischen beiden Formaten. Wichtiger ist, dass die SBOM automatisch im Build entsteht.

Sind wir als Hersteller zur SBOM verpflichtet?

Für Produkte im Anwendungsbereich des Cyber Resilience Act gilt die Pflicht zur Erstellung einer maschinenlesbaren SBOM grundsätzlich ab dem 11. Dezember 2027. Sie muss mindestens die obersten Abhängigkeiten erfassen. Prüfen Sie, ob Ihr Produkt in den Anwendungsbereich fällt und welche Übergangsregeln gelten. Daraus folgt keine pauschale Pflicht, die SBOM öffentlich bereitzustellen [8].

Quellen

Weiterlesen

Expertise Cybersecurity Expertise Platform Engineering Wissen Terraform im Team Wissen MCP absichern