Cyber Resilience Act: Artikel 14 Berichtspflichten treten in Kraft

Die Berichtspflichten nach Artikel 14 des Cyber Resilience Act sind am 11. September 2026 in Kraft getreten und reichen weiter, als viele Softwarehersteller annehmen. Artikel 14 ist der erste Teil des europäischen Cyber Resilience Act, des Gesetzes der Europäischen Union über die Sicherheit von Produkten mit digitalen Elementen, der verbindlich wird. Patchstack, das nach eigenen Angaben mehr als die Hälfte aller bekannten Schwachstellen im WordPress-Ökosystem koordiniert hat und sich als eine der aktivsten Nummerierungsstellen der Welt bezeichnet, hat eine Erklärung zu den neuen Regeln zusammen mit der Einführung eines Dienstes zu deren Handhabung veröffentlicht. Dieser Erklärung zufolge betreffen die Pflichten hauptsächlich Unternehmen, die Produkte mit digitalen Elementen auf dem europäischen Markt bereitstellen, sie gelten aber auch für Maintainer von Open-Source-Software, die das Gesetz als Open-Source-Stewards behandelt. Ein Detail ist für alle wichtig, die annahmen, die Uhr beginne erst mit neuen Veröffentlichungen: Artikel 14 erfasst alle Produkte und Software, einschließlich allem, was vor dem 11. September 2026 auf dem europäischen Markt bereitgestellt wurde.

Zwei Arten von Ereignissen müssen ab diesem Datum gemeldet werden. Das erste ist eine Schwachstelle, die von Angreifern aktiv ausgenutzt wird, also eine Softwareschwäche, die bereits in realen Angriffen genutzt wird und nicht nur eines Tages genutzt werden könnte. Das zweite ist ein schwerwiegender Sicherheitsvorfall, der ein Produkt betrifft. Berichte werden bei nationalen Cybersicherheitsbehörden und bei ENISA, der Agentur der Europäischen Union für Cybersicherheit, über eine einzige EU-Plattform eingereicht. Die Fristen sind streng: eine Frühwarnung innerhalb von 24 Stunden, eine ausführlichere Meldung innerhalb von 72 Stunden und ein detaillierter Abschlussbericht später. Zusätzlich zu den Berichten selbst müssen Hersteller auch die betroffenen Nutzer darüber informieren, was passiert ist und wie sie sich schützen können.

Wer genau die Pflicht trägt, hängt davon ab, wie die Software finanziert wird, und Patchstack verwendet ein WordPress-Plugin, um zu zeigen, wo die Grenze gezogen wird. Wenn der Code des Plugins unter der GPL-Lizenz Open Source ist, der weit verbreiteten Lizenz, die es jedem erlaubt, den Code zu lesen und wiederzuverwenden, das Plugin aber auch eine Premium-Version oder eine andere Möglichkeit hat, Einnahmen für seinen Maintainer zu generieren, dann gilt der Verkäufer als Hersteller und nicht als Open-Source-Steward. Ein völlig kostenloses und quelloffenes Plugin ohne jegliche kommerzielle Absicht, selbst wenn es von Mitarbeitern einer juristischen Person gepflegt wird, wird als Open-Source-Steward behandelt. Die Pflichten nach Artikel 14 gelten in beiden Fällen. Der Unterschied besteht darin, dass ein Open-Source-Steward nicht mit einem Bußgeld belegt werden kann, während die Europäische Union weiterhin andere Mittel nutzen kann, um ein nicht konformes Produkt vom europäischen Markt entfernen zu lassen. Patchstack betont, dass dies für jedes Open-Source-Ökosystem gilt und nicht WordPress-spezifisch ist, das es als Beispiel verwendet, weil Open Source dort nicht kostenlos bedeutet: Alle WordPress-Plugins sind Open Source und GPL-lizenziert, doch die meisten der beliebten sind kommerzielle Produkte.

Jeder Bericht besteht aus drei Formularen, und jedes Formular hat seine eigene Frist. Das erste ist eine Frühwarnung, die ohne unangemessene Verzögerung und in jedem Fall innerhalb von 24 Stunden ab dem Moment eingereicht werden muss, in dem das Unternehmen von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Vorfall Kenntnis erlangt. Das zweite ist die Meldung dieser aktiv ausgenutzten Schwachstelle oder des schwerwiegenden Vorfalls, fällig ohne unangemessene Verzögerung und in jedem Fall innerhalb von 72 Stunden, und sie muss allgemeine Informationen sowie eine erste Einschätzung enthalten. Das dritte ist der Abschlussbericht. Bei einer aktiv ausgenutzten Schwachstelle ist er spätestens 14 Tage nach dem Verfügbarwerden einer Korrekturmaßnahme, wie eines Patches (ein Software-Update, das den Fehler behebt), fällig. Bei einem schwerwiegenden Vorfall ist er innerhalb eines Monats nach der 72-Stunden-Meldung fällig.

Alle diese Berichte müssen über die EU Single Reporting Platform, kurz SRP, eingereicht werden. Patchstacks Rat ist, dass Maintainer ihre Konten sofort anlegen, denn EU-Login-Konten sind persönlich und Multi-Faktor-Authentifizierung, ein zweiter Identitätsnachweis wie ein an ein Telefon gesendeter Code, ist erforderlich, bevor die Plattform erreicht werden kann. Die SRP hat keine API, was bedeutet, dass es keinen automatisierten Weg für ein anderes System gibt, einen Bericht in Ihrem Namen einzureichen, und die Plattform verlangt, dass für jeden einzelnen Bericht drei verschiedene Formulare von Hand ausgefüllt werden. Angesichts einer harten 24-Stunden-Frist sagt Patchstack, dass das sofortige Anlegen der EU-Konten es viel einfacher macht, diese Frist einzuhalten, wenn tatsächlich etwas passiert.

Patchstack nutzte dasselbe Datum, um eine Plattform für Open-Source-Maintainer anzukündigen, die nach eigenen Angaben die Einhaltung von Artikel 14 von Anfang bis Ende abdeckt und zunächst kostenlos zugänglich ist. Das Unternehmen warnt, dass es in Zukunft eine Gebühr pro Bericht einführen könnte, wenn das Berichtsvolumen zu hoch wird und die Single Reporting Platform immer noch keine API hat. Laut Patchstack leistet die Plattform drei Dinge: Sie verfolgt die aktive Ausnutzung einzelner Schwachstellen, sammelt Beweise und alarmiert den Maintainer, sobald die Anforderungen von Artikel 14 ausgelöst werden; sie kann als offizieller benannter Vertreter für den Maintainer fungieren, die Berichte einreichen und jedes Formular innerhalb seiner Frist halten; und sie bietet einen einzigen Kanal für ein Managed Vulnerability Disclosure Programme (mVDP) zusammen mit einem Bug-Bounty-Programm, für ein Produkt oder mehrere. Patchstack sagt, die mVDP-Plattform wurde zu diesem Zweck in Zusammenarbeit mit der Europäischen Union (EIC) entwickelt, und das Unternehmen ist GDPR-konform, nach ISO 27001 und SOC 2 Type 2 zertifiziert und in der EU ansässig. Es sagt auch, dass mehr als 1.000 Open-Source-Produkte und -Projekte bereits sein mVDP für die Schwachstellenkoordination nutzen, und es schreibt Partnerschaften mit großen Webhosting-Unternehmen und seine RapidMitigate-Technologie dem zu, was es als die schnellste und detaillierteste Erkennung bekannter ausgenutzter Schwachstellen (KEVs) auf dem Markt bezeichnet.

Für Website-Betreiber ist die praktische Lesart einfach. Die Personen, die diese Berichte einreichen, sind die Anbieter, nicht die Kunden, sodass ein Site-Betreiber nach einem Angriff auf ein Plugin keine EU-Formulare ausfüllen wird. Was sich ändert, ist der Druck auf diese Anbieter: Eine aktiv ausgenutzte Schwachstelle in einem kommerziellen Plugin setzt seinen Hersteller jetzt unter eine gesetzliche Uhr, um Nutzer zu warnen und zu erklären, wie sie sich schützen können, und die Nichterfüllung hat Konsequenzen. Da die meisten beliebten Plugins kommerziell sind, liegt diese Pflicht bei den Unternehmen dahinter, während kostenlose und nicht-kommerzielle Projekte weiterhin melden müssen, aber nicht mit Bußgeldern belegt werden können. So oder so bleibt der schnellste Schutz für eine Site derselbe, nämlich Sicherheitsupdates zu installieren und Software zu entfernen, die niemand pflegt. Für Teams, die Patch-Fenster lieber nicht selbst verfolgen möchten, ist AEU Hosting unser Managed-WordPress-Hosting-Dienst, der darauf ausgelegt ist, WordPress-Sites von Anfang bis Ende aktuell und sicher zu halten, was genau die Art von Grundlagenarbeit ist, die diese Geschichte belohnt.

Ein Punkt, der es wert ist, wiederholt zu werden, weil er leicht zu übersehen ist: Die Pflichten sind nicht auf Software beschränkt, die nach der Frist veröffentlicht wurde. Produkte und Software, die bereits vor dem 11. September 2026 auf dem europäischen Markt waren, sind ebenfalls erfasst, sodass die relevante Frage für einen Anbieter nicht ist, wann der Code veröffentlicht wurde, sondern ob es eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall zu melden gibt.