SBOM: Die Stückliste, die im Ernstfall Stunden spart

Inhaltsverzeichnis

Eine SBOM ist eine Stückliste für Software: eine maschinenlesbare Aufstellung aller Bestandteile, aus denen ein Produkt zusammengesetzt ist. Klingt nach Bürokratie, ist aber die Antwort auf eine sehr praktische Frage – wenn morgen eine Lücke in einer verbreiteten Bibliothek bekannt wird, könnt ihr dann in Minuten sagen, ob ihr betroffen seid, oder braucht ihr dafür zwei Tage? Seit dem 11. September 2026 hängt an dieser Frage auch eine Frist. Stand: 10. September 2026.

Was drinsteht

SBOM steht für Software Bill of Materials. Der Begriff kommt aus der Fertigung: Dort listet die Stückliste jedes Teil, das in ein Produkt eingebaut wird, mit Hersteller und Version. Bei Software ist der Gedanke derselbe, nur ist die Fertigungstiefe größer – moderne Anwendungen bestehen zum überwiegenden Teil aus fremdem Code.

AngabeWofür sie gebraucht wird
Name der KomponenteZuordnung zu Schwachstellenmeldungen
Versionder eigentliche Kern – Lücken betreffen fast immer Versionsbereiche
Hersteller oder HerkunftUnterscheidung gleichnamiger Pakete verschiedener Quellen
Eindeutige Kennungmaschineller Abgleich ohne Ratespiele bei Schreibweisen
Abhängigkeitsbeziehungzeigt, ob eine Komponente direkt oder über eine andere hereinkommt
Lizenzrechtliche Prüfung, nicht sicherheitsrelevant, aber meist gleich mit erfasst

Die letzte Zeile ist der Grund, warum viele Betriebe schon eine halbe SBOM haben, ohne es zu wissen: Wer aus Lizenzgründen erfasst, was er einsetzt, hat den mühsamen Teil hinter sich. Zur Sicherheitsprüfung fehlen dann meist nur noch die genauen Versionen.

Warum das jetzt Thema wird

Zwei Dinge treffen zusammen: die Fertigungstiefe und eine neue Frist.

Infografik: Nach Kenntnis einer Schwachstelle laufen 24 Stunden. Ohne Stückliste dauert die Frage, ob man betroffen ist, zwei Tage Recherche und reißt die Frist; mit Stückliste ist es eine Abfrage von Minuten. Der CRA verlangt eine maschinenlesbare Stückliste mit mindestens den obersten Abhängigkeiten, Vorlage auf Verlangen, Pflicht ab 11. Dezember 2027.
Eine Meldung geht ein. Ohne Stückliste ist die Frage nach der Betroffenheit eine Recherche von Tagen, mit Stückliste eine Abfrage von Minuten.

Die gestrichelte Linie ist der Punkt. Die 24-Stunden-Frist aus Artikel 14 des Cyber Resilience Act beginnt, sobald der Hersteller Kenntnis erlangt – nicht, sobald er seine Betroffenheit geklärt hat. Wer zwei Tage braucht, um die Frage zu beantworten, hat die Frist bereits gerissen, bevor er weiß, ob er etwas zu melden hatte. Die Details der Fristen stehen im Guide Cyber Resilience Act.

Dazu kommt die Lieferkette. Betriebe, die unter NIS2 fallen, müssen die Sicherheit ihrer Zulieferer berücksichtigen – und geben diese Anforderung als Fragebogen weiter, siehe der Guide NIS2. Für kleine Softwarehäuser kommt die SBOM-Pflicht deshalb oft nicht vom Gesetzgeber, sondern vom größten Kunden.

Was der CRA tatsächlich verlangt

Anhang I Teil II Nummer 1 verlangt von Herstellern, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch Erstellung einer Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Das ist weniger, als viele befürchten: keine Aufschlüsselung bis in die letzte verschachtelte Ebene. Veröffentlichen muss sie niemand – die Verordnung hält ausdrücklich fest, dass Hersteller dazu nicht verpflichtet sein sollen; vorzulegen ist sie auf begründetes Verlangen der Marktüberwachungsbehörde. Die Anforderung gilt mit der vollen Anwendung ab dem 11. Dezember 2027, nicht schon jetzt.

Die zwei Formate

Es haben sich zwei maschinenlesbare Formate durchgesetzt. Die Entscheidung dazwischen ist selten wichtig, weil sich Werkzeuge in der Regel in beide Richtungen exportieren lassen.

CycloneDXSPDX
HerkunftOWASP-Umfeld, aus der SicherheitseckeLinux Foundation, aus der Lizenzecke
StärkeSchwachstellen und RisikoLizenzen und Herkunft
Typischer EinsatzSicherheitsprozesse, MeldekettenCompliance, Rechtsabteilung
PraktischNimm das Format, das dein größter Kunde verlangt. Wenn keiner etwas verlangt, nimm das, was deine Werkzeuge ohnehin erzeugen.

Wie ihr anfangt, ohne ein Projekt daraus zu machen

Der häufigste Fehler ist, SBOM als Einführungsvorhaben zu behandeln. Es ist ein Nebenprodukt des Bauprozesses. Wenn es das nicht ist, veraltet die Liste schneller, als sie gepflegt werden kann.

  1. Für ein einziges Produkt eine Liste erzeugen. Gängige Werkzeuge lesen ein Projektverzeichnis und schreiben eine Stückliste heraus. Das ist ein Nachmittag, kein Quartal. Das Ergebnis ist meistens ernüchternd lang – genau das ist die Erkenntnis.
  2. Die Erzeugung in den Bauprozess hängen. Bei jedem Bau entsteht die Liste neu und wird zusammen mit dem Ergebnis abgelegt. Eine handgepflegte Liste ist nach vier Wochen falsch, und eine falsche Liste ist gefährlicher als keine, weil man sich auf sie verlässt.
  3. Die Listen zentral ablegen, versioniert. Entscheidend ist, dass ihr auch für eine Version von vor zwei Jahren nachsehen könnt, die bei einem Kunden noch läuft. Genau danach wird im Ernstfall gefragt.
  4. Einmal den Ernstfall proben. Nimm eine bekannte Schwachstelle aus den letzten Monaten und miss die Zeit, bis ihr sagen könnt, welche eurer Produkte betroffen sind. Diese eine Zahl sagt mehr über eure Bereitschaft als jede Richtlinie – und sie ist das Einzige, was im Ernstfall zählt.

Was eine SBOM nicht leistet

Hier ist Ehrlichkeit nötig, weil das Thema gern überverkauft wird.

Sie macht nichts sicherer. Eine Stückliste beschreibt den Zustand, sie verbessert ihn nicht. Wer eine SBOM erzeugt und nie gegen Schwachstellendatenbanken abgleicht, hat eine Datei erzeugt, sonst nichts.

Sie sagt nicht, ob ihr verwundbar seid. Sie sagt, dass eine Komponente enthalten ist. Ob die betroffene Funktion in eurem Produkt überhaupt erreichbar ist, steht auf einem anderen Blatt – dafür gibt es ergänzende Angaben zur Ausnutzbarkeit.

Sie erfasst nicht alles. Was zur Laufzeit nachgeladen wird, was im Container-Grundsystem steckt oder was über eine fremde Schnittstelle hereinkommt, taucht in einer Standard-Stückliste oft nicht auf.

Trotzdem bleibt sie die Grundlage. Man kann nicht absichern, was man nicht kennt – und der Nutzen zeigt sich nicht am Tag, an dem man sie erstellt, sondern an dem, an dem eine Meldung hereinkommt.

Häufige Fragen

Was ist eine SBOM?

Eine Software Bill of Materials, also eine maschinenlesbare Stückliste aller Komponenten eines Softwareprodukts, mit Name, Version, Herkunft und Abhängigkeitsbeziehungen. Sie beantwortet die Frage, woraus ein Produkt zusammengesetzt ist.

Verlangt der Cyber Resilience Act eine SBOM?

Ja. Anhang I Teil II verlangt eine Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Sie ist auf begründetes Verlangen der Marktüberwachungsbehörde vorzulegen, muss aber nicht veröffentlicht werden. Die Anforderung gilt ab dem 11. Dezember 2027.

Welches Format soll ich nehmen, CycloneDX oder SPDX?

Beide sind etabliert. CycloneDX kommt aus dem Sicherheitsumfeld, SPDX aus dem Lizenzumfeld; die meisten Werkzeuge exportieren in beide Richtungen. Praktisch entscheidet, was der größte Kunde verlangt oder was die vorhandenen Werkzeuge ohnehin erzeugen.

Muss ich meine SBOM veröffentlichen?

Nein. Nach dem CRA muss sie den Marktüberwachungsbehörden auf Verlangen zugänglich gemacht werden. Kunden können eine Herausgabe vertraglich verlangen, das ist aber eine Frage der Vereinbarung, nicht des Gesetzes.

Wie aufwendig ist die Erstellung?

Für ein einzelnes Produkt mit gängigen Werkzeugen überschaubar, oft ein Nachmittag. Der Aufwand liegt nicht im ersten Erstellen, sondern im Aktuellhalten – deshalb sollte die Liste automatisch bei jedem Bauvorgang entstehen.

Macht eine SBOM meine Software sicherer?

Nicht für sich genommen. Sie beschreibt den Zustand und ist die Voraussetzung dafür, bei einer Schwachstellenmeldung schnell zu prüfen, ob man betroffen ist. Ohne regelmäßigen Abgleich mit Schwachstellendatenbanken bleibt sie eine Datei ohne Wirkung.

Werkzeuge sind schnell aufgesetzt, Prozesse nicht

Eine Stückliste erzeugt ein Werkzeug in Minuten. Dass jemand sie im Ernstfall liest, richtig deutet und daraus die Meldeentscheidung ableitet, ist eine Frage der Qualifikation. Im kostenlosen Erstgespräch schauen wir auf euren tatsächlichen Stand und ob die Kosten über Förderprogramme ganz oder teilweise übernommen werden können.

Kostenloses Erstgespräch sichern
Benedikt Backhaus, schreibt bei Scaly über KI-Tools und neue Modelle

Benedikt Backhaus – schreibt bei Scaly über KI-Tools, neue Modelle und aktuelle Entwicklungen rund um künstliche Intelligenz. Preise und Funktionsangaben prüft er an den Seiten der Anbieter, nicht an Vergleichsportalen – Stand jeweils im Text. Einschätzung, keine Rechtsberatung. Benedikt auf LinkedIn

Diesen Artikel Teilen:

Über den Autor

Bild von Benedikt Backhaus

Benedikt Backhaus

Benedikt Backhaus schreibt bei Scaly über KI-Tools, neue Modelle und aktuelle Entwicklungen rund um künstliche Intelligenz. Er verfolgt die KI-Szene laufend und ordnet ein, was neue Releases praktisch bedeuten — für Lernende, Arbeitsuchende und Unternehmen. Ehrlich, mit Quellen und ohne Hype.

Diese Artikel könnten Sie auch interessieren

Qwen 3.8: Alibabas Open-Source-Offensive – und was sie für dich bedeutet

Qwen 3.8: Alibabas Open-Source-Offensive – und was sie für dich bedeutet

AI Act seit August 2026: Was jetzt wirklich gilt – und was verschoben wurde

AI Act seit August 2026: Was jetzt wirklich gilt – und was verschoben wurde

Open-Source-KI 2026: Welches offene Modell wofür?

Open-Source-KI 2026: Welches offene Modell wofür?