Cybersicherheit 1 h agoZu Lesezeichen hinzufügen
Das Sicherheitsteam des Linux-Kernels veröffentlicht 432 CVE in 48 Stunden. Eine spektakuläre Rohzahl, aber sie muss in den richtigen Kontext gesetzt werden: Es ist eine direkte Folge der im Jahr 2024 übernommenen CNA-Politik.
Das Sicherheitsteam des Linux-Kernels veröffentlicht 432 CVE in zwei Tagen - ein Höchststand, der alarmierende Schlagzeilen und Diskussionen in den Mailinglisten anheizt. Die Zahl selbst ist unbestritten, aber ihre Interpretation erfordert Kontext.
Seit Februar 2024 ist das Linux-Projekt CNA (CVE Numbering Authority) bei MITRE geworden. Das bedeutet, dass das Kernel-Team selbst CVE-Kennungen für seine Sicherheitskorrekturen vergeben kann, ohne auf eine Drittstelle zurückgreifen zu müssen. Direktes Ergebnis: Die Veröffentlichung von CVE hat explosionsartig zugenommen, nicht weil der Kernel plötzlich unsicherer ist, sondern weil jeder Patch, der potenziell sicherheitsrelevant sein könnte, nun standardmäßig ein CVE erhält.
Man muss drei Kategorien in dieser Masse von CVE unterscheiden:
Die CNA-Politik des Kernels, vertreten durch Greg Kroah-Hartman, ist eindeutig: jeder sicherheitsrelevante Patch ist ein CVE, und es liegt an den Nutzern (Distributionen, Unternehmen), zu filtern, was sie betrifft. Das ist eine Umkehrung der Verantwortung im Vergleich zur Ära „wir nennen es CVE, wenn es bereits ausgenutzt wird“ - intellektuell ehrlicher, aber es erzeugt diese Spitzenwerte.
Der Untertitel der Berichterstattung von The Register ist eindeutig: der Höchststand „nährt Spekulationen über KI-gestützte Bug Reports“. Die Idee kursiert seit mehreren Monaten in den Kernel-Listen: Die Demokratisierung von Tools, die intelligentes Fuzzing und statische Analyse durch LLM betreiben, erzeugt Bug Reports in Echtzeit, und ein Teil dieser Reports (die echten Positivfälle) endet in Patches, die unter der CNA-Politik zu CVE werden.
An dieser Stelle ist nichts offiziell seitens des Kernel-Teams bestätigt. Der Wechsel zur breiten CNA reicht völlig aus, um die Rohzahl zu erklären, ohne einen KI-Faktor herbeizuführen. Aber die Frage ist berechtigt: Wenn morgen ein signifikanter Teil der CVE durch KI-Tools erzeugt wird, muss das Ökosystem diese Reports anders behandeln (eigener Kanal, obligatorische menschliche Überprüfung vor CVE, explizite Markierung in den Beschreibungen)? Die Debatte ist nicht abgeschlossen.
1. Panik vor der Rohzahl vermeiden: 432 CVE ≠ 432 Maschinen zum Neuinstallieren. 2. Die Advisories Ihrer Distribution verfolgen (Debian DSA, Ubuntu USN, Red Hat RHSA) - sie filtern bereits für Sie. 3. Auf einem öffentlichen Desktop-PC: Die wöchentlichen automatischen Updates reichen aus. 4. Auf einer kritischen Flotte: Bewerten Sie CVE für CVE über die üblichen Tools (OpenSCAP, kernel-live-patching) statt alles auf einmal korrigieren zu wollen.
Der Kern des Themas ist eine alte Debatte der Open-Source-Sicherheit: Welche Granularität für die Offenlegung von Schwachstellen?
Das alte Modell („wir sprechen nur über echte, ausgenutzte Schwachstellen“) hatte den Vorteil der Lesbarkeit und den Nachteil, einen künstlich niedrigen CVE-Rauschpegel zu schaffen - Unternehmen glaubten, ihr Kernel sei „sauber“, während Dutzende von Sicherheitsfehlern jeden Monat unter dem Radar blieben.
Das neue Modell (breite CNA) macht die Realität sichtbar, aber roh unbrauchbar für die meisten Teams. Die Vermittlung wird zur Aufgabe der Distributionen und der Patch-Management-Tools, nicht des Endnutzers.
Eine ehrliche Zahl zur Orientierung: Der Linux-Kernel behebt etwa 1.800 bis 2.500 Bugs pro Monat in den stabilen Zweigen. Der Anteil, der die Sicherheit betrifft, ist strukturell bedeutend - der Kernel ist ein Monster von 30+ Millionen Zeilen C, ein großer Teil davon wenig geprüfter Treibercode. Dass die CVE-Veröffentlichung diese Realität widerspiegelt, ist gesund; dass es den Eindruck eines Brandes vermittelt, ist es nicht.
Zu beachten
Artikel von künstlicher Intelligenz erstellt, unter menschlicher redaktioneller Kontrolle geprüft.