Die SBOM: Stückliste für Ihre Software

Eine SBOM (Software Bill of Materials) ist die Stückliste Ihrer Software: welche Bibliotheken, Pakete und Programme in Ihrem Produkt stecken, in welcher Version. Der Cyber Resilience Act (CRA), offiziell Cyberresilienz-Verordnung, macht sie für Hersteller zur Pflicht. Sie muss maschinenlesbar sein und mindestens die obersten Abhängigkeiten abdecken; veröffentlichen müssen Sie sie nicht.

Ein Vergleich hilft: Auf einer Lebensmittelpackung steht die Zutatenliste. Die SBOM ist dasselbe für Firmware oder eine App, nur dass sie eine Maschine lesen kann, die sie dann mit Schwachstellendatenbanken abgleicht.

Was der CRA genau verlangt

Die Pflicht steht in Anhang I Teil II Nummer 1 der Verordnung (EU) 2024/2847. Hersteller ermitteln und dokumentieren die Schwachstellen und Komponenten ihres Produkts, „u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format“. Abgedeckt sein müssen mindestens die obersten Abhängigkeiten, also die Bauteile, die Ihr Produkt direkt einbindet.

Drei weitere Stellen gehören dazu:

Stelle	Was sie sagt
Anhang VII Nr. 2 Buchst. b	Die SBOM gehört zur technischen Dokumentation, als Teil Ihres Prozesses zur Schwachstellenbehandlung.
Anhang VII Nr. 8	Eine Marktüberwachungsbehörde kann die SBOM mit begründetem Antrag anfordern.
Anhang II Nr. 9	Entscheiden Sie sich, die SBOM Nutzern bereitzustellen, sagen Sie in der Nutzerinformation, wo sie zu finden ist.

Die SBOM bleibt also in der Regel intern. Sie zeigen sie der Behörde, wenn die fragt, und Kunden, wenn Sie wollen. Manche B2B-Kunden verlangen sie trotzdem im Vertrag.

Welches Format

Der CRA nennt kein Format. Artikel 13 Absatz 24 erlaubt der Kommission, Format und Inhalt per Durchführungsrechtsakt festzulegen; das ist noch nicht passiert. In der Praxis haben sich zwei offene Standards durchgesetzt:

• CycloneDX, ein Format der OWASP-Gemeinschaft, oft im Sicherheitsumfeld genutzt;
• SPDX, das auch Lizenzangaben genau abbildet.

Beide sind JSON- oder XML-Dateien. Die ENISA hat im Oktober 2026 eine technische Empfehlung zu SBOMs veröffentlicht, Version 1.10 (PDF bei der ENISA).

In Deutschland kommt die Technische Richtlinie BSI TR-03183-2 dazu. Sie ist nicht verbindlich, setzt aber strengere Regeln als der CRA, zum Beispiel Mindestversionen der Formate und Hashwerte für jede Datei. Was darin steht, erklärt der Ratgeber zur BSI TR-03183.

Was in eine gute SBOM gehört

Für jedes Bauteil mindestens:

• Name und exakte Version, also „openssl 3.0.13“ statt „OpenSSL 3“;
• wer es herstellt oder pflegt;
• eine eindeutige Kennung, etwa eine Package-URL (purl) oder CPE, damit Datenbanken das Bauteil sicher finden;
• die Abhängigkeiten zwischen den Bauteilen;
• die Lizenz.

Pro ausgelieferter Version gibt es eine eigene SBOM. Ändert ein Update auch nur eine Bibliothek, brauchen Sie eine neue Liste.

Wie Sie eine SBOM erstellen

Es gibt zwei Wege, und beide haben Grenzen.

Beim Bauen. Ihr Build-System, zum Beispiel Yocto oder Buildroot, kennt jedes Paket, das es in das Image packt. Viele Systeme können daraus direkt eine SBOM schreiben. Das ist der genaueste Weg, wenn Sie den ganzen Build selbst in der Hand haben.

Aus der fertigen Datei. Ein Werkzeug öffnet das Firmware-Image oder die App und sucht darin nach erkennbaren Bauteilen und Versionsangaben. Das hilft, wenn Teile vom Chiphersteller oder einem Zulieferer kommen und Sie den Build nicht kennen. Es findet aber nur, was die Datei verrät. Statisch eingebundener Code ohne Versionsangabe bleibt manchmal unsichtbar.

Viele Teams nutzen beides: die Build-SBOM als Grundlage und eine Prüfung der fertigen Datei als Gegenprobe. Abweichungen zeigen oft genau die Bauteile, die jemand vergessen hat.

Was eine SBOM nicht ist

Eine SBOM sagt nicht, ob Ihr Produkt sicher ist. Sie sagt, was drinsteckt. Ob eine bekannte Schwachstelle in einer Bibliothek Ihr Gerät wirklich angreifbar macht, hängt davon ab, wie Sie die Bibliothek nutzen. Diese Bewertung bleibt Ihre Aufgabe.

Und eine SBOM ist nie fertig. Neue Schwachstellen erscheinen jeden Tag für Bauteile, die gestern noch unauffällig waren. Darum ist der Abgleich wichtiger als die Datei selbst.

Was Proofsheet hier erstellt

Sie laden eine Datei hoch: ein Firmware-Image (gzip, tar, zip, cpio oder MBR-Partitionen), eine Android-App, ein Windows-, Linux- oder Apple-Programm, JavaScript, WebAssembly oder ein ZIP-Archiv. Die Web-App Proofsheet listet die Bauteile und Versionen automatisch auf, soweit die Datei sie zeigt, und erzeugt die Stückliste als CycloneDX 1.5 und SPDX 2.3. Exakte Versionen gleicht die App mit der NVD ab; Treffer, die nur auf eine Versionsfamilie passen, kennzeichnet sie als solche.

Verschlüsselte Firmware kann die App nicht öffnen. Dann sagt der Bericht das, und Sie zahlen nichts. Kein Mensch sieht sich Ihre Datei an, und sie wird innerhalb von 24 Stunden gelöscht.

Proofsheet liefert technische Nachweise, kein rechtliches Zertifikat. Ein erster Bericht mit den drei größten Risiken ist kostenlos: Kostenlosen Bericht erstellen. Weiter lesen: BSI TR-03183 und technische Dokumentation.