Red Hats erster Security-Signals-Bericht: Behebungstempo statt CVE-Zählerei
Serguey Asael Shinder2 Min. LesezeitRed Hat hat am 15. Oktober 2026 die erste Ausgabe eines Quartalsberichts veröffentlicht: „Open Source Security Signals | Q3 2026“. Die These: Die Zahl der Schwachstellen sagt wenig über das Risiko. Entscheidend sei, ob ein Fund ein System tatsächlich angreifbar macht, wie ein Fix durch Abhängigkeitsbäume wandert und wie schnell er bei der Software ankommt, die ihn braucht. Grundlage ist Red Hats Dienst Lightwell, der nach eigenen Angaben bis zum 1. Oktober mehr als 30.000 geprüfte Versionen von Open-Source-Paketen für Java und Python ausgeliefert hat. Diesen Hintergrund sollte man beim Lesen behalten: Die Schlussfolgerungen laufen auf jene wiederverwendbaren, geprüften Fixes hinaus, die Lightwell verkauft.
Signal 1: Der Schweregrad ist nicht alles. Kritische und wichtige Lücken seien sofort zu schließen, aber auch schwächere verdienten mehr Aufmerksamkeit, weil sich mehrere kleine Probleme verbinden können. Der Bericht zitiert eine Auswertung von IBM X-Force zu 223 öffentlich gemeldeten Schwachstellen, die mit KI-Spitzenmodellen gefunden wurden: 55,2 % waren hoch oder kritisch, 91,0 % aus der Ferne erreichbar, 25,6 % erlaubten Codeausführung. Als Beispiel aus der Lieferkette dient die Kompromittierung des Python-Projekts Ultralytics im Dezember 2024: Schadcode gelangte über die Build-Umgebung des Projekts in vier PyPI-Releases, nicht über den öffentlichen Quellcode. Trusted Publishing, Herkunftsnachweise und Transparenzlogs von PyPI halfen, die Ursache auf den Cache von GitHub Actions einzugrenzen.
Signal 2: Fixes müssen reisen. Ein Fix im Upstream betrifft oft mehrere Komponenten. Beispiel ist Netty 4.1.133.Final, ein Sicherheitsrelease aus dem Mai mit 12 CVEs quer durch HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, Proxy und Kompression. Fixes müssen zudem ältere Versionen erreichen, die noch laufen: Spring Boot 2.7.18 (November 2023) beendete den Open-Source-Support für die Linie 2.x nach 5,5 Jahren und 121 Releases, und Spring Framework 5.3.19 folgte 2022 binnen zwei Wochen auf 5.3.18, weil die Untersuchung von Spring4Shell (CVE-2022-22965) ein zweites Problem zutage förderte.
Signal 3: Ein Fix, viele Nutzer. Herzstück ist ein Modell für eine angenommene Lücke in JAXB, der Implementierung von Jakarta XML Binding, die bis Java 8 im JDK steckte. Ausgehend von geschätzten 3 Millionen produktiven Java-Anwendungen nimmt Red Hat an, dass 20 % auf Java 8 laufen und davon 90 % JAXB nutzen (540.000), und dass 25 % der übrigen 2,4 Millionen JAXB als Abhängigkeit enthalten (600.000) – zusammen 1,14 Millionen. Mit Raten für veraltete, verwundbare Versionen von 30 % und 20,5 % ergeben sich 285.000 potenziell betroffene Anwendungen. Bei 20 Stunden zu 125 Dollar je Anwendung kostete die getrennte Behebung 712,5 Millionen Dollar oder 5,7 Millionen Stunden. Gegenüber einem Branchenmittel von 54,81 Tagen für hohe und kritische Lücken (Edgescan) spart ein Szenario mit 10 Tagen 44,81 Tage je Anwendung, zusammen 12,8 Millionen Expositionstage.
Red Hat bezeichnet all das ausdrücklich als modellierte Schätzungen und die 10 Tage als Szenario, nicht als gemessenes Ergebnis bei Lightwell-Kunden. Jeder Schritt beruht auf einer Annahme aus Umfragen Dritter; die Summen zeigen Größenordnungen, keine Messwerte.
Quelle: Red Hat, „Open Source Security Signals | Q3 2026“ — https://www.redhat.com/en/blog/open-source-security-signals-q3-2026