Cuando los equipos de seguridad piensan en software open source al final de su vida útil (EOL), la conversación suele empezar y terminar en el mismo punto: no hay más parches. Eso es cierto, pero solo es la mitad de la historia, y posiblemente la mitad menos peligrosa. Hay dos problemas que se agravan y que la mayoría de los equipos desconocen.
Problema uno: el ecosistema CVE no investiga lo que no tiene soporte
Cuando se descubre una vulnerabilidad en un proyecto open source, los mantenedores determinan qué versiones están afectadas y registran un CVE con un rango definido. Todas las herramientas de escaneo, SBOM y feeds CVE consumen ese rango. Si tu versión queda fuera, no recibes alerta. No porque estés seguro, sino porque nadie lo ha comprobado. Las versiones EOL quedan fuera de ese rango casi por defecto. La razón es un problema de escala: en solo cinco años, el recuento global de CVE se duplicó mientras que los CVE sin puntuación aumentaron 37 veces, según el informe State of the Software Supply Chain 2026 de Sonatype. Los mantenedores ya están desbordados investigando y parcheando las versiones que soportan activamente, y a medida que tanto el volumen de CVE como el número total de lanzamientos de paquetes siguen creciendo, la capacidad de investigación necesaria para cubrir líneas de versiones anteriores simplemente no existe. La investigación de Sonatype mencionó explícitamente las "versiones EOL omitidas en los avisos" como un factor que genera una falsa sensación de seguridad, contribuyendo a los 167,286 falsos negativos (componentes explotables que pasaron completamente desapercibidos) identificados solo en 2025.
¿Cómo se ve esto en la práctica?
Dos vulnerabilidades críticas recientes en el ecosistema Spring lo ilustran. CVE-2026-22732 (Spring Security, Crítica, marzo 2026, CVSS 9.1): esta vulnerabilidad provoca que las cabeceras de seguridad de respuesta, incluyendo Cache-Control, X-Frame-Options, Strict-Transport-Security y Content-Security-Policy, se eliminen silenciosamente en ciertas configuraciones de aplicaciones servlet. El rango afectado oficial cubre Spring Security 5.7.x hasta 7.0.x. Spring Security 6.2.x no está listado. Alcanzó su 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 por detrás del rango listado, no recibe ninguna señal del escáner. HeroDevs ha confirmado que Spring Security 6.2.x está afectado y ha aplicado un parche para clientes NES. El registro CVE oficial no lo refleja.
¿Con qué frecuencia ocurre esto?
Los ejemplos de Spring no son casos aislados. Reflejan un patrón que HeroDevs encuentra consistentemente en su práctica de Never-Ending-Support. Cuando se divulga un nuevo CVE en un paquete con soporte, HeroDevs descubre que necesita parchear una versión EOL que el registro CVE oficial no lista como afectada aproximadamente el 80% de las veces. El radio de alcance de cualquier vulnerabilidad dada es sistemáticamente más amplio de lo que muestra el registro. En otras palabras: por cada cuatro de cada cinco CVE divulgados en una versión con soporte, 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 mal el software EOL
La brecha de investigación de CVE mencionada se aplica al software EOL que la comunidad sabe que es EOL. Resulta que eso es una fracción muy pequeña del problema real. La fuente más citada de datos EOL es 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 específicas de paquetes se identifican como EOL. Ese es el universo del que parten la mayoría de los escáneres y equipos de seguridad. Aquí está la escala real del problema. En el informe State of the Software Supply Chain 2026 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 en npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist y crates.io, HeroDevs descubrió que 5.4 millones de esas versiones están al final de su vida útil. Sin embargo, la fuente pública más completa de la industria (endoflife.date) solo cubre unas 7,000 de ellas. El desglose por ecosistema es llamativo. Aproximadamente el 25% de las versiones de paquetes npm están EOL. NuGet ronda el 18%, Cargo el 13%, PyPI el 11% y Maven Central el 10%. Son versiones que aparecen activamente en SBOM empresariales hoy en día, sin cobertura de investigación CVE y sin vía de parche. El informe de Sonatype encontró que entre el 5 y el 15% de los componentes en los grafos de dependencias empresariales están EOL, lo que indica exposición EOL incluso cuando los equipos creen que solo están usando librerías de alto nivel con soporte. Las dependencias transitivas (los paquetes de los que dependen tus paquetes) soportan la mayor parte de esta exposición oculta. La mayoría de las organizaciones están subestimando profundamente su exposición EOL, y no es su culpa. Sus herramientas nunca fueron diseñadas para detectar abandono a escala. HeroDevs ha confirmado más de 81,000 versiones de paquetes EOL con CVE conocidos y sin vía de parche disponible, lo que significa que son CVE que fueron investigados y confirmados. Dado que aproximadamente el 80% de los CVE en versiones con soporte 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 acercarse a más de 400,000 en todos los registros.
Por qué esto está empeorando
Esta dinámica no es nueva. Lo nuevo es la velocidad a la que se está agravando. 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 críticas CVSS 9.0+ en 2025. El volumen de descargas de PyPI creció más del 50% interanual. Cada nueva versión de paquete que entra en 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, el factor más determinante podría ser la IA. En abril de 2026, Anthropic anunció Project 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, incluyendo 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, esto es realmente una buena noticia. Las vulnerabilidades encontradas a escala de IA pueden canalizarse 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 fuente descubrirá hallazgos en versiones que ningún mantenedor está vigilando. Esos hallazgos no serán investigados oficialmente contra los rangos afectados EOL. No activarán alertas de escáner para usuarios EOL. Ningún parche upstream los solucionará. La misma capacidad que acelera la defensa para el software con soporte amplía la brecha de exposición para todo lo que ya ha quedado atrás. Las señales tempranas de este cambio ya son visibles. El impacto completo aún no ha llegado.
¿Cuánto de tu stack está ya EOL?
No lo sabes. Tu escáner no lo sabe. Tu feed CVE no lo sabe. Los datos de Sonatype dicen que entre el 5 y el 15% de los componentes en un stack empresarial típico están EOL. Solo para npm, es el 25% de todas las versiones de paquetes. Spring Boot 3.2 incluía 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 el CLI. Lo comparamos con 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 divulgadas en paquetes EOL no investigados solo crecerá.
Deja una respuesta