Lizenzfristen von Erweiterungen: Updates nicht verlieren

Die Größenordnung erklärt, warum sich der Aufwand für ein Register lohnt. Eine Vorbemerkung gehört davor: Alle Zahlen dieses Abschnitts stammen aus einer Schwachstellendatenbank für das WordPress-Ökosystem, weil dort öffentlich ausgewertet wird, was für den Shopware-Store nicht vorliegt. Ihre Übertragung auf einen Shop ist deshalb eine Annahme, gestützt auf die gleiche Bauweise - schlanker Kern, viele zugekaufte Erweiterungen, jede mit eigener Frist -, nicht auf eine Messung im eigenen Bestand. Allein im Jahr 2025 wurden dort 11.334 (Patchstack) neue Schwachstellen erfasst. Davon galten 4.124 (36 %) (Patchstack) als so ernst, dass sie eine sofortige Schutzmaßnahme verlangten - nicht ein Update in der nächsten Wartungsrunde, sondern eine Regel, die den Angriff sperrt, bis das Update da ist. Der Anteil, der auf Erweiterungen entfällt, liegt bei 91 % (Patchstack); der Systemkern spielt in dieser Statistik eine kleine Nebenrolle. Wer den Kern gewissenhaft aktualisiert und die Erweiterungen laufen lässt, pflegt damit ausgerechnet den kleineren Teil der Angriffsfläche.

Zwei Befunde aus demselben WordPress-Datensatz widersprechen der üblichen Erwartung. Erstens war fast die Hälfte der Meldungen zum Zeitpunkt der Veröffentlichung noch offen: 46 % (Patchstack) der Schwachstellen hatten keine rechtzeitige Korrektur des Entwicklers. Zweitens schneiden ausgerechnet die kostenpflichtigen Bausteine schlechter ab - bei den tatsächlich beobachteten Angriffen zählten sie dreimal so viele (Patchstack) bereits ausgenutzte Schwachstellen als die kostenlosen. Der Kaufpreis ersetzt also nicht die Frage, wie lange und wie zuverlässig der Anbieter die Erweiterung pflegt. Er verschiebt sie nur an eine Stelle, an der sie seltener gestellt wird.

Der letzte Punkt trifft Betreiber besonders hart, weil er außerhalb ihrer Reichweite liegt. Im Berichtsjahr davor wurden 1.614 (Patchstack) Erweiterungen und Vorlagen wegen ungeklärter Sicherheitsprobleme aus dem WordPress.org-Verzeichnis genommen - ein Beispiel aus einem fremden Baukastensystem, das den Vorgang zeigt und nicht die Zahl für den Shopware-Store. Im Shop laufen sie danach unverändert weiter: Das Verzeichnis ist der Ort, an dem sie verschwinden, nicht die Installation. Ein Bestandsaudit der Erweiterungen prüft deshalb nicht nur Laufzeit und Wirkung, sondern auch die schlichte Frage, ob es die Quelle überhaupt noch gibt und wer sie heute betreibt.

Erweiterungen altern nicht für sich allein. Sie altern gegen einen Takt, den zwei andere Schichten vorgeben. Das Shopsystem veröffentlicht seine kleinen Fassungen jeden ersten Montag im Monat (Shopware) und die großen Sprünge einmal im Jahr. Wichtiger als der Rhythmus ist die Kopplung: Der Wechsel in eine niedrigere Unterstützungsstufe ist an Major-Releases gebunden, nicht an feste Termine (Shopware). Wer seine Planung an Kalenderjahren aufhängt, plant deshalb an der Wirklichkeit vorbei. Die tragfähige Achse ist die Releasefolge, und die Lizenzfristen der Erweiterungen müssen auf dieser Achse liegen, nicht auf einer eigenen.

Am Ende dieser Folge steht eine Stufe, die im Betrieb regelmäßig überrascht. Eine Fassung außerhalb des regulären Supports erhält nur noch Sicherheitskorrekturen (Shopware), und diese Korrekturen kommen über ein eigenes Sicherheitspaket statt über den gewohnten Aktualisierungsweg. Für den Erweiterungsbestand bedeutet das doppelte Arbeit: Der bekannte Update-Befehl greift nicht mehr, und jede Erweiterung muss zusätzlich gegen die Fassung geprüft werden, für die es überhaupt noch Korrekturen gibt. Eine belastbare Update-Strategie trennt darum von Anfang an zwischen Systemsprung, Erweiterungspflege und Laufzeitumgebung - drei Fristen, drei Verantwortliche, ein Kalender.

Die Laufzeitumgebung unter dem Shop verdient dabei eine eigene Zeile im Register, weil ihre Frist die härteste ist. Jeder Entwicklungszweig der eingesetzten Skriptsprache wird ab der ersten stabilen Fassung zwei Jahre (The PHP Group) vollständig unterstützt, danach folgen zwei weitere Jahre (The PHP Group) mit ausschließlich sicherheitsrelevanten Korrekturen. Vier Jahre klingen nach viel. Gemessen an einem Markt, der mehrere Tausend Erweiterungen (Shopware) führt und in dem jede Erweiterung ihre eigene Lizenz- und Freigabefrist mitbringt, ist es ein enges Fenster. Wie ein solcher Wechsel ohne Ausfall gelingt, zeigt der Beitrag zum Wechsel der Laufzeitumgebung.

Ein Lizenzregister ist keine Datenbank, sondern eine Gewohnheit. Es genügt eine Tabelle mit sechs Spalten, die bei jedem Kauf, jeder Verlängerung und jeder Abschaltung angefasst wird. Entscheidend ist weniger das Werkzeug als die Frage, wer sie anfasst und wann. In der Shopware-Wartung hängt das Register am monatlichen Wartungslauf: Der Bestand wird gegen die Installation abgeglichen, jede Abweichung wird notiert, und jede Frist im Vorlauffenster wird zu einer Entscheidung mit Namen und Datum. Was daran automatisiert werden kann, sollte automatisiert werden - der Rest bleibt eine Aufgabe für Menschen, weil die Antwort „ersetzen oder abschalten“ selten technisch ist.

Der häufigste Fehler beim ersten Aufbau ist die Vollständigkeit aus der Rechnung statt aus dem System. Rechnungen zeigen, was gekauft wurde; die Installation zeigt, was läuft. Dazwischen liegen erfahrungsgemäß abgeschaltete Bausteine, die weiterhin Code mitbringen, Testinstallationen, die produktiv geworden sind, und Erweiterungen aus Projekten, an die sich niemand mehr erinnert. Erst der Abgleich beider Seiten ergibt ein Register, das trägt. Wie die laufenden Sicherheitsupdates daran andocken, entscheidet sich an derselben Stelle: Ohne belastbaren Bestand ist jede Priorisierung eine Vermutung.

Im Handel ist das Ausnutzen von Schwachstellen mit 42 % (Verizon) der mit Abstand häufigste Einstiegsweg bei bestätigten Datenabflüssen. In 68 % (Verizon) der Fälle steckt zusätzlich eine dritte Partei mit drin: ein Dienstleister, ein Hoster oder eben zugekaufte Software. Über alle Branchen hinweg liegt der Anteil der Vorfälle mit Drittbeteiligung bei 48 % (Verizon). Eine Erweiterung ohne Update-Anspruch ist genau so eine dritte Partei - nur eine, die niemand mehr betreut. Wie schnell ein solcher Zustand auf die Sichtbarkeit durchschlägt, zeigt der Beitrag zum neuen Pflichthinweis auf Produktseiten, der nach einem Systemsprung ebenso lautlos verschwinden kann.

Die deutsche Erhebungslage stützt das Bild aus der Betreiberperspektive. Bei den geschädigten Unternehmen waren technische Schwachstellen in 50 Prozent (Bitkom) der Fälle ein Grund für den entstandenen Schaden, veraltete Hard- oder Software in 43 Prozent (Bitkom). Auf Cyberangriffe entfallen inzwischen 76 Prozent (Bitkom) der Gesamtschäden, deren Höhe mit 211 bis 270,8 Milliarden Euro (Bitkom) im Jahr angegeben wird. Das sind Zahlen für die gesamte Wirtschaft, nicht für einen einzelnen Shop; ihre Aussage für den Betrieb liegt im Verhältnis: Der Anteil, der auf veraltete Software zurückgeht, ist kein Randposten.

Dass diese Last vor allem kleine und mittlere Betriebe trifft, ist keine Vermutung: rund 80 Prozent (BSI) der angezeigten Angriffe richteten sich gegen kleine und mittlere Unternehmen. Zugleich wächst der Markt, in dem diese Betriebe arbeiten - der deutsche Onlinehandel erreichte zuletzt 92,3 Mrd. Euro (HDE) Umsatz, und rund 19,9 % (Web Almanac) der untersuchten Websites sind Shops. Der Shopsystem-Markt selbst ist dabei eine lange Reihe kleiner Systeme: 362 (Web Almanac) erkannte Systeme standen in einer Erhebung nur einer Handvoll mit nennenswertem Anteil gegenüber. Für den einzelnen Betreiber heißt das, dass der Update-Pfad seiner Erweiterungen an wenigen Anbietern hängt - und jede Lizenzfrist eine Abhängigkeit sichtbar macht, die sonst unbemerkt bleibt.