SBOM nach CRA: Was Softwarehersteller wissen müssen
Der Cyber Resilience Act verpflichtet Hersteller, eine Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format zu erstellen, die mindestens die Top-Level-Abhängigkeiten des Produkts erfasst. Die SBOM ist Teil der technischen Dokumentation und muss nicht veröffentlicht werden.
Zuletzt aktualisiert:
Was der CRA verlangt
Anhang I Teil II Nr. 1 verlangt, dass Hersteller die Komponenten und Schwachstellen ihres Produkts identifizieren und dokumentieren – unter anderem durch eine SBOM. Sie gehört zur technischen Dokumentation nach Anhang VII und muss Marktüberwachungsbehörden auf begründetes Verlangen vorgelegt werden. Eine Pflicht zur Veröffentlichung besteht nicht; Sie können sie aber Nutzern zur Verfügung stellen.
Was eine SBOM enthält
- Name und Version jeder Komponente
- Hersteller bzw. Herkunft der Komponente
- eindeutige Kennungen, z. B. Package URL (purl) oder CPE
- Abhängigkeitsbeziehungen zwischen den Komponenten
- Lizenzinformationen und Hashwerte, soweit verfügbar
- Metadaten zur SBOM selbst: Ersteller, Zeitpunkt, Produktversion
Formate: CycloneDX und SPDX
Der CRA schreibt kein bestimmtes Format vor. Etabliert sind zwei offene Standards: CycloneDX (OWASP), stark auf Sicherheitsanwendungsfälle wie Schwachstellenabgleich ausgerichtet, und SPDX (Linux Foundation, ISO/IEC 5962), ursprünglich aus dem Lizenz-Compliance-Umfeld. Beide gelten als maschinenlesbar im Sinne des CRA.
Orientierung: BSI TR-03183-2
Die Technische Richtlinie TR-03183-2 des BSI beschreibt konkrete Anforderungen an SBOMs – Pflichtfelder, zulässige Formate, Tiefe der Abhängigkeiten. Sie ist nicht rechtsverbindlich, aber eine gute Orientierung, solange harmonisierte Normen (Stand September 2026) noch nicht im Amtsblatt zitiert sind.
SBOM in der CI aktuell halten
Eine SBOM ist nur so gut wie ihre Aktualität. Bewährt hat sich, sie bei jedem Build oder Release automatisch zu erzeugen, versioniert abzulegen und der ausgelieferten Produktversion eindeutig zuzuordnen. Manuell gepflegte Tabellen veralten mit dem nächsten Dependency-Update.
Von der SBOM zum Schwachstellenabgleich
Ihren eigentlichen Nutzen entfaltet die SBOM, wenn sie laufend mit Schwachstellendatenbanken abgeglichen wird. So sehen Sie bei einer neuen CVE sofort, welche Produkte und Versionen betroffen sind – eine Voraussetzung, um die CRA-Meldefristen einzuhalten und Schwachstellen unverzüglich zu beheben.
Wie Nuowei unterstützt
Nuowei erzeugt für jedes verbundene GitHub-Repository automatisch eine SBOM und hält sie bei Änderungen am Code aktuell. Die Komponenten werden kontinuierlich auf bekannte Schwachstellen (CVEs) und Auffälligkeiten in der Lieferkette geprüft; die Ergebnisse fließen in Ihre CRA-Nachweise ein.