Das Dilemma beginnt mit einem strukturellen Problem: Wenn ein Sicherheitsforscher eine Schwachstelle findet, dokumentieren die Projektmaintainer, welche Versionen betroffen sind. Diese Information fließt in CVE-Einträge ein, die alle Sicherheitsscanner weltweit konsumieren. Liegt die eingesetzte Version außerhalb dieser definierten Range, bleibt die Warnung aus — nicht weil die Software sicher ist, sondern weil niemand sie überprüft hat.
Bei EOL-Versionen ist dies fast die Regel. Der Grund ist pragmatisch: Maintainer sind mit der Menge an Schwachstellen überfordert. Sonatype’s «State of the Software Supply Chain»-Report zeigt, dass die CVE-Zahlen in fünf Jahren verdoppelt wurden, während ungeprüfte CVEs um das 37-Fache anwuchsen. Projektverantwortliche müssen sich auf ihre aktiv gepflegten Versionen konzentrieren. Eine flächendeckende Überprüfung alter Release-Linien ist schlicht nicht machbar.
Die Realität des Problems ist größer als bislang bekannt. Die industrie-Standard-Datenbank endoflife.date verfolgt etwa 7.000 EOL-Versionen — ein winziger Bruchteil. Analysen zeigen: Von 12 Millionen untersuchten Paketversionen across npm, PyPI, Maven, NuGet und anderen Registries sind 5,4 Millionen EOL. Bei npm sind etwa 25 Prozent aller Versionen nicht mehr gepflegt, bei NuGet 18 Prozent, bei PyPI 11 Prozent. Diese Versionen tauchen regelmäßig in Enterprise-SBOMs auf — ohne jeden CVE-Untersuchungsschutz und ohne Reparaturpfad.
Zwei aktuelle kritische Lücken im Spring-Ökosystem verdeutlichen das Ausmaß. CVE-2026-22732 betrifft Spring Security mit einem CVSS-Wert von 9,1 — Security-Header werden stillschweigend gelöscht. Der offizielle Datensatz listet die Versionen 5.7.x bis 7.0.x auf. Spring Security 6.2.x ist nicht aufgeführt, obwohl es mit Spring Boot 3.2 versendet wird und ebenfalls verwundbar ist. Der Scanner wird nicht warnen, weil die Version außerhalb des dokumentierten Bereichs liegt.
Das ist kein Einzelfall. Bei etwa 80 Prozent der auf unterstützten Versionen gefundenen CVEs stellt sich nachträglich heraus, dass auch die EOL-Versionen betroffen sind. Der tatsächliche Schadensradius ist systematisch größer als die Datensätze zeigen.
Eine zusätzliche Bedrohung zeichnet sich am Horizont ab: KI-gestützte Schwachstellenforschung. Anthropics Project Glasswing kann Nullday-Lücken automatisiert erkennen. Bei aktiv gepflegter Software ist das ein Segen. Bei EOL-Software ändert sich die Rechnung fundamental. Schwachstellen, die KI in alten Codebasen findet, werden keine Maintainer überprüfen, keine CVE-Einträge triggern und keine Scanner alarmieren. Die gleiche Technologie, die die Verteidigung beschleunigt, vergrößert die Schutzlücke für alles Veraltete.
Deutsche Unternehmen sollten ihre Abhängigkeitsgraphen neu bewerten — nicht als Frage der Compliance, sondern als existenzielles Risiko. Das BSI sollte EOL-Monitoring in seine Sicherheitsempfehlungen aufnehmen. Ein sauberer Scan ist kein Sicherheitszeichen. Er bedeutet nur: Nicht überprüft.