Thought Leadership
Canonical stellt Ubuntus Kernel-Updates auf einen einheitlichen Zwei-Wochen-Zyklus um, um mit der wachsenden Zahl KI-entdeckter Sicherheitslücken Schritt zu halten.
Ubuntu-Entwickler Canonical hat angekündigt, den Veröffentlichungsrhythmus für Kernel-Updates grundlegend zu ändern, um schneller auf die stark gestiegene Zahl gemeldeter Sicherheitslücken reagieren zu können.
Bisheriger Rhythmus reicht nicht mehr aus
Bislang folgte Canonical bei Kernel-Updates einem sogenannten 4/2-Rhythmus: ein regulärer Stable-Release-Update-Zyklus alle vier Wochen, ergänzt um einen separaten Sicherheitszyklus alle zwei Wochen. Dieses Modell war 2023 nach Kritik an der Reaktionszeit auf die Zenbleed-Sicherheitslücke eingeführt worden.
Wie der neue Zyklus funktioniert
Künftig führt Canonical beide Zyklen zu einem einheitlichen, überlappenden Zwei-Wochen-Rhythmus zusammen. Da sich die Zyklen überschneiden, erscheint dadurch praktisch jede Woche ein neues Kernel-Release. In der ersten Woche integriert Canonical Patches, bereitet Pakete vor, führt Builds sowie erste Rauchtests durch, während in der zweiten Woche Zertifizierung, Integration und Regressionstests folgen, bevor das jeweilige Update allgemein verfügbar wird. Wer schneller auf Fixes zugreifen möchte, kann bereits während der laufenden Zertifizierung auf Kernel-Kandidaten aus dem sogenannten -proposed-Repository zugreifen und eigene Testverfahren starten, muss dabei jedoch mehr Verantwortung für eigene Regressionstests übernehmen.
Ursache: explodierende Zahl an CVEs
Als Hauptgrund für die Umstellung nennt Canonical die stark gestiegene Zahl an CVEs, den öffentlichen Kennungen für bekannte Sicherheitslücken. In einem Blogbeitrag erklärt das Unternehmen:
„Die jüngste Explosion beim Umfang der CVEs wird durch künstliche Intelligenz befeuert: Große Sprachmodelle und spezialisierte KI-Agenten haben die Entdeckung von Fehlern von einem manuellen, zeitintensiven Prozess in eine hochgradig automatisierte Maschine verwandelt.“
Canonical
Hinzu kommt, dass die Linux-Kernel-Community mittlerweile selbst als CVE Numbering Authority auftritt und dadurch inzwischen Tausenden Fehlern eigene CVE-Kennungen zuweist, mit der Begründung, auf Kernel-Ebene könne praktisch jede Art von Fehler, die ein laufendes System beeinträchtigt, potenziell als Sicherheitslücke eingestuft werden.
Auch der Linux-Kernel selbst kämpft mit der Flut
Ubuntu ist mit diesem Problem nicht allein. Bereits während der Release-Candidate-Phasen von Linux 7.0 hatte Linux-Erfinder Linus Torvalds einen deutlichen Anstieg der Bugreports bemerkt, ohne dass die gemeldeten Fehler gravierend genug waren, um die pünktliche Veröffentlichung zu verzögern. Bei Linux 7.1 zeigte sich jedoch, dass es sich dabei um keinen Einzelfall handelte: Die Release Candidates blieben weiterhin ungewöhnlich umfangreich, und Meldungen kamen zunehmend über eigentlich für sensible Fälle vorgesehene sichere Kanäle für geringfügige Änderungen herein oder duplizierten bereits vorhandene Meldungen, wodurch die Menge nach Einschätzung von Torvalds „nahezu vollständig unüberschaubar“ wurde.
Canonical setzt selbst auf KI-gestützte Fehlersuche
Canonical nutzt umgekehrt selbst KI-gestützte Werkzeuge zur eigenen Fehlersuche. Mit dem intern entwickelten Auditing-Agenten Redhound, der auf modernen Sprachmodellen aufbaut, durchsucht das Unternehmen eigene Codebasen gezielt nach komplexen, logikbasierten Sicherheitslücken. Redhound deckte dabei bereits drei kritische Logikfehler im Container- und VM-Manager LXD auf, die unter den Kennungen CVE-2026-34177, CVE-2026-34178 und CVE-2026-34179 koordiniert behoben wurden.
Schnellere Reaktion bei fehlenden Fixes
Canonical kündigte zudem an, künftig innerhalb von 24 bis 48 Stunden nach einer öffentlichen Offenlegung sichere Übergangslösungen zu veröffentlichen, sofern noch kein vollständiger Fix vorliegt, oder andernfalls zumindest Hinweise zur Absicherung des betroffenen Systems bereitzustellen. Trotz der beschleunigten Taktung will das Unternehmen an der umfangreichen Testphase für jedes reguläre Release festhalten, um das gewohnte Vertrauensniveau der Ubuntu-Nutzer aufrechtzuerhalten.
(red)
