SBOM-Pflicht im Cyber Resilience Act: was Hersteller jetzt aufbauen müssen

Wer Produkte mit digitalen Elementen in der EU in Verkehr bringt, muss künftig belegen können, woraus seine Software besteht. Der Cyber Resilience Act macht die Software Bill of Materials — kurz SBOM — zur rechtlichen Pflicht. Sie muss maschinenlesbar sein, mindestens die direkten Abhängigkeiten abdecken und Teil der technischen Dokumentation sein. Die Marktüberwachungsbehörde kann sie anfordern.

Das ist neu. Bislang war die SBOM ein Reifegradmerkmal, das gute Hersteller freiwillig pflegten. Ab dem 11. Dezember 2027 ist sie Voraussetzung dafür, ein Produkt überhaupt verkaufen zu dürfen.

Was der CRA verlangt — und wo es steht

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847. Sie gilt unmittelbar in allen Mitgliedstaaten; eine nationale Umsetzung wie beim BSIG gibt es nicht.

Die SBOM-Pflicht steht in Anhang I Teil II — dem Abschnitt über die Anforderungen an die Schwachstellenbehandlung. Verlangt wird ein Verzeichnis der im Produkt enthaltenen Komponenten in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene abdeckt.

Drei Wörter dieser Formulierung entscheiden über die Umsetzung:

Maschinenlesbar. Gemeint sind Formate wie CycloneDX oder SPDX. Eine PDF-Liste erfüllt die Anforderung nicht, auch wenn sie inhaltlich vollständig ist. Der Zweck ist die automatisierte Auswertung — eine Liste, die ein Mensch abtippen muss, verfehlt ihn.

Mindestens. Die obersten Abhängigkeiten sind die Untergrenze, nicht das Ziel. Wer dort aufhört, erfüllt den Buchstaben und verfehlt den Zweck. Dazu unten mehr.

Enthaltene Komponenten. Maßgeblich ist, was im ausgelieferten Artefakt steckt — nicht, was in der Architekturdokumentation steht.

Die Fristen

| Datum | Was gilt | | ---------- | --------------------------------------------------------------------------------------- | | 10.12.2024 | Verordnung in Kraft getreten | | 11.09.2026 | Meldepflichten: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle | | 11.12.2027 | Vollständige Anwendung, einschließlich Konformitätsbewertung und SBOM |

Die erste Frist ist bereits erreicht. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen melden — und genau hier zeigt sich, warum die SBOM kein Dokumentationsthema ist: Ohne Komponenteninventar lässt sich eine Meldefrist nicht einhalten, weil niemand innerhalb der Frist beantworten kann, ob das eigene Produkt betroffen ist.

Am 27. Juli 2026 hat die Europäische Kommission eine Anwendungs-Guidance veröffentlicht, die Herstellern die Auslegung erleichtern soll. Wer die Umsetzung erst 2027 beginnt, hat den Puffer aufgebraucht, den diese Reihenfolge eigentlich bietet.

Der entscheidende Punkt: Die SBOM steht beim Vulnerability Handling

Die Einordnung im Anhang ist keine Formalie. Die SBOM steht nicht bei den Anforderungen an das Produktdesign, sondern bei der Schwachstellenbehandlung. Sie ist kein Ausweisdokument, sondern ein Betriebsmittel.

Der Praxistest dafür heißt Log4Shell. Als die Schwachstelle im Dezember 2021 bekannt wurde, zerfielen die betroffenen Unternehmen in zwei Gruppen: solche, die binnen Stunden sagen konnten, welche Systeme die Bibliothek enthielten — und solche, die wochenlang suchten. Der Unterschied war nie die Qualität des Sicherheitsteams. Es war das Vorhandensein eines belastbaren Inventars.

Genau diesen Zustand adressiert der CRA. Die Frage ist nicht, ob Sie eine Liste vorzeigen können, sondern ob Sie beim nächsten kritischen CVE innerhalb der Meldefrist eine belastbare Antwort geben.

Warum „Top-Level" nicht reicht

Die Verordnung verlangt mindestens die obersten Abhängigkeiten. Das ist die rechtliche Untergrenze und praktisch selten ausreichend.

Ein Beispiel aus der Java-Welt: Ihre Anwendung bindet ein Framework ein — das ist eine Top-Level-Abhängigkeit und steht in Ihrer SBOM. Das Framework bringt seinerseits zwei Dutzend Bibliotheken mit, darunter die anfällige. Eine SBOM, die nur die oberste Ebene führt, zeigt die betroffene Komponente nicht. Sie ist formal konform und im Ernstfall wertlos.

Für die Konformitätsbewertung mag die Untergrenze genügen. Für die Meldefrist bei aktiv ausgenutzten Schwachstellen genügt sie nicht. Wer beides zusammendenkt, erzeugt die SBOM transitiv — also über alle Ebenen.

Aus dem Build, nicht aus der Doku

Der häufigste Umsetzungsfehler ist, die SBOM einmalig von Hand zusammenzustellen. Das Ergebnis ist am Tag der Erstellung korrekt und danach nie wieder.

Belastbar wird eine SBOM, wenn sie im Build-Prozess entsteht — aus demselben Lauf, der das ausgelieferte Artefakt erzeugt. Nur dann beschreibt sie das Produkt und nicht die Absicht. Drei Konsequenzen folgen daraus:

Je Release eine SBOM. Nicht je Produkt. Wer fünf unterstützte Versionen im Feld hat, braucht fünf Inventare — sonst lässt sich nicht sagen, welche Kundeninstallation betroffen ist.

Container zählen mit. Was im Image liegt, ist Teil des ausgelieferten Produkts, auch wenn es niemand bewusst hinzugefügt hat. Basis-Images bringen regelmäßig Pakete mit, die in keiner Abhängigkeitsdatei stehen.

Archivieren, nicht überschreiben. Die SBOM einer vor drei Jahren ausgelieferten Version muss noch abrufbar sein, solange die Version unterstützt wird. Das ist eine Anforderung an die Ablage, nicht an das Werkzeug.

Ohne VEX ertrinken Sie in Meldungen

Eine vollständige SBOM erzeugt ein Folgeproblem, über das selten gesprochen wird: Sie werden zu jedem CVE in jeder enthaltenen Komponente einen Treffer bekommen — auch dann, wenn der verwundbare Code in Ihrem Produkt gar nicht erreichbar ist.

Ein typisches mittelgroßes Produkt enthält einige hundert Komponenten. Ohne Bewertung produziert das eine Liste, die niemand abarbeitet. Dafür gibt es VEX (Vulnerability Exploitability eXchange): eine maschinenlesbare Aussage dazu, ob eine bekannte Schwachstelle im konkreten Produkt ausnutzbar ist — und wenn nicht, warum nicht.

Der CRA verlangt VEX nicht ausdrücklich. Wer die Schwachstellenbehandlung aber ohne diese Bewertungsebene aufsetzt, hat nach dem ersten Quartal ein Rückstandsproblem und keine belastbare Triage. Die SBOM sagt, was drin ist. VEX sagt, was davon zählt.

NIS2 und CRA: zwei Regime, ein Haus

Für viele Hersteller gelten beide Regelwerke gleichzeitig, und die Verwechslung ist der häufigste Fehler in der Planung.

| | NIS2 / BSIG | Cyber Resilience Act | | ------------- | ---------------------------------------- | ---------------------------------------------- | | Gegenstand | Ihr Unternehmen | Ihr Produkt | | Auslöser | Sektor und Unternehmensgröße | Inverkehrbringen in der EU | | Kernpflichten | Risikomanagement, Registrierung, Meldung | Konformität, Schwachstellenbehandlung, Updates | | Aufsicht | BSI | Marktüberwachungsbehörden | | Rechtsform | Richtlinie, national umgesetzt | Verordnung, unmittelbar geltend |

Ein Maschinenbauer mit 300 Beschäftigten fällt über Anhang II der NIS2-Richtlinie unter das BSIG — und für seine vernetzten Anlagen zusätzlich unter den CRA. Dasselbe gilt für Elektronikhersteller und für Medizinprodukte, wo zusätzlich die MDR mitspielt.

Organisatorisch lassen sich beide Stränge zusammenführen: Ein Meldeprozess kann beide Fristen bedienen, ein Schwachstellenprozess beide Anforderungen. Inhaltlich bleiben es zwei Nachweisstränge mit unterschiedlichen Prüfmaßstäben — wer sie vermischt, hat am Ende für keines der beiden einen sauberen Nachweis.

Die Lieferkettensicherheit ist der Punkt, an dem beide zusammenlaufen. Ihre SBOM ist zugleich die Grundlage dafür, Zulieferer nach § 30 BSIG zu bewerten — und Ihre eigenen Kunden werden dieselbe SBOM von Ihnen verlangen, sobald sie ihre NIS2-Pflichten ernst nehmen.

Typische Fehler

Die SBOM als Anhang zum Angebot. Sie ist ein Betriebsartefakt, kein Vertriebsdokument. Wer sie nur zum Verkaufszeitpunkt erzeugt, hat sie zum Zeitpunkt des Vorfalls nicht.

Nur die eigene Anwendung. Betriebssystem, Laufzeitumgebung und Basis-Image gehören zum ausgelieferten Produkt.

Ein Format für alles. CycloneDX und SPDX haben unterschiedliche Stärken. Entscheiden Sie bewusst, statt das Standardformat des erstbesten Werkzeugs zu übernehmen.

Keine Verantwortlichkeit. Wenn niemand benannt ist, der die SBOM je Release freigibt, verfällt sie wie jede andere Dokumentation.

Was jetzt zu tun ist

Die Reihenfolge ist wichtiger als die Werkzeugwahl:

1. Produktinventar. Welche Produkte mit digitalen Elementen bringen Sie in Verkehr, in welchen unterstützten Versionen? Ohne diese Liste ist alles Weitere ungenau.
2. Ein Produkt exemplarisch. Erzeugen Sie für ein Produkt eine SBOM aus dem Build und vergleichen Sie sie mit dem, was Sie erwartet hätten. Die Abweichung ist regelmäßig der Erkenntnisgewinn.
3. In die Pipeline. Erst wenn die Erzeugung automatisiert ist, lohnt die Ausweitung auf das Portfolio.
4. Schwachstellenprozess anschließen. SBOM, Abgleich gegen Schwachstellendatenbanken, Bewertung per VEX, Meldeweg. Das Schwachstellenmanagement ist der Prozess, in den die SBOM einzahlt.
5. Meldewege klären. Die CRA-Meldepflichten gelten seit September 2026. Prüfen Sie, ob Ihr bestehender NIS2-Meldeprozess die CRA-Fristen mitbedienen kann.

Wo die Ausgangslage unklar ist, klärt eine Gap-Analyse zuerst den Anwendungsbereich: welche Produkte betroffen sind, welche Anforderungen bereits erfüllt werden und welche Lücken bis Dezember 2027 zu schließen sind.

Primärquellen

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), insbesondere Anhang I Teil II zur Schwachstellenbehandlung
• Europäische Kommission, Anwendungs-Guidance zum Cyber Resilience Act vom 27. Juli 2026

Dieser Beitrag gibt den Stand zum Veröffentlichungsdatum wieder und ersetzt keine Rechtsberatung. Für die verbindliche Auslegung im Einzelfall sind der Verordnungstext und die Guidance der Kommission maßgeblich.