¿Cuál es la diferencia entre SAST, DAST e IAST?
Respuesta breve
El SAST lee el código fuente sin ejecutarlo y encuentra pronto fallos como los puntos de inyección, pero con muchos falsos positivos. El DAST ataca la aplicación en ejecución desde fuera, sin visibilidad del código, y encuentra problemas realmente explotables pero tarde y con cobertura superficial. El IAST instrumenta la aplicación en ejecución para correlacionar el comportamiento en runtime con el código, obteniendo resultados precisos con contexto del código, pero necesita una aplicación ejercitada y soporte de un agente.
Estos tres acrónimos describen formas complementarias de encontrar vulnerabilidades en una aplicación, y un buen candidato explica las concesiones en lugar de recitar definiciones.
Estático (SAST)
El Static Application Security Testing analiza el código fuente, el bytecode o los binarios sin ejecutarlos. Rastrea el flujo de datos desde las entradas no confiables (fuentes) hasta las operaciones peligrosas (sinks) para señalar cosas como inyección SQL o XSS. Como ve todo el código, se ejecuta pronto — a menudo en cada commit o pull request — y apunta a la línea exacta. El coste son los falsos positivos: no puede saber si una ruta señalada es realmente alcanzable en runtime, por lo que la carga de triaje es real.
Dinámico (DAST)
El Dynamic Application Security Testing ataca la aplicación en ejecución desde fuera, como un atacante no autenticado, sin visibilidad del código fuente. Encuentra problemas genuinamente explotables — autenticación rota, configuraciones erróneas, inyecciones que realmente se disparan — y produce menos falsos positivos. Las desventajas: se ejecuta tarde (necesitas un entorno desplegado), la cobertura depende de cuán a fondo recorra la aplicación, y no puede apuntar al código culpable.
Interactivo (IAST)
El Interactive Application Security Testing coloca un agente dentro de la aplicación en ejecución y observa la ejecución del código mientras la aplicación es ejercitada (a menudo por pruebas funcionales o DAST existentes). Al correlacionar el flujo de datos en runtime con el código real, ofrece hallazgos precisos con contexto a nivel de línea — menos falsos positivos que el SAST, más visibilidad del código que el DAST. El inconveniente: necesita instrumentación en runtime, soporte del lenguaje/runtime y buena cobertura de pruebas para ejercitar las rutas.
Lo que ninguno detecta bien
Los fallos de lógica de negocio, la autorización rota y las debilidades de diseño se escapan a los tres — estos necesitan modelado de amenazas y revisión manual.
Lo que buscan los entrevistadores
Quieren que posiciones estas herramientas como capas en un pipeline, que nombres una fortaleza y una debilidad concretas de cada una, y que reconozcas que el escaneo automatizado nunca sustituye a la revisión humana.
Posibles preguntas de seguimiento
- ¿Por qué el SAST produce tantos falsos positivos y cómo se gestionan?
- ¿En qué momento del pipeline ejecutarías cada tipo de prueba?
- ¿Qué tipos de vulnerabilidades no detecta de forma fiable ninguno de ellos?