Eine SBOM erstellen: Die Stückliste hilft erst mit einem Arbeitsablauf

Wer eine SBOM erstellen will, braucht mehr als eine einmal exportierte Datei. Ein belastbarer Ablauf erzeugt für jedes Release eine maschinenlesbare Komponentenliste im Build, validiert sie, bindet sie eindeutig an das ausgelieferte Artefakt und übergibt sie an das Schwachstellenmanagement.

SPDX oder CycloneDX strukturieren die Daten, bewirken für sich genommen aber noch keinen Sicherheitsgewinn. Entscheidend sind identifizierbare Komponenten und Abhängigkeiten, ein festgelegter Aktualisierungszeitpunkt, eine gegen unbemerkte Änderungen geschützte Ablage und eine verantwortliche Stelle, die Warnungen bewertet.

1. Inhalt und Bezugsobjekt festlegen

Eine SBOM ist ein verschachteltes Inventar der Bestandteile einer Softwareanwendung oder eines Systems. Die gemeinsame Behördenleitlinie zu den Mindestelementen fordert von entwickelnden, beschaffenden und betreibenden Organisationen erwartete Mindestdaten sowie Praktiken und Prozesse für Erzeugung und Nutzung.

Zuerst muss feststehen, welches auslieferbare Objekt die Liste beschreibt: etwa ein Container-Image, Installationspaket oder eine Firmware. Ein praxistaugliches internes Mindestprofil sollte das Produkt und seine Release-Version, die enthaltenen Komponenten mit Version und Produzent, eindeutige Kennungen sowie die Beziehungen zwischen direkten und transitiven Abhängigkeiten erfassen. Hashwerte, Lizenzangaben, Erzeugungswerkzeug und dokumentierte Erfassungslücken verbessern die Nachvollziehbarkeit.

Ein bewusst formatsneutrales Beispielschema dient als Checkliste:

• Dokument: Autor, Erzeugungszeitpunkt, Werkzeug, Formatversion und Dokument-ID
• Produkt: Name, Release-Version, Produkt-ID und Hash des Artefakts
• Komponente: Name, Version, Produzent, Paketkennung wie purl oder CPE, Hash und Lizenz
• Beziehung: Zuordnung zum Produkt und Abhängigkeiten zwischen Komponenten
• Abdeckung: untersuchte Quellen und bekannte Lücken

Das ist kein gültiges SPDX- oder CycloneDX-Dokument. Die tatsächliche SBOM muss das Schema der vereinbarten Spezifikationsversion erfüllen; optionale Felder werden erst dann betriebliche Pflicht, wenn Vertrag oder interner Prozess sie verlangt.

2. Das Format vom Folgeprozess her wählen

Die Formatentscheidung beginnt beim empfangenden System. Zu prüfen ist, welches Format der Generator vollständig ausgibt, das Repository validieren kann und das Analysewerkzeug ohne verlustreiche Konvertierung verarbeitet. Ein verbindliches Austauschformat samt Spezifikationsversion ist meist robuster als zwei parallel gepflegte Varianten.

Das NIST nennt SPDX, CycloneDX und SWID als maschinenlesbare Formate. Es empfiehlt außerdem zugängliche Repositories mit digital signierten SBOMs und deren Verbindung mit automatisierter Schwachstellenerkennung. Zugleich warnt die Behörde: Wer die Daten nicht einlesen, analysieren und in Maßnahmen übersetzen kann, verbessert damit voraussichtlich nicht sein Lieferkettenrisikomanagement; die SBOM ergänzt bestehende Risiko- und Schwachstellenprozesse, statt sie zu ersetzen.

Für typische Build-SBOMs sind SPDX und CycloneDX daher Kandidaten, keine automatische Antwort. Entscheidend ist der vollständige Pfad vom Generator bis zur Auswertung. Ein zusätzliches Format lohnt sich nur, wenn ein Vertragspartner oder Zielsystem es tatsächlich benötigt.

3. Erzeugung und Release in der Pipeline verbinden

Das zuverlässigste Muster erzeugt Artefakt und SBOM im selben Pipeline-Lauf. Eine nachträgliche Binäranalyse kann bei Altsoftware eine Ersatzliste liefern, erfasst aber nicht zwingend dieselben Abhängigkeiten wie der ursprüngliche Build.

1. Abhängigkeiten auflösen und Versionen sperren, soweit das Build-System dies unterstützt.
2. Das Release-Artefakt erzeugen und seinen kryptografischen Hash berechnen.
3. Direkte und transitive Komponenten im selben Lauf erfassen.
4. Die SBOM gegen die festgelegte Formatversion validieren.
5. Qualitätsregeln anwenden: fehlende Versionen, ungültige Paketkennungen, Komponenten ohne Beziehung und unerklärte Erfassungslücken.
6. Artefakt, SBOM, Validierungsprotokoll und Signatur oder Attestierung gemeinsam veröffentlichen.

Ähnliche Dateinamen genügen nicht als Zuordnung. Release-ID, Artefakt-Hash und Dokument-ID sollten so referenziert werden, dass später genau die Stückliste des ausgelieferten Binärstands auffindbar ist. Eine neue SBOM ist nötig, wenn ein neues Release entsteht, sich enthaltene Komponenten ändern oder ein Neuaufbau andere Abhängigkeiten einzieht.

Alte Fassungen dürfen dabei nicht überschrieben werden. Sie werden zusammen mit Signatur, Prüfergebnis und Release-Zuordnung mindestens so lange aufbewahrt, wie die zugehörige Produktversion unterstützt oder noch betrieben wird. Diese Dauer ist eine betriebliche Empfehlung und muss an Produktlebenszyklus sowie vertragliche Pflichten angepasst werden.

4. Lieferanten-SBOMs kontrolliert übernehmen

Bei eingehenden SBOMs reicht die Prüfung auf das Vorhandensein einer Datei nicht aus. Beschaffung und Produktsicherheit müssen feststellen, ob das Dokument zum gelieferten Stand gehört, automatisiert verarbeitet werden kann und verwertbare Komponentenidentitäten enthält.

• Ist das Dokument im vertraglich vereinbarten Format und gegen dessen Schema valide?
• Stimmen Produktname, Version und ein vorhandener Artefakt-Hash mit der Lieferung überein?
• Besitzen Komponenten Versionen, Produzentenangaben und geeignete Kennungen?
• Sind direkte und transitive Beziehungen sowie bekannte Erfassungslücken ausgewiesen?
• Sind Autor, Erzeugungszeitpunkt und Werkzeug nachvollziehbar?
• Lässt sich eine Signatur oder Attestierung mit dem vereinbarten Vertrauensanker prüfen?
• Regelt der Vertrag Korrekturen und neue SBOMs für aktualisierte Produktversionen?

Abweichungen sollten als strukturierter Befund an den Lieferanten zurückgehen. Eine intern durch Binäranalyse erzeugte Liste kann fehlende Transparenz teilweise ausgleichen, ist aber keine Herstellererklärung und sollte als eigener Befund gekennzeichnet bleiben.

5. Aus dem Inventar einen Warnprozess machen

Nach der Veröffentlichung beginnt die laufende Nutzung. Das Repository ordnet eingesetzte Produktversionen ihren SBOMs zu, gleicht die Komponentenkennungen mit Schwachstellenmeldungen ab und eröffnet bei einem Treffer einen bewertbaren Vorgang. Eine abgelegte Datei ohne diesen Kreislauf bleibt eine Momentaufnahme.

Ein CVE-Treffer belegt zunächst nur, dass eine gemeldete Schwachstelle zu einer erkannten Komponente passen könnte. Die CycloneDX-Dokumentation zu VEX beschreibt eine maschinenlesbare Übermittlung des Ausnutzbarkeitsstatus im jeweiligen Produktkontext. Für die Bewertung zählen deshalb die konkrete Produktversion, die Verwendung der betroffenen Funktion, Konfiguration, Erreichbarkeit und belastbare Angaben des Herstellers.

Die Zuständigkeiten müssen den gesamten Weg abdecken: Entwicklung verantwortet Abhängigkeiten und bekannte Erfassungslücken, das Build- oder Plattformteam Generator und Validierung, Release Management die Artefaktzuordnung, Product Security die Bewertung neuer Treffer und der Betrieb die tatsächlich eingesetzten Versionen. Die Beschaffung legt für Fremdsoftware Format, Lieferweg, Aktualisierung und Korrekturpflicht fest.

Eine Freigabe sollte scheitern, wenn die SBOM ungültig ist, nicht eindeutig zum Artefakt gehört oder vereinbarte Pflichtfelder ohne dokumentierte Ausnahme fehlen. Jeder Schwachstellentreffer erhält einen Verantwortlichen, eine Frist und einen Status; ein korrigiertes Release wiederum ein neues Artefakt und eine neue SBOM. Erst dieser wiederholbare Ablauf macht die Stückliste für Sicherheitsentscheidungen nutzbar.

Lesen Sie auch:

• KB5120998 bringt die bewegliche Taskleiste – und neue Darstellungsfehler
• KI-Inhalte kennzeichnen: Vier Fälle entscheiden über die Pflicht
• QScan und QTRouter abgeschaltet: Die Einbrüche reichen bis NASA und Fed