In den letzten Artikeln unserer Serie ging es um die Cyberrisikobewertung und die Antwort auf die Frage: Ist mein Produkt beim Inverkehrbringen cybersicher? Es gibt aber noch eine unbequemere Folgefrage, die Anhang I, Teil II des Cyber Resilience Act aufwirft: Bleibt es das auch in fünf Jahren — oder in zehn? Das ist der fundamentale Unterschied zwischen den beiden Teilen von Anhang I. Teil I beschreibt einen Zustand, den das Produkt erreichen muss. Teil II beschreibt die Prozesse, die der Hersteller dauerhaft betreiben muss, um diesen Zustand zu halten. Teil I ist ein Projektziel. Teil II ist operativer Dauerbetrieb. Genau diese Herstellerpflicht rückt die Cybersicherheit im laufenden Betrieb in den Fokus. Zwei Dinge sind dafür entscheidend: die Software-Stückliste (Software Bill of Materials, kurz SBOM) und das kontinuierliche Schwachstellen-Management (Vulnerability Management). Die zugehörigen Pflichten aus dem CRA behandelt dieser Artikel im Detail.
Manuel Sandler
Der Cyber Resilience Act bündelt diese Anforderung an „Cybersicherheit im Dauerbetrieb“ in acht spezifischen Pflichten, die in Anhang I Teil II dargelegt sind. Auf diese Pflichten gehen wir im Folgenden ein.
Anschließend wenden wir uns einem erweiterten Verständnis der SBOM zu, die hier weniger als eine Pflicht unter vielen zu sehen ist, sondern als das Rückgrat des Ganzen. Denn cybersicherheitsrelevante Schwachstellen lassen sich nur finden, bewerten, beheben und im Ernstfall melden, wenn man überhaupt weiß, was im eigenen Produkt steckt.
Die acht Pflichten aus CRA-Anhang I Teil II — und ihr Bezug zu EN 40000-1-3
Die entstehende europäische Standardisierungsreihe EN-40000 ist in den vorangegangenen Artikeln bereits vorgestellt worden. Mit Blick auf die erwähnten CRA-Pflichten nehmen wir uns die EN 40000-1-3 vor, die den Umgang mit Schwachstellen (Vulnerability Handling) adressiert und so die Anforderungen aus Anhang I Teil II in konkrete, prüfbare Prozessanforderungen übersetzt. (Eine zusätzliche Hilfestellung bietet dabei auch die EN 40000-1-2, die in ihrem Anhang C ein Mapping zwischen Standard und CRA-Anforderungen enthält.)
Der Gewinn für die Praxis: Aus der gesetzlichen Pflicht „der Hersteller muss Schwachstellen behandeln” wird eine überprüfbare Anleitung, „so sieht ein nachvollziehbarer Prozess dafür aus”.
Wie bereits geschildert: Zwar befindet sich diese Norm noch im Entwurf und begründet daher offiziell noch keine Konformitätsvermutung — als Arbeitsgrundlage taugt sie aber schon heute.
Bis es dann zur Referenzierung im EU-Amtsblatt kommt — frühestens Ende 2026/2027 erwartet — gilt die ebenfalls bereits erwähnte BSI TR-03183 (Teil 2) als pragmatischste Übergangslösung. Wer heute mit ihr arbeitet, baut auf einem Fundament, das inhaltlich nah genug an EN 40000-1-3 liegt, um den späteren Übergang ohne Neuerfindung zu ermöglichen.
Jetzt aber los mit dem Blick auf Anhang I, Teil II des CRA, die Anforderungen an die Behandlung von Schwachstellen.
Pflicht 1: Identifikation und Dokumentation von Schwachstellen und Komponenten
Die erste dieser Pflichten (s. Anhang I, Teil II, Nr. 1) verlangt, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren. Dafür braucht es unter anderem eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen.
Der Begriff der „obersten Abhängigkeiten” ist präzise gewählt und wird oft missverstanden: Gemeint sind die Komponenten, die man direkt und bewusst integriert hat — nicht die transitiven Abhängigkeiten, also alles, was diese Komponenten ihrerseits nachladen, über beliebig viele Ebenen hinweg.
Eine SBOM, die nur die erste Ebene direkter Abhängigkeiten abbildet, erfüllt bereits die Mindestanforderung des CRA. Ein Beispiel: Bindet ein Produkt die Bibliothek OpenSSL direkt ein, muss OpenSSL in der SBOM stehen — die Dutzenden Bibliotheken, die OpenSSL seinerseits nachlädt, sind nach der Mindestanforderung nicht zwingend aufzuführen. Für das Vulnerability-Management ist die vollständige Tiefe trotzdem oft die bessere Wahl: Eine Schwachstelle in einer tief verschachtelten Unter-Bibliothek kann genauso gefährlich sein wie eine in der direkt eingebundenen Komponente.
Bedeutet im Klartext: Aus Vulnerability-Management-Perspektive ist eine vollständige, tiefe SBOM wertvoller; aus Compliance-Perspektive ist die erste Ebene das Mindesterfordernis. Gerade Unternehmen, die SBOMs neu einführen, sollten sich zunächst auf diese oberste Ebene konzentrieren und die Tiefe später ausbauen.
Die EN 40000-1-3 gibt Orientierung zu Format- und Inhaltsanforderungen und empfiehlt etablierte maschinenlesbare Formate. Die beiden heute relevantesten sind:
- SPDX (Software Package Data Exchange, ISO/IEC 5962:2021)
- und CycloneDX (ein OWASP-Standard).
Beide werden in der BSI TR-03183 Teil 2 auf die CRA-Anforderungen gemappt und sind als Umsetzungsgrundlage anerkannt.
Die Wahl zwischen beiden ist weniger eine regulatorische als eine technische Entscheidung. Primär sollte sie sich an der vorhandenen Toolchain und der Integration in den Build-Prozess orientieren.
Wichtig: Die SBOM muss nicht veröffentlicht werden — und sollte es in der Regel auch nicht, denn eine offengelegte Komponentenliste ist für Angreifer eine bequeme Vorlage für gezielte Attacken. Der CRA-Erwägungsgrund 77 stellt klar, dass Hersteller nicht zur Veröffentlichung verpflichtet sind. Die SBOM ist ein internes Dokument, das aber auf begründetes Verlangen der Marktüberwachungsbehörde vorzulegen ist. Ihre Vertraulichkeit bleibt damit prinzipiell gewahrt.
Pflicht 2: Unverzügliche Behandlung und Behebung von Schwachstellen
Schwachstellen sind mit Blick auf die Produktrisiken unverzüglich zu behandeln und zu beheben.
Der CRA sieht hierfür dedizierte Sicherheitsaktualisierungen vor, die, soweit technisch machbar, getrennt von Funktionsaktualisierungen laufen.
„Unverzüglich” ist dabei kein starrer Zeitraum, sondern risikobasiert: Eine kritische Schwachstelle mit aktivem Exploit verlangt eine andere Reaktionsgeschwindigkeit als eine niedrigschwellige ohne bekannte Ausnutzung.
Wichtig ist außerdem, worauf sich „unverzüglich” bezieht: auf das Behandeln der Schwachstelle, nicht zwingend auf das sofortige Beheben. Behandeln ist dabei der Oberbegriff für die gesamte Reaktion: die Schwachstelle bewerten, ihre Ausnutzbarkeit einschätzen, sie priorisieren und, wo nötig, vorübergehend eindämmen, bis ein Patch bereitsteht. Das eigentliche Beheben ist nur der letzte Schritt und braucht manchmal Zeit, etwa wenn die Schwachstelle in einer Drittkomponente liegt und der Fix von deren Hersteller abhängt.
Der CRA fordert damit einen Triage-Prozess, der Schwachstellen nach Schweregrad und Ausnutzbarkeit klassifiziert und die Priorität der Behebung daran ausrichtet.
Die Trennung von Sicherheits- und Funktionsupdates ist in vielen Release-Prozessen strukturell nicht vorgesehen.
Ein Unternehmen mit monatlichem Release-Zyklus, das Sicherheits-Patches nur im Rahmen regulärer Releases ausliefert, erfüllt die Anforderung möglicherweise nicht — jedenfalls nicht für kritische Schwachstellen, die schneller behandelt werden müssen. Ein separater, release-unabhängiger Prozess für Sicherheits-Patches ist die Konsequenz.
Die EN 40000-1-3 definiert Anforderungen an den internen Triage- und Remediationsprozess — von der Erfassung einer neuen Schwachstellenmeldung bis zur Bereitstellung des Patches und der Benachrichtigung der Nutzer.
An dieser Stelle auch noch der ergänzende Hinweis: Diese Behebung ist dabei nicht zwangsläufig immer ein Software-Update. Je nach Produkt kann sie auch eine geänderte Konfiguration, eine Einschränkung betroffener Funktionen oder, im Extremfall, den Austausch von Hardwarekomponenten bedeuten.
Pflicht 3: Regelmäßige Sicherheitstests und -überprüfungen
Die Sicherheit des Produkts ist regelmäßig und wirksam zu testen und zu überprüfen. Mehr schreibt der CRA dazu nicht vor, auch spezifische Testmethoden werden nicht erwähnt.
Zulässig sind unter anderem Penetrationstests, Fuzzing, formale Verifikation und strukturierte Code-Reviews. Hinzu kommen die beiden gängigen automatisierten Verfahren SAST und DAST: Static Application Security Testing prüft den Quellcode, ohne das Programm auszuführen, Dynamic Application Security Testing testet umgekehrt die laufende Anwendung von außen. Ein Teil dieser Verfahren, etwa Fuzzing, formale Verifikation und Code-Reviews, gehört seiner Natur nach in die Entwicklungsphase, während Penetrationstests und wiederkehrende SAST- und DAST-Läufe das Produkt auch über die Feldzeit hinweg begleiten können.
Welche Kombination angemessen ist, ergibt sich aus dem Risikoprofil. Gefordert ist nicht eine bestimmte Methode, sondern Regelmäßigkeit und Wirksamkeit.
Muss ich als Hersteller jetzt jede Woche ein Produkt-Pentesting initiieren? Eher nicht.
„Regelmäßig” heißt in erster Linie: nicht nur einmalig vor dem ersten Release, sondern kontinuierlich über den Entwicklungs- und Betriebs-Lifecycle.
Dazu gehört:
- neue Komponenten vor der Integration prüfen;
- nach wesentlichen Änderungen die betroffenen Bereiche neu bewerten;
- in festen Intervallen — unabhängig von Produktänderungen — das Sicherheitsniveau insgesamt überprüfen, weil sich das Bedrohungsumfeld auch ohne Produktänderung verschiebt.
Zu dieser wiederkehrenden Überprüfung gehört auch die Risikobewertung selbst: Ob die einmal getroffenen Einstufungen noch dem aktuellen Stand der Technik und der aktuellen Bedrohungslage entsprechen, sollte in festen Abständen kontrolliert werden. Was gestern als geringes Risiko galt, kann sich durch neue Angriffstechniken verschieben, wie bereits in unserem Artikel zur CRA-Risikobewertung beschrieben.
Merksatz: Die Tests prüfen das Produkt. Die Überprüfung der Risikobewertung prüft, ob überhaupt noch das Richtige getestet wird.
„Wirksamkeit” heißt, dass die Tests tatsächlich geeignet sind, relevante Schwachstellen zu finden, statt Compliance-Checkboxen abzuhaken. Ein jährlicher Penetrationstest, der Kernfunktionalität und kritische Schnittstellen nicht abdeckt, ist formal eine Prüfung, aber eben nicht wirksam im Sinne der Pflicht.
Auch hier gibt die EN 40000-1-3 Orientierung zur Testtiefe nach Risikoprofil. Ein Produkt der Important Class II erfordert beispielsweise eine tiefere und breitere Testabdeckung als eines der Default-Kategorie.
Pflicht 4: Transparente Kommunikation behobener Schwachstellen
Sobald eine Sicherheitsaktualisierung bereitgestellt wurde, sind Informationen über die beseitigte Schwachstelle zu teilen und zu veröffentlichen:
- Beschreibung,
- Information zur Identifikation des betroffenen Produkts,
- Auswirkungen,
- Schweregrad
- sowie verständliche Hinweise zur Behebung.
Die Publikationspflicht greift nach Bereitstellung des Patches, nicht schon bei Entdeckung. Der Regelfall ist die Veröffentlichung, sobald das Update verfügbar ist. Der CRA erlaubt ausdrücklich, die Veröffentlichung zurückzuhalten – dies jedoch nur als Ausnahme in hinreichend begründeten Fällen, nämlich dann, wenn der Hersteller die Sicherheitsrisiken einer Veröffentlichung höher gewichtet als deren Sicherheitsnutzen. In diesen Fällen darf die Offenlegung hinausgezögert werden, bis Nutzer den Patch einspielen konnten.
Das ist das Responsible-Disclosure-Prinzip: vollständige öffentliche Kommunikation erst, wenn eine Korrekturmaßnahme verfügbar ist und Nutzer Zeit hatten, sie anzuwenden.
In der Praxis heißt das: Für jeden gepatchten Sicherheitsfehler eine Security Advisory (eine öffentliche Sicherheitsmitteilung, die die behobene Schwachstelle und ihre Behebung beschreibt) mit mindestens einer Beschreibung der Schwachstelle (idealerweise mit CVE-Nummer), den betroffenen Produktversionen, dem Schweregrad (typischerweise nach CVSS), den Auswirkungen bei Ausnutzung und klaren Hinweisen zur Behebung, in der Regel durch Einspielen des Updates.
Bei Produkten ohne Update-Funktion greift die Behebung per Patch naturgemäß nicht – hier muss die CRA-Cyber-Risikobewertung entsprechend umso gründlicher ausfallen, wie im zweiten Artikel dieser Serie näher ausgeführt.
Pflicht 5: Coordinated Vulnerability Disclosure Policy
Eine Strategie für die koordinierte Offenlegung von Schwachstellen ist aufzustellen und umzusetzen. Das ist innerhalb dieser Auflistung eigentlich das einzige Prozessdokument, das der CRA explizit und namentlich fordert. Keine andere der acht Pflichten verlangt ein spezifisches, veröffentlichtes Richtliniendokument, nur die Coordinated Vulnerability Disclosure (CVD) Policy.
Eine CVD-Policy beschreibt dreierlei:
- wie externe Schwachstellenmeldungen entgegengenommen werden (welcher Kanal, z.B. E-Mail, Meldeformular, Security-Seite, welche Angaben der Melder machen soll, wie schnell er eine Bestätigung erhält);
- den internen Bearbeitungsprozess (Triage, Bewertung, Priorisierung, klar zugewiesene Verantwortlichkeiten, interne Information, angestrebte Behebungsfristen);
- und den Offenlegungsprozess (wann und wie die Schwachstelle nach Behebung veröffentlicht und ob der externe Melder einbezogen wird).
Die Bedeutung dieser Policy wird oft unterschätzt: Ein großer Teil aller Cybersecurity-Schwachstellen wird nicht vom Hersteller selbst entdeckt, sondern von außen. Von Sicherheitsforschern, Nutzern oder Dritten. Ohne einen klaren, öffentlich sichtbaren Meldeweg landet dieses Wissen nirgendwo, und eine Lücke bleibt offen, die längst hätte geschlossen werden können. Die CVD-Policy ist damit die Brücke, die externe Funde überhaupt erst in behebbare Schwachstellen verwandelt.
Die EN 40000-1-3 konkretisiert auch hier Mindestinhalte und Prozess; in der Praxis orientieren sich viele Hersteller an der ISO/IEC 30111:2019 (Vulnerability Handling Processes) und der ISO/IEC 29147 (Vulnerability Disclosure).
Wichtig für die Praxis: Die CVD-Policy muss veröffentlicht sein. Nicht nur intern, sondern öffentlich zugänglich für externe Sicherheitsforscher, die eine Schwachstelle melden wollen. Das security.txt-Format (RFC 9116) ist beispielsweise ein etablierter Weg, auf Policy und Meldekanal hinzuweisen.
Pflicht 6: Erleichterung des Informationsaustauschs über Schwachstellen
Der Informationsaustausch über mögliche Schwachstellen im Produkt und in enthaltenen Drittkomponenten ist zu erleichtern. Unter anderem durch eine dedizierte Kontaktadresse für die Meldung entdeckter Schwachstellen.
Das ist die technische Umsetzungspflicht zur vorangegangenen Pflicht 5: Die CVD-Policy beschreibt den Prozess, Pflicht 6 verlangt die technische Zugänglichkeit des Meldekanals.
Eine öffentlich zugängliche Kontaktmöglichkeit ist Pflicht: E-Mail-Adresse, ein „Vulnerability melden“-Web-Formular oder die security.txt mit weiteren Informationen sind gängige Umsetzungen.
Diese Pflicht umfasst auch Schwachstellen in enthaltenen Drittkomponenten (Vgl. dazu vorherige Ausführung zur SBOM).
Findet ein externer Sicherheitsforscher eine Schwachstelle in einer integrierten Komponente, soll der Hersteller als Anlaufstelle fungieren und die Meldung an den jeweiligen Komponenten-Hersteller weiterleiten. Das gilt nicht nur für Open-Source-Bibliotheken, sondern für zugelieferte Komponenten aller Art, von kommerzieller Fremdsoftware über Firmware bis zu integrierten Hardware-Modulen mit eigener Software (etwa Steuergeräten in einem Gesamtsystem). Wer eine Komponente in sein Produkt aufnimmt, übernimmt damit auch die Rolle der Meldebrücke zu deren Hersteller.
Genau das verlangt Art. 13 Abs. 5–6 CRA auch vom Hersteller selbst: Stellt er im Rahmen seiner Sorgfaltspflicht eine Schwachstelle in einer integrierten Drittkomponente fest, muss er die Person oder Einrichtung informieren, die diese Komponente herstellt oder wartet. Hat er selbst einen Software- oder Hardware-Fix entwickelt, muss er den Code oder die Unterlagen dem Maintainer in maschinenlesbarem Format mitteilen.
Dadurch fordert der CRA eine wechselseitige Pflicht: Wer von Open-Source-Projekten profitiert, soll im Gegenzug zu deren Sicherheit beitragen. Der eigentliche Sinn dieser Pflicht liegt im größeren Bild: Kein Hersteller entwickelt heute isoliert, sondern baut auf einem Geflecht aus Open-Source- und Drittkomponenten auf. Indem der CRA jeden Hersteller zur offenen Anlaufstelle macht — auch für Schwachstellen in fremdem Code —, sorgt er dafür, dass ein Fund an einer Stelle das gesamte Ökosystem sicherer machen kann, statt in einer Sackgasse zu enden.
Pflicht 7: Sichere Update-Verteilungsmechanismen
Mechanismen für die sichere Verbreitung von Aktualisierungen sind bereitzustellen, damit Schwachstellen rechtzeitig und bei Sicherheitsaktualisierungen gegebenenfalls automatisch behoben oder eingedämmt werden können. Das ist die technische Infrastruktur-Pflicht des Vulnerability Managements.
Sicherheitsupdates müssen sicher zum Nutzer gelangen, dafür muss der gesamte Update-Kanal gegen Angriffe gesichert sein:
- kryptografische Signaturen für Update-Pakete stellen sicher, dass nur authentische, freigegebene Updates eingespielt werden;
- sichere Übertragungskanäle (TLS) schützen gegen Manipulation unterwegs;
- die Signaturverifikation vor der Installation stellt sicher, dass das empfangene Update dem entspricht, was der Hersteller bereitgestellt hat.
Es gilt sich aber auch vor Augen zu führen: Der „Update-Kanal” ist nicht mit „Online-Update” gleichzusetzen.
Der CRA schreibt keinen bestimmten Verteilweg vor, sondern verlangt, dass dieser Weg sicher ist, welcher auch immer es ist.
Für Produkte, die sich nicht online aktualisieren lassen, etwa festverbaute oder bewusst vom Netz getrennte Systeme, muss der Hersteller einen anderen sicheren Weg bereitstellen: einen abgesicherten Download, den der Betreiber selbst einspielt, oder die Einbindung des Sicherheitsupdates in ein Wartungskonzept, bei dem geschultes Servicepersonal die Aktualisierung vor Ort vornimmt.
Die Sicherungsmechanismen bleiben dieselben, Signatur, Integritäts- und Versionsprüfung, nur der Transportweg ist ein anderer.
Wichtig im Zuge des CRA: Gerade Hersteller solcher Produkte müssen hierfür oft neue Prozesse und Arbeitsweisen etablieren, weil ein geregelter Update-Weg im Feld bislang schlicht nicht vorgesehen war.
Signatur und TLS allein decken allerdings nicht alles ab. Ein Angreifer könnte ein älteres, noch gültig signiertes Update mit einer bereits bekannten Schwachstelle erneut einspielen — ein sogenannter Downgrade- oder Rollback-Angriff. Dagegen helfen Versionsbindung und Anti-Rollback-Zähler, die das Zurückfallen auf einen älteren Stand verhindern. Ebenso gehört die Robustheit des Update-Vorgangs selbst dazu: die Möglichkeit, nach einem fehlgeschlagenen oder unterbrochenen Update in einen funktionsfähigen Zustand zurückzukehren, damit ein Sicherheitsupdate das Gerät nicht unbrauchbar macht. Die ENISA-Advisory zu sicheren Update-Mechanismen (Entwurf, Mai 2026) beschreibt beides als Kern eines belastbaren Update-Designs — vom Anti-Rollback-Zähler bis zur atomaren Installation, die einen bekannt-guten Stand jederzeit verfügbar hält. Hier greift Pflicht 7 sichtbar in die Verfügbarkeits- und Integritätsanforderungen aus unserem dritten Artikel zu den CRA-Cybersecurity-Anforderungen an Produkte hinein (s. Anforderungen (h) und (f)).
Auch hier noch der Blick auf die EN 40000-1-3: Sie adressiert darüber hinaus auch die Absicherung der Update-Infrastruktur selbst, die Server und Systeme, über die Updates verteilt werden. Ein Angreifer, der den Update-Server kompromittiert und Schadcode als legitimes Update verteilt, realisiert genau das Szenario, das Pflicht 7 verhindern soll. Die Sicherheit des Update-Kanals ist damit nicht nur Produkt-, sondern auch Betriebsinfrastruktur-Anforderung.
Genau an dieser Stelle knüpft der CRA an die Scope-Frage aus dem zweiten Artikel dieser CRA-Artikelserie zur CRA-Cyberrisikobewertung an: Dort haben wir die Grenze des Bewertungsgegenstands (Item Boundaries) gezogen und den herstellereigenen Update-Server eingeordnet.
Zur Erinnerung: Zwingend zum Produkt gehört das Update-Interface im Gerät selbst — der Mechanismus, der Updates abruft, per TLS überträgt, Signaturen prüft und Rollbacks verhindert. Den dahinterliegenden Server kann man als externen Endpunkt modellieren; seine Sicherheit wird dann über Pflicht 7 (sichere Verteilung) und gegebenenfalls NIS2 erfasst, nicht über den Produkt-Scope. Zum vollwertigen Bestandteil des Produkts (RDPS) wird der Server erst, wenn er über die reine Update-Auslieferung hinaus eine operative Kernfunktion trägt.
So schließt sich der Kreis: Was mit der CRA-Cyberrisikobewertung in unserem zweiten CRA-Artikel als Grenzziehung begann, wird hier zur konkreten Prozesspflicht.
Pflicht 8: Kostenlose und unverzügliche Verteilung verfügbarer Sicherheitsupdates
Verfügbare Sicherheitsaktualisierungen sind unverzüglich und, sofern nicht vertraglich anders mit gewerblichen Nutzern vereinbart, kostenlos zu verbreiten. Stets begleitet von Hinweisen zu möglichen Nutzermaßnahmen.
Der CRA schließt damit explizit das Geschäftsmodell aus, Sicherheits-Patches als kostenpflichtige Upgrades oder Premium-Features anzubieten.
Sicherheitsupdates müssen kostenlos sein. Für alle Nutzer, über den gesamten Unterstützungszeitraum.
Einzige Ausnahme: eine explizite vertragliche Vereinbarung mit gewerblichen Nutzern bei maßgeschneiderten Produkten; für Standard-Consumer-Produkte gilt sie nicht.
Dabei sind zwei verbreitete Missverständnisse auszuräumen:
- „Kostenlos” gilt für die Dauer des Unterstützungszeitraums, nicht zeitlich unbegrenzt. Nach dessen Ende steht es dem Hersteller frei, verlängerte Wartung oder Updates kostenpflichtig Die Grenze ist das Support-Ende, nicht der Preis.
- Kostenlos und unverzüglich meint die Bereitstellung, nicht die erzwungene Installation. Ob ein Update automatisch oder erst nach manueller Freigabe eingespielt wird, regelt Anforderung (c) aus Anhang I Teil I. Die Pflicht 8 verlangt nur, dass es rechtzeitig und ohne Zusatzkosten zur Verfügung steht.
„Unverzüglich” hat hier dieselbe risikobasierte Bedeutung wie bei Pflicht 2: Die Bereitstellungsgeschwindigkeit muss dem Schweregrad entsprechen. Ein kritischer Patch für eine aktiv ausgenutzte Schwachstelle darf nicht monatelang auf das nächste reguläre Release warten.
Noch ein wichtiger Hinweis zum bereits erwähnten Zusatz „begleitet von Hinweisen zu möglichen Nutzermaßnahmen”: Ein Update, das kommentarlos ausgeliefert wird, erfüllt die Pflicht nur halb. Nutzer müssen erfahren, was es behebt und ob sie selbst aktiv werden müssen — hier greift Pflicht 8 unmittelbar in die Kommunikationspflicht aus Pflicht 4.
So unterschiedlich die vorgestellten acht Pflichten aus Anhang I Teil II sind — sie teilen einen blinden Fleck, wenn eine Sache fehlt: die Kenntnis der eigenen Komponenten.
Ohne sie bleibt jede der acht Pflichten Stückwerk.
Damit ist die Software Bill of Materials keine Pflicht neben den anderen, sondern die Grundlage unter allen.
Sehen wir sie uns nun genauer an.
CRA und die SBOM im Detail: Kein Buzzword, sondern operative Grundvoraussetzung
Die SBOM ist in der CRA-Diskussion zu einem der meistgenannten Begriffe geworden. Mal als Symbol des bürokratischen Aufwands, mal als technische Wunderlösung.
Beides trifft nicht zu.
Der Kern ist pragmatisch: Wer nicht weiß, welche Komponenten in seinem Produkt stecken, kann auch nicht wissen, ob eine neu entdeckte Schwachstelle sein Produkt betrifft.
Die Erstellung der SBOM, der Softwarestückliste, ist somit keine Compliance-Übung, sondern die Grundvoraussetzung dafür, dass Vulnerability Management entlang des Produktlebenszyklus überhaupt funktionieren kann.
Dabei ist der Gedanke einer Stückliste an sich nichts Neues. Die Hardware-Stückliste, die Bill of Materials im klassischen Sinn, ist in der Produktentwicklung seit Jahrzehnten etabliert. Jeder Hersteller weiß, welche physischen Komponenten in seinem Produkt verbaut sind. Und dieser Blick gehört auch unter dem CRA dazu: Sicherheitsrelevante Hardwarekomponenten müssen ebenso bekannt und bewertet sein, denn der CRA betrachtet das Produkt mit digitalen Elementen als Ganzes, nicht nur seine Software. Der Unterschied ist nur, dass die Hardware-Seite dank etablierter Stücklisten-Praxis meist keine große Hürde mehr darstellt. Das eigentlich Neue, und für viele Hersteller Ungewohnte, ist die gleiche Systematik auf der Softwareseite: eine vollständige, gepflegte, maschinenlesbare Übersicht darüber, was im Produkt an Software steckt.
Was eine SBOM konkret ist und was sie für den Hersteller und seine CRA-Pflichten leisten muss
Eine SBOM ist eine formale, maschinenlesbare Aufzeichnung aller Softwarekomponenten eines Produkts, einschließlich Versionen, Lizenzen und Beziehungen zueinander. Im CRA-Kontext erfüllt sie zwei Kernfunktionen:- Vulnerability Scanning: Die SBOM ermöglicht den automatischen Abgleich aller enthaltenen Komponenten mit CVE-Datenbanken. Wird eine neue Schwachstelle in einer Open-Source-Bibliothek entdeckt, kann der Hersteller innerhalb von Minuten feststellen, ob und in welchen Produktversionen diese Bibliothek enthalten ist — vorausgesetzt, die SBOM ist aktuell und vollständig. (Hierbei können Software-Plattformen helfen, wie das inkludierte Vulnerability Management in CYMETRIS)
- Transparenz und Nachweisführung: Die SBOM ist die Grundlage für den Nachweis, dass die Pflicht 1 (s. oben) erfüllt ist. Ohne sie kann ein Hersteller gegenüber Marktüberwachungsbehörden nicht belegen, dass er alle enthaltenen Komponenten kennt und systematisch auf bekannte Schwachstellen prüft.
Über Mindestinhalt und Tiefe der SBOM gemäß CRA
Als Mindestanforderung fordert der CRA (s. Anhang I, Teil II, Nr. 1) die Dokumentation der „obersten Abhängigkeiten“, also der direkt eingebundenen Komponenten, in einem gängigen, maschinenlesbaren Format.
Einzelne Pflichtfelder schreibt der Verordnungstext dabei nicht vor. Festgelegt ist nur die Tiefe (mindestens Top-Level), die Maschinenlesbarkeit und ein gängiges Format. Als „gängige” Formate haben sich in der Praxis CycloneDX und SPDX etabliert.
Welche Felder eine SBOM konkret enthalten sollte, ergibt sich daher nicht aus dem CRA selbst, sondern aus hierzu etablierten Standards. Ein praxistauglicher Minimalinhalt für eine Software Bill of Materials, die dem CRA entspricht, sieht etwa so aus:
- Lieferant/Hersteller der Komponente
- Name und Version der Komponente
- Eindeutiger Identifikator (z. B. Package URL / PURL oder CPE)
- Beziehung zum Produkt (direkte Abhängigkeit)
- SBOM-Autor und Zeitstempel der Erstellung
- Lizenz der Komponente (für den CRA-Open-Source-Kontext dringend empfohlen)
- Herkunft (Quelle, Repository) (ergänzend)
Für die bereits erklärten transitiven Abhängigkeiten ist die vollständige Erfassung empfehlenswert, aber nach CRA-Mindestanforderung nicht zwingend.
Die SBOM ist zudem über den gesamten Unterstützungszeitraum aktuell zu halten.
In der Praxis lässt sich eine vollständige, tiefe SBOM für die meisten modernen Softwareprodukte mit verfügbaren Tools automatisiert im Build-Prozess generieren. Der Zusatzaufwand für die Tiefe ist bei automatisierter Erstellung marginal, der Mehrwert fürs Vulnerability Management erheblich.
SPDX vs. CycloneDX — die Formatfrage bei der SBOM-Erstellung
Beide Formate sind vom CRA akzeptiert, beide werden von EN 40000-1-3 und TR-03183 Teil 2 adressiert, beide sind mit verbreiteten Tools generierbar.
Die Entscheidung ist primär eine Toolchain-Frage:
- SPDX ist ein ISO-Standard (ISO/IEC 5962:2021) mit starker Verankerung im Open-Source-Ökosystem und besonderem Fokus auf Lizenzinformationen — das ältere und breit etablierte Format.
- CycloneDX ist ein OWASP-Standard mit stärkerem Security-Fokus, expliziter Unterstützung für Vulnerability-Referenzen und einer aktiveren Security-Entwicklungsgemeinschaft; für Security-fokussierte Anwendungsfälle — also den CRA-Kontext — ist es oft die pragmatischere Wahl.
Die Formatwahl ist weniger wichtig als die Konsequenz der Pflege. Ein perfekt strukturiertes SPDX-Dokument, das nach dem ersten Release nie wieder aktualisiert wird, hat keinen operativen Wert. Eine informal strukturierte CycloneDX-SBOM, die bei jedem Release automatisch neu generiert wird, ist dagegen ein echter Sicherheitsbeitrag.
Die eigentliche SBOM-Herausforderung: Organisation, nicht Format
Viele Hersteller stellen beim SBOM-Start fest, dass nicht das Format das Problem ist, sondern die Datenlage darunter. Organisch gewachsene Produkte haben oft keine zentrale Erfassung ihrer Abhängigkeiten: Komponenten wurden ohne systematische Dokumentation integriert, Versionen ohne Festhalten der Änderung aktualisiert, Open-Source-Bibliotheken kopiert statt als Abhängigkeit verwaltet.
In solchen Fällen ist die SBOM-Erstellung zunächst ein Bestandsaufnahme-Projekt: Was ist tatsächlich im Produkt?
Das kann unangenehm werden, weil es vorher unsichtbare Lücken und Risiken sichtbar macht.
Aber absolut notwendig, und je früher, desto besser.
Die dauerhafte Lösung ist die Integration der SBOM-Generierung in den Build-Prozess: Jeder Build erzeugt automatisch eine aktuelle SBOM, die in der Versionsverwaltung abgelegt und je Release-Version archiviert wird. Damit ist die SBOM kein einmaliges Dokument mehr, sondern entsteht bei jedem Build von selbst neu und bleibt so ohne zusätzlichen Pflegeaufwand aktuell. Aus der anfänglichen Bestandsaufnahme wird auf diese Weise ein dauerhaft verlässlicher Stand, der das dokumentierte Produkt und das tatsächlich ausgelieferte Produkt synchron hält.
Der CRA und die Sorgfaltspflicht bei Open-Source-Komponenten
Moderne Produkte, von hardwarenaher Firmware über eingebettete Software bis zur großen Enterprise-Anwendung, enthalten typischerweise erhebliche Anteile an Open-Source.
Das ist erstmal effizient, aber im CRA-Kontext mit Verpflichtungen verbunden.
Der Art. 13 Abs. 5 verpflichtet Hersteller zur Sorgfaltspflicht bei der Integration von Drittkomponenten — einschließlich freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wurde.
Das bedeutet konkret: Der Hersteller verantwortet, dass integrierte Open-Source-Komponenten keine bekannten ausnutzbaren Schwachstellen enthalten — diese Verantwortung lässt sich nicht an das Open-Source-Projekt delegieren.
Entdeckt der Hersteller im Rahmen dieser Sorgfaltspflicht eine Schwachstelle in einer integrierten Open-Source-Komponente, muss er nach Art. 13 Abs. 6:
- Die Person oder Einrichtung informieren, die die Komponente herstellt oder wartet
- Die Schwachstelle selbst beheben und entsprechende Patches in sein Produkt einbauen
- Einen selbst entwickelten Software-Fix in maschinenlesbarem Format an den Komponenten-Maintainer weitergeben
Das ist eine ausdrückliche Pflicht zum Zurückgeben: Wer von Open Source profitiert, trägt im Gegenzug zu deren Sicherheit bei, und das gesamte Ökosystem gewinnt.
Damit ist das Bild der acht Pflichten vollständig — und ihr gemeinsamer Nenner, die Software Bill of Materials, tritt klar hervor: Sie bilden keine Liste voneinander unabhängiger Häkchen, sondern eine zusammenhängende Kette.
Die SBOM speist das Monitoring, das Monitoring löst den Patch-Prozess aus, der Patch wird über sichere Kanäle verteilt und über die CVD-Policy kommuniziert — und mit der Open-Source-Reziprozität reicht diese Kette bewusst über das eigene Produkt hinaus ins Ökosystem.
Fällt ein Glied aus, verliert die gesamte Kette ihre Wirkung.
Inhaltliche Verzahnung mit den anderen Artikeln dieser CRA-Artikelserie
Das Vulnerability Management und die SBOM-Erstellung stehen nicht isoliert da. Sie sind das operative Rückgrat, das die übrigen CRA-Pflichten erst erfüllbar macht:
- Die CRA-Meldepflichten (s. erster Artikel): Hier entstehen die Inhalte, die im Ernstfall binnen 24 Stunden gemeldet werden müssen. Eine aktiv ausgenutzte Schwachstelle, die die Meldepflicht nach Art. 14 Abs. 1 auslöst, ist ein Ergebnis des Vulnerability-Monitoring-Prozesses. Wer kein strukturiertes Monitoring betreibt, erfährt von einer Ausnutzung möglicherweise erst durch externe Meldungen — oder gar nicht. Vulnerability Handling ist also die notwendige Vorstufe, um die Meldepflicht erfüllen zu können, kein separates Thema.
- Die Essential Cybersecurity Requirements (s. dritter Artikel): Anforderung (a) aus Anhang I Teil I — beim Inverkehrbringen keine bekannten ausnutzbaren Schwachstellen — ist strukturell nur durch einen funktionierenden Vulnerability-Handling-Prozess nachweisbar. Ohne SBOM und ohne CVE-Scanning vor dem Release kann ein Hersteller nicht belegen, dass er (a) tatsächlich erfüllt hat.
- Der CRA-Unterstützungszeitraum — die Support Period: Die acht Pflichten gelten nicht nur zum Zeitpunkt des Inverkehrbringens, sondern über den gesamten Unterstützungszeitraum (s. Art. 13 Abs. 8). Mindestens fünf Jahre, bei längerer erwarteter Nutzungsdauer entsprechend länger. Ein Prozess, der beim Release eingerichtet und danach nicht mehr aktiv betrieben wird, erfüllt die Anforderung nicht. Die fünf Jahre sind der Planungshorizont, nicht das Projektende.
Take-away: SBOM, Monitoring, Patch, Kommunikation — One Step At A Time
Wer kein SBOM und keinen strukturierten Patch-Prozess hat, kann weder die Essential Requirements dauerhaft erfüllen noch die CRA-Meldepflichten aus unserem ersten Artikel fristgerecht bedienen.
Vulnerability Management ist der operative Motor, der die anderen CRA-Pflichten erst erfüllbar macht.
Der wichtigste praktische Rat, den man mit Blick auf die Breite der To-Do’s auch in 2026 noch geben kann: einfach anfangen.
- Der CRA kennt zwei Arten von Pflichten: Teil I beschreibt, wie sicher das Produkt sein muss. Teil II verlangt Prozesse, die dauerhaft laufen. Cybersicherheit wird damit zur Daueraufgabe.
- Teil II umfasst acht Pflichten: Komponenten kennen, Schwachstellen behandeln, regelmäßig testen, offen kommunizieren, einen Meldeweg anbieten, Updates sicher verteilen und sie kostenlos bereitstellen.
- „Unverzüglich" heißt: die Schwachstelle sofort bewerten und eindämmen. Das eigentliche Beheben darf dauern, wenn das Risiko es zulässt.
- Die SBOM ist die Grundlage von allem: Wer nicht weiß, was im Produkt steckt, kann keine Schwachstelle finden, bewerten oder melden.
- Die Mindestanforderung ist machbar: Nur die direkt eingebauten Komponenten müssen in einem maschinenlesbaren Format erfasst sein. Veröffentlichen muss man die SBOM nicht.
- Update-Kanal heißt nicht automatisch Online-Update: Auch Geräte ohne Internetzugang brauchen einen sicheren Weg, etwa per Download oder über die Wartung.
- Sicherheitsupdates müssen kostenlos sein, über den gesamten Support-Zeitraum. Patches als Bezahl-Feature sind nicht erlaubt.
- Der wichtigste Rat: einfach anfangen. Eine unvollständige SBOM ist besser als keine. Wer auf die perfekte Lösung wartet, startet oft monatelang gar nicht.
- Key Learnings
Eine unvollständige SBOM ist besser als keine.
Ein manuell gepflegter Patch-Prozess ist besser als keiner.
Ein rudimentäres CVD-Dokument ist besser als das Fehlen jeder Richtlinie.
Der häufigste und folgenreichste Fehler ist der Versuch, von Anfang an eine vollständige, vollautomatisierte, perfekte Lösung aufzubauen und dabei monatelang gar nicht zu starten.
Vulnerability Management ist ein reifendes Handwerk: Es beginnt als überschaubarer, manuell gepflegter Prozess und wird mit wachsender Erfahrung und besserer Toolchain (ist CYMETRIS erwähnt worden?) schrittweise ausgebaut.
Wer heute anfängt, ist in zwölf Monaten weiter als wer heute auf die perfekte Lösung wartet.
Produktcybersicherheit ist kein Zustand, den man einmalig erreicht. Sie ist ein Prozess, den man dauerhaft betreibt. Eine einmalige Sicherheitsprüfung vor dem Release reicht nicht, wenn das Produkt fünf Jahre oder länger im Feld ist, in dieser Zeit neue Schwachstellen in verwendeten Komponenten entdeckt werden, neue Angriffsmethoden entstehen und sich das Bedrohungsumfeld verändert.
Ein funktionierendes Vulnerability Management besteht aus vier zusammenwirkenden Elementen:
- wissen, was im Produkt steckt (SBOM);
- erfahren, wenn neue Schwachstellen in diesen Komponenten entdeckt werden (Monitoring);
- reagieren können, wenn Handlungsbedarf besteht (Patch-Prozess);
- und transparent kommunizieren, wenn Schwachstellen behoben wurden (CVD-Policy, Security Advisories, Update-Verteilung).
Diese vier Elemente zusammen machen den Unterschied zwischen einem Hersteller, der den CRA als regulatorische Pflichtübung abarbeitet, und einem, der tatsächlich dauerhaft sichere Produkte liefert — und das über fünf Jahre oder mehr nachweisen kann.
