Wie lange bekommt dein Linux noch Updates?

Ein Linux-Release hat selten nur ein Datum. Red Hat trennt bei RHEL zwischen Full Support, in dem noch Hardware-Enablement und neue Treiber nachkommen, und Maintenance Support, in dem im Wesentlichen nur noch sicherheitsrelevante und kritische Fixes erscheinen. Danach lässt sich die Laufzeit über Extended Life Cycle Support kostenpflichtig verlängern. Ubuntu LTS liefert fünf Jahre regulären Support für das Main-Repository, alles darüber hinaus und der komplette Universe-Bereich hängen an Ubuntu Pro mit Expanded Security Maintenance. Debian übergibt nach dem regulären Security-Support an das LTS-Team, das nur noch ausgewählte Architekturen und Pakete abdeckt. SLES rechnet in General Support und anschließendem LTSS, das je Service Pack zugebucht wird. Wer diese Phasen gleichsetzt, plant an der Realität vorbei.

Der Schmerz entsteht selten beim Hauptsystem, sondern in den Nebenbaustellen. Ein Ubuntu-Server gilt intern als unterstützt, die kritische Komponente stammt aber aus Universe und ist ohne Ubuntu Pro nie in den fünf Jahren mit drin gewesen. Ein RHEL-Host hängt auf einer alten Minor-Version fest, weil eine Applikation zertifiziert ist, und bekommt damit nur noch über Extended Update Support Fixes. Bei SLES läuft der General Support des eingesetzten Service Packs aus, während das Team gedanklich noch mit der Laufzeit der Major-Version rechnet. Das Ergebnis sind Systeme, die im Audit als gepatcht gelten und trotzdem offene CVEs tragen.

CentOS 7 hat 2024 vorgeführt, wie teuer eine späte Reaktion wird: Migrationen wurden unter Zeitdruck durchgezogen, Anwendungen mussten parallel auf neuere Python- und OpenSSL-Stände gehoben werden, und für die Restlaufzeit kaufte man Drittanbieter-Patches. Wer den Lebenszyklus dagegen als rollierende Planung führt, verteilt Upgrades über mehrere Quartale, testet sie regulär und braucht keine Notfallbudgets.