Melde- und Offenlegungspflichten im Cyber Resilience Act

TL;DR: Ab dem 11. September 2026 verpflichtet der Cyber Resilience Act Hersteller dazu, ausgenutzte Schwachstellen und schwerwiegende Vorfälle über eine zentrale Meldeplattform an die ENISA zu melden. Die Meldefristen sind knapp bemessen, daher müssen Hersteller ihre Prozesse zum Umgang mit Schwachstellen und Vorfällen entsprechend verbessern. Außerdem sollten sie sich mit dem CSAF-Standard vertraut machen, da dieser wahrscheinlich zum primären Format für die Meldung von Schwachstellen an die ENISA werden wird.

Während sich ein Großteil der Diskussion (zumindest auf LinkedIn) auf NIS2 konzentriert, ist mit dem Cyber Resilience Act (CRA) eine weitere EU-Verordnung in Kraft getreten. Teile des CRA gelten ab dem 11. September 2026. Über die Weihnachtsfeiertage habe ich mir die Zeit genommen, den Gesetzestext zu lesen und daraus Schlussfolgerungen zu ziehen, was diese Verordnung für betroffene Kunden bedeutet.

Dieser Blogpost beschäftigt sich mit den Meldepflichten des Cyber Resilience Act, dir in diesem Jahr in Kraft treten. Ich werde auch auf weitere Abschnitte eingehen, die sich mit der Meldung von Sicherheitslücken und Sicherheitshinweisen befassen. Dieser Post ist bei weitem keine umfassende Einführung in die CRA Verordnung. Ich empfehle hierzu das eBook Manufacturing European Software sowie den FAQ - Cyber Resilience Act implementation der EU.

Ich bin (offensichtlich) kein Jurist, und dieser Post stellt keine Rechtsberatung dar. Dieser Beitrag enthält mehrere Zitate aus dem CRA-Verordnungstext. Ich verwende sie hauptsächlich, um meine Annahmen zu untermauern. Du kannst sie überspringen, wenn Du möchtest.

Ziele des Cyber Resilience Acts

Mit dem Cyber Resilience Act verfolgt die Europäische Union in erster Linie folgende Ziele:

• Behebung des unzureichenden Cybersicherheitsniveaus vieler Produkte
  Produkte sollten von Haus aus sicher sein. Anbieter müssen zeitnah Sicherheitsupdates für identifizierte Schwachstellen bereitstellen.

• Unterstützung von Verbrauchern/Unternehmen bei der Beurteilung der Sicherheit von Produkten
  Nutzer sollten in der Lage sein, zu beurteilen, ob das verwendete Produkt auf dem neuesten Stand ist oder bekannte Sicherheitslücken aufweist.

Durch die Verpflichtung der Anbieter zur Meldung und Offenlegung von Schwachstellen versucht der CRA, das zweite Ziel zu erreichen. Anbieter sollten nicht mehr in der Lage sein, unsichere Praktiken wie „Silent Patching” anzuwenden. Die Meldepflichten des Cyber Resilience Act, die am 11. September 2026 in Kraft treten, sollen Verbrauchern helfen, aktive Bedrohungen zu erkennen, die ein umgehendes Handeln erfordern.

Meldepflichten gemäß Artikel 14

Der Cyber Resilience Act trat im Dezember 2024 in Kraft (als EU-Verordnung muss es nicht von den Mitgliedstaaten in nationales Recht umgesetzt werden). Die Meldepflicht für Schwachstellen gilt ab dem 11. September 2026. Die vollständige Durchsetzung aller CRA-Anforderungen beginnt am 11. Dezember 2027.

Die Meldepflichten sind in Artikel 14 beschrieben. Darin ist festgelegt, dass aktiv ausgenutzte Sicherheitslücken (Absatz 1) und „schwerwiegende Sicherheitsvorfälle” (Absatz 3) über eine spezielle Meldeplattform an die ENISA gemeldet werden müssen. Schauen wir uns zunächst die Anforderungen für die Meldung von Schwachstellen an.

Ein Hersteller meldet jede aktiv ausgenutzte Schwachstelle, die in dem Produkt mit digitalen Elementen enthalten ist und von der er Kenntnis erlangt, gleichzeitig dem gemäß Absatz 7 als Koordinator benannten CSIRT und der ENISA…

Aktiv ausgenutzte Schwachstellen

Es ist wichtig zu beachten, dass sich die Verordnung speziell auf aktiv ausgenutzte Schwachstellen bezieht. Hersteller müssen nicht alle Schwachstellen in allen Produkten an die ENISA oder ein lokales CSIRT melden. Schwachstellen, die bei Penetrationstests oder Red-Team-Assessments entdeckt oder ausgenutzt wurden, müssen ebenfalls nicht gemeldet werden. Die Verordnung unterscheidet jedoch nicht zwischen Zero-Day-Schwachstellen und bekannten Sicherheitslücken, die bereits vor Monaten oder Jahren behoben wurden oder Produktversionen betreffen, die nicht länger unterstützt werden. Sie umfasst auch Schwachstellen in Komponenten von Drittanbietern, die in das Produkt integriert wurden. Die CRA definiert aktiv ausgenutzte Schwachstellen in Artikel 3 Absatz 42. Absatz 68 im Abschnitt „n Erwägung nachstehender Gründe“ bringt noch mehr Klarheit:

Bei aktiv ausgenutzten Schwachstellen handelt es sich um Fälle, in denen ein Hersteller feststellt, dass eine Sicherheitsverletzung, die sich auf seine Nutzer oder andere natürliche oder juristische Personen auswirkt, darauf zurückzuführen ist, dass ein böswilliger Akteur einen Fehler in einem der Produkte mit digitalen Elementen nutzt, die vom Hersteller auf dem Markt bereitgestellt werden. Bei solchen Schwachstellen kann es sich beispielsweise um Schwächen in den Identifizierungs- und Authentifizierungsfunktionen eines Produkts handeln. Schwachstellen, die ohne böswillige Absicht bei in gutem Glauben ausgeführten Tests, Untersuchungen, Korrekturen oder Offenlegungen, die auf die Sicherheit und den Schutz des Systemeigners und seiner Nutzer abzielen, festgestellt werden, sollten nicht meldepflichtig sein.

Schwerwiegende Sicherheitsvorfälle

Hersteller müssen nun auch sämtliche schwerwiegenden Sicherheitsvorfälle melden, die Auswirkung auf die Sicherheit von CRA-regulierten Produkten haben könnten. Hier Artikel 14 Absatz 3:

Ein Hersteller meldet jeden schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt und von der er Kenntnis erlangt, gleichzeitig dem gemäß Absatz 7 als Koordinator benannten CSIRT und der ENISA. …

Die Verordnung definiert einen “schwerwiegenden Sicherheitsvorfall” in Artikel 14, Absatz 5.

Für die Zwecke von Absatz 3 gilt ein Sicherheitsvorfall, der Auswirkungen auf die Sicherheit des Produkts mit digitalen Elementen hat, als schwerwiegend, wenn

(a) er sich negativ auf die Fähigkeit eines Produkts mit digitalen Elementen auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von sensiblen oder wichtigen Daten oder Funktionen zu schützen, oder

(b) er zur Einführung oder Ausführung eines böswilligen Codes in einem Produkt mit digitalen Elementen oder im Netzwerk und Informationssystem eines Nutzers des Produkts mit digitalen Elementen geführt hat oder dazu führen kann.

Der entscheidende Wortlaut lautet „auswirken kann“. Beispielsweise gilt eine Kompromittierung, in der ein Angreifer unter anderem Zugriff auf den Build Umgebung einer Anwendung erhält, als schwerwiegender Vorfall, auch wenn keine nachweisbare Manipulation von Builds erfolgte.

Meldepflichten und Fristen

Sowohl für ausgenutzte Schwachstellen als auch für schwerwiegende Vorfälle legt der Cyber Resilience Act strenge Fristen fest. Für ausgenutzte Schwachstellen gilt:

• Innerhalb von 24 Stunden nach Kenntnis der Ausnutzung muss der Hersteller eine Frühwarnung zur Schwachstelle an die ENISA übermitteln.
• Innerhalb von 72 Stunden muss der Hersteller Einzelheiten zu den betroffenen Produktversionen, der Art der Schwachstelle sowie zu allen angewandten oder verfügbaren Maßnahmen zur Risikominderung bereitstellen.
• Innerhalb von 14 Tagen muss der Anbieter eine vollständige Beschreibung der Schwachstelle, Informationen über den Angreifer (sofern bekannt), der die Schwachstelle ausgenutzt hat, sowie Einzelheiten zu Sicherheitsupdates oder Korrekturmaßnahmen vorlegen.

Ich gehe davon aus, dass diese Informationen im Abschnitt „Known Exploited Vulnerabilities” Datensatz aufgenommen werden. Die ENISA stellt diesen bereits über die EU-Schwachstellendatenbank (EUVD) zur Verfügung.

Die Fristen für schwerwiegende Vorfälle sind ähnlich. Für die Einreichung des endgültigen Vorfallsberichts steht jedoch mehr Zeit zur Verfügung. Die Frist beträgt einen Monat statt 14 Tage.

In beiden Fällen müssen Anbieter die neue zentrale Meldeplattform für die Einreichung ihrer Berichte nutzen. Derzeit ist diese Plattform noch nicht verfügbar. Mann kann sich aber die technischen Spezifikationen in der öffentlichen Ausschreibung ansehen, um uns ein erstes Bild von den zu erwartenden Funktionen zu machen.

Leider liefert die ENISA derzeit keine Beispiele dafür, was sie in den einzelnen Berichtsschritten einfordert. Auf der Grundlage der technischen Spezifikationen gehe ich jedoch davon aus, dass CSAF-basierte Advisorys (siehe unten) erwartet werden.

Als Hersteller ist es wichtig zu beachten, dass man nach der Registrierung einem CSIRT zugewiesen wird, basierend auf dem Land, in dem man registriert ist. Dieses CSIRT bestätigt dann die Registrierung. Die Sicherheitsteams der Anbieter sollten diesen Schritt im Voraus erledigen, um Zeit zu sparen falls sie eine Schwachstelle oder einen Vorfall melden müssen.

Was ist mit den Kunden?

Bisher haben wir nur die Meldepflichten gegenüber der ENISA behandelt. Anbieter müssen jedoch auch ihre Kunden über die Schwachstelle und mögliche Abhilfemaßnahmen informieren. Andernfalls wird das zuständige CSIRT (sofern möglich) versuchen, dies zu tun. Diese Anforderung ist in Artikel 14 Absatz 8 festgelegt:

Nachdem der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt, erlangt hat, informiert er die betroffenen Nutzer des Produkts mit digitalen Elementen und gegebenenfalls alle Nutzer über diese Schwachstelle oder diesen schwerwiegenden Sicherheitsvorfall und erforderlichenfalls über jegliche Risikominderungsmaßnahmen und Korrekturmaßnahmen, die die Nutzer ergreifen können, um die Auswirkungen dieser Schwachstellen oder Sicherheitsvorfälle zu mindern, gegebenenfalls in einem strukturierten, maschinenlesbaren Format, das leicht automatisch zu verarbeiten ist. Versäumt es der Hersteller, die Nutzer des Produkts mit digitalen Elementen rechtzeitig zu informieren, können die als Koordinatoren benannten CSIRTs diese Informationen den Nutzern zur Verfügung stellen, wenn sie dies für verhältnismäßig und erforderlich halten, um die Auswirkungen dieser Schwachstellen oder Sicherheitsvorfälle zu verhindern oder abzumildern.

Es ist wichtig zu verstehen, dass Anbieter nicht nur Warnungen zu aktiv ausgenutzten Schwachstellen herausgeben müssen. Sie müssen auch Warnungen zu bekannten/behobenen Schwachstellen veröffentlichen, selbst wenn diese nicht aktiv ausgenutzt wurden. Eine Meldung an ENISA muss in diesem Fall aber nicht erfolgen. Aus dem CRA Anhang I, Teil II (Anforderungen an die Behandlung von Schwachstellen).

Die Hersteller von Produkten mit digitalen Elementen müssen:…
(4)…sobald eine Sicherheitsaktualisierung bereitgestellt worden ist, Informationen über beseitigte Schwachstellen teilen und veröffentlichen, einschließlich einer Beschreibung der Schwachstellen mit Angaben, anhand deren die Nutzer das betroffene Produkt mit digitalen Elementen, die Auswirkungen der Schwachstellen und ihre Schwere erkennen können, sowie eindeutige und verständliche Informationen, die den Nutzern helfen, die Schwachstellen zu beheben; in hinreichend begründeten Fällen, in denen die Hersteller der Auffassung sind, dass die Risiken der Veröffentlichung die Vorteile in Bezug auf die Sicherheit überwiegen, können sie die Veröffentlichung von Informationen über eine behobene Schwachstelle so lange aufschieben, bis den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden;

Dies ist im Großen und Ganzen eine gute Sache, da dadurch die Möglichkeit „stiller Patches” für kritische Schwachstellen beseitigt wurde, auch wenn einige Anbieter die „Verzögerung” bis zum Äußersten ausdehnen werden. Dies ist jedoch nicht Teil von Artikel 14 der Verordnung und tritt daher erst am 11. Dezember 2027 in Kraft.

Optimierung des Umgangs mit Schwachstellen

Aufgrund enger Fristen müssen Anbieter die Meldewege für potenzielle Schwachstellen und Sicherheitsvorfälle optimieren. Dazu gehört:

Machen Sie klare Angaben zur Meldung von Sicherheitslücken und Sicherheitsvorfällen
In der Vergangenheit hatte ich mit mehreren Anbietern zu tun, bei denen ich gezwungen war, Standard-Support- oder Vertriebskanäle zu nutzen, um eine Schwachstelle zu melden. Im schlimmsten Fall wurde die Meldung blockiert, weil ich keinen Kunden vertrat. Daher sollten Anbieter klare Angaben dazu machen, wie Schwachstellen gemeldet werden können. Dies wird zwar auch im Cyber Resiliance Act (in Abschnitt 76) erwähnt, ist jedoch keine Verpflichtung. Ich empfehle hier den Practical Guide to Vulnerability Handling and Disclosure des Global CVE Allocation System, der eine gut verständliche Einführung in dieses Thema bietet.

Weisen Sie die Vertriebs- und Kundensupport-Teams an, diese Informationen an das Sicherheitsteam weiterzuleiten
Diese Teams stehen oft in direktem Kontakt mit den Kunden. Daher sind sie möglicherweise die ersten, die Berichte über ausgenutzte Schwachstellen erhalten, die sie dann an das Sicherheitsteam weiterleiten müssen. Dies gilt auch, wenn die Schwachstelle bereits behoben wurde, da alle ausgenutzten Schwachstellen an die ENISA gemeldet werden müssen.

Testen Sie den Prozess zur Behandlung von Schwachstellen
Der Prozess zur Behandlung eingehender Schwachstellenmeldungen sollte regelmäßig getestet werden. Beispielsweise können Hersteller die Ergebnisse eines Penetrationstests verwende, um den Meldeprozess zu validieren und sicherzustellen, dass er wie vorgesehen funktioniert. Die Tests sollten auch den Prozess der Meldung des Problems an die ENISA, die Erstellung der offiziellen Advisories und die Information der Kunden umfassen.

CSAF (Common Security Advisory Framework)

Beim Lesen des Cyber Resilience Act (und der dazugehörigen Dokumente) bin ich zum ersten Mal bewusst auf das Common Security Advisory Framework (CSAF) aufmerksam geworden. Vereinfacht gesagt handelt es sich bei CSAF um ein JSON-basiertes Format zur Veröffentlichung von Schwachstellen-Advisories. Es definiert darüber hinaus Möglichkeiten, wie diese Advisorys automatisch veröffentlicht und abgerufen werden können. CSAF ist ein internationaler Standard, aber das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) scheint die treibende Kraft bei seiner Entwicklung und Verbreitung zu sein.

Der CSAF Standart taucht in mehreren Dokumenten zum Cyber-Resilienz-Gesetz auf. So heißt es beispielsweise in der technischen Spezifikation der zentralen Meldeplattform, dass Hersteller in der Lage sein müssen, Daten in diesem Format hochzuladen.

Data Exchange Standard: Primarily use CSAF (Common Security Advisory Framework) in JSON format for data exchange.

Hersteller-Advisories

Wenn es um Sicherheitshinweise geht, denken die meisten Sicherheitsexperten an das Programm „Common Vulnerability and Exposure“ (CVE) (https://www.cve.org/). Sein Ziel ist es, Schwachstellen in der Cybersicherheit zu identifizieren, zu definieren und zu katalogisieren. Das CVE-Programm definiert auch ein JSON-basiertes Datensatzformat. Warum brauchen wir also ein weiteres Format? Weil es besser zu den Anforderungen der Anbieter passt.

Zunächst einmal erhalten viele Anbieter nicht für jede Schwachstelle in ihren Produkten eine CVE-ID. In der Vergangenheit war der CVE-Prozess komplex, insbesondere für Teams, die damit nicht vertraut waren. Diese Situation hat sich in den letzten Jahren aufgrund der wachsenden Zahl von CVE Naming Authorities (CNAs), die CVE-IDs vergeben können, verbessert. Es kann jedoch immer noch einige Zeit dauern, bis man eine CVE-ID erhält, auf die man in einem Advisory verweisen kann.

Ein weiteres Problem, das mit CSAF-basierten Empfehlungen einfacher zu lösen ist, sind Schwachstellen in Abhängigkeiten. Nehmen wir an, wir haben eine kritische Schwachstelle wie CVE-2025-55182 (React2Shell), die eine große Anzahl von Produkten betrifft. Das CVE-JSON-Format definiert einen „affected” Abschnitt, in dem betroffene Produkte aufgelistet werden, aber ein Anbieter müsste sich an die CNA wenden, die die CVE zugewiesen hat, um diesen Datensatz mit einer Liste seiner eigenen Produkte zu aktualisieren. Dies ist für Schwachstellen, die eine große Anzahl von Produkten betreffen, nicht praktikabel. Aus diesem Grund gibt es separate Datenbanken für weit verbreitete Schwachstellen wie Log4shell (CVE-2021-44228).

Auf der anderen Seite würden Benutzer und Unternehmen, die wissen möchten, ob sie von einer solchen Schwachstelle betroffen sind, viel Zeit damit verbringen, solche Datenbanken zu finden. Im schlimmsten Fall könnten Kunden die Hersteller kontaktieren, um zu fragen, ob ein Produkt betroffen ist, wie es im Fall der Log4shell-Schwachstelle mehrfach vorgekommen ist. CSAF vereinfacht diesen Prozess, indem es Herstellern ermöglicht, Advisories zu veröffentlichen, die mehrere Schwachstellen bündeln. Das Format ermöglicht es den Herstellern weiterhin, jede Schwachstelle separat zu beschreiben und bei Bedarf auf CVEs zu verweisen. Es beschreibt außerdem klare Wege, wie Unternehmen diese Advisories automatisch erhalten können.

Aus dem CSAF FAQ:

CSAF is not a replacement for CVE. A CSAF document may include one or many security vulnerabilities that have been assigned a CVE. Not all vulnerabilities are assigned a CVE. CSAF also allows for any organization to be able to disclose or consume security vulnerabilities or responses that do not have an assigned CVE.

Wenn Sie sehen möchten, wie eine CSAF-basierte Advisory aussieht, empfehle ich die von Open-Xchange GmbH veröffentlichten Advisories.

CSAF Profile und Icident Response

Der CSAF-Standard kann nicht nur für Advisories verwendet werden, da er mehrere Profile enthält, die verschiedene Anwendungsfälle abdecken. Die Profilliste umfasst ein Profil für die Reaktion auf Sicherheitsvorfälle, das zur Reaktion auf Security Incidents verwendet werdet werden sollte. Ich gehe davon aus, dass die ENISA-Meldeplattform diese Art von CSAF-Dokument verlangt, wenn Anbieter einen schwerwiegenden Vorfall melden müssen.

Letzte Worte

Der Cyber Resilience Act führt zusätzliche Meldepflichten ein. Diese Pflichten beziehen sich in erster Linie auf aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle. Anbieter, bei denen die Produktsicherheit bereits großgeschrieben wird, dürften hier kaum Probleme haben. Dennoch ist jetzt ein guter Zeitpunkt, um die Meldeprozesse und die Art und Weise, wie Security Advisories veröffentlicht werden, zu prüfen.

Die entscheidende Frage ist, wie Kunden diese Informationen nutzen werden. Selbst heute noch sind wir mit vielen gut dokumentierten Sicherheitslücken konfrontiert, aber viele betroffene Instanzen oder Geräte bleiben ungepatcht. Ich hoffe, dass andere Teile der CRA, wie beispielsweise die Verpflichtung zur Bereitstellung automatischer Updates, hier Abhilfe schaffen werden.

Danke an Diana Polekhina bei Unsplash für das Titelbild.