Wenn Sicherheitsteams an End-of-Life (EOL) Open-Source-Software denken, beginnt und endet die Diskussion normalerweise am selben Punkt: keine Patches mehr. Das stimmt zwar, aber es ist nur die halbe Wahrheit und wohl die weniger gefährliche Hälfte. Es gibt zwei sich überschneidende Probleme, derer sich die meisten Teams nicht bewusst sind. ## Problem Eins: Das CVE-Ökosystem untersucht nicht, was es nicht unterstützt Wenn eine Schwachstelle in einem Open-Source-Projekt entdeckt wird, bestimmen die Maintainer, welche Versionen betroffen sind, und reichen eine **CVE** mit einem definierten betroffenen Bereich ein. Jeder Schwachstellenscanner, jedes SBOM-Tool und jeder CVE-Feed in der Branche verarbeitet diesen Bereich. Wenn Ihre Version außerhalb dieses Bereichs liegt, erhalten Sie keine Benachrichtigung. Nicht, weil Sie sicher sind, sondern weil niemand nachgesehen hat. EOL-Versionen fallen fast standardmäßig außerhalb dieses Bereichs. Der Grund dafür ist einfach: Es ist ein Skalierungsproblem. Laut dem Sonatype State of the Software Supply Chain Report 2026 hat sich die globale CVE-Anzahl in nur fünf Jahren verdoppelt, während die Anzahl der nicht bewerteten CVEs um das 37-fache gestiegen ist. Die Maintainer sind bereits überfordert, die aktiv unterstützten Versionen zu untersuchen und zu patchen. Da sowohl das CVE-Volumen als auch die Gesamtzahl der Paketveröffentlichungen weiter wachsen, fehlt einfach die Untersuchungskapazität, um ältere Release-Linien abzudecken. Die Maintainer müssen realistisch sein, wie weit zurück in ihrer eigenen Release-Historie sie vernünftigerweise gehen können. Die Forschung von Sonatype nannte ausdrücklich "EOL-Versionen, die aus Advisories weggelassen werden" als Treiber für falsche Sicherheitszuversicht und trug zu den 167.286 False Negatives bei, also ausnutzbaren Komponenten, die allein im Jahr 2025 völlig unmarkiert blieben. ### Wie sieht das in der Praxis aus? Zwei aktuelle kritische Schwachstellen im Spring-Ökosystem verdeutlichen dies. **CVE-2026-22732 — Spring Security (Kritisch, März 2026, CVSS 9.1)** Diese Schwachstelle führt dazu, dass Sicherheitsantwort-Header, einschließlich `Cache-Control`, `X-Frame-Options`, `Strict-Transport-Security` und `Content-Security-Policy`, in bestimmten Servlet-Anwendungskonfigurationen stillschweigend fallen gelassen werden. Der offizielle betroffene Bereich umfasst Spring Security 5.7.x bis 7.0.x. Spring Security 6.2.x ist nicht aufgeführt. Es erreichte im Dezember 2025 das EOL. Spring Boot 3.2 liefert Spring Security 6.2 aus. Jede Organisation, die Boot 3.2 ausführt, eine Minor-Version hinter dem aufgeführten Bereich, erhält kein Scannersignal. **HeroDevs** hat bestätigt, dass Spring Security 6.2.x betroffen ist und hat einen Fix für NES-Kunden zurückportiert. Der Upstream-CVE-Datensatz spiegelt dies nicht wider. ### Wie oft passiert das? Die oben genannten Spring-Beispiele sind keine Ausreißer. Sie spiegeln ein Muster wider, das HeroDevs im Rahmen seiner Never-Ending-Support-Praxis konsequent antrifft. Wenn ein neues CVE für ein unterstütztes Paket offengelegt wird, stellt HeroDevs fest, dass es eine EOL-Version patchen muss, die im offiziellen CVE-Datensatz nicht als betroffen aufgeführt ist, und das **ungefähr 80 % der Zeit**. Die Angriffsfläche jeder Schwachstelle ist systematisch größer als das, was der Datensatz zeigt. Einfach ausgedrückt: Bei vier von fünf CVEs, die für eine unterstützte Version offengelegt werden, besteht eine vernünftige Wahrscheinlichkeit, dass eine von Ihnen verwendete EOL-Version ebenfalls betroffen ist, und kein Scanner der Welt wird Ihnen das mitteilen. ## Problem Zwei: Die Branche zählt die falsche EOL-Software Die oben genannte CVE-Untersuchungslücke gilt für EOL-Software, von der die Community tatsächlich weiß, dass sie EOL ist. Das stellt sich als ein sehr kleiner Bruchteil des eigentlichen Problems heraus. Die am weitesten verbreitete Quelle für EOL-Daten ist [endoflife.date](http://endoflife.date/), die etwa 350 aktiv gepflegte Projekte verfolgt; wichtige Frameworks und Laufzeiten, für die Maintainer explizit End-of-Life-Daten veröffentlicht haben. Über diese 350 Projekte hinweg werden etwa 7.000 spezifische Paketversionen als EOL identifiziert. Das ist das Universum, mit dem die meisten Scanner und Sicherheitsteams arbeiten. Hier ist das tatsächliche Ausmaß des Problems. Im Sonatype State of the Software Supply Chain Report 2026, der in Zusammenarbeit mit HeroDevs erstellt wurde, zeigt die Daten eine andere Geschichte. Bei der Analyse des Lebenszyklusstatus von 12 Millionen Paketversionen, die npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist und crates.io umfassen, stellte HeroDevs fest, dass **5,4 Millionen dieser Versionen End-of-Life sind**. Die umfassendste öffentliche Quelle der Branche (endoflife.date) deckt jedoch nur etwa 7.000 davon ab. Die Aufschlüsselung nach Ökosystem ist bemerkenswert. Ungefähr 25 % der npm-Paketversionen sind EOL. NuGet liegt bei etwa 18 %, Cargo bei 13 %, PyPI bei 11 % und Maven Central bei 10 %. Dies sind Versionen, die heute aktiv in Enterprise-SBOMs vorkommen, ohne CVE-Untersuchungsabdeckung und ohne Korrekturweg. Der Sonatype-Bericht ergab, dass 5-15 % der Komponenten in Enterprise-Abhängigkeitsgraphen EOL sind, was eine EOL-Exposition anzeigt, selbst wenn Teams glauben, nur unterstützte Top-Level-Bibliotheken zu verwenden. Transitive Abhängigkeiten, die Pakete, von denen Ihre Pakete abhängen, tragen den Großteil dieser versteckten Exposition. Die meisten Organisationen melden ihre EOL-Exposition in erheblichem Maße falsch, und das ist nicht ihre Schuld. Ihre Tools wurden nie dafür entwickelt, eine Aufgabe in diesem Umfang zu erkennen. HeroDevs hat über 81.000 EOL-Paketversionen mit bekannten CVEs und ohne verfügbaren Korrekturweg bestätigt, was bedeutet, dass dies CVEs sind, die aktiv untersucht und bestätigt wurden. Angesichts der Tatsache, dass etwa 80 % der CVEs für unterstützte Versionen auch EOL-Versionen betreffen, die nie offiziell untersucht wurden, ist die tatsächliche Zahl wahrscheinlich weitaus größer. HeroDevs schätzt, dass die tatsächliche Zahl über alle Registries hinweg näher bei **>400.000** liegen könnte. ## Warum wird das schlimmer? Diese Dynamik ist nicht neu. Neu ist die Geschwindigkeit, mit der sie sich verschärft. Das OSS-Ökosystem skaliert schneller als die Sicherheitsinfrastruktur, die zu seiner Überwachung aufgebaut wurde. Allein npm verzeichnete im Jahr 2025 über 838.000 Veröffentlichungen, die mit kritischen CVSS 9.0+-Scores verbunden waren. Das Download-Volumen von PyPI wuchs im Jahresvergleich um über 50 %. Jede neue Paketversion, die in eine Registry gelangt, ist eine zukünftige EOL-Version, und die EOL-Population wächst kontinuierlich, während die Untersuchungskapazität, um sie abzudecken, nicht mitwächst. Die wichtigere treibende Kraft ist jedoch möglicherweise **KI**. Im April 2026 kündigte **Anthropic** Project Glasswing zusammen mit der Claude Mythos Preview an und dokumentierte seine Fähigkeit, Zero-Day-Schwachstellen in allen wichtigen Betriebssystemen und Browsern zu identifizieren und auszunutzen – einschließlich Schwachstellen, die seit Jahrzehnten unentdeckt waren. Die Initiative ist ausdrücklich defensiv ausgerichtet und zielt darauf ab, kritische Schwachstellen zu finden und zu beheben, bevor Angreifer sie ausnutzen können. Für Software mit aktiver Unterstützung sind dies wirklich gute Nachrichten. Schwachstellen, die im KI-Maßstab gefunden werden, können an Ingenieure weitergeleitet werden, die sie beheben können. Für EOL-Software ist die Rechnung anders. Eine KI, die Schwachstellen in der gesamten Codebasis findet, wird Erkenntnisse in Versionen aufdecken, die kein Maintainer beobachtet. Diese Erkenntnisse werden nicht offiziell gegen die EOL-betroffenen Bereiche untersucht. Sie lösen keine Scanner-Alarme für EOL-Benutzer aus. Kein Upstream-Patch wird sie jemals beheben. Die gleiche Fähigkeit, die die Verteidigung für unterstützte Software beschleunigt, vergrößert die Expositionslücke für alles, was bereits zurückgelassen wurde. Die ersten Anzeichen dieser Verschiebung sind bereits sichtbar. Die volle Auswirkung ist noch nicht eingetreten. ## Wie viel Ihres Stacks ist bereits EOL? Sie wissen es nicht. Ihr Scanner weiß es nicht. Ihr CVE-Feed weiß es nicht. Die Daten von Sonatype besagen, dass 5-15 % der Komponenten in einem typischen Enterprise-Stack EOL sind. Allein für npm sind es 25 % aller Paketversionen. Spring Boot 3.2 lieferte Spring Security 6.2 aus, seit Dezember EOL, kein Scannersignal. **Was ist Ihre Zahl?** Das HeroDevs EOL Dataset verrät es Ihnen in unter fünf Minuten. Laden Sie ein SBOM hoch oder führen Sie die CLI aus. Wir prüfen es gegen über 12 Millionen Paketversionen über npm, PyPI, Maven, NuGet und jede andere wichtige Registry, einschließlich der transitiven Abhängigkeiten, die Ihr Scanner übersprungen hat. Sie erhalten einen Bericht, der jedes EOL-Paket in Ihrem Stack auflistet. Kein Verkaufsgespräch. Keine Kreditkarte. Mit zunehmender Skalierung der KI-gestützten Schwachstellenforschung wird die Anzahl der nicht offengelegten Schwachstellen in unerforschten EOL-Paketen nur noch weiter steigen. **[Scannen Sie jetzt kostenlos meinen EOL-Status →](http://www.herodevs.com/eol-dataset/eol-data?utm_source=sponsored-article&utm_medium=paid-sponsorship&utm_campaign=2026q2_eolds-ga-phase2_global&utm_content=bleeping-computer_20260505)**