Supportende im Web-Stack: Komponenten ohne Updates

Was ein Supportende wirklich bedeutet

Ein Supportende ist ein Kalendertag, kein Zustand der Software. Am Tag davor ist ein PHP-Zweig gepflegt, am Tag danach ist er es nicht mehr – die Dateien auf dem Server sind byteweise dieselben. Die PHP Group beschreibt das Modell ohne Spielraum: Ein Release-Zweig bekommt zwei Jahre lang reguläre Fehlerkorrekturen (PHP Group), danach folgt eine Phase, in der nur noch Sicherheitslücken geschlossen werden. Nach insgesamt vier Jahren endet auch das (PHP Group). Ab diesem Tag existiert für eine neu entdeckte Lücke in diesem Zweig schlicht kein Patch mehr, unabhängig davon, wie schwer sie wiegt.

Das Risiko daran ist kein theoretisches. Die ENISA hat für ihre europäische Lagebeurteilung 4875 Vorfälle aus dem Zeitraum Juli 2024 bis Juni 2025 ausgewertet (ENISA) – ein Volumen, das zeigt, wie routiniert bekannte Schwächen in der Breite ausgenutzt werden. Eine Komponente ohne Herstellerkorrektur ist in dieser Lage kein Restrisiko, sondern ein offenes Ende. Wie Sie überhaupt mitbekommen, dass eine Lücke Ihre Bauteile betrifft, haben wir im Beitrag zu den Schwachstellen-Feeds EUVD und CVE auseinandergenommen.

• Was endet: Fehlerkorrekturen, Sicherheitskorrekturen, offizielle Pakete der Distribution, verbindliche Aussagen des Herstellers zu neu gemeldeten Lücken.
• Was nicht endet: die Erreichbarkeit der alten Dateien auf Paketspiegeln, die Funktionsfähigkeit im Alltag, der Eindruck im Team, dass ja alles läuft.
• Was neu beginnt: Ihre eigene Beweislast. Ab dem Supportende müssen Sie erklären können, warum ein ungepflegtes Bauteil in einem Produkt steckt, das Sie in Verkehr bringen.
• Was sich nicht ändert: der Wartungsvertrag, das Hosting-Paket, die Rechnung – keines dieser Dokumente wird automatisch angepasst, wenn ein Fenster zuläuft.

Die CRA-Fristen als Taktgeber

Zwei Daten strukturieren die kommenden Jahre. Die Meldepflicht für aktiv ausgenutzte Schwachstellen greift ab dem 11. September 2026 (Europäische Kommission), die Hauptpflichten des Cyber Resilience Act gelten ab dem 11. Dezember 2027 (Europäische Kommission). Dazwischen liegt der Zeitraum, in dem sich entscheidet, ob eine Organisation ihre Bauteile kennt oder sie erst im Ernstfall zusammensucht. Der Unterstützungszeitraum selbst soll dabei fünf Jahre nicht unterschreiten (Amtsblatt der EU) – eine Untergrenze, an der sich viele Fenster im Web-Stack messen lassen müssen. Was die Meldepflicht im Einzelnen verlangt, steht im Beitrag zur CRA-Meldepflicht ab September 2026.

Rechnen Sie diese Untergrenze einmal gegen die Praxis. Eine Angular-Hauptversion wird typischerweise 24 Monate unterstützt (Angular), Laravel korrigiert Fehler 18 Monate und Sicherheitslücken zwei Jahre lang (Laravel), eine Node.js-LTS-Linie sagt Korrekturen kritischer Fehler für insgesamt 30 Monate zu (Node.js). Kein einziges dieser Fenster reicht allein bis an die fünf Jahre heran. Das ist kein Vorwurf an die Projekte – es heißt nur, dass die Zusage gegenüber Ihren Kunden nicht aus einem einzelnen Bauteil kommen kann, sondern aus einem geplanten Wechsel von Fenster zu Fenster.

Supportfenster im Vergleich

Die folgende Tabelle stellt zusammen, was die Projekte selbst zusagen. Sie ersetzt keine Prüfung Ihrer konkreten Installation, aber sie macht die Größenordnungen sichtbar – und die Spannweite ist erheblich. Zwischen dem kürzesten und dem längsten Fenster in dieser Liste liegt rund der Faktor zehn: sechs Monate bei einem Node.js-Current-Zweig gegen fünf Jahre bei Python, Ubuntu LTS und OpenSSL LTS. Wer alle diese Bauteile in einem Produkt kombiniert, hat nicht ein Supportende, sondern eine Kette davon.

Zwei Zeilen aus dieser Tabelle verdienen besondere Aufmerksamkeit. Ein Ubuntu-Zwischenrelease bekommt nur neun Monate Updates (Canonical) – wer damit produktiv fährt, steht mehrmals im Jahr vor einem Wechsel, den niemand eingeplant hat. Und bei OpenSSL entscheidet die Kennzeichnung: Eine LTS-Fassung bekommt mindestens fünf Jahre Support zugesagt (OpenSSL), eine Fassung ohne dieses Kennzeichen wird ab 3.5 nur noch 13 Monate voll unterstützt (OpenSSL). Beide Bauteile sind unsichtbar, solange sie funktionieren. Sichtbar werden sie erst, wenn ein Scanner die Version aus einem Antwortkopf liest – siehe dazu die Preisgabe von Versionen über Server-Header.

Warum alte Zweige so hartnäckig überleben

Die Zahlen zeigen ein sehr klares Muster: Alte Zweige verschwinden nicht, sie sedimentieren. 51 Prozent der Websites laufen auf einem CMS (Web Almanac 2024) und erben damit dessen Versionspflege samt aller Erweiterungen. Nur 63,5 Prozent der PHP-Websites nutzen den Hauptzweig 8 (W3Techs); der Rest sitzt auf älteren Zweigen. Bei WordPress-Installationen, die sich bei WordPress.org melden, laufen 17,11 Prozent auf PHP 7.4 und 1,346 Prozent noch auf PHP 5.6 (WordPress.org). Der zweite Wert ist klein, aber er beschreibt Installationen, deren Unterbau seit vielen Jahren keine Korrektur mehr gesehen hat. Was das für den laufenden Betrieb heißt, steht im Beitrag zum WordPress-Sicherheitsmonitoring.

Die Gründe für dieses Beharrungsvermögen sind selten technischer Natur. Ein Zweigwechsel berührt Erweiterungen, eigene Anpassungen, Buildketten und Testabdeckung gleichzeitig, und jeder dieser Punkte hat einen anderen Verantwortlichen. Solange nichts sichtbar kaputtgeht, gewinnt der Aufschub jede Priorisierungsrunde. Das Supportende ändert an dieser Dynamik nichts – es verschiebt nur die Kosten des Aufschubs von der Wartung in die Haftung. Deshalb ist die entscheidende Frage nicht, ob ein Wechsel ansteht, sondern wie viele Monate Restlaufzeit noch auf der Uhr sind.

Das Frontend altert am leisesten

Server-Bauteile bekommen Aufmerksamkeit, weil sie Updates einfordern. Im Frontend liegt der Code dagegen als Datei im Auslieferungsverzeichnis und meldet sich nicht von selbst. jQuery ist weiterhin die meistgenutzte Bibliothek im Web und erscheint auf 74 Prozent der Seiten (Web Almanac 2024), jQuery UI läuft trotz weitgehender Abkündigung noch auf 22 Prozent (Web Almanac 2024). Diese Dateien werden bei keinem Distributionsupdate mitgezogen, sie stehen in keinem Paketmanager des Servers und tauchen in keiner Systemliste auf. Wie man sie trotzdem findet, zeigt der Beitrag zu verwundbaren JavaScript-Bibliotheken.

Dazu kommt alles, was fremde Server in Ihre Seite hineinreichen: Einbindungen für Zahlung, Karten, Chat oder Auswertung. Deren Versionsstand bestimmt jemand anderes, und ein Supportende dort erfahren Sie in der Regel gar nicht. Diese Klasse von Bauteilen gehört genauso in die Inventur wie das eigene Paket – wir haben sie im Beitrag zu Drittanbieter-Skripten getrennt betrachtet, weil dort neben dem Supportende auch der stille Austausch einer Datei ein Thema ist.

Die Inventur: acht Felder je Bauteil

Eine Liste, die nur Namen enthält, hilft an dieser Stelle nicht. Damit aus dem Bestand eine Entscheidung wird, braucht jedes Bauteil dieselben Felder – und zwar so, dass ein fehlender Wert als fehlend erkennbar bleibt und nicht stillschweigend als Null durchgeht. Dieselbe Logik gilt für zugekaufte Leistungen: Wer Dienstleister im Stack hat, braucht deren Nachweise in derselben Struktur, wie es der Beitrag zur NIS2-Lieferkette beschreibt.

1. Name und Zweig – nicht die Patch-Version, sondern der Zweig, an dem das Supportfenster hängt (etwa der PHP-Zweig, nicht die dritte Stelle).
2. Herkunft – Distributionspaket, Herstellerpaket, Bibliothek im Auslieferungsverzeichnis oder Einbindung von fremdem Server.
3. Supportende laut Hersteller – als Datum, mit Verweis auf die Seite, auf der es steht.
4. Quelle des Datums – die Adresse, unter der die Zusage veröffentlicht ist; ohne sie ist das Datum eine Behauptung.
5. Restlaufzeit in Monaten – der einzige Wert, nach dem sich sinnvoll sortieren lässt.
6. Gemessen ja oder nein – ein eigenes Feld, das sagt, ob der Wert wirklich erhoben wurde oder nur geschätzt ist.
7. Verantwortlich – eine Rolle, kein Name, damit die Zuordnung einen Personalwechsel überlebt.
8. Nachfolger – der Zweig, auf den gewechselt wird, samt bekanntem Supportende. Ohne dieses Feld wird aus jedem Wechsel eine neue Recherche.

Restlaufzeit berechnen und einstufen

Aus dem Bestand wird eine Reihenfolge, sobald jedes Bauteil eine Restlaufzeit trägt. Die Rechnung ist trivial, der Wert dahinter ist es nicht: Er verwandelt eine Liste in einen Plan. Python etwa setzt das Supportende hart auf fünf Jahre nach dem Erscheinen einer Version (Python Software Foundation) – das Datum steht damit am Tag der Veröffentlichung fest und lässt sich Jahre im Voraus eintragen. Wichtig ist nur, dass ein nicht ermittelter Wert als nicht ermittelt sichtbar bleibt. Dieselbe Trennung zwischen gemessen und geraten empfehlen wir auch beim Health-Check-Endpunkt, der sonst grüne Antworten für ungeprüfte Abhängigkeiten liefert.

from datetime import date

def restlaufzeit(supportende, heute=None):
    """Monate bis zum Supportende. None bedeutet: nicht ermittelt."""
    if supportende is None:
        return None
    heute = heute or date.today()
    return (supportende.year - heute.year) * 12 + (supportende.month - heute.month)

def stufe(monate):
    if monate is None:
        return "ungemessen"      # nicht als 0 behandeln
    if monate < 0:
        return "abgelaufen"
    if monate <= 3:
        return "kritisch"
    if monate <= 12:
        return "planen"
    return "beobachten"

bestand = [
    ("php-zweig", date(2027, 12, 31)),
    ("node-lts", date(2027, 4, 30)),
    ("frontend-bibliothek", None),
]
for name, ende in bestand:
    m = restlaufzeit(ende)
    print(f"{name}: {stufe(m)} ({m if m is not None else 'kein Datum'})")

Vier Stufen reichen für die Steuerung: abgelaufen, kritisch, planen, beobachten – und dazu die fünfte Kategorie ungemessen, die bewusst keine Zahl bekommt. Ein Bauteil ohne ermitteltes Supportende ist kein sicheres Bauteil, es ist ein unbekanntes. Wer diese Fälle mit einer Null oder einem großzügigen Standardwert auffüllt, baut sich eine Liste, die durchweg beruhigend aussieht. Ergänzend liefert ein regelmäßiger Security-Scan die Außensicht auf denselben Stack: Was von außen an Versionen sichtbar wird, gehört in dieselbe Tabelle wie das, was Sie von innen wissen.

Migration planen, bevor das Fenster zuläuft

Ein Wechsel, der erst nach dem Supportende beginnt, findet unter Zeitdruck statt und erzeugt dabei zuverlässig neue Fehler. Die praktikable Reihenfolge ist deshalb umgekehrt: Der Termin für den Wechsel wird aus dem Supportende abgeleitet, nicht aus der freien Kapazität. Erfahrungsgemäß tauchen dabei Abhängigkeiten auf, die niemand auf dem Zettel hatte – ein Zertifikatsproblem etwa, das erst nach dem Umzug auf eine neuere Bibliothek sichtbar wird, wie im Beitrag zur unvollständigen Zertifikatskette beschrieben.

1. Zieltermin setzen: Wechsel abgeschlossen, bevor das Fenster zuläuft – nicht am selben Tag.
2. Nachfolger festlegen: die konkrete Zielversion samt deren eigenem Supportende, damit der nächste Wechsel schon im Kalender steht.
3. Abhängigkeiten prüfen: Erweiterungen, eigene Anpassungen und Buildkette gegen die Zielversion, bevor Termine zugesagt werden.
4. Testabdeckung vorziehen: was vor dem Wechsel nicht geprüft wird, wird danach im Betrieb geprüft.
5. Sicherheitsköpfe mitziehen: ein Umzug ist der günstigste Zeitpunkt, um etwa die Cross-Origin-Header COOP, COEP und CORP sauber zu setzen.
6. Rückweg definieren: ein beschriebener Weg zurück, der ohne Zeitdruck erprobt wurde, nicht ein theoretischer.
7. Nachweis ablegen: Datum, Zielversion, Prüfergebnis – das ist später der Beleg, dass der Unterstützungszeitraum eingehalten wurde.

Ein Bauteil ohne ermitteltes Supportende ist kein sicheres Bauteil, sondern ein unbekanntes. Der Unterschied entscheidet, ob eine Liste eine Entscheidungsgrundlage ist oder eine Beruhigung.

— XICTRAQ

Supportenden laufend im Blick behalten

Eine Inventur ist ein Stichtag, ein Supportende ist eine Bewegung. Zwischen beiden liegt der Grund, warum Tabellenblätter diese Aufgabe selten überstehen: Sie altern in dem Moment, in dem sie fertig sind. Das CRA-Komponenten-Cockpit hält den Bestand deshalb fortlaufend, verbindet ihn mit Hinweisen auf gemeldete Schwachstellen und meldet sich, wenn eine Restlaufzeit unter die gesetzte Schwelle fällt – 90, 30 und 7 Tage vor dem Termin, statt einmal im Jahr beim Durchsehen der Liste.

Der organisatorische Gewinn ist dabei größer als der technische. Wer jederzeit sagen kann, welche Bauteile in welcher Version laufen und wann deren Fenster zuläuft, beantwortet Kunden- und Prüferfragen aus dem Bestand statt aus dem Gedächtnis. Für welche Pakete diese Funktion enthalten ist, steht auf der Preisübersicht samt der jeweils geltenden Mindestlaufzeit. Der Aufwand für die erste Inventur bleibt Ihrer – der Aufwand für jede folgende nicht.