La IA está encontrando vulnerabilidades críticas más rápido de lo que los equipos pueden arreglarlas

En los últimos 90 días hemos ejecutado pentests autónomos contra distintos sistemas de producción, y los resultados son difíciles de ignorar.
Las aplicaciones modernas no solo son vulnerables. Son continuamente vulnerables.
El problema no es que los equipos no hagan pruebas de seguridad. Es que ahora los atacantes operan a velocidad de máquina, mientras que las pruebas y las correcciones siguen haciéndose con tiempos humanos.
A medida que la IA acelera el descubrimiento de vulnerabilidades, la ventana entre que aparece un fallo y se explota se está reduciendo. Si las pruebas y las correcciones no avanzan al mismo ritmo, esa brecha se convierte en la superficie de ataque.

Lo que estamos viendo en la práctica

En 28 empresas, nuestros agentes identificaron:

• ~2000 vulnerabilidades en total

• 44,6% críticas o de alta gravedad (829 hallazgos)

• 21,6 vulnerabilidades por análisis de media (mediana: 15)

• El 65,1% de los análisis descubrieron al menos un problema crítico

• Máximo: 88 vulnerabilidades en un solo análisis

Estos no son riesgos teóricos. Cada hallazgo se valida con un exploit funcional de prueba de concepto.
Casi la mitad de todas las vulnerabilidades que encontramos son graves, y la mayoría de los sistemas tiene al menos un problema crítico.
Lo más preocupante es el tipo de vulnerabilidades que hay detrás de estas cifras. No son simples errores de configuración ni dependencias desactualizadas. Son problemas más profundos en cómo se diseñan y se comportan las aplicaciones.

No son fallos simples

Los problemas más comunes que estamos viendo son fallos de lógica.
Un fallo de lógica significa que el sistema se está comportando exactamente como se ha programado, pero el diseño en sí es inseguro.
No son errores de configuración ni librerías desactualizadas. Son fallos en cómo funciona realmente la aplicación, cómo fluye la información, cómo se aplican los permisos y cómo confían los sistemas entre sí.

Esto es lo que significa en la práctica:

• IDOR (Insecure Direct Object Reference) — 177 hallazgos
  Los atacantes pueden acceder o modificar los datos de otros usuarios simplemente cambiando identificadores (por ejemplo, IDs de usuario, IDs de archivo). Esto puede exponer datos sensibles a gran escala o incluso permitir la toma de control de cuentas.

• SSRF (Server-Side Request Forgery) — 122 hallazgos
  Los atacantes pueden engañar al servidor para que haga solicitudes en su nombre, a menudo hacia sistemas internos. Esto puede exponer APIs internas, credenciales de la nube o infraestructura que nunca debería ser accesible públicamente.

• Falta de autenticación — 105 hallazgos
  Los endpoints o acciones sensibles son accesibles sin iniciar sesión. Eso significa que cualquiera en internet puede activar funcionalidades críticas o acceder a datos protegidos.

Estas vulnerabilidades son especialmente peligrosas porque explotan cómo se comporta la aplicación, no solo cómo está configurada.
Los escáneres tradicionales tienen dificultades aquí porque no entienden el comportamiento. Buscan firmas, no lógica.

Por qué la IA está encontrando más

Hasta hace poco, encontrar y explotar este tipo de vulnerabilidades requería tiempo, habilidad y trabajo manual.
Eso ha cambiado.

Los agentes de IA ahora pueden interactuar con las aplicaciones igual que lo haría un atacante humano, pero a una escala y velocidad completamente distintas.
No se limitan a escanear endpoints, los exploran.

• Prueban casos límite

• Encadenan varios pasos

• Iteran rápidamente entre miles de posibilidades

En lugar de comprobar problemas conocidos, sondean activamente cómo se comporta una aplicación y buscan formas de romperla. No duermen nunca. Su jornada nunca termina. Tienen memorizada la base de conocimiento del mundo.
Este cambio es lo que está impulsando los resultados que estamos viendo: una detección constante de problemas críticos en la mayoría de los análisis.

Por qué el open source puede acelerar el descubrimiento de vulnerabilidades

El open source cambia cómo se descubren las vulnerabilidades.
Imagina abrir una cerradura. Si conoces su funcionamiento interno, es mucho más fácil abrirla.
Cuando los sistemas de IA tienen acceso al código fuente, pueden analizar directamente cada ruta de código en lugar de inferir el comportamiento desde fuera.
En pruebas controladas de referencia usando la suite de validación de XBow, de acceso público, el acceso al código fuente aumentó la detección de vulnerabilidades en aproximadamente un 20% frente a las pruebas de caja negra.
También vemos esta diferencia en escenarios del mundo real.
Con visibilidad total, los agentes de IA pueden:

• Seguir el flujo de datos de extremo a extremo

• Identificar supuestos rotos en la lógica de negocio

• Explorar casos límite con mucha más eficiencia

Esto hace que los fallos de lógica sean mucho más fáciles de encontrar y explotar.
A medida que más aplicaciones se construyen en abierto y los sistemas de IA mejoran, la velocidad de descubrimiento de vulnerabilidades sigue aumentando.
Dicho esto, que el código sea cerrado no te hace seguro por defecto.
La seguridad por oscuridad nunca ha sido una defensa real. Un atacante decidido, con suficiente capacidad de cómputo y suficientes tokens que gastar, todavía puede enumerar, hacer fuzzing y acabar encontrando rutas explotables, incluso sin acceso directo al código.
Eso significa que la conclusión no va de elegir entre open source y cerrado. Va de adaptar cómo pruebas y proteges los sistemas.
Independientemente de la arquitectura, las evaluaciones puntuales tradicionales se quedan cortas. Las bases de código evolucionan a velocidad de máquina, y las superficies de ataque también.

El verdadero problema: más velocidad = menos coste

Hace unos años, encontrar y explotar vulnerabilidades requería tiempo, habilidad y paciencia.
Hoy, ese plazo se ha desplomado.
Los sistemas de IA pueden:

• Ejecutar miles de pruebas en paralelo

• Explorar continuamente nuevas rutas de código

• Encadenar exploits automáticamente

Esto significa que las vulnerabilidades se están descubriendo más rápido que nunca, a menudo en cuestión de horas o días desde que se introducen.
Pero la mayoría de las organizaciones no se han adaptado a este cambio.
Las pruebas de seguridad siguen tratándose como un evento periódico:

• Una vez al año

• Quizá una vez al trimestre

Y las correcciones suelen avanzar todavía más despacio, esperando priorización, capacidad de ingeniería y ciclos de lanzamiento. Incluso el tiempo que se tarda en llevar el código a producción crea huecos que los sistemas más rápidos pueden aprovechar.
Esto crea una brecha cada vez mayor:

• Las vulnerabilidades se descubren a velocidad de máquina

• Las correcciones se despliegan con tiempos humanos

Esa brecha es la verdadera superficie de ataque.
Si una vulnerabilidad crítica existe durante días o semanas antes de corregirse, da igual cómo se haya encontrado. Es explotable.
El modelo tradicional de “prueba, informa, corrige después” simplemente no funciona cuando tanto los atacantes como los sistemas de descubrimiento operan de forma continua.
Ese modelo ya está obsoleto.

Lo que realmente funciona

El cambio no va de herramientas. Va de enfoque.
La seguridad necesita pasar de:

• pruebas puntuales → pruebas continuas

En la práctica, esto no es solo un cambio de herramientas.
Requiere replantear cómo encaja la seguridad en el ciclo de desarrollo.
Las pruebas continuas suelen combinar:

• Sistemas automatizados que ejecutan pruebas continuamente, no solo una vez al año

• Seguridad integrada directamente en los pipelines de CI/CD

• Desarrolladores que asumen y corrigen los problemas como parte de los flujos de trabajo normales

• Pruebas humanas periódicas para rutas de ataque más profundas y complejas

Esto no es algo que la mayoría de los equipos pueda resolver solo contratando más gente.
Las pruebas manuales no escalan al ritmo del desarrollo moderno ni de los atacantes modernos.
Por eso estamos viendo un giro hacia la automatización y, en muchos casos, hacia externalizar las pruebas continuas a sistemas que pueden operar a velocidad de máquina.
La urgencia aquí es real.

¿Y ahora qué?

La IA ya está acelerando el descubrimiento de vulnerabilidades. Los atacantes no están esperando a tu próximo pentest programado.
Si tu aplicación cambia a diario, tus pruebas de seguridad y tu capacidad para corregir problemas tienen que seguir ese ritmo.
Independientemente de la arquitectura, las evaluaciones puntuales tradicionales se quedan cortas. Las bases de código evolucionan a velocidad de máquina, y las superficies de ataque también.
Los sistemas open source tienen que reconocer y asumir la exposición adicional que implica la visibilidad del código. Los sistemas cerrados, por su parte, no pueden confiar en la oscuridad y también tendrán que mejorar su postura de seguridad.
La brecha entre la velocidad a la que construimos software y la frecuencia con la que lo probamos está creciendo.
La IA está acelerando ambos lados, pero ahora mismo los atacantes llevan ventaja.
Si no escalas activamente la seguridad para igualar la amenaza, tus sistemas fallarán.

El benchmark mencionado arriba (XBow) está disponible públicamente en GitHub. Nuestros resultados combinan pruebas controladas de benchmark con datos reales de sistemas de producción en toda nuestra plataforma.