Cuando los equipos de seguridad piensan en software de código abierto fin de vida (EOL), la conversación generalmente comienza y termina en el mismo lugar: ya no hay parches. Eso es cierto, pero es solo la mitad de la historia, y argumentablemente la mitad menos peligrosa. Hay dos problemas compuestos de los que la mayoría de los equipos no son conscientes. ## Problema Uno: El Ecosistema CVE No Investiga Lo Que No Soporta Cuando se descubre una vulnerabilidad en un proyecto de código abierto, los mantenedores determinan qué versiones se ven afectadas y registran una **CVE** con un rango afectado definido. Cada escáner de vulnerabilidades, herramienta SBOM y feed de CVE en la industria consume ese rango. Si tu versión cae fuera de él, no recibes ninguna alerta. No porque estés a salvo, sino porque nadie lo verificó. Las versiones EOL caen fuera de ese rango casi por defecto. La razón es sencilla: es un problema de escala. En solo cinco años, el recuento global de CVE se duplicó mientras que el número de CVE no calificadas aumentó 37 veces, según el informe 2026 State of the Software Supply Chain de **Sonatype**. Los mantenedores ya están abrumados investigando y aplicando parches a las versiones que soportan activamente, y a medida que el volumen de CVE y el número total de lanzamientos de paquetes continúan creciendo, el ancho de banda de investigación necesario para cubrir líneas de lanzamiento más antiguas simplemente no existe. Los mantenedores deben ser realistas sobre hasta dónde pueden retroceder razonablemente en su propio historial de lanzamientos. La investigación de Sonatype nombró explícitamente "versiones EOL omitidas de los avisos" como un impulsor de falsa confianza de seguridad, contribuyendo a los 167,286 falsos negativos, componentes explotables que pasaron completamente desapercibidos, que identificaron solo en 2025. ### ¿Cómo Se Ve Esto en la Práctica? Dos vulnerabilidades críticas recientes en el ecosistema Spring lo hacen concreto. **CVE-2026-22732 — Spring Security (Crítica, Marzo 2026, CVSS 9.1)** Esta vulnerabilidad provoca que los encabezados de respuesta de seguridad, incluidos `Cache-Control`, `X-Frame-Options`, `Strict-Transport-Security` y `Content-Security-Policy`, se descarten silenciosamente en ciertas configuraciones de aplicaciones servlet. El rango afectado oficial cubre Spring Security 5.7.x a 7.0.x. Spring Security 6.2.x no está listado. Llegó a EOL en diciembre de 2025. Spring Boot 3.2 incluye Spring Security 6.2. Cualquier organización que ejecute Boot 3.2, una versión menor detrás del rango listado, no recibe ninguna señal del escáner. **HeroDevs** ha confirmado que Spring Security 6.2.x se ve afectado y ha realizado un backport de una solución para clientes de NES. El registro CVE upstream no refleja esto. ### ¿Con Qué Frecuencia Sucede Esto? Los ejemplos de Spring anteriores no son casos aislados. Reflejan un patrón que HeroDevs encuentra consistentemente en su práctica de Never-Ending-Support. Cuando se divulga una nueva CVE en un paquete soportado, HeroDevs descubre que necesita aplicar parches a una versión EOL que el registro oficial de CVE no lista como afectada **aproximadamente el 80% de las veces**. El radio de explosión de cualquier vulnerabilidad dada es sistemáticamente más amplio de lo que muestra el registro. Dicho de forma sencilla: para cuatro de cada cinco CVE divulgadas en una versión soportada, existe una probabilidad razonable de que una versión EOL que estés ejecutando también esté afectada, y ningún escáner en el mundo te lo dirá. ## Problema Dos: La Industria Está Contando el Software EOL Incorrecto La brecha de investigación de CVE anterior se aplica al software EOL que la comunidad sabe que es EOL. Eso resulta ser una fracción muy pequeña del problema real. La fuente de datos EOL más citada es [endoflife.date](http://endoflife.date/), que rastrea aproximadamente 350 proyectos mantenidos activamente; frameworks y runtimes importantes donde los mantenedores han publicado explícitamente fechas de fin de vida. En esos 350 proyectos, aproximadamente 7,000 versiones de paquetes específicas se identifican como EOL. Ese es el universo con el que trabajan la mayoría de los escáneres y equipos de seguridad. Aquí está la escala real del problema. En el informe 2026 State of the Software Supply Chain de Sonatype, producido en asociación con HeroDevs, los datos cuentan una historia diferente. Analizando el estado del ciclo de vida en 12 millones de versiones de paquetes que abarcan npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist y crates.io, HeroDevs encontró que **5.4 millones de esas versiones son fin de vida**. Sin embargo, la fuente pública más completa de la industria (endoflife.date) solo representa ~7,000 de ellas. El desglose por ecosistema es llamativo. Aproximadamente el 25% de las versiones de paquetes npm son EOL. NuGet se sitúa alrededor del 18%, Cargo en el 13%, PyPI en el 11% y Maven Central en el 10%. Estas son versiones que aparecen activamente en SBOM empresariales hoy en día, sin cobertura de investigación de CVE ni ruta de solución. El informe de Sonatype encontró que entre el 5% y el 15% de los componentes en los gráficos de dependencias empresariales son EOL, lo que indica exposición EOL incluso cuando los equipos creen que solo están utilizando bibliotecas de nivel superior soportadas. Las dependencias transitivas, los paquetes de los que dependen tus paquetes, conllevan la mayor parte de esta exposición oculta. La mayoría de las organizaciones están subreportando profundamente su exposición EOL, y no es su culpa. Sus herramientas nunca fueron construidas para detectar el abandono a escala. HeroDevs ha confirmado más de 81,000 versiones de paquetes EOL con CVE conocidas y sin ruta de solución disponible, lo que significa que estas son CVE que fueron investigadas y confirmadas activamente. Dado que aproximadamente el 80% de las CVE en versiones soportadas también afectan a versiones EOL que nunca fueron investigadas oficialmente, el número real es probablemente mucho mayor. HeroDevs estima que la cifra real podría ser cercana a **>400,000** en todos los registros. ## Por Qué Esto Está Empeorando Esta dinámica no es nueva. Lo nuevo es la tasa a la que se está acumulando. El ecosistema OSS está escalando más rápido que la infraestructura de seguridad construida para monitorearlo. Solo npm registró más de 838,000 lanzamientos asociados con puntuaciones CVSS 9.0+ críticas en 2025. El volumen de descargas de PyPI creció más del 50% año tras año. Cada nueva versión de paquete que ingresa a un registro es una futura versión EOL, y la población EOL crece continuamente, mientras que la capacidad de investigación para cubrirla no lo hace. Sin embargo, la fuerza impulsora más significativa puede ser la **IA**. En abril de 2026, **Anthropic** anunció el Proyecto Glasswing junto con Claude Mythos Preview, documentando su capacidad para identificar y explotar vulnerabilidades de día cero en todos los sistemas operativos y navegadores principales, incluidas vulnerabilidades no detectadas durante décadas. La iniciativa es explícitamente defensiva, dirigida a encontrar y corregir vulnerabilidades críticas antes de que los atacantes puedan explotarlas. Para el software con soporte activo, esta es una noticia genuinamente buena. Las vulnerabilidades encontradas a escala de IA pueden ser dirigidas a ingenieros que puedan abordarlas. Para el software EOL, el cálculo es diferente. Una IA que encuentra vulnerabilidades en todo el panorama del código base presentará hallazgos en versiones que ningún mantenedor está vigilando. Esos hallazgos no serán investigados oficialmente contra los rangos afectados por EOL. No activarán alertas de escáner para usuarios EOL. Ningún parche upstream los abordará jamás. La misma capacidad que acelera la defensa para el software soportado amplía la brecha de exposición para todo lo que ya ha quedado atrás. Las primeras señales de este cambio ya son visibles. El impacto total aún no ha llegado. ## ¿Cuánto de Tu Stack Ya Es EOL? No lo sabes. Tu escáner no lo sabe. Tu feed de CVE no lo sabe. Los datos de Sonatype indican que entre el 5% y el 15% de los componentes en un stack empresarial típico son EOL. Solo para npm, es el 25% de todas las versiones de paquetes. Spring Boot 3.2 incluyó Spring Security 6.2, EOL desde diciembre, sin alerta de escáner. **¿Cuál es tu número?** El Conjunto de Datos EOL de HeroDevs te lo dice en menos de cinco minutos. Sube un SBOM o ejecuta la CLI. Lo verificamos contra más de 12 millones de versiones de paquetes en npm, PyPI, Maven, NuGet y todos los demás registros importantes, incluidas las dependencias transitivas que tu escáner omitió. Obtienes un informe que lista cada paquete EOL en tu stack. Sin llamada de ventas. Sin tarjeta de crédito. A medida que la investigación de vulnerabilidades asistida por IA escala, el número de vulnerabilidades no reveladas en paquetes EOL no investigados solo crecerá. **[Ejecuta Mi Escaneo EOL Gratuito →](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)**