Debian 11 „Bullseye“ erreicht am 31. August 2026 das Ende seines Lebenszyklus. Ein praktischer Leitfaden für Administratoren

Umfassender Support während des gesamten Lebenszyklus | Lesezeit: ca. 10 Min.

Die wichtigsten Erkenntnisse

• Die kostenlose Sicherheitsunterstützung für Debian 11 endet am 31. August 2026, wenn das ehrenamtliche LTS-Team die Unterstützung für Bullseye einstellt. Debians eigenes Sicherheitsteam hat sich bereits im August 2024 zurückgezogen.
• Ein nicht unterstütztes Betriebssystem ist der schwerwiegendste Befund, den ein Schwachstellenscanner liefern kann, und gefährdet die Einhaltung der PCI-DSS-, HIPAA-, SOC-2- und FedRAMP-Vorgaben.
• Ein zweistufiges Upgrade auf Debian 12 und anschließend auf Debian 13 ist die eigentliche Lösung. Wenn dies nicht vor Ablauf der Frist umgesetzt werden kann, sorgt der „Endless Lifecycle Support“ von TuxCare für Debian 11 sorgt dafür, dass „Bullseye“ weiterhin mit Patches versorgt wird, sodass das Upgrade nach Ihren eigenen Zeitplänen erfolgen kann.

Fragen Sie drei Debian-Administratoren, wann Bullseye wirklich das Ende seiner Lebensdauer erreicht, und Sie werden möglicherweise drei verschiedene Daten hören. Das ist keine Nachlässigkeit. Es ist eine Nebenwirkung der Art und Weise, wie Debian eine Version unterstützt: Die Verantwortung wechselt im Laufe der Lebensdauer durch verschiedene Hände, und die Bedeutung des Begriffs „unterstützt“ ändert sich bei jedem Wechsel stillschweigend. Für Debian 11 ist der entscheidende Datum der 31. August 2026. Dann stellt das ehrenamtliche Long-Term-Support-Team die Veröffentlichung von Patches ein, und die letzte Quelle für kostenlose Sicherheitsupdates für Bullseye versiegt.

Um Mitternacht passiert nichts Dramatisches. apt funktioniert weiterhin, und Ihre Dienste reagieren nach wie vor. Was sich ändert, ist, dass der stetige Strom an CVE-Korrekturen, auf den Sie sich seit fünf Jahren verlassen haben, einfach versiegt und die Verantwortung für jede neu bekannt gewordene Sicherheitslücke nun bei Ihnen liegt.

Dieser Leitfaden erläutert, was sich durch die Frist tatsächlich ändert, warum ein nicht gepatchter Debian-Host ein größeres Risiko darstellt, als es auf den ersten Blick scheint, und welche vier Möglichkeiten es gibt, von Bullseye abzuweichen – einschließlich der Fälle, in denen es falsch ist, das Upgrade zu überstürzen.

So funktioniert der Debian-Support in der Praxis

Eine Debian-Version erhält nicht nur einen Supportzeitraum, sondern eine ganze Kette. In den ersten rund drei Jahren kümmert sich das Debian-Sicherheitsteam direkt um die Fehlerbehebungen – das ist der „vollständige“ Support, den sich die meisten Menschen vorstellen. Wenn die nächste stabile Version veröffentlicht wird, wird die ältere Version an das Long-Term-Support-Team übergeben – eine separate Initiative, die von Freiwilligen und Sponsorunternehmen getragen wird und den Support auf etwa fünf Jahre ab Veröffentlichung ausdehnt, allerdings nur für eine sorgfältig ausgewählte Untergruppe von Paketen und Architekturen. Danach kann ein kommerzielles Extended-LTS-Programm von Freexian die Updates auf 10 Jahre verlängern, obwohl dieses Programm außerhalb des eigentlichen Debian-Projekts angesiedelt ist.

Bullseye befindet sich nun in der letzten freien Phase dieser Staffel. Es wurde am 14. August 2021 veröffentlicht, hat im August 2024 die volle Unterstützung durch das Sicherheitsteam verlassen und läuft bis zum 31. August 2026 auf freiwilliger LTS-Basis. Da Debian LTS den Umfang sowohl hinsichtlich der Pakete als auch der Architekturen einschränkt – Bullseye LTS ist auf i386, amd64, armhf und arm64 beschränkt –, können einige Komponenten auf einem bestimmten Host bereits außerhalb des unterstützten Bereichs liegen. Durch die Installation des Pakets „debian-security-support“ wird angezeigt, welche Ihrer installierten Pakete nicht mehr abgedeckt sind. Überprüfen Sie dies daher lieber, anstatt davon auszugehen. 

Hier ist eine Übersicht über die aktuellen Veröffentlichungen (Stand: Juni 2026):

Die Tabelle zeigt auch, warum sich das naheliegende Upgrade-Ziel verschoben hat. Buster (10) ist bereits nicht mehr verfügbar, und Bookworm (12) wird am 11. Juli 2026 aus dem regulären Support genommen und tritt danach in seine eigene LTS-Phase ein. Damit bleibt Trixie (13) die Version mit der längsten verbleibenden Laufzeit. Für ein Team, das jetzt von Bullseye migriert, mag Bookworm ein notwendiges Sprungbrett sein, aber Trixie ist langfristig das bessere Ziel.

Abbildung 1. Jede Route ab Bullseye bietet eine unterschiedliche Abdeckung des Gebiets. Die kostenlosen Optionen enden zuerst.

Was das Ende des Suppenküchenbetriebs für Debian 11 bedeutet 

Da die Server weiterhin laufen, ist es leicht, die Frist als unbedeutend abzutun. Das ist sie jedoch nicht. Die Kosten verteilen sich auf drei Bereiche: Sicherheit, Compliance und das Ökosystem rund um Bullseye.

Jede neue CVE wird zu Ihrem Problem

Sicherheit steht an erster Stelle. Debians Sicherheitskorrekturen werden offen entwickelt. Sobald also ein Patch für eine unterstützte Version veröffentlicht wird, kann jeder den Commit einsehen, genau erkennen, welche Zeilen geändert wurden, und daraus ableiten, welchen Fehler der Patch behebt. Auf einem gepflegten System ist das harmlos, da die Korrektur bereits implementiert ist. Bei Bullseye ist derselbe öffentliche Commit jedoch eine kostenlose Anleitung: Der anfällige Code befindet sich nach wie vor auf Ihren Servern und ist nun detailliert dokumentiert. Früher erforderte es viel Zeit für Reverse Engineering, dieses Wissen in einen funktionierenden Exploit umzuwandeln. Da KI nun die Routinearbeit übernimmt, verkürzt sich diese Zeit immer weiter, und die Sicherheitslücke zwischen „Patch ist öffentlich“ und „Exploit ist im Umlauf“ wird immer kleiner.

Da das Betriebssystem die Grundlage für alle anderen Komponenten bildet, ist der Schadensumfang groß. Eine nicht behobene Sicherheitslücke im Kernel, in OpenSSL oder einem anderen Paket bleibt nicht auf einen einzelnen Dienst beschränkt, sondern gefährdet den Host und alle darauf ausgeführten Prozesse.

Abbildung 2. Ein öffentlicher Fix für eine unterstützte Version dient Angreifern als Vorlage für Angriffe auf die ungepatchte Version.

Prüfer weisen auf ein nicht unterstütztes Betriebssystem hin

Das Compliance-Risiko wartet nicht auf einen Exploit. Die meisten Schwachstellenscanner lesen die Betriebssystemversion direkt vom Host ab, sodass eine ganze Flotte von Bullseye-Rechnern bei Scans nach dem 31. August als „nicht unterstütztes Betriebssystem“ angezeigt wird.

PCI DSS erwartet, dass bekannte Sicherheitslücken in festgelegten Abständen behoben werden. SOC-2-Prüfer betrachten Komponenten, deren Lebenszyklus beendet ist (EOL), als Kontrolllücke. Sowohl HIPAA als auch FedRAMP legen Wert auf ein dokumentiertes Patch- und Schwachstellenmanagement, dessen Einhaltung deutlich schwieriger wird, sobald für das zugrunde liegende Betriebssystem keine Updates mehr bereitgestellt werden. Schon eine einzige nicht mehr unterstützte Distribution kann zu Befunden in einer ansonsten ordentlichen Infrastruktur führen, und Cyber-Versicherer haben begonnen, EOL-Software direkt in ihre Ausschlussklauseln aufzunehmen.

Das Ökosystem geht ohne dich weiter

Auch das Ökosystem rund um Bullseye entwickelt sich weiter. Paketbetreuer und apt-Repositorys von Drittanbietern stellen ihre Bullseye-Builds ein. Offizielle Container-Images werden auf Bookworm und Trixie neu erstellt. Konfigurationsmanagement-Module, Überwachungsagenten und Sprach-Laufzeitumgebungen werden nicht mehr für Version 11 getestet. All dies sind kleine, aber lästige Probleme. Über mehrere Quartale hinweg summieren sich diese Probleme und festigen Bullseye in seiner aktuellen Position: Jede neue Abhängigkeit erfordert eine Fixierung oder eine Umgehungslösung, und das von Ihnen aufgeschobene Upgrade könnte umso kostspieliger werden, je länger Sie damit warten.

Vier Wege weg von Bullseye

Es gibt keine allgemeingültige richtige Antwort. Der richtige Weg hängt davon ab, wie kritisch die Systeme sind, wie viel Betriebslast Sie bewältigen können und ob ein sauberes Upgrade realistisch gesehen rechtzeitig durchgeführt werden kann. Das folgende Flussdiagramm hilft Ihnen, die Auswahl schnell einzugrenzen; die Details zu den einzelnen Optionen folgen im Anschluss.

Abbildung 3. Ein schneller Weg, um die Auswahl einzugrenzen. „Selbstversorgung“ wird außer Acht gelassen, da nur wenige Teams dafür Personal bereitstellen können.

Aktualisieren Sie auf Debian 12 und anschließend auf Debian 13

Das ist das Ziel, das jeder Bullseye-Host anstreben sollte, und für viele Systeme ist es der richtige Schritt, jetzt damit zu beginnen. Die für Debian spezifische Schwierigkeit besteht darin, dass man keine Versionen überspringen kann. Unterstützte In-Place-Upgrades erfolgen jeweils nur für eine Release-Version; der Umstieg von Version 11 bedeutet also zwei aufeinanderfolgende „dist-upgrades“, von denen jedes seine eigenen geänderten Standardeinstellungen, entfernte Pakete und Drittanbieter-Repositorys mit sich bringt, die neu verknüpft werden müssen. Da Bookworm selbst kurz vor dem Eintritt in den LTS-Status steht, sollten Sie Trixie anstreben, wenn Sie den längsten Spielraum wünschen. Behandeln Sie dies wie ein vollwertiges Projekt: Üben Sie auf einem Klon, erstellen Sie vor jedem Schritt einen Snapshot und halten Sie ein Rollback bereit, falls ein Dienst nicht wie erwartet wiederhergestellt wird.

Debian Extended LTS bei Freexian kaufen

Freexian, ein Unternehmen, das maßgeblich am Betrieb von Debian LTS beteiligt ist, bietet ein kommerzielles „Extended LTS“-Programm an, das Sicherheitsupdates für Bullseye bis zum 30. Juni 2031 abdeckt. Der Reiz liegt auf der Hand: Man bleibt bei Version 11 und verzichtet gänzlich auf ein Upgrade. Drei Details entscheiden darüber, ob das Programm für Sie geeignet ist. Der Umfang beschränkt sich auf eine Paketliste, wobei ein fester Basissatz stets unterstützt wird und alles darüber hinaus pro Paket kalkuliert wird, während einige Pakete nur begrenzt oder gar nicht unterstützt werden. Nach dem von Freexian selbst veröffentlichten Kostenmodell steigt der Preis alle sechs Monate – in der ersten Hälfte des Zeitraums sanft und später steil, wenn andere Kunden abwandern. Und der Kernel wird auf dem neuesten Stand gehalten, indem man auf neuere Kernel-Versionen umgestellt wird, die aus späteren Debian-Veröffentlichungen zurückportiert wurden, anstatt den derzeit verwendeten Kernel beizubehalten. Für Hosts, deren Pakete im unterstützten Satz enthalten sind und deren Betreiber steigende Rechnungen sowie gelegentliche Kernel-Wechsel in Kauf nehmen, ist dies eine legitime Möglichkeit, Zeit zu gewinnen.

Pflegen Sie die Patches selbst

Theoretisch kann man CVEs verfolgen und Korrekturen in die eigenen Neukompilierungen zurückportieren. Für ein Betriebssystem bedeutet das, die Sicherheitspflege für den Kernel, die C-Bibliotheken und Dutzende von Diensten zu übernehmen – und zwar nach dem Zeitplan der Angreifer und nicht nach dem eigenen. Nur eine Handvoll Organisationen verfügt über die personellen Ressourcen und die erforderlichen C- und C++-Kenntnisse, um dies ordnungsgemäß zu bewerkstelligen. Die meisten tun dies nicht, und eine mit halbem Personalbestand durchgeführte Lösung ist gefährlicher, als zuzugeben, dass man dazu nicht in der Lage ist, da sie den Anschein von Absicherung erweckt, ohne dass diese tatsächlich gegeben ist.

Erweitern Sie Bullseye mit TuxCare ELS

Dies ist oft die praktischste Option, wenn das Upgrade nicht rechtzeitig vor Ablauf der Frist sicher durchgeführt werden kann. Der „Endless Lifecycle Support“ von TuxCare für Debian 11 sorgt dafür, dass bestehende Bullseye-Installationen auch nach Ablauf der LTS-Unterstützung weiterhin mit Patches versorgt werden.

TuxCare verfolgt CVEs, portiert die Korrekturen zurück und stellt sie als signierte Pakete über apt bereit. Dabei deckt das Projekt eine breite Palette an Serverpaketen ab und patcht den von Ihnen bereits verwendeten Kernel, anstatt Sie auf eine neuere Version umzustellen – das Gegenteil des oben beschriebenen Ansatzes von Freexian. Sie können Pakete anfordern, die noch nicht auf der Liste stehen. Ein Host verbindet sich mit einem kurzen Skript mit dem TuxCare-Repository, ohne Neustart und ohne „dist-upgrade“, und die Patches werden über Ihren bestehenden Paket-Workflow bereitgestellt.

TuxCare veröffentlicht zudem Errata und OVAL-Daten, sodass OpenSCAP und andere OVAL-kompatible Tools den Patch-Status auf diesen Hosts weiterhin auslesen können. Der Preis ist für die gesamte Vertragslaufzeit festgeschrieben, sodass die Kosten nicht steigen, je älter die Version wird.

Was Sie hier eigentlich kaufen, ist Zeit. ELS trennt „Sicherheit gewährleisten“ von „Upgrade abschließen“, sodass ein festes Kalenderdatum nicht mehr ausschlaggebend für die zu planenden technischen Arbeiten ist. Das System bewährt sich, wenn das Upgrade nicht vor dem 31. August abgeschlossen werden kann, wenn ein Prüfer eine kontinuierliche, dokumentierte Patch-Verwaltung nachweisen muss oder wenn eine Flotte so stabil ist, dass ein überstürztes Zwei-Schritt-Upgrade das größere Risiko darstellt.

Wenn ein schnelles Upgrade der falsche Schritt ist

Auf einer Folie gewinnt „einfach ein Upgrade durchführen“ jedes Mal. In der realen Infrastruktur gibt es jedoch einige Faktoren, die dies häufiger als erwartet zum falschen ersten Schritt machen.

Die beiden Schritte sind der schwierige Teil. Um von Bullseye zu Trixie zu gelangen, muss man zunächst Bookworm durchlaufen, und jedes „dist-upgrade“ bringt geänderte Standardeinstellungen, entfernte Pakete und Repositorys von Drittanbietern mit sich, die möglicherweise neu verweist oder ersetzt werden müssen – für manche gibt es vielleicht gar keinen Pfad von Bullseye zu Bookworm. Das ist Konfigurationsarchäologie, und die lässt sich nicht einfach auf eine Frist komprimieren.

Terminorientierte Migrationen kosten mehr, als es auf den ersten Blick scheint. Ein unter Zeitdruck durchgeführtes Upgrade führt zu fehlerhaften Konfigurationen, überspringt Randfälle und verkürzt die Testphase. Die Folgen zeigen sich im nächsten Quartal in Form von Vorfällen und Bereitschaftsdiensten – und diese übersteigen häufig bei weitem die Kosten, die ein ruhigeres, planmäßiges Upgrade verursacht hätte, selbst wenn man ein Jahr verlängerten Support mit einberechnet.

Nicht jeder Host erhält in diesem Quartal ein Upgrade. Ein Gerät, eine Box, auf der eine „eingefrorene“ Workload läuft, oder eine bereits zur Erneuerung vorgesehene Geräteflotte rechtfertigen derzeit möglicherweise keine OS-Migration über zwei Schritte. Diese Geräte bis zur geplanten Umstellung auf dem aktuellen „Bullseye“-Stand zu halten, ist solide Technik und keine Ausflucht.

Die Zeit für Debian 11 anhalten

Der 31. August 2026 steht fest. Danach enden die kostenlosen Patches für Bullseye, und jede neue CVE geht zu Lasten derjenigen, die das System noch nutzen. Der Umstieg auf Debian 12 und anschließend auf Debian 13 ist das richtige Ziel, und es lohnt sich, jetzt damit zu beginnen. Für Server, die den Umstieg nicht rechtzeitig schaffen oder bei denen sich die Umstellung noch nicht lohnt, sorgt der „Endless Lifecycle Support“ von TuxCare für Debian 11 sorgt dafür, dass sie über apt auf dem neuesten Stand bleiben – ohne Neustarts oder Versionssprünge.

Wenn Sie dies auf Ihren eigenen Immobilienbestand übertragen möchten, sprechen Sie mit einem TuxCare-Experten über die Hosts, die Sie über die Frist hinaus weiterbetreiben müssen. Das Ziel ist es, Ihren Migrationstermin selbst zu wählen, anstatt ihn vom Kalender vorgeben zu lassen.

Zusammenfassung

Artikel Name

Debian 11 „Bullseye“ erreicht das Ende seines Lebenszyklus

Beschreibung

Erläutern Sie, was sich durch die Frist tatsächlich ändert, warum ein nicht gepatchter Debian-Host ein größeres Risiko darstellt, als es auf den ersten Blick scheint, und welche vier Auswege es aus Bullseye gibt.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers