CRA und SBOM: Software Bill of Materials richtig aufbauen und im Prozess nutzen

Eine Software Bill of Materials, kurz SBOM, ist für viele Software- und Gerätehersteller einer der praktisch wichtigsten Bausteine der CRA-Umsetzung. Sie schafft eine nachvollziehbare Übersicht darüber, welche Softwarekomponenten und Abhängigkeiten in einem Produkt stecken. Der eigentliche Nutzen entsteht aber erst, wenn die SBOM mit Versionen, Releases, Schwachstellenmeldungen und Verantwortlichkeiten verbunden wird.

Den übergeordneten Zusammenhang aus Pflichten, Fristen und Konformität erklärt der zentrale Leitfaden zum Cyber Resilience Act. Für die organisatorische Einordnung ist außerdem der Beitrag zu den CRA-Herstellerpflichten relevant.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was verlangt der CRA bei einer SBOM?

Der CRA verlangt, dass Hersteller die Komponenten ihrer Produkte identifizieren und dokumentieren. Dazu gehört eine Software Bill of Materials in einem gängigen und maschinenlesbaren Format. Diese Anforderung steht im Zusammenhang mit dem Schwachstellenmanagement: Hersteller sollen bei einer neu bekannt gewordenen Schwachstelle schnell feststellen können, ob eine betroffene Komponente in eigenen Produkten eingesetzt wird und welche Versionen betroffen sind.

Die Verordnung behandelt die SBOM damit nicht als reine Dokumentationspflicht. Sie ist ein Werkzeug, um Schwachstellen systematisch zu erkennen, zu bewerten und zu behandeln. Genau deshalb sollte sie nicht nur in einem Compliance-Ordner liegen, sondern mit dem technischen Produktprozess verbunden werden.

Das BSI konkretisiert die praktische Ausgestaltung in seiner Technischen Richtlinie TR-03183. Der Überblick zur Richtlinie und zu den einzelnen Teilen ist auf der BSI-Seite zur TR-03183 verfügbar.

Muss jede SBOM veröffentlicht werden?

Nein. Der CRA verlangt nicht, dass Hersteller ihre vollständige SBOM öffentlich ins Internet stellen. Die Stückliste muss intern so vorliegen, dass der Hersteller seine Pflichten erfüllen und die technische Dokumentation unterstützen kann. Je nach Produkt, Vertrag oder Lieferkette können Kunden oder Geschäftspartner zusätzliche SBOM-Anforderungen stellen. Das ist aber von der gesetzlichen Grundpflicht zu unterscheiden.

Diese Unterscheidung ist praktisch wichtig. Eine interne SBOM kann Informationen enthalten, die für die Schwachstellenbewertung notwendig sind, aber nicht ohne Prüfung veröffentlicht werden sollten. Unternehmen brauchen deshalb eine Regel, welche SBOM-Fassung intern geführt wird und welche Informationen gegebenenfalls an Kunden oder Prüfer herausgegeben werden.

Welche Informationen sollte eine CRA-taugliche SBOM enthalten?

Eine brauchbare SBOM muss Komponenten eindeutig identifizierbar machen. In der Praxis gehören mindestens der Name der Komponente, Version, Lieferant oder Ursprung, eindeutige Identifikatoren und Abhängigkeitsbeziehungen in die Daten. Entscheidend ist, dass ein Sicherheitsteam eine neu gemeldete Schwachstelle einem konkreten Produktbestandteil zuordnen kann.

Warum reicht der Paketname allein nicht?

Ein Paketname ohne Version ist für die Schwachstellenbewertung zu ungenau. Viele CVEs betreffen nur bestimmte Versionsbereiche. Wenn in der SBOM lediglich „OpenSSL“ oder „log4j“ steht, beantwortet sie die entscheidende Frage nicht: Ist genau die ausgelieferte Produktversion betroffen?

Deshalb sollten Produktversion, Komponentenfassung und Build-Bezug zusammenpassen. Bei einem Release 4.2.1 muss nachvollziehbar sein, welche SBOM zu genau diesem Release gehört. Wird später ein Hotfix 4.2.2 veröffentlicht, entsteht eine neue oder aktualisierte Stückliste.

Wie wichtig sind Abhängigkeitsbeziehungen?

Sehr wichtig. Moderne Software enthält direkte und transitive Abhängigkeiten. Eine Bibliothek kann also in einem Produkt stecken, obwohl sie nie bewusst vom eigenen Entwicklerteam ausgewählt wurde. Ohne Abhängigkeitsbeziehungen bleibt unklar, warum eine Komponente vorhanden ist und welches Paket sie einzieht.

Für die Praxis ist daher eine einfache Komponentenliste nur der Anfang. Je besser die Beziehungen zwischen Komponenten abgebildet werden, desto schneller lässt sich bei einer Schwachstelle feststellen, welche Anwendung, welches Modul und welcher Build betroffen sind.

Welches Format eignet sich für eine SBOM?

In der Praxis haben sich vor allem maschinenlesbare Formate wie SPDX und CycloneDX etabliert. Beide können für automatisierte Verarbeitung genutzt werden. Welches Format besser passt, hängt von Werkzeugkette, Kundenanforderungen und bereits vorhandenen Prozessen ab.

Für den CRA ist weniger entscheidend, welches Logo auf dem Format steht, sondern ob die Stückliste die benötigten Informationen zuverlässig liefert, automatisiert verarbeitet werden kann und in den Schwachstellenprozess eingebunden ist. Ein Formatwechsel löst keine Prozessprobleme.

SPDX oder CycloneDX – was ist besser?

Für viele Unternehmen ist nicht „besser“, sondern „passender“ die richtige Frage. SPDX wird häufig auch im Zusammenhang mit Lizenz- und Herkunftsinformationen genutzt. CycloneDX ist stark auf Software-Lieferkette und Sicherheitsinformationen ausgerichtet. Zahlreiche Tools können beide Formate erzeugen.

Wer noch keine Vorgabe hat, sollte zuerst prüfen, welche Ausgabe das eigene Build- und Scan-Werkzeug zuverlässig erzeugt und welches Format von Kunden, Prüfstellen oder bestehenden Sicherheitsplattformen unterstützt wird. Ein stabil automatisierter Prozess mit guter Datenqualität ist wertvoller als ein theoretisch bevorzugtes Format, das nur manuell gepflegt wird.

Wie wird eine SBOM im Entwicklungsprozess erzeugt?

Am zuverlässigsten entsteht die SBOM automatisiert in CI/CD oder Build-Pipeline. Dort steht fest, welche Komponenten tatsächlich in den Build einfließen. Die erzeugte Datei wird anschließend dem Release zugeordnet und unveränderbar archiviert.

1. Build identifizieren: Jeder produktive Build erhält eine eindeutige Versions- oder Build-ID.
2. Komponenten erfassen: Ein SBOM-Tool analysiert Paketmanager, Artefakte, Container oder Binärdateien.
3. Stückliste erzeugen: Die Ausgabe wird in einem definierten maschinenlesbaren Format gespeichert.
4. Qualität prüfen: Fehlende Versionen, unbekannte Komponenten und Dubletten werden erkannt.
5. Release verknüpfen: SBOM, Binärartefakt und Quellcode-Stand werden eindeutig zusammengeführt.
6. Archivieren: Die SBOM bleibt für die Lebensdauer des Produkts und den relevanten Supportzeitraum nachvollziehbar.

Bei Hardwareprodukten mit eingebetteter Software sollte derselbe Gedanke auf Firmware und mitgelieferte Software angewandt werden. Entscheidend ist die Sicht auf das ausgelieferte Gesamtprodukt, nicht nur auf das Hauptrepository.

Kann eine SBOM automatisch aus dem Quellcode erzeugt werden?

Ja, aber der Quellcode allein ist nicht immer die beste Quelle. Eine Analyse des Repositories zeigt, welche Abhängigkeiten deklariert sind. Sie beweist noch nicht zwingend, welche Komponenten tatsächlich im ausgelieferten Artefakt gelandet sind.

Bei Container-Images, Firmware, Desktop-Anwendungen oder gebündelten Paketen ist deshalb oft eine Kombination sinnvoll: Abhängigkeiten aus Paketmanagern erfassen und zusätzlich das finale Artefakt analysieren. Damit sinkt das Risiko, dass Build-Skripte, statisch eingebundene Bibliotheken oder nachgelagerte Packaging-Schritte unberücksichtigt bleiben.

Wie verbindet man die SBOM mit dem Schwachstellenmanagement?

Die SBOM wird dann wertvoll, wenn neue Schwachstellen automatisiert oder halbautomatisiert gegen die enthaltenen Komponenten geprüft werden. Das Unternehmen braucht dafür einen Prozess, der Sicherheitsinformationen sammelt, Treffer bewertet und betroffene Produktversionen identifiziert.

Was passiert bei einer neuen CVE?

Zuerst wird geprüft, ob die betroffene Komponente in einer aktiven Produktversion vorkommt. Danach folgt die technische Bewertung: Ist die verwundbare Funktion tatsächlich enthalten oder erreichbar? Gibt es eine Konfiguration, die das Risiko reduziert? Ist ein Patch verfügbar? Welche Kunden oder Geräte sind betroffen?

Die SBOM beantwortet also die Frage „Wo ist die Komponente?“. Die eigentliche Risikobewertung beantwortet „Ist unser Produkt konkret betroffen und wie schwer?“. Beide Schritte gehören zusammen.

Welche Rolle spielt VEX?

VEX-Dokumente können ergänzend festhalten, ob eine bekannte Schwachstelle ein konkretes Produkt tatsächlich betrifft. Das ist besonders hilfreich, wenn ein Scanner eine verwundbare Bibliotheksversion findet, der verwundbare Codepfad aber im eigenen Produkt nicht genutzt wird.

Eine SBOM ohne fachliche Bewertung kann sonst zu einer langen Liste scheinbarer Treffer führen. VEX ersetzt keine SBOM, kann aber das Schwachstellenmanagement deutlich präziser machen.

Wie häufig muss eine SBOM aktualisiert werden?

Mindestens bei jedem relevanten Produktrelease. Jede Änderung an Komponenten kann die Sicherheitslage verändern. Deshalb sollte die SBOM nicht nur einmal zu Projektbeginn erzeugt werden.

In einem gut automatisierten Prozess entsteht sie ohnehin bei jedem Build oder Release. Praktisch archiviert werden sollten vor allem die Stücklisten der ausgelieferten Versionen. So kann das Unternehmen Jahre später nachvollziehen, welche Bibliotheken in einem alten, noch unterstützten Release enthalten waren.

Gerade bei Produkten mit langem CRA-Supportzeitraum ist diese Historie wichtig. Eine neue Schwachstelle kann eine Produktversion betreffen, die vor Jahren ausgeliefert wurde, aber weiterhin sicherheitsrelevant gepflegt werden muss. Ohne archivierte SBOMs lässt sich die Betroffenheit dann oft nur mit erheblichem Aufwand rekonstruieren.

Wie tief sollte eine CRA-SBOM gehen?

Der CRA verlangt ausdrücklich mindestens die obersten Abhängigkeiten. Für die praktische Schwachstellenbehandlung kann es trotzdem sinnvoll sein, auch transitive Abhängigkeiten zu erfassen. Denn viele Sicherheitslücken liegen nicht in einer direkt eingebundenen Bibliothek, sondern in einer tieferen Komponente, die über ein Framework oder Paket in das Produkt gelangt.

Die passende Tiefe hängt vom Produkt und vom Risiko ab. Ein kleines Programm mit wenigen Abhängigkeiten kann vollständig überschaubar sein. Bei einer komplexen Plattform, einem Container-Stack oder einer Firmware mit zahlreichen Bibliotheken wäre eine reine Top-Level-Liste häufig zu grob, um neue Schwachstellen schnell zuzuordnen.

Ist mehr immer besser?

Nicht automatisch. Eine sehr tiefe SBOM bringt nur dann Nutzen, wenn die Daten zuverlässig identifiziert, aktualisiert und verarbeitet werden können. Tausende unklare oder falsch zugeordnete Komponenten erzeugen eher Fehlalarme. Ziel ist eine belastbare Stückliste, die das Security-Team tatsächlich für Entscheidungen nutzen kann.

Wie verbindet man SBOM und CRA-Risikobewertung?

Die SBOM beantwortet die Frage, welche Komponenten in einer konkreten Produktversion enthalten sind. Die CRA-Risikobewertung beantwortet dagegen, welche Auswirkungen eine Schwachstelle oder ein Angriffsszenario auf genau dieses Produkt haben kann.

Ein sinnvoller Prozess verbindet beide Ebenen. Wird in einer Bibliothek eine neue Schwachstelle bekannt, sucht das Team zuerst über die SBOM nach betroffenen Produktversionen. Danach wird geprüft, ob die verwundbare Funktion im Produkt genutzt wird, wie erreichbar sie ist, welche Schutzmechanismen existieren und welches Restrisiko bleibt. Das Ergebnis kann wiederum die Risikobewertung verändern.

Wie hilft eine SBOM bei den CRA-Meldepflichten?

Ab dem 11. September 2026 gelten die vorgezogenen Meldepflichten des CRA. Bei einer aktiv ausgenutzten Schwachstelle bleibt wenig Zeit für die erste Einordnung. Eine gepflegte SBOM verkürzt die Suche nach betroffenen Produkten und Versionen erheblich.

Sie entscheidet zwar nicht allein, ob ein Fall meldepflichtig ist. Sie liefert aber schnell die technische Ausgangslage für Incident Response, Security-Team und Produktverantwortliche. Der konkrete 24- und 72-Stunden-Prozess ist im Beitrag zu den CRA-Meldepflichten beschrieben.

Welche Nachweise sollten Unternehmen zur SBOM aufbewahren?

Neben den eigentlichen SBOM-Dateien sollten Hersteller dokumentieren, wie die Stücklisten erzeugt und geprüft werden. Dazu gehören verwendete Tools und Versionen, Build- oder Release-Bezug, Qualitätsprüfungen, Verantwortlichkeiten und gegebenenfalls bekannte Grenzen der Erfassung.

Für einen Prüfer sollte nachvollziehbar sein, dass die SBOM nicht zufällig entstanden ist, sondern Teil eines reproduzierbaren Prozesses ist. Das stärkt auch die CRA-Konformitätsbewertung, weil Komponentenmanagement, Risikobewertung und technische Dokumentation auf denselben Produktstand verweisen können.

Welche typischen Fehler machen Unternehmen bei SBOMs?

Eine Excel-Liste manuell pflegen

Für kleine Produkte kann eine Tabelle kurzfristig funktionieren. Bei regelmäßigen Releases, vielen Abhängigkeiten und mehreren Produkten wird sie schnell unzuverlässig. Manuelle Pflege erzeugt Lücken und passt oft nicht zum tatsächlichen Build.

Nur direkte Abhängigkeiten erfassen

Viele sicherheitsrelevante Komponenten kommen transitiv ins Produkt. Wer nur die erste Ebene dokumentiert, übersieht einen erheblichen Teil der Software-Lieferkette.

Keine Verbindung zum Release herstellen

Eine SBOM ohne eindeutigen Bezug zu Version und Build ist im Ernstfall schwer nutzbar. Genau diese Zuordnung sollte technisch erzwungen werden.

SBOM erzeugen, aber nicht überwachen

Eine Datei im Archiv meldet keine neue Schwachstelle. Unternehmen brauchen eine Verbindung zu Vulnerability Feeds, Scannern oder einem geregelten manuellen Monitoring. Sonst bleibt die Stückliste passiv.

Alte Produktversionen vergessen

Der CRA verlangt Schwachstellenbehandlung über den Supportzeitraum. Wer nur die neueste Version überwacht, kann unterstützte Altversionen übersehen.

Wie passt die SBOM in die technische Dokumentation?

Die technische Dokumentation soll nachvollziehbar machen, wie ein Produkt die CRA-Anforderungen erfüllt. Die SBOM ist dabei ein wichtiger Nachweis für Komponentenmanagement und Schwachstellenbehandlung. Sie sollte mit Risikobewertung, Testnachweisen, Versionsverwaltung und Maßnahmen zur Schwachstellenbehandlung zusammenpassen.

Das bedeutet nicht, dass jede Detaildatei in ein einziges Dokument kopiert werden muss. Sinnvoller ist ein strukturiertes Nachweissystem: Die technische Dokumentation verweist auf die freigegebene SBOM eines Releases, die ihrerseits unveränderbar gespeichert ist.

Wie startet ein kleines Unternehmen ohne bestehende SBOM?

Ein KMU muss nicht sofort eine komplexe Plattform einführen. Der sinnvollste Start ist ein einzelnes repräsentatives Produkt. Dort wird geprüft, welche Paketmanager und Build-Systeme genutzt werden, welches Tool die Komponenten zuverlässig erkennt und wie die Ausgabe mit der Release-Version verknüpft werden kann.

Danach folgt ein Test mit einer bekannten Schwachstelle: Kann das Team innerhalb kurzer Zeit feststellen, welche eigenen Versionen betroffen wären? Wenn diese Frage nicht zuverlässig beantwortet werden kann, fehlt noch ein Teil des Prozesses.

Welche nächsten Schritte sind sinnvoll?

Wer eine SBOM einführt, sollte sie direkt mit den übrigen CRA-Pflichten verbinden. Prüfen Sie zuerst, welche Produkte unter den CRA-Anwendungsbereich fallen. Danach gehören die Stücklisten in den Prozess für Herstellerpflichten und in den Ablauf für Schwachstellen- und Vorfallmeldungen. Für die Nachweisführung ist außerdem die Konformitätsbewertung relevant.