CRA-Meldepflicht: Was Agenturen beachten müssen, die Shopware-Plugins oder Symfony-Bundles ausliefern

Inhalt

1. Ausgangslage: Wann Ihre Agentur Hersteller ist
2. Drei Wege, mit der Meldepflicht umzugehen
3. Woran Sie erkennen, ob Ihr Prozess trägt
4. Was Sie diese Woche angehen sollten

Die letzte Woche war für viele Agenturen anstrengend genug. Am 21. Oktober kam das PHP-Sicherheitsupdate gegen PHP2Shell, kurz danach folgten Sicherheitslücken in FrankenPHP. Server patchen, Kunden informieren, Worker neu starten: Das war die operative Arbeit. Wenn sie erledigt ist, bleibt eine Frage, die sich viele bisher nicht gestellt haben. Was wäre gewesen, wenn die Lücke nicht im Interpreter gesteckt hätte, sondern in einem Plugin, das Ihre Agentur selbst ausliefert?

Seit dem 11.09.2026 hat diese Frage eine rechtliche Seite. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen zu melden. Die Fristen sind kurz. Viele Agenturen, die Shopware-Plugins oder Symfony-Bundles vertreiben, haben dafür noch keinen Ablauf. Das ist verständlich, denn die Pflicht ist neu und die meisten Texte dazu richten sich an Hardware-Hersteller. Dieser Artikel ordnet ein, was für Agenturen gilt und welche Entscheidung jetzt ansteht. Den technischen Notfall selbst behandelt der Beitrag zum PHP-Sicherheitsupdate vom 21. Oktober. Hier geht es um Prozess und Verantwortung.

Ausgangslage: Wann Ihre Agentur Hersteller ist

Der CRA spricht von „Produkten mit digitalen Elementen“. Dazu zählt auch reine Software. Die Kanzlei Rickert bringt es auf eine kurze Formel: Software ist ein Produkt, wer Software ausliefert, ist Hersteller. Für Agenturen heißt das konkret: Wer ein Plugin im Shopware Store verkauft oder ein Bundle als lizenziertes Produkt an mehrere Kunden vertreibt, fällt nach dieser Auslegung unter die Herstellerpflichten.

Weniger eindeutig ist die reine Auftragsentwicklung für einen einzelnen Kunden. Ob individuell entwickelter Code als „auf dem Markt bereitgestellt“ gilt, hängt von Vertrag und Vertriebsweg ab. Diese Abgrenzung sollten Sie mit Ihrer Rechtsberatung klären. Für die praktische Vorbereitung hilft sie wenig. Die Prozesse, die der CRA verlangt, sind auch bei Kundenprojekten sinnvoll.

Zeitlich gilt Folgendes. Seit dem 11.09.2026 gilt Art. 14 mit den Meldepflichten. Bei einer aktiv ausgenutzten Schwachstelle ist innerhalb von 24 Stunden eine Frühwarnung fällig, innerhalb von 72 Stunden eine ausführlichere Meldung, später ein Abschlussbericht. Gleiches gilt für schwerwiegende Sicherheitsvorfälle. Die übrigen Pflichten, etwa zu Konformität und Dokumentation, gelten ab dem 11.12.2027. Laut Rickert erfasst die Meldepflicht auch Produkte, die schon vor September auf dem Markt waren.

Bei den Bußgeldern lohnt ein genauer Blick. Die oft zitierte Ausnahme für kleine Unternehmen ist enger, als sie meist dargestellt wird. Nach Art. 64 Abs. 10 lit. a gilt sie nur für Kleinst- und Kleinunternehmen und nur für die 24-Stunden-Frühwarnung. Die 72-Stunden-Meldung und der Abschlussbericht sind nicht ausgenommen, mittlere Unternehmen gar nicht. Ab wann die Bußgeldvorschriften überhaupt anwendbar sind, wird in Sekundärquellen unterschiedlich dargestellt. Verlassen sollten Sie sich darauf nicht. Die Meldepflicht selbst gilt unabhängig davon.

Drei Wege, mit der Meldepflicht umzugehen

Option 1: Abwarten bis Dezember 2027

Manche Agenturen planen, sich erst mit der vollen Geltung des CRA zu beschäftigen. Das spart heute Aufwand. Es übersieht aber, dass Art. 14 bereits gilt. Tritt vorher eine aktiv ausgenutzte Lücke in einem eigenen Plugin auf, muss die Meldung innerhalb der Fristen stehen. Wer dann erst klären muss, wer zuständig ist, an welche Stelle gemeldet wird und welche Kunden betroffen sind, schafft 24 Stunden kaum. Das Risiko liegt weniger im Bußgeld als im Vertrauensverlust bei Kunden, die erfahren, dass ihr Dienstleister keinen Ablauf hatte.

Option 2: Minimalprozess für die Meldepflicht

Der pragmatische Weg: Sie definieren, wer Sicherheitshinweise annimmt, wer eine Schwachstelle bewertet und wer meldet. Dazu kommen eine öffentlich erreichbare Kontaktadresse für Sicherheitsmeldungen und eine Vorlage für Frühwarnung und Folgemeldung. Der Aufwand ist überschaubar und lässt sich in wenigen Tagen umsetzen.

Die Grenze dieses Ansatzes zeigt sich bei der Bewertung. Um zu entscheiden, ob eine Lücke Ihr Produkt betrifft, müssen Sie wissen, welche Komponenten in welcher Version darin stecken. Ohne diese Übersicht wird die Bewertung zur Suche, und die Frist läuft.

Option 3: Schwachstellenmanagement mit SBOM

Hier wird für jedes ausgelieferte Plugin oder Bundle automatisch eine Software Bill of Materials erzeugt. Sie listet alle Abhängigkeiten mit Versionen. Bekannte Schwachstellen werden laufend gegen diese Liste geprüft. Für Composer-Projekte ist das mit vorhandenen Werkzeugen machbar und lässt sich in die bestehende CI einbinden:

# SBOM-Generator als Entwicklungsabhängigkeit installieren
composer require --dev cyclonedx/cyclonedx-php-composer

# Maschinenlesbare SBOM im CycloneDX-Format erzeugen,
# zum Beispiel bei jedem Release-Build in der CI
composer CycloneDX:make-sbom --output-format=JSON --output-file=sbom.json

# Bekannte Schwachstellen in den installierten Abhängigkeiten prüfen
composer audit

Der Code zeigt, warum diese Option mehr ist als Bürokratie. Mit SBOM und regelmäßigem Audit beantworten Sie die Frage „Sind wir betroffen?“ in Minuten. Genau diese Antwort brauchen Sie, bevor die 24-Stunden-Frist läuft. Der Aufwand liegt in der Einrichtung und in der Pflege über alle ausgelieferten Versionen hinweg.

Ein Punkt wird bei Plugins oft übersehen. Ein Shopware-Plugin liefert den Interpreter nicht mit. Eine Lücke wie PHP2Shell ist deshalb in der Regel keine meldepflichtige Schwachstelle Ihres Plugins. Anders sieht es bei Abhängigkeiten aus, die Sie mit ausliefern, etwa gebündelte Bibliotheken im vendor-Verzeichnis eines Plugins. Hier hilft die SBOM, die Grenze sauber zu ziehen.

Woran Sie erkennen, ob Ihr Prozess trägt

Ob Option 2 reicht oder Option 3 nötig ist, hängt von der Zahl Ihrer Produkte und Versionen ab. Vier Fragen helfen bei der Einordnung.

Können Sie innerhalb einer Stunde sagen, welche Plugin-Versionen eine bestimmte Bibliothek enthalten?

Wenn die Antwort nur mit manueller Suche durch mehrere Repositories möglich ist, fehlt die SBOM. Bei einem einzelnen Plugin mag das noch gehen. Bei mehreren Produkten mit parallelen Versionen für unterschiedliche Shopware-Linien wird es knapp.

Gibt es eine feste Stelle, an der Sicherheitshinweise ankommen?

Hinweise kommen über viele Wege: Store-Bewertungen, Support-Tickets, E-Mails an einzelne Entwickler. Wenn niemand für den Eingang verantwortlich ist, beginnt die Frist, ohne dass jemand es merkt. Eine eigene Adresse und eine benannte Person sind die Mindestanforderung.

Ist geregelt, wer meldet, wenn die zuständige Person ausfällt?

Eine 24-Stunden-Frist verträgt keinen Urlaub ohne Vertretung. Gerade in kleinen Teams ist das die eigentliche Schwachstelle. Der Artikel zum Bus-Faktor bei Eigenentwicklungen beschreibt, wie sich Wissen und Zuständigkeiten so verteilen lassen, dass sie einen Ausfall überstehen.

Wissen Ihre Kunden, wer im Ernstfall handelt?

Eine Lücke in Ihrem Plugin betrifft die Shops Ihrer Kunden. Die Meldung an die Behörde ist eine Seite, die Information der Betreiber eine andere. Beides sollte in Wartungsverträgen sauber geregelt sein. Wie ein solcher Rahmen mit festen Reaktions- und Patch-Zeiten aussieht, steht im Beitrag zum Wartungsvertrag für Symfony-Anwendungen.

Beantworten Sie zwei oder mehr dieser Fragen mit „nein“, reicht ein Minimalprozess voraussichtlich nicht aus. Dann lohnt es sich, SBOM und Audit jetzt einzuführen, solange kein konkreter Vorfall Druck macht.

Was Sie diese Woche angehen sollten

Die Woche nach PHP2Shell ist ein guter Zeitpunkt für eine nüchterne Bestandsaufnahme. Listen Sie alle Plugins und Bundles auf, die Ihre Agentur an Dritte ausliefert. Klären Sie für jedes, ob Sie als Hersteller gelten, und lassen Sie die Grenzfälle rechtlich prüfen. Benennen Sie eine verantwortliche Person samt Vertretung und richten Sie eine Kontaktadresse für Sicherheitsmeldungen ein. Wenn das steht, folgt die SBOM für das Produkt mit den meisten Installationen. Der Rest lässt sich danach Produkt für Produkt nachziehen. Wer dafür Unterstützung bei der technischen Umsetzung sucht, findet auf der Seite zum Symfony-Entwickler für Wartung und Sicherheit den Einstieg.