AWS filtert Linux-CVEs für EC2 mit Skript, KI und Ingenieuren

AWS-Ingenieure stellten im Oktober 2026 einen Ablauf vor, der Linux-CVEs für den von AWS betriebenen EC2-Infrastrukturkernel zunächst per Skript filtert, anschließend mit einem KI-Agenten klassifiziert und von Ingenieuren prüfen lässt. CVE steht für eine standardisierte Kennung einer Sicherheitslücke. Der Prozess sortiert mögliche Fälle für die weitere Bewertung; er spielt keine Patches automatisch ein.

Welchen Kernel AWS bewertet

Der Ablauf betrifft den Linux-Kernel für die EC2-Infrastruktur. Er ist vom Betriebssystem Amazon Linux und von den Kerneln zu unterscheiden, die Kunden in ihren virtuellen Maschinen ausführen. AWS gleicht mögliche Sicherheitslücken mit seiner eigenen Kernel-Umgebung ab.

Erst filtert ein Skript, dann klassifiziert die KI

Ein Skript vergleicht die betroffenen Versionsbereiche eines CVE-Eintrags und die darin genannten Quelldateien mit der Kernelversion und den tatsächlich in AWS’ Image eingebauten Dateien. Dieser erste Schritt nutzt keine KI. In AWS’ Umgebung sortierte der Filter laut der Präsentation etwa 70 Prozent der CVEs aus. Wie viel übrig bleibt, hängt stark von der Kernelkonfiguration und der jeweiligen Umgebung ab.

Für die verbleibenden Fälle erhält der KI-Agent den angepassten Kernel-Quellbaum, die Kernelkonfiguration, ein Bedrohungsmodell und eine Schweregradskala. Er klassifiziert jeden CVE-Eintrag einzeln und erstellt eine Tabelle mit Angaben wie Subsystem, Art der Schwachstelle und Angriffsweg. Die Ingenieure prüfen diese Ergebnisse anschließend.

Das Tempo ersetzt keine Prüfung

AWS bezifferte die Verarbeitung durch den Agenten auf etwa 3,4 Sekunden pro CVE. Die manuelle Triage dauere Minuten pro Fall. Die 3,4 Sekunden beschreiben nur die Klassifizierung, nicht Prüfung, Behebung, Tests oder Bereitstellung eines Updates.

Justinien Bouron schätzte den Anteil problematischer Entscheidungen informell auf 5 bis 10 Prozent. Für die Einordnung der Ergebnisse bleibt die menschliche Prüfung Teil des Ablaufs.

Kernel-Upgrades reichen bis in Userspace und Firmware

Beim Wechsel von Linux 5.10 auf 6.12 ordnete AWS die erfassten Upgrade-Probleme vier Bereichen zu. Userspace bezeichnet Programme und Dienste, die außerhalb des Kernels laufen.

Die Anteile beziehen sich auf die bei diesem Upgrade erfassten Probleme. AWS zufolge wurden 15 Prozent der Kernel-Code-Fixes in den Hauptentwicklungszweig des Linux-Kernels übernommen. Die Verteilung zeigt, dass die Qualifizierung eines neuen Kernels auch Änderungen außerhalb des Kernel-Codes umfassen kann.

AWS nannte für drei Kernel-Upgrades unterschiedliche Zeiträume: 24 Monate für den Wechsel von 4.19 auf 5.10, 12 Monate für 5.10 auf 6.12 und 6 Monate für 6.12 auf 6.18. AWS führte die kürzeren Zeiten auf bessere Werkzeuge, eine breitere Testabdeckung und ein erfahrenes Team zurück.

LTS-Zahlen und Reaktionen auf einzelne CVEs

LTS steht für „Long-Term Support“, also langfristige Pflege. AWS’ Bestandsaufnahme vom 16. September 2026 zählte nicht behobene CVEs in den jeweiligen LTS-Zweigen. Die Zahlen beziehen sich auf die Zweige; AWS bewertet die Relevanz für seine EC2-Systeme durch den Abgleich mit der konkreten Kernelversion und Konfiguration.

Die Medianwerte messen die Zeit zwischen dem Zusammenführen eines Fixes in Mainline und seiner Veröffentlichung in einem LTS-Zweig. Sie geben nicht an, wann AWS ein Update bereitstellt.

Für einen CVE-Fall nennt AWS vier mögliche Reaktionen: keine Maßnahme, wenn die Schwachstelle die eigene Umgebung nicht betrifft; auf den nächsten LTS-Patch warten, wenn die Auswirkungen das zulassen; einen Fix direkt übernehmen, wenn eine schnellere Behebung nötig ist; oder eine Umgehungslösung nutzen, falls ein Kernel-Update nicht möglich ist. Welche Option passt, hängt vom Einzelfall ab.