La nueva era de AppSec: por qué el código generado por IA necesita pruebas dinámicas ofensivas

Mi colega Manoj Nair escribió recientemente sobre la creciente brecha entre lo que crea la IA y lo que los equipos de seguridad realmente prueban. Planteó que la velocidad del desarrollo impulsado por IA ha superado radicalmente la capacidad de validación, y que la respuesta no puede ser reducir la velocidad, sino cambiar el significado de las pruebas. Estoy de acuerdo con cada palabra.

Quiero profundizar un nivel más. He dedicado casi una década a crear motores de pruebas dinámicas de seguridad. Primero en Probely, empresa que cofundé, y ahora en Snyk, donde nuestra tecnología impulsa Snyk API & Web. Así que, cuando digo que todo está a punto de cambiar en la manera en que esta industria entiende las pruebas dinámicas de seguridad, no estoy haciendo una predicción del mercado: describo lo que veo en las arquitecturas que probamos todos los días.

El análisis de código se volvió mucho más inteligente. Pero aún no es suficiente.

Empecemos reconociendo sus méritos: el análisis estático ha avanzado muchísimo.

Durante años, esta categoría quedó atrapada en una era de comparación rígida y ruidosa de patrones, con motores basados en reglas que generaban grandes volúmenes de hallazgos, pero muy pocas señales útiles.

Luego llegó una primera ola de aprendizaje automático e IA simbólica, capaz de rastrear flujos de datos más profundos en las bases de código: motores como Snyk Code, impulsado por DeepCode AI, que aportaron una comprensión semántica real al análisis estático.

Y ahora está surgiendo una capacidad realmente distinta: herramientas con agentes que usan razonamiento semántico para entender la intención real del código, no solo su sintaxis. Estos modelos pueden detectar directamente en el código fuente fallas complejas en la lógica de negocio y problemas de autorización, de formas que habrían sido impensables hace cinco años.

Esto representa un avance real y significativo. De hecho, ha evolucionado tanto que cabe preguntarse si la industria seguirá llamándolo «SAST» o creará un término completamente nuevo.

Pero aquí está el punto: incluso el motor de análisis de código más avanzado tiene un límite: no puede probar lo que no puede ejecutar.

Las aplicaciones modernas no son monolitos; son entornos distribuidos, compuestos y de varios niveles: aplicaciones de una sola página que se comunican con decenas de microservicios de backend, cada uno con su propio contexto de autenticación, patrones de acceso a datos y ciclo de implementación. Un escáner de código sofisticado podría detectar correctamente una falla de autorización en la base de código de un microservicio. Pero ¿qué pasa si la vulnerabilidad solo se manifiesta cuando interactúan varios componentes?

Considera un caso real: un problema de autorización que solo aparece por cómo una aplicación frontend gestiona un token, combinado con la forma en que una puerta de enlace de API enruta la solicitud y con la manera en que un servicio secundario de backend interpreta el rol del usuario. Ninguna base de código contiene por sí sola la vulnerabilidad. Esta surge de la interacción. El análisis estático, por muy inteligente que sea, tiene dificultades para manejar el estado entre componentes de distintas bases de código, porque fundamentalmente no puede observar el sistema en su conjunto.

Eso es exactamente lo que pueden hacer las pruebas dinámicas de seguridad. Pueden validar si un atacante realmente puede explotar un sistema cuando todos esos componentes diferentes están conectados en un entorno en vivo.

Este punto ciego de ejecución se extiende directamente a la frontera que describió Manoj: agentes de IA que llaman a API de forma autónoma y a gran escala, de maneras que quienes los crearon nunca previeron. Riesgos como la inyección de prompts, el secuestro de objetivos y el envenenamiento del contexto no existen en el código fuente. Son comportamientos emergentes que solo ocurren durante la ejecución. Al igual que esas interacciones complejas entre microservicios, estas amenazas solo pueden validarse interactuando dinámicamente con el sistema en vivo.

La convergencia de la que nadie habla

Hay algo más que está ocurriendo en el mercado y que, en mi opinión, merece más atención directa.

En el último año surgió una nueva etiqueta: «pentester de IA». Y la etiqueta refleja algo real, porque estas herramientas representan un cambio genuino de enfoque. En lugar de un escáner rígido que envía cargas estáticas a cada entrada que encuentra, esta nueva generación de herramientas puede razonar sobre el estado de la aplicación y decidir qué hacer a continuación según el contexto, de forma muy parecida a como lo haría un investigador de seguridad.

Pero esto es lo que he observado y lo que creo que el mercado está entendiendo mal: estos enfoques son complementarios por naturaleza, no competitivos.

Hace poco probamos una aplicación deliberadamente vulnerable con un motor tradicional de pruebas dinámicas de seguridad y un enfoque independiente de pentesting impulsado por IA. Y te aseguro que los resultados fueron reveladores.

El motor de pruebas dinámicas de seguridad encontró vulnerabilidades que el enfoque impulsado por IA no detectó, simplemente porque los motores tradicionales están diseñados para realizar pruebas exhaustivas y metódicas: prueban sistemáticamente cada parámetro, cada endpoint y cada caso límite.

Mientras tanto, el enfoque impulsado por IA encontró fallas complejas en la lógica que el motor tradicional no pudo comprender, porque podía razonar sobre cadenas de autorización y lógica de negocio de maneras que un escáner determinista nunca podría.

Ninguno fue suficiente por sí solo. Juntos ofrecieron una imagen mucho más completa.

Esto me indica que la industria se encamina claramente hacia una convergencia. Es probable que el futuro producto de esta categoría combine ambas capacidades: un modo exhaustivo que cubra integralmente los pipelines (lo que las organizaciones necesitan para tener garantías continuas) y un modo dirigido, basado en el contexto, para explotar vulnerabilidades lógicas en profundidad (el que detecta las fallas de autorización y las vulnerabilidades encadenadas que el código generado por IA introduce a gran escala).

Aún no se sabe con certeza cuál será la etiqueta: si el mercado conservará «DAST», cambiará a «pentesting con IA» o inventará algo completamente nuevo. Pero la convergencia en sí parece inevitable.

Hacia dónde vamos

Si tuviera que describir el cambio arquitectónico más importante que se avecina, diría que la inteligencia a nivel de código y las pruebas dinámicas de seguridad están estrechando cada vez más sus vínculos.

Durante la mayor parte de su historia, las pruebas dinámicas de seguridad funcionaron como una caja negra, sin conocer el código fuente ni comprender la lógica interna de la aplicación. Sondeaban desde el exterior e informaban lo que encontraban. Esa era tanto su fortaleza (probaban la realidad, no la teoría) como su limitación (no podían ver el contexto que las haría mucho más eficaces).

Eso está cambiando. A medida que las plataformas maduran, la evolución natural apunta a lo que los investigadores de seguridad siempre han llamado pruebas de «caja gris»: un enfoque que interactúa con la aplicación en vivo y comprende el código fuente subyacente. En una dirección, el análisis a nivel de código puede plantear la hipótesis de endpoints ocultos o fallas lógicas que las pruebas dinámicas de seguridad luego confirman (o descartan) en el entorno en vivo. En la otra dirección —y esto se acerca más a cómo trabajan realmente los hackers humanos de élite—, las pruebas dinámicas de seguridad pueden detectar comportamientos sospechosos cuando las aplicaciones o las API están en vivo y luego usar el contexto del código para entender exactamente cómo está implementada una protección y crear la carga precisa que se necesita, en lugar de probar a la fuerza.

Esto también empieza a resolver uno de los mayores obstáculos históricos de las pruebas dinámicas de seguridad: la corrección de vulnerabilidades. Una herramienta dinámica siempre podía demostrar que existía una vulnerabilidad, mostrando la solicitud y la respuesta HTTP maliciosas, junto con la evidencia de la explotación, pero dejaba a los desarrolladores con la duda de dónde se originaba realmente la falla en la base de código. Al correlacionar la prueba dinámica con el contexto del código, obtienes algo mucho más potente: un hallazgo que demuestra la posibilidad de explotación durante la ejecución y señala directamente el código que hay que corregir.

Esa es la evolución que vale la pena observar. No porque algún proveedor haya logrado concretarla por completo (aunque nosotros sí), sino porque ya están dadas las condiciones arquitectónicas necesarias y los equipos que reconozcan antes esta convergencia crearán los programas de seguridad más sólidos.

La convicción de quien lo construye

Quiero cerrar con algo en lo que creo cada vez más con cada arquitectura que probamos.

La era de tratar las pruebas dinámicas de seguridad como un requisito de cumplimiento —con escáneres lentos y ruidosos que se ejecutan cada trimestre y cuyos resultados se archivan— está llegando a su fin. No porque la idea fuera equivocada, sino porque el mundo a su alrededor ha cambiado.

El código generado por IA se publica más rápido de lo que cualquier proceso humano puede revisarlo; los agentes de IA llaman a las API más rápido de lo que cualquier inventario puede registrarlo. Y las vulnerabilidades que introducen estas fuerzas, como las fallas de autorización, los errores de lógica de negocio y los fallos de estado entre componentes, son precisamente las que solo las pruebas dinámicas de seguridad pueden demostrar de manera concluyente.

Lo que está surgiendo no reemplaza el análisis de código, sino que representa la otra mitad de la ecuación: el análisis de código te indica qué podría ser vulnerable, pero las pruebas dinámicas de seguridad te dicen qué se puede explotar. Cuando se combinan ambas señales, disminuye el ruido y se agudiza la señal... los desarrolladores pueden publicar con confianza, en lugar de sentir ansiedad.

Si estás creando un programa de seguridad para la era de la IA, esa confianza es el recurso en el que vale la pena invertir.