La firma de capital riesgo a16z acaba de compartir un gráfico que ha causado revuelo en X en los últimos días. El gráfico muestra que las CVE críticas y altas han pasado de menos de 100 al mes a más de 600 al mes desde la primavera de 2026 en 21 grandes empresas de software. Los datos provienen de Epoch AI e incluyen recuentos de Apple, AWS, Microsoft, Google y Adobe.
Y como esto es X, por supuesto que la gente dio su opinión (sí, nosotros estamos haciendo lo mismo aquí).
Se dividieron en dos bandos. Uno lo interpretó como un cambio real en el riesgo, mientras que el otro señaló que las vulnerabilidades explotadas conocidas (KEV) no se han movido desde 2024, por lo que el mero hecho de que haya más divulgaciones no significa necesariamente que haya más peligro.
Incluso el propio informe de a16z matiza esto:
«Ya sea que realmente haya más vulnerabilidades, o que haya algún cambio en los informes o en la definición, es difícil decirlo con solo mirar el gráfico, pero es probable que al menos una parte (y tal vez gran parte) de este crecimiento parabólico se deba a un cambio sustancial importante en la forma en que se descubren las vulnerabilidades y/o en lo que todavía se considera seguro».
Pero ambos bandos lo están interpretando mal por completo. Ni el recuento bruto de nuevos CVEs ni una cifra KEV estática determinan realmente el riesgo. El riesgo se determina por la rapidez con la que puedes descubrir qué vulnerabilidades importan y con qué rapidez se solucionan una vez validadas.
Es evidente que la inteligencia artificial ha facilitado mucho la búsqueda de vulnerabilidades (tanto para atacantes como para defensores). Los modelos de vanguardia encuentran vulnerabilidades más rápido de lo que los revisores pueden validarlas, incluidos errores de larga data que sobrevivieron a años de revisión manual.
Por lo tanto, el salto en el gráfico de a16z se explica mejor porque la inteligencia artificial acelera la búsqueda de errores que ya existían, en lugar de que el software se vuelva menos seguro de repente. Pero eso es solo una parte de la historia.
Qué pasa cuando una institución intenta seguir el ritmo de una detección sencilla
NIST, la institución que todos consideran como la referencia absoluta para los datos de vulnerabilidades, está lidiando exactamente con el mismo problema a mayor escala. Partiendo de la suposición de que más CVE significaban más peligro, intentaba puntuar cada CVE que recibía. Sin embargo, el volumen absoluto de CVE hizo que esto fuera prácticamente imposible. Y, al final, el sistema colapsó.
Una auditoría federal realizada este mes de mayo reveló que la acumulación pendiente había crecido de 13 000 a más de 27 000 en dieciocho meses. ¿La solución propuesta por el NIST? Dejar de puntuarlos todos. En su lugar, prioriza los CVE vinculados al uso federal, software crítico o aquellos que ya figuran en la lista de vulnerabilidades explotadas conocidas de CISA. Todo lo demás se marca como «sin programar», por lo que es probable que no se vuelva a revisar.
El problema del NIST tiene que ver con la divulgación y puntuación de las vulnerabilidades. Sin embargo, incluso en el caso de aquellas que superan ese filtro por completo —es decir, que están confirmadas, puntuadas y se sabe que se explotan activamente—, lograr que se solucionen es donde las cosas todavía parecen fallar.
El cuello de botella está en la corrección
El informe de investigación de violaciones de datos de Verizon de 2026, basado en más de mil millones de registros de vulnerabilidades, reveló que solo el 26 % de las vulnerabilidades confirmadas y explotadas activamente (en la lista KEV de CISA) se remediaron por completo en 2025, por debajo del 38 % del año anterior. El tiempo medio para parchear por completo una aumentó a 43 días, frente a los 32 anteriores.
Incluso las organizaciones con mejores recursos solo remedian por completo entre el 30 % y el 40 % de estas en la primera semana. Verizon llama a esto la «paradoja de la remediación», que en realidad es otra forma de decir que las vulnerabilidades se aceleran mientras que la corrección se ralentiza.
Se sabe que estas vulnerabilidades se explotan activamente y constan en una lista pública. A pesar de ello, siguen sin corregirse con la suficiente rapidez.
Cómo es en realidad una corrección rápida
Este mes, una vulnerabilidad de RCE sin autenticación llamada Stylesmuggler comenzó a afectar a Adobe Commerce y Magento Open Source. No tenía ningún CVE asociado ni ningún aviso oficial de Adobe.
Una vulnerabilidad no necesita un número CVE ni un aviso del proveedor para ser real o para ser explotada. Esperar a cualquiera de ambas cosas antes de actuar significa que los atacantes ya llevan ventaja. La única forma de evitarlo es confiar en una solución capaz de encontrar y confirmar vulnerabilidades por sí misma, y solucionarlas rápidamente una vez que lo hace.
Aikido Intel la detectó de forma independiente, sin esperar a que Adobe o un número CVE confirmaran su autenticidad. Realizó el seguimiento de la vulnerabilidad bajo tres entidades diferentes, y Aikido Libraries lanzó un parche operativo para múltiples versiones afectadas. Se implementó como una solicitud de extracción de AutoFix directamente en el flujo de trabajo que los equipos ya utilizan, en lugar de requerir una migración manual separada y laboriosa. Todo esto antes de que Adobe lanzara su propio parche de emergencia más de 24 horas después.
Sin embargo, StyleSmuggle no es un caso aislado. En el primer año de funcionamiento de Intel, el 67 % de los paquetes en los que encontró vulnerabilidades nunca se habían divulgado públicamente en ninguna base de datos (ni en NVD, ni en GitHub Advisory, ni en MITRE, ni en ningún otro sitio).
Así pues, la verdadera historia es...
El aumento en el volumen de CVE es similar a la cantidad de paquetes npm publicados cada año; se acumula exponencialmente, por lo que vigilar su crecimiento carece un poco de sentido. Lo que importa es la rapidez con la que se soluciona una vulnerabilidad real y confirmada y, ahora mismo, en toda la industria, no se está haciendo lo suficientemente rápido.
A medida que la IA democratiza las capacidades de detección y explotación, la ciberseguridad debe reinventarse en torno a lo que ocurre después de que se descubre un problema. Eso empieza por saber cuáles de las vulnerabilidades que aparecen son realmente alcanzables y explotables. El análisis de alcanzabilidad de Aikido filtra cualquier elemento que no tenga una ruta de ejecución hacia el código vulnerable, y el análisis de explotabilidad de CVE va más allá, evaluando cómo se utiliza realmente un paquete en tu entorno para decidir si vale la pena actuar ante una vulnerabilidad alcanzable.
Aikido se encarga de las correcciones de dos formas. Para problemas conocidos y solucionables, AutoFix puede generar la solución directamente. En el caso de los paquetes de código abierto, parchea la versión exacta que ya está fijada en el archivo de bloqueo (lockfile) del equipo, sin necesidad de realizar una gran actualización o migración. Funciona de la misma manera para las imágenes base de contenedores vulnerables y el código de aplicaciones. Cuando una corrección requiere una decisión humana, la vulnerabilidad sigue señalándose con una recomendación específica y práctica, para que alguien pueda actuar de inmediato en lugar de tener que averiguar por dónde empezar. El siguiente paso, que consiste en hacer todo esto hasta llegar a producción sin esperar a que alguien fusione el código, no está muy lejano.
Encontrar vulnerabilidades nunca ha sido tan fácil. Ahora, el enfoque debe centrarse en cómo filtrar las vulnerabilidades para descartar el ruido y solucionarlas rápidamente.
