Was ist eine SBOM und was muss sie enthalten?

Was in einer SBOM steht

Für jede Komponente beschreibt eine SBOM, was sie ist und woher sie kommt. Als Untergrenze gelten die sieben Mindestelemente der US-Behörde NTIA; die deutsche Technische Richtlinie BSI TR-03183-2 geht darüber hinaus, etwa mit Lizenzangaben und kryptografischen Hashwerten.

• Name und Version der Komponente
• Lieferant oder Herkunft
• eindeutige Kennung, zum Beispiel ein Package-URL (purl)
• Abhängigkeitsbeziehungen
• Lizenzangaben
• Hashwerte zur Identifikation der Artefakte
• Ersteller und Zeitstempel der SBOM

SPDX und CycloneDX

Zwei Formate haben sich durchgesetzt: SPDX, als ISO/IEC 5962 standardisiert, und CycloneDX, als ECMA-424 standardisiert. Beide sind maschinenlesbar und werden von gängigen Werkzeugen erzeugt. Die BSI TR-03183-2 nennt in Version 2.1.0 als Mindestversionen CycloneDX 1.6 und SPDX 3.0.1.

Tiefe und Aussagekraft

Eine SBOM ist nur so gut wie ihre Abdeckung. Entscheidend ist, aus welcher Quelle sie erzeugt wurde (Quellcode, Build-System oder fertiges Binärartefakt), ob transitive Abhängigkeiten enthalten sind und ob sie zum ausgelieferten Release passt. Eine SBOM, die nicht zum Release gehört, beantwortet die entscheidende Frage nicht.

• eine SBOM je ausgeliefertem Release, nicht je Repository
• Erzeugung automatisiert im Build, nicht von Hand
• bekannte Lücken dokumentieren, etwa statisch gelinkte oder kopierte Komponenten

Was der Cyber Resilience Act verlangt

Nach Anhang I Teil II Nr. 1 der Verordnung (EU) 2024/2847 müssen Hersteller Komponenten ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten abdeckt. Die SBOM ist Teil der technischen Dokumentation; sie muss nicht veröffentlicht, aber Marktüberwachungsbehörden auf begründetes Verlangen vorgelegt werden. Die Anforderungen gelten vollständig ab dem 11. Dezember 2027.