EU Cyber Resilience Act (CRA) erklärt: Was WP-Agenturen und -Entwickler wissen müssen

Sie müssen den vollständigen Text des EU-Gesetzes zur Cyber-Resilienz nicht kennen, um seine Präsenz zu spüren. Wenn Sie WordPress-Software (mit kommerzieller Absicht) entwickeln oder warten und diese in der EU verwendet wird, gilt dieses Gesetz höchstwahrscheinlich auch für Sie. 

Die CRA erwartet von Ihnen, dass Sie wissen, welche Abhängigkeiten Ihr Code enthält. Es wird von Ihnen erwartet, dass Sie ein Verfahren einrichten, wenn jemand eine Schwachstelle meldet. Man erwartet von Ihnen, dass Sie Sicherheitsaktualisierungen von allem anderen trennen. Und ja, wenn etwas ausgenutzt wird, haben Sie eine Frist für die Meldung, genau wie jeder andere Anbieter digitaler Produkte in Europa.

Die CRA wird nicht nur Plugin-Entwickler betreffen. Sie betrifft Themeshops, Freiberufler, Agenturen und Menschen, die stapelweise Kunden-Websites mit Code pflegen, den sie nicht selbst geschrieben haben. Sie betrifft Marktplätze. Es betrifft jeden, der Software auf eine Weise vertreibt, die EU-Nutzer erreicht. Der Unterschied besteht darin, dass einige Entwickler ein System haben, um mit diesen Verpflichtungen umzugehen. Die meisten werden es nicht haben.

Sie müssen nicht alles auf einmal überarbeiten. Aber Sie müssen wissen, welche Änderungen auf Sie zukommen, welche Aufgaben Sie haben und an welchen Mindesterwartungen Sie gemessen werden.

Genau darum geht es in diesem Artikel.

Was ist der EU Cyber Resilience Act (CRA)?

Der Cyber Resilience Act (CRA) ist eine europäische Verordnung, die verbindliche Cybersicherheitsanforderungen für alle in der EU verkauften oder vertriebenen digitalen Produkte einführt. Dies gilt sowohl für Hardware (wie Router oder intelligente Geräte) als auch für Software und schließt die Remote-Datenverarbeitungslösungen des Herstellers nur dann ein, wenn diese Lösungen für das Funktionieren des Produkts unerlässlich sind (allgemeine SaaS sind vom Anwendungsbereich ausgeschlossen).

Die CRA wurde vom Europäischen Parlament im März 2024 und vom Rat der EU im Oktober desselben Jahres förmlich verabschiedet. Das Gesetz gilt für alle Produkte mit "digitalen Elementen", die sich mit einem Netzwerk verbinden können, einschließlich Open-Source-Software, Plugins, Apps und eingebettete Systeme.

Die Ratingagentur schließt zwei wesentliche Lücken:

1. Der allgemeine Mangel an eingebauter Sicherheit und zuverlässigen Updates bei digitalen Produkten.
2. Mangelnde Transparenz: Die Benutzer wissen oft nicht, ob ein Produkt sicher ist oder ob der Anbieter tatsächlich Schwachstellen beheben wird.

Um diese Probleme zu lösen, sieht das Gesetz zwei Arten von Anforderungen vor:

• Sicherheit bei Entwicklung und Produktdesign.
• Ein formeller Prozess zur Behandlung von Schwachstellen, einschließlich Offenlegung und Patching.

Diese Regeln gelten für den gesamten Lebenszyklus des Produkts. Aktualisierungen, Reaktion auf Zwischenfälle und Dokumentation fallen alle in den Geltungsbereich. Wenn Ihr Produkt in der EU verwendet wird, unabhängig davon, wo Sie Ihren Sitz haben, und ein kommerzielles Element aufweist, ist die Einhaltung der CRA bis Dezember 2027 obligatorisch.

Quelle für den Geltungsbereich: Gesetz über die Widerstandsfähigkeit im Internet, Artikel 2

Wie sich die CRA auf WordPress-Entwickler und Plugin-Autoren auswirkt

Die CRA gilt für jedes Produkt mit digitalen Elementen, das in der EU angeboten wird. Dazu gehören der WordPress-Kern, Plugins, Themes und sogar SaaS-Tools, wenn sie Daten aus der Ferne verarbeiten. Dabei spielt es keine Rolle, ob das Produkt kostenpflichtig oder kostenlos, quelloffen oder proprietär ist. Wenn es in der EU verwendet wird und direkt oder indirekt ein kommerzielles Element enthält, fällt es unter die Verordnung. Und deshalb greift dieses Gesetz in jede Schicht des WordPress-Ökosystems ein.

Plugin-Entwickler sind "Hersteller" im Sinne der CRA. Wenn Sie ein Plugin anbieten, das eine Pro-Version hat, Daten sammelt, Werbung unterstützt oder von einem Unternehmen gewartet wird, fallen Sie in den Anwendungsbereich. Das Gleiche gilt für Entwickler von Themen und Dienstanbieter. Auch wenn das Plugin selbst kostenlos ist, gilt die CRA, wenn hinter dem Angebot eine kommerzielle Absicht steht.

Es ist ein weit verbreitetes Missverständnis, dass Open-Source-Software ausgeschlossen ist. Das ist nicht der Fall.

Die CRA führt einen eigenen Begriff ein, "Open-Source-Stewardship", um die Rolle von Organisationen wie der WordPress Foundation zu beschreiben. Aber WordPress selbst fehlt derzeit diese Art von strukturierter Verwaltung. Es gibt keine zentrale Koordinierungsstelle dafür, wie Plugin-Anbieter die Offenlegungen, Sicherheitsberichte oder die Reaktion auf Vorfälle handhaben. Diese Verantwortung ist zersplittert und wird oft einzelnen Entwicklern oder kleinen Teams überlassen.

Und das wirft ein tieferes Problem auf. Eine der Anforderungen der CRA ist, dass die Entwickler die Nutzer und die ENISA benachrichtigen müssen, wenn eine Sicherheitslücke aktiv ausgenutzt wird. Aber in den meisten WordPress-Konfigurationen haben die Plugin-Entwickler keine Möglichkeit zu wissen, wer ihre Nutzer sind. Wenn Ihr Plugin von WordPress.org heruntergeladen oder über eine Plattform wie WordPress.com installiert wird, wissen Sie möglicherweise nicht, wer Ihre Nutzer sind. Das Gesetz erwartet jedoch, dass Sie die Nutzer benachrichtigen. Aber so wie WordPress strukturiert ist, können Sie das nicht.

Dieses Problem wurde noch nicht gelöst, und es kann auch nicht von einem einzelnen Plugin-Autor gelöst werden. Es ist die Art von Problem, die Änderungen auf der Ebene des Ökosystems erfordert: koordinierte Sicherheitskennzeichen, strukturierte Metadaten im Plugin-Repository und ein gemeinsames Verständnis darüber, wer welche Verantwortung trägt.

Ab Mitte 2026 wird von den Produkten erwartet, dass sie formelle Verfahren für den Umgang mit Sicherheitslücken einhalten. Dazu gehören ein klarer Ansprechpartner für Sicherheitsmeldungen, ein dokumentierter Zeitplan für die Offenlegung von Schwachstellen und ein Patching-Prozess. Ende 2027 treten dann die vollständigen Anforderungen in Kraft: Sicherheit über den gesamten Lebenszyklus, CE-Kennzeichnung, Rückverfolgbarkeit von Updates und mehr.

Die Entwickler müssen formale Prozesse für den Umgang mit Sicherheitslücken einführen. Das WordPress.org-Plugin-Verzeichnis muss Sicherheitsmarkierungen und Aktualisierungskennzeichnungen unterstützen. Die Foundation muss Anleitungen bereitstellen oder eine klarere Rolle als Verwalterin einnehmen. Die breitere Gemeinschaft wird sich auch mit neuen Begriffen vertraut machen müssen, darunter SBOMs, Vorfallsberichte, Audit-Dokumentation und andere.

Die Zeitspanne ist kurz, und die Verpflichtungen sind spezifisch. Jeder, der auf WordPress aufbaut, Plugin-Teams, Theme-Shops, Agenturen und sogar Einzelpersonen, die für die Wartung zuständig sind, sollten sich überlegen, wie sie diese Verpflichtungen erfüllen können.

Was WordPress-Entwickler tun müssen

Wenn Sie ein Autor von WordPress-Plugins und -Themes sind, finden Sie hier eine kurze Checkliste, die Sie befolgen können:

1. Führen Sie detaillierte Änderungsprotokolle und Aktualisierungsaufzeichnungen, damit Sie nachvollziehen können, wann und wie Sicherheitsprobleme behoben wurden.
2. Informieren Sie die Benutzer, wenn ein Update eine Sicherheitsbehebung enthält (z. B. durch Versionshinweise oder Dashboard-/Admin-Hinweise).
3. Verwenden Sie Tools zur Überwachung von Abhängigkeiten wie z. B. WP Umbrella um verwundbare Pakete frühzeitig zu erkennen.
4. Bemühen Sie sich, Berichte über kritische Schwachstellen innerhalb von 24 bis 72 Stunden zu bearbeiten und zu bestätigen.
5. Legen Sie eine klare Richtlinie für die Offenlegung von Sicherheitsinformationen fest (z. B. indem Sie eine SECURITY.md-Datei zu Ihrem Repository hinzufügen).
6. Stellen Sie Sicherheitsaktualisierungen getrennt von Funktionsaktualisierungen bereit, sofern dies technisch möglich ist, und zwar kostenlos und mit deutlichen Hinweisen.
7. Benennen Sie einen einzigen Sicherheitskontakt und nehmen Sie ihn in die Benutzeranweisungen auf.
   

CRA-Compliance für WordPress-Agenturen und Care-Plan-Anbieter

Agenturen sind bei diesem Wandel nicht nur Zuschauer. Wenn Sie Kunden-Websites verwalten, benutzerdefinierte Themes oder Plugins erstellen oder Pflegepläne anbieten, die Updates und Sicherheitsüberwachung beinhalten, hat die CRA direkte Auswirkungen auf Ihre Arbeitsweise und Ihre Verantwortlichkeiten.

Das offensichtlichste Risiko liegt in der kundenspezifischen Entwicklung. Wenn Ihr Team ein Plugin, ein Modul oder ein Thema entwickelt, egal wie klein, das auf einer Kundenseite in der EU eingesetzt wird, sind Sie nicht nur ein Dienstleister.

Gemäß der CRA sind Sie jetzt ein "Hersteller". Das bedeutet, dass von Ihnen erwartet wird, dass Sie sichere Entwicklungspraktiken anwenden, Ihre Arbeit dokumentieren und ein Verfahren zur Behebung von Schwachstellen bereitstellen. Wenn eines Ihrer Module ausgenutzt wird, haben Sie 24 Stunden Zeit, um die EU-Behörden (ENISA) zu benachrichtigen, und zwei Wochen, um das Problem zu lösen.

Aber auch wenn Sie keinen Code schreiben, sind Sie nicht aus dem Schneider. Die meisten Agenturen agieren als Distributoren oder Importeure, wenn sie Software von Dritten einsetzen. Dazu gehört das Installieren von Plugins von WordPress.org oder das Bündeln von Themes mit neuen Builds. In diesen Rollen wird von Ihnen erwartet, dass Sie überprüfen, ob die von Ihnen verwendeten Produkte den CRA-Standards entsprechen. 

Das bedeutet nicht, dass Sie jede Codezeile überprüfen müssen, aber es bedeutet, dass Sie wissen, wo sich die Software Bill of Materials (SBOM) befindet, dass Sie wissen, wie Sicherheitsaktualisierungen gehandhabt werden, und dass Sie diese Dokumentation aufbewahren. Sie müssen keine SBOMs erstellen, aber Sie müssen in der Lage sein, sie abzurufen.

Für die Anbieter von Pflegeplänen sind die Auswirkungen sogar noch unmittelbarer. Die CRA legt fest, wie schnell Sicherheitsvorfälle behandelt werden müssen. Das bedeutet, dass die Trennung von Funktions-Updates und Sicherheits-Patches eine rechtliche Notwendigkeit ist. Wenn ein von Ihnen verwaltetes Plugin eine kritische Sicherheitslücke aufweist, die aktiv ausgenutzt wird, reicht es nicht aus, auf den nächsten monatlichen Sprint zu warten.

Sie müssen die Website aktualisieren und sich möglicherweise innerhalb weniger Stunden mit dem Plugin-Anbieter, Ihrem Kunden und den Ansprechpartnern bei den Behörden abstimmen. Diese Umstellung wird sich auch auf Ihre Kommunikation mit den Kunden auswirken. Sicherheitsaktualisierungen müssen nach Prioritäten geordnet, dokumentiert und in einigen Fällen archiviert werden.

In den Berichten über die Pflegepläne muss unter Umständen angegeben werden, wann Sicherheits-Patches installiert wurden. Möglicherweise müssen Sie auch Unterlagen wie Risikobewertungen, Aktualisierungsprotokolle und Abhilfemaßnahmen für jede Software, mit der Sie arbeiten, sammeln und aufbewahren.

Es gibt auch ein breiteres Risiko: Viele Agenturen bauen einmalige Lösungen mit kostenlosen Plugins und schnellen Integrationen, die nicht mehr den CRA-Standards entsprechen. Wenn Sie ein kostenloses Plugin einsetzen, das seit Jahren nicht mehr aktualisiert wurde, Schwachstellen nicht offenlegt oder keine SBOMs enthält, gehen Sie ein rechtliches Risiko für Ihren Kunden und sich selbst ein.

Wie die Entwickler von Plug-ins müssen auch die Agenturen anfangen, an die Rückverfolgbarkeit zu denken. Welche Software läuft auf welchen Websites? Wann wurde sie zuletzt aktualisiert? Gibt es eine Dokumentation für den Fall, dass sie kaputt geht oder eine Sicherheitslücke entsteht? Wer ist für den Patching-Prozess zuständig? Im Moment sind diese Informationen über Tabellen, E-Mails und Staging-Server verstreut. Unter CRA wird das nicht mehr ausreichen.

Agenturen, die Pflegepläne erstellen oder Websites im Auftrag von Kunden verwalten, müssen ihre Arbeitsabläufe und Dokumentationsgewohnheiten anpassen. Sie müssen die Wartung wie eine Compliance-Dienstleistung behandeln, nicht nur wie eine Supportpauschale.

CRA-Sanktionen und Geldbußen bei Nichteinhaltung der Vorschriften

Der Cyber Resilience Act (CRA) führt schwerwiegende Durchsetzungsmechanismen bei Nichteinhaltung ein.

Geldbußen und finanzielle Sanktionen

• 15 Millionen Euro oder bis zu 2,5 % des weltweiten Jahresumsatzes (je nachdem, welcher Betrag höher ist) wegen Nichterfüllung wesentlicher Sicherheitsanforderungen (z. B. "Secure-by-design", Umgang mit Sicherheitslücken).
• 10 Millionen Euro oder 2 % des weltweiten Umsatzes bei Verstößen gegen andere Verpflichtungen (Dokumentation, Meldung von Vorfällen).
• 5 Millionen Euro oder 1 % des Umsatzes für die Erteilung falscher oder irreführender Auskünfte.

(Quelle: CRA Artikel 64)

Wichtig ist, dass die Mitgliedstaaten die Befugnis haben, zusätzliche Konsequenzen zu verhängen, wie den Rückruf eines nicht konformen Produkts oder die Anordnung seiner Rücknahme vom EU-Markt.

Wie proaktive WordPress-Sicherheit helfen kann

Im Kern fordert die Ratingagentur proaktiven Schutz. Sie möchte, dass digitale Elemente "von vornherein gesichert" sind. Sie erwartet Maßnahmen, die die Angriffsfläche verringern, bevor Schwachstellen ausgenutzt werden.

Für Behörden und Anbieter von Pflegeplänen bedeutet dies, dass sie über Malware-Scans und Bereinigungsdienste hinausgehen müssen. Sie brauchen Systeme, die bekannte Bedrohungen blockieren, sichere Standardeinstellungen erzwingen und eine nachvollziehbare Aufzeichnung über den Umgang mit Schwachstellen erstellen.

Dies ist der Grund, warum Tools wie WP Umbrelladas Site Protect Add-on von WP Umbrella wertvoll sein. Es vereint eine Reihe von Schutzmaßnahmen, die sich direkt an den Erwartungen der CRA in Bezug auf den Umgang mit Schwachstellen und die Sicherheit im Lebenszyklus orientieren:

• Virtuelles Patching blockiert bekannte Schwachstellen, auch wenn ein Plugin oder Theme noch nicht aktualisiert wurde, und schließt so die Lücke zwischen der Veröffentlichung eines Patches und seiner Bekanntgabe.
• Kontinuierliche Überwachung und Bedrohungsberichte bieten die Art von Prüfpfad, den Agenturen benötigen, um ihren Kunden (oder Aufsichtsbehörden) nachzuweisen, dass Schwachstellen aufgespürt und entschärft werden.

Da Site Protect mehrere Verteidigungsebenen in einer einzigen, leichtgewichtigen Lösung konsolidiert, hilft es Agenturen, einen Flickenteppich von Plugins durch einen strukturierten, überprüfbaren Prozess zu ersetzen. In Kombination mit der Leistungs- und Betriebszeitüberwachung von WP Umbrella, der Verwaltung von Massenupdates für Plugins, Themes und den WordPress-Kern, Update-Protokollen und GDPR-konformen Backups können Behörden Schwachstellen stoppen, bevor sie eskalieren.

Es ist wichtig, sich darüber im Klaren zu sein, dass kein Tool "Compliance in einer Box" bieten kann. Bei der CRA geht es ebenso sehr um Prozesse (Meldung von Vorfällen, SBOMs und Offenlegungsfristen) wie um technische Sicherheitsvorkehrungen. Durch die Einführung proaktiver Sicherheitsmaßnahmen wie virtuelles Patching und automatisches Hardening sind die Agenturen jedoch besser in der Lage, diese Anforderungen zu erfüllen und ihre Kunden in Echtzeit zu schützen.