El panorama de la seguridad de las aplicaciones está experimentando su transformación más dramática desde el cambio a DevOps y la nube. Los asistentes de codificación de IA están cambiando fundamentalmente la forma en que las organizaciones crean software: generan código a velocidades que hacen que los enfoques de seguridad tradicionales sean matemáticamente imposibles de sostener.
Se trata de una remodelación del sistema de seguridad que se produce una vez cada década. Algunas herramientas están siendo absorbidas. Otros se volverán más críticos que nunca. La pregunta que todo líder de seguridad debería hacerse: ¿cuál es cuál?
La IA está exacerbando la crisis de clasificación del SAST
Aquí está la matemática que todo líder de seguridad sabe pero de la que no quiere hablar: un ingeniero de AppSec que clasificaba manualmente 15.000 hallazgos SAST de 50 desarrolladores ya era una batalla perdida. Ahora esos mismos 50 desarrolladores que utilizan asistentes de IA producen más de 75.000 hallazgos. El modelo no sólo sufre tensiones bajo la velocidad de la IA, sino que se rompe por completo.
Según la reciente encuesta AI-Era AppSec de StackHawk, la mayoría de los equipos de AppSec dedican al menos el 40 % de su tiempo a clasificar las alertas SAST y, cuando realmente se realizan pruebas en tiempo de ejecución, el 98 % de esos hallazgos resultan no explotables. Las matemáticas no cuadran.
SAST está siendo devorado por su IDE
Llevaré el desafío de SAST un paso más allá. Siempre ha sido valioso por una razón: detectar las vulnerabilidades a tiempo, antes de que se conviertan en soluciones costosas. Cuanto antes lo encuentres, más barato será arreglarlo. Ese principio no ha cambiado.
Lo que está cambiando es dónde reside esa capacidad y, fundamentalmente, cómo funciona.
SAST es coincidencia de patrones, y la coincidencia de patrones es exactamente lo que la IA hace mejor. Los asistentes de código de IA ya comprenden el contexto de seguridad en todos los idiomas, identifican vulnerabilidades en tiempo real y solucionan problemas automáticamente durante la generación de código. La capacidad no está desapareciendo. Se está trasladando directamente a IDE impulsados por IA, integrados en el propio flujo de trabajo de desarrollo.
Pero puede que parezca diferente del SAST al que estamos acostumbrados. El paradigma puede pasar de estar centrado en la detección a estar seguro por defecto. De cualquier manera, los equipos de seguridad deberán reevaluar lo que esperan de las herramientas de código seguro.
Logísticamente, las pruebas en tiempo de ejecución no se pueden absorber
El análisis estático puede trasladarse al IDE porque coincide con patrones. Las pruebas en tiempo de ejecución no pueden porque requieren algo que la IA no puede replicar: una aplicación en ejecución.
Un modelo de IA puede indicarle que un patrón de código podría ser vulnerable a la inyección de SQL. Lo que no puede decirle es si esa vulnerabilidad es realmente explotable en su entorno, con la configuración de su base de datos, a través de sus puntos finales API reales. Eso requiere ejecutar la aplicación. Envío de solicitudes reales. Observar respuestas reales. Esta no es una limitación que mejores modelos puedan resolver. Es una limitación fundamental.
La IA analiza el código. DAST valida la realidad.
Tres capacidades existen solo en tiempo de ejecución: explotabilidad real versus riesgo teórico, lógica de negocios y validación de control de acceso que requiere comprender la intención del producto y contexto de infraestructura que no existe en el código fuente.
Los riesgos que importan no aparecen en los análisis estáticos
Las fallas en la lógica empresarial (autorización rota, fallas en el control de acceso, BOLA/BFLA) son ahora el riesgo de seguridad de API número uno. No aparecen en los patrones de código. Aparecen cuando pruebas si el usuario A realmente puede acceder a los datos del usuario B. SAST analiza la sintaxis y el flujo de datos, pero no puede responder preguntas en tiempo de ejecución como «¿Esta API respeta los permisos basados en roles?» o «¿Pueden los atacantes encadenar estas llamadas para aumentar los privilegios?»
El desarrollo de la IA amplía esta brecha. Cuando los desarrolladores generan funciones completas con IA, revisan «¿esto hace lo que quiero?», no «¿es seguro?». Eso crea riesgos que SAST no puede ver: flujos de autenticación mal entendidos, lógica de autorización copiada y pegada aplicada incorrectamente, los desarrolladores de puntos finales no se dan cuenta de que han expuesto.
Y a medida que los equipos incorporan funciones impulsadas por IA (integraciones LLM, agentes autónomos), están introduciendo categorías de riesgo completamente nuevas. Inyección inmediata. Fuga de datos a través de respuestas modelo. Comportamientos que sólo surgen en tiempo de ejecución. Ninguna regla estática los detecta. No importa lo que te digan, tienes que ejecutar la aplicación para identificarlos.
El camino a seguir: DAST primero
Hasta ahora, DAST siempre ha jugado un papel secundario frente a SAST y SCA. No porque las pruebas en tiempo de ejecución sean menos valiosas, sino más valiosas. Encuentra lo que es realmente explotable, no lo que teóricamente podría ser un problema. Pero las herramientas DAST heredadas requirieron semanas de configuración manual, y ese bagaje aún da forma a la percepción.
Esa barrera ha desaparecido. El DAST moderno tarda horas en implementarse, no semanas. Y aquí está la verdadera ecuación del costo: la implementación es un esfuerzo único, pero la puesta en funcionamiento es lo que se paga todos los días. Es posible que DAST requiera más reflexión desde el principio, pero entonces estarás evaluando cientos de hallazgos, no decenas de miles. SAST es más fácil de activar. DAST es más fácil de ejecutar.
Combinar el análisis del código fuente para el descubrimiento de superficies de ataque con un enfoque de desplazamiento hacia la izquierda significa descubrimiento automático de qué probar, configuraciones que se adaptan a cada aplicación y orientación de reparación que comprende su código específico. El tiempo de obtención de valor cambia. Puede corregir vulnerabilidades explotables más rápido de lo que puede ordenar su trabajo pendiente de SAST.
El análisis estático se está trasladando al IDE. La validación en tiempo de ejecución es donde la brecha se está ampliando y donde este cambio crea el mayor avance.
DAST no está muriendo en la era de la IA. Finalmente se está convirtiendo en lo que debería haber sido desde el principio: las pruebas que realmente importan.
Fuente