SBOM und SLSA: Herkunft von Software nachweisen

Begriffe vorab

• SBOM: Software Bill of Materials: maschinenlesbare Liste der Bestandteile einer Software.
• SPDX: Offenes SBOM-Format, standardisiert als ISO/IEC 5962:2021.
• CycloneDX: Weiteres verbreitetes SBOM-Format.
• Provenienz: Nachweis, wie, wo und aus welchem Quellcode ein Artefakt gebaut wurde.
• SLSA: Supply-chain Levels for Software Artifacts: Rahmen für abgesicherte Build-Prozesse.

Warum eine Stückliste?

Als Log4Shell bekannt wurde, lautete die erste Frage in vielen Organisationen: Setzen wir das ein, und wo? Eine SBOM beantwortet das, weil sie Bestandteile einer Software listet. Die US-Behörde NTIA beschrieb 2021 Mindestangaben: sieben Datenfelder – Lieferant, Komponentenname, Version, weitere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor der SBOM-Daten und Zeitstempel. Dazu kommen Anforderungen an Maschinenlesbarkeit und Abläufe (Häufigkeit, Tiefe, Verteilung).

Formate

Verbreitet sind SPDX (Version 2.2.1 wurde im August 2021 als ISO/IEC 5962:2021 veröffentlicht) und CycloneDX (ein Projekt der OWASP-Community). Moderne Werkzeuge erzeugen sie automatisch aus dem Build.

SLSA: Wie wurde gebaut?

SLSA („Salsa“) wurde von Google initiiert und wird von der OpenSSF betreut. Version 1.0 betrachtet den Build-Track mit den Stufen 0 bis 3:

• Stufe 1: Es gibt eine Provenienz, also einen Nachweis, wie das Artefakt gebaut wurde – noch unsigniert.
• Stufe 2: Die Provenienz ist signiert und stammt von einer dedizierten Build-Plattform; Manipulation nach dem Build ist erkennbar.
• Stufe 3: Die Build-Plattform ist so gehärtet, dass sich Builds nicht gegenseitig manipulieren können.

Nach Berichten wurde die Version 1.2 im November 2025 beschlossen und ergänzt einen Source-Track, der Quellhistorie und Schutz vor nachträglicher Manipulation behandelt.

Wie beides zusammenpasst

Die SBOM sagt was drinsteckt, SLSA sagt wie es entstanden ist. Zusammen helfen sie, nach einem Vorfall schnell zu klären, ob man betroffen ist, und im Vorfeld, Manipulationen im Build zu erschweren.

Beispiel

Ein Team erzeugt bei jedem Build automatisch eine SBOM und legt sie zusammen mit dem Release ab. Wird eine Schwachstelle in einer Bibliothek bekannt, durchsucht das Team die SBOMs aller Releases und kennt innerhalb von Minuten die betroffenen Produkte.

Fang klein an: eine automatisch erzeugte SBOM pro Release bringt bereits viel Nutzen.

Zum Selbermachen

1. Erzeuge für ein eigenes Projekt mit einem Werkzeug deiner Wahl eine SBOM im SPDX- oder CycloneDX-Format und sieh sie dir an.
2. Prüfe, ob dein Build-Prozess nachvollziehbar dokumentiert und reproduzierbar ist.

Verwandte Themen

Open Source → „Lehren aus Heartbleed und Log4Shell“. Lieferkette → „XZ Utils und CRA“ (der CRA verlangt Aufmerksamkeit für Komponenten). Normen → „NIST CSF 2.0“.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Die sieben Mindestdatenfelder der NTIA (2021), SPDX als ISO/IEC 5962:2021 (August 2021), CycloneDX als verbreitetes Format und die SLSA-Stufen 0 bis 3 der Version 1.0 wurden gegen NTIA und Fachquellen geprüft. Nicht einzeln belegt: die Zuordnung von CycloneDX zur OWASP-Community (verbreitete Angabe, hier nicht gegen die Primärseite geprüft), die Aussage zu SLSA 1.2 und dem Source-Track (nur Sekundärberichte) sowie das Beispiel (konstruiert).

Quellen

• NTIA – „The Minimum Elements For a Software Bill of Materials (SBOM)“ (Juli 2021)
• ISO/IEC 5962:2021 „Information technology — SPDX® Specification V2.2.1“
• CycloneDX – „Authoritative Guide to SBOM“ (cyclonedx.org)
• SLSA – Spezifikation (slsa.dev), betreut von der OpenSSF