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

En los últimos 90 días, hemos ejecutado pentests autónomos contra varios sistemas de producción, y los resultados son difíciles de ignorar.
Las aplicaciones modernas no solo son vulnerables. Son vulnerables de forma continua.
El problema no es que los Teams no hagan pruebas de seguridad. Es que ahora los atacantes operan a velocidad de máquina, mientras que las pruebas y la remediación siguen ocurriendo a ritmo humano.
A medida que la IA acelera el descubrimiento de vulnerabilidades, la ventana entre que se introduce un fallo y que 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 el mundo real

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 descubrió al menos un problema crítico

• Pico: 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 que resulta aún más preocupante es el tipo de vulnerabilidades 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 errores simples

Los problemas más habituales que estamos viendo son fallos de lógica.
Un fallo de lógica significa que el sistema se comporta exactamente como se ha programado, pero el diseño en sí es inseguro.
No son errores de configuración ni bibliotecas 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 entre sí los sistemas.

Esto es lo que significa en la práctica:

• IDOR (Insecure Direct Object Reference) — 177 hallazgos
  Los atacantes pueden acceder a datos de otros usuarios o modificarlos 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 peticiones en su nombre, a menudo a sistemas internos. Esto puede exponer APIs internas, credenciales en 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 problemas aquí porque no entienden el comportamiento. Buscan firmas, no lógica.

Por qué la IA encuentra más

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

Los agentes de IA ahora pueden interactuar con las aplicaciones como lo haría un atacante humano, pero a una escala y velocidad completamente distintas.
No se limitan a escanear endpoints, sino que 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. Nunca duermen. Su jornada laboral nunca termina. Tienen memorizada la base de conocimientos del mundo.
Este cambio es lo que está impulsando los resultados que vemos: un descubrimiento 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 elegir una cerradura. Cuando conoces el funcionamiento interno de la cerradura, 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 benchmark usando el XBow validation suite disponible públicamente, el acceso al código fuente aumentó la detección de vulnerabilidades en aproximadamente un 20% en comparación con las pruebas de caja negra.
También vemos esta brecha en escenarios del mundo real.
Con visibilidad total, los agentes de IA pueden:

• Seguir los flujos de datos de extremo a extremo

• Identificar supuestos rotos en la lógica de negocio

• Explorar casos límite de forma mucho más eficiente

Eso hace que los fallos de lógica sean significativamente más fáciles de encontrar y explotar.
A medida que más aplicaciones se construyen en abierto y que los sistemas de IA mejoran, la velocidad de descubrimiento de vulnerabilidades sigue aumentando.
Dicho esto, que el código no sea abierto 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, aún puede enumerar, hacer fuzzing y, con el tiempo, descubrir rutas explotables, incluso sin acceso directo al código.
Eso significa que la conclusión no va de elegir entre open source o cerrado. Va de adaptar cómo pruebas y proteges los sistemas.
Independientemente de la arquitectura, las evaluaciones tradicionales puntuales no dan en el blanco. Las bases de código evolucionan a velocidad de máquina, y las superficies de ataque también.

El verdadero problema: más velocidad = menor 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

Eso 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 la remediación suele avanzar todavía más despacio, a la espera de priorización, capacidad de ingeniería y ciclos de lanzamiento. Incluso el tiempo que lleva pasar código a producción crea brechas 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 plazos 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. Se puede explotar.
El modelo tradicional de «probar, informar, arreglar más tarde» simplemente no se sostiene 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 de forma continua, 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 Teams pueda resolver solo con más personal.
Las pruebas manuales no escalan lo suficiente para igualar la velocidad del desarrollo moderno ni la de los atacantes modernos.
Por eso estamos viendo un cambio 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 van a esperar 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 ir al mismo ritmo.
Independientemente de la arquitectura, las evaluaciones tradicionales puntuales no dan en el blanco. Las bases de código evolucionan a velocidad de máquina, y las superficies de ataque también.
Los sistemas de open source tienen que reconocer y asumir la exposición adicional que conlleva la visibilidad del código. Los sistemas de código cerrado, por su parte, no pueden confiar en la oscuridad y también tendrán que mejorar su postura de seguridad.
La brecha entre lo rápido que construimos software y lo a menudo que lo probamos se está ampliando.
La IA está acelerando ambos lados, pero ahora mismo los atacantes llevan ventaja.
Si no estás escalando activamente la seguridad para igualar la amenaza, tus sistemas fallarán.

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