Was ist eine SBOM?

Wofür steht SBOM?

SBOM steht für Software Bill of Materials, also Software-Stückliste. Der Begriff stammt aus der Fertigung, wo eine Stückliste die Teile aufführt, aus denen ein Produkt besteht. CISA beschreibt eine SBOM als verschachteltes Inventar, eine Liste der Zutaten, aus denen Softwarekomponenten bestehen.

Der Großteil des Codes einer modernen Anwendung stammt von anderen, und das meiste davon kommt indirekt hinzu: Sie fügen ein Paket hinzu, und es bringt Dutzende transitive Abhängigkeiten mit. Eine SBOM hält all das fest, sodass Sie die Frage „Sind wir betroffen?“ beantworten können, ohne ein einziges Repository zu lesen.

Was enthält eine SBOM?

Eine brauchbare SBOM besteht aus zwei Teilen: Daten über die SBOM selbst und Daten über jede Komponente. Die 2026 Minimum Elements, die CISA, NSA und FBI am 29. Juli 2026 mit internationalen Partnern veröffentlicht haben, ersetzen die NTIA-Liste von 2021 und setzen die Basis, auf die sich die meisten Käufer heute beziehen.

Teil	Felder
Über die SBOM	Autor und Signatur des Autors, Zeitstempel, Name und Version des Datenformats, Name und Version des Tools, SBOM-Version und der Generierungskontext
Über jede Komponente	Name, Version, Hersteller, Kennungen wie eine Package-URL, Hashwert und Algorithmus, Lizenz und Abhängigkeitsbeziehungen

Der Generierungskontext ist wichtiger, als er aussieht. Er sagt, wann die SBOM entstanden ist: vor dem Build, während des Builds, aus dem fertigen Artefakt oder danach. Genau deshalb können sich zwei SBOMs desselben Releases unterscheiden. Unter SBOM-Beispiele sehen Sie, wie diese Felder in einer echten Datei aussehen.

SBOM-Formate

Zwei Formate decken fast alle SBOMs im Einsatz ab. CycloneDX von OWASP kommt aus der Sicherheit und beschreibt auch Schwachstellen und Dienste. SPDX von der Linux Foundation kommt aus der Lizenz-Compliance. Beide können die Minimum Elements abbilden, und die meisten Tools schreiben beide. Wie Sie wählen, lesen Sie unter CycloneDX vs. SPDX.

Warum SBOMs wichtig sind

• Schnellere Reaktion auf Vorfälle. Taucht eine Schwachstelle wie Log4Shell auf, lautet die Frage, welche Ihrer Produkte sie enthalten. Mit SBOMs ist das eine Suche. Ohne sie ist es ein Projekt.
• Schwachstellenüberwachung nach dem Release. Software, die bei der Auslieferung sauber war, kann morgen verwundbar sein. Wer gespeicherte SBOMs erneut mit neuen Advisories abgleicht, erkennt das, ohne etwas neu zu bauen.
• Lizenzrisiko. Die deklarierte Lizenz jeder Komponente zeigt Copyleft- oder kommerzielle Bedingungen, bevor sie ins Produkt gelangen.
• Fragen von Kunden und Regulierungsbehörden. Käufer verlangen in der Beschaffung immer häufiger eine SBOM, und mehrere Frameworks setzen ein Komponenteninventar voraus.

Wer braucht eine SBOM?

Alle, die Software ausliefern, und alle, die dafür einstehen müssen, was darin steckt. Die Anforderung kommt meist über einen dieser Wege:

• Medizinprodukte. FDA Section 524B verlangt für Cyber Devices eine SBOM in Zulassungsanträgen vor dem Inverkehrbringen.
• In der EU verkaufte Produkte. Der Cyber Resilience Act verlangt von Herstellern eine SBOM. Siehe CRA-SBOM-Anforderungen und Tools.
• Öffentliche Beschaffung des US-Bundes. Das OMB-Memo M-26-05 vom Januar 2026 überlässt jeder Behörde die Entscheidung, ob sie eine verlangt. Rechnen Sie also mit Einzelfallentscheidungen.
• Zahlungssoftware. PCI DSS 4.0, Anforderung 6.3.2, verlangt ein Inventar individuell entwickelter Software und ihrer Drittanbieterkomponenten. Eine SBOM schreibt sie nicht vor, aber eine SBOM erfüllt den Zweck.

So erzeugen Sie eine SBOM

Es gibt drei Wege zu einer SBOM, und die Methode entscheidet, was in der Datei landet.

Methode	Was sie liest	Typische Lücke
Quellcode scannen	Manifeste und Lockfiles im Repository	Alles, was der Build lädt und in keinem Lockfile steht
Ergebnis scannen	Ein fertiges Container-Image oder eine Binärdatei	Kompilierter Code ist mehrdeutig, und Build-Tools hinterlassen keine Spuren
Build aufzeichnen	Was der Build während der Ausführung tatsächlich geladen hat	Datenverkehr, der die Aufzeichnung umgeht und markiert werden sollte

Open-Source-Generatoren wie Syft, Trivy und cdxgen nutzen die ersten beiden Methoden. Sie widersprechen einander beim selben Commit, weil jeder eigene Regeln dafür hat, was er liest. Die Optionen im direkten Vergleich finden Sie unter die besten SBOM-Tools.

SBOM vs. SCA vs. VEX

• Eine SBOM ist ein Inventar. Sie sagt, was vorhanden ist, nicht, ob es sicher ist.
• Software Composition Analysis ist die Analyse. Sie findet Komponenten und prüft sie auf Risiken, und viele SCA-Tools erzeugen dabei eine SBOM.
• VEX ist eine Aussage über die Auswirkung. Sie sagt, ob eine bekannte Schwachstelle Ihr Produkt tatsächlich betrifft, und reduziert so das Rauschen, das eine SBOM allein erzeugt.

Die SBOM zu erzeugen ist der einfache Teil

Eine Datei, die niemand liest, ändert nichts. Der Wert entsteht, wenn Sie eine SBOM pro Release aufbewahren, die SBOMs überwachen und sie im Ernstfall finden. Diese Arbeit ist SBOM-Verwaltung, und SBOM Best Practices zeigt, wie sie gelingt.

Wie CRACI SBOMs erzeugt

CRACI ist ein GitHub-Actions-Runner, der jedes Paket aufzeichnet, das ein Job lädt, auf jeder Ebene des Baums und einschließlich der aus CI-Caches wiederhergestellten Pakete. Das Ergebnis ist eine SBOM des Builds, der das Release erzeugt hat, mit einem Vollständigkeitsstatus, der angibt, was der Job nicht sehen konnte. Sie lässt sich als CycloneDX oder SPDX exportieren, und CRACI bewertet sie laufend neu, sobald neue Schwachstellen veröffentlicht werden. Siehe SBOM-Generierung zur Build-Zeit.

SBOM: häufig gestellte Fragen

Was ist eine SBOM, einfach erklärt?

Eine SBOM ist eine Zutatenliste für Software. Sie nennt jede Komponente eines Produkts mit Version, Hersteller und Lizenz, in einem Format, das Maschinen lesen können.

Wofür steht SBOM?

SBOM steht für Software Bill of Materials, also Software-Stückliste.

Warum brauchen Sie eine SBOM?

Damit Sie schnell erkennen, ob eine neu veröffentlichte Schwachstelle das betrifft, was Sie ausliefern, Lizenzrisiken vor dem Release sehen und Kunden und Regulierungsbehörden antworten können, die wissen wollen, was in Ihrem Produkt steckt.

Was sind die beiden wichtigsten SBOM-Formate?

CycloneDX und SPDX. CycloneDX stammt von OWASP und kommt aus der Sicherheit. SPDX stammt von der Linux Foundation und kommt aus der Lizenz-Compliance. Beide können die Minimum Elements abbilden.

Ist eine SBOM gesetzlich vorgeschrieben?

Das hängt von Produkt und Markt ab. FDA Section 524B verlangt eine für Cyber Devices, und der EU Cyber Resilience Act verlangt von Herstellern eine. In der öffentlichen Beschaffung des US-Bundes entscheidet heute jede Behörde selbst. Für viele andere Unternehmen ist sie eher eine Kundenanforderung als eine gesetzliche.

Wie oft sollte eine SBOM aktualisiert werden?

Erzeugen Sie für jedes Release eine neue SBOM, denn jeder Build kann andere Versionen laden. Die SBOM eines Releases ändert sich danach nicht mehr, Sie sollten sie aber weiter mit neuen Schwachstellen abgleichen.

Wer erstellt die SBOM?

Meist das Team, das die Software baut, idealerweise im CI, sodass jedes Release automatisch eine erhält. Zugekaufte Software sollte mit einer SBOM des Lieferanten kommen.