Was ist eine SBOM und was verlangt der Cyber Resilience Act?

Was ist eine SBOM und wie definiert sie der CRA?

Eine SBOM (Software Bill of Materials, auf Deutsch Software-Stückliste) ist ein maschinenlesbares Verzeichnis aller Komponenten, aus denen ein Produkt besteht, samt ihrer Versionen und Abhängigkeiten – sozusagen die Zutatenliste der Software. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) definiert die Software-Stückliste als „formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“ (Art. 3 Nr. 39).

Eine Komponente kann ein eigenes Modul sein, eine Bibliothek eines Drittanbieters, ein Open-Source-Paket oder Firmware eines Zulieferers. Die Stückliste beschreibt dabei genau eine Produktversion: Sie listet, was in dieser Version steckt, nicht welche Schwachstellen darin bekannt sind. Die Version ändert sich nicht, während Informationen über Schwachstellen täglich hinzukommen.

Was verlangt der CRA genau von einer SBOM?

Die Anforderung steht in Anhang I Teil II Nummer 1. Danach müssen Hersteller „die Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Aus diesem einen Satz ergeben sich drei Bedingungen:

• Gängiges Format. Die Verordnung nennt kein bestimmtes Format. Die Kommission kann es per Durchführungsrechtsakt festlegen und dabei europäische oder internationale Normen berücksichtigen (Art. 13 Abs. 24). Üblich sind SPDX und CycloneDX.
• Maschinenlesbar. Die Stückliste muss ein Programm einlesen können, nicht nur ein Mensch. Eine Bibliotheksliste in PDF oder Word erfüllt die Bedingung nicht.
• Mindestens die obersten Abhängigkeiten. Gemeint sind die direkten Abhängigkeiten – die Komponenten, auf denen Ihr Produkt unmittelbar aufbaut. Tiefer liegende, indirekte Abhängigkeiten verlangt der CRA als Mindestumfang nicht; in der Praxis brauchen Sie sie aber oft trotzdem.

Die SBOM ist nur eine von mehreren Pflichten aus Anhang I. Ob der CRA Ihr Produkt überhaupt betrifft und welches Konformitätsbewertungsverfahren gilt, klären Sie kostenlos im CRA-Produktcheck.

SPDX oder CycloneDX – welches Format braucht der CRA?

Beide Formate erfüllen die CRA-Anforderung; die Verordnung bevorzugt keines. SPDX und CycloneDX sind offene, weit verbreitete Standards, die Ihre Build-Werkzeuge in der Regel automatisch erzeugen.

Als Orientierung dient in Deutschland die Technische Richtlinie BSI TR-03183-2 „Software Bill of Materials (SBOM)“ in der Version 2.1.0. Sie beschreibt, welche Datenfelder eine SBOM enthalten sollte, und bildet diese Felder auf SPDX und CycloneDX ab. Die Richtlinie ist freiwillig: Sie ist nicht verpflichtend und begründet keine Konformitätsvermutung, soll aber auf die Anforderungen des CRA vorbereiten. Der CRA selbst verweist nicht auf sie.

Wählen Sie das Format, das Ihre Build-Werkzeuge erzeugen und Ihre Abnehmer einlesen können. Entscheidend ist weniger die Wahl zwischen SPDX und CycloneDX als dass die SBOM bei jedem Build automatisch entsteht und nicht von Hand gepflegt wird.

Ab wann gilt die SBOM-Pflicht nach dem CRA?

Verpflichtend ab dem 11. Dezember 2027, und zwar für Produkte, die ab diesem Tag in Verkehr gebracht werden (Art. 71 Abs. 2). Ein Produkt, das vorher in Verkehr gebracht wurde, muss die Anforderungen aus Anhang I – und damit die SBOM – erst dann erfüllen, wenn es danach einer wesentlichen Änderung unterliegt (Art. 69 Abs. 2).

Praktisch heißt das: Die SBOM-Pflicht aus Anhang I greift erst Ende 2027. Die Meldepflicht nach Art. 14 gilt aber schon seit dem 11. September 2026, auch für längst verkaufte Produkte (Art. 69 Abs. 3). Dafür brauchen Sie die SBOM faktisch bereits heute.

Muss ich die SBOM veröffentlichen?

Nein. Nach Erwägungsgrund 77 des CRA sollen Hersteller nicht verpflichtet sein, die Software-Stückliste zu veröffentlichen. Die SBOM ist Teil der technischen Dokumentation, die Sie zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufbewahren, je nachdem, welcher Zeitraum länger ist (Art. 13 Abs. 13).

• Der Marktüberwachungsbehörde legen Sie die technische Dokumentation auf Verlangen vor, damit sie die Konformität mit Anhang I prüfen kann.
• Ihren Nutzern geben Sie die Stückliste nur, wenn Sie sich selbst dafür entscheiden.

Liefern Sie eine Komponente, die ein Kunde in sein eigenes Produkt einbaut, meldet dieser auch Schwachstellen in Ihrer Komponente und muss dafür wissen, was darin steckt. Rechnen Sie damit, dass er die Stückliste anfragt.

Wozu brauche ich die SBOM in der Praxis?

Vor allem, um schnell zu beantworten, wo eine verwundbare Komponente steckt. Taucht die Meldung einer aktiv ausgenutzten Schwachstelle in einer verbreiteten Bibliothek auf, müssen Sie wissen, welche Versionen welcher Produkte sie enthalten. Mit einer SBOM je Release beantworten Sie das mit einer Abfrage; ohne sie durchsuchen Sie Repositorys und Builds von Hand.

Daran hängt die Meldepflicht nach Art. 14: eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden, nachdem Sie Kenntnis erlangt haben (Art. 14 Abs. 2). Wie wir den Meldeablauf aufsetzen, steht auf der Seite CRA-Meldepflicht; dort finden Sie auch 30 Tage CVE-Überwachung kostenlos, die mit Ihrer SBOM läuft.

Häufige Fragen

Reicht eine SBOM mit nur den obersten Abhängigkeiten?

Als Mindestumfang nach Anhang I ja. Für die Meldepflicht nach Art. 14 reicht sie aber oft nicht: Eine aktiv ausgenutzte Schwachstelle kann in einer indirekten, tiefer liegenden Abhängigkeit stecken, die eine einstufige Stückliste nicht zeigt. Wir empfehlen deshalb, den vollständigen Abhängigkeitsbaum zu erzeugen.

Gehören Entwicklungs- und Test-Bibliotheken in die SBOM?

Wenn Sie sie nicht mit dem Produkt ausliefern, nein. Der CRA verlangt, die im Produkt enthaltenen Komponenten zu dokumentieren. Werkzeuge, die nur beim Bauen oder Testen gebraucht und nicht mitgeliefert werden, zählen nicht dazu.

Erstellt ein Werkzeug die SBOM von allein?

Aus Manifesten und Lock-Dateien die meisten Komponenten ja. Was in keinem Manifest steht, sieht es aber nicht: kopierten Quellcode, mitgelieferte Binärbibliotheken oder Firmware eines Zulieferers. Das ergänzen Sie von Hand oder durch Analyse des fertigen Builds und prüfen die SBOM anschließend gegen das Schema des Formats.

Was droht, wenn die SBOM fehlt?

Bei einem ab dem 11. Dezember 2027 in Verkehr gebrachten Produkt ist es ein Verstoß gegen Anhang I. Für Verstöße gegen die Anforderungen aus Anhang I und die Pflichten aus Art. 13 und 14 drohen Geldbußen bis zu 15 Mio. € oder 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2).