Hola mis estimados lectores. En nuestro artículo anterior hablamos del análisis estático de seguridad (SAST), esa práctica casi rebelde de leer el código fuente sin ejecutarlo para encontrar vulnerabilidades antes de que el software vea la luz. Recuerdan que en aquella ocasión lo comparamos con revisar los planos de un puente antes de soldar la primera viga. Y dejamos una promesa pendiente: que el análisis estático no es suficiente. Porque por muy limpios que estén los planos, siempre hay algo que solo se descubre cuando el puente ya está en pie y los camiones empiezan a cruzarlo. Y ese algo tiene nombre: análisis dinámico de seguridad, o DAST.
Mientras que SAST opera en silencio, sobre el código quieto, frío, sin ejecutar, DAST hace exactamente lo contrario. Lanza el programa —o una versión de prueba— y lo ataca como si fuera un adversario real, pero de forma controlada, metódica y automatizada. DAST no necesita ver el código fuente. Ni siquiera le importa en qué lenguaje está escrito. Lo único que necesita es una dirección: una URL, un endpoint de API, un formulario de autenticación, un campo de búsqueda. A partir de ahí, empieza a comportarse como un hacker ético pero incansable, que prueba miles de patrones de ataque por segundo mientras usted toma su café. Y cuando encuentra una grieta, no especula: la explota (en un entorno seguro) y le muestra exactamente cómo un atacante real podría haber robado esa base de datos.
La disrupción de DAST es diferente a la de SAST, pero igual de incómoda para la industria. SAST incomoda porque obliga a los desarrolladores a cambiar su forma de escribir código desde el minuto uno. DAST incomoda porque demuestra, con evidencias ejecutables, que el software funcionando puede ser perfectamente funcional y absolutamente vulnerable al mismo tiempo. Un programa puede cumplir todos los requisitos de negocio, pasar todas las pruebas funcionales, tener una interfaz hermosa y, sin embargo, caer en segundos ante una inyección SQL que un DAST encuentra en el primer escaneo. La funcionalidad no es seguridad. Y DAST se dedica a recordárnoslo cada vez que lo ejecutamos.
Pero vayamos a lo concreto. ¿Cómo funciona realmente un análisis dinámico? Imagine que tiene una aplicación web con un formulario de inicio de sesión. Un DAST típico comenzará enviando peticiones completamente normales: usuario “admin", contraseña “1234”. Anota la respuesta. Luego empezará a mutar esos parámetros: usuario “admin' --” (una de las formas clásicas de inyección SQL), usuario “<script>alert(1)</script>” (para probar XSS), usuario “../../../etc/passwd” (para intentar una manipulación de rutas de archivos). Cada vez, el analizador examina la respuesta del servidor. Si ve un mensaje de error de base de datos, si detecta que el script se ejecutó en el navegador, si encuentra que el servidor devuelve el contenido de un archivo sensible, entonces DAST ha encontrado una vulnerabilidad. Y lo mejor de todo: puede generar un informe con la petición exacta que causó el fallo, para que el equipo de desarrollo la reproduzca y la corrija.
Esta lógica de “probar, fallar, reportar” es tan simple como poderosa. Tanto, que la industria ha creado una subcategoría completa llamada fuzzing: enviar datos aleatorios o semialeatorios a una aplicación para ver qué se rompe. Un buen fuzzer puede generar millones de variaciones en minutos. Y lo que encuentra suele ser aterrador: desde desbordamientos de búfer en aplicaciones escritas en C hasta vulnerabilidades lógicas en las API modernas. De hecho, algunos de los bugs más famosos de la última década —como Heartbleed o Shellshock— fueron detectados primero por técnicas cercanas al fuzzing, no por revisión estática de código. Eso no es un defecto de SAST, sino una virtud de DAST: el código puede ser correcto sobre el papel y peligroso en ejecución.
Ahora bien, si SAST tenía el problema de los falsos positivos —señalar peligros donde no los hay—, DAST tiene el problema inverso: los falsos negativos. Un analizador dinámico solo puede encontrar vulnerabilidades que sean capaces de provocar. Si una vulnerabilidad requiere un estado específico de la aplicación (por ejemplo, haber iniciado sesión tres veces con contraseñas erróneas y luego una correcta con un parámetro especial), y DAST no conoce esa secuencia, la vulnerabilidad pasará desapercibida. Por eso, el éxito de DAST depende enormemente de lo bien que esté “entrenado” el escáner para entender la lógica de negocio de la aplicación. Los escáneres más avanzados permiten definir sesiones autenticadas, recorrer flujos de trabajo complejos (un carrito de compra, una transferencia bancaria, una solicitud de préstamo) y luego, dentro de ese contexto, lanzar los ataques.
Aquí aparece una tensión fascinante entre SAST y DAST, que vale la pena explorar porque define la arquitectura de seguridad de cualquier organización seria. SAST es barato en ejecución (no necesita desplegar la aplicación, solo leer archivos) pero caro en mantenimiento (requiere configurar reglas específicas para cada lenguaje y framework). DAST es caro en ejecución (necesita un entorno real o una copia de producción, consume recursos, puede ser lento) pero más fácil de estandarizar (un mismo escáner puede atacar aplicaciones escritas en diez lenguajes diferentes, porque solo habla HTTP, no código fuente). Por eso, la sabiduría convencional dice: usa SAST temprano, en el escritorio del desarrollador, y usa DAST más tarde, en el entorno de pruebas o incluso en producción, con cuidado. Pero la sabiduría disruptiva que propongo aquí es otra: úsalos siempre, el uno junto al otro, como dos linternas con espectros diferentes.
Porque hay vulnerabilidades que solo SAST puede encontrar. Por ejemplo, una contraseña hardcodeada en un archivo de configuración que nunca se envía al cliente. DAST jamás descubriría eso, porque nunca ve el archivo. Pero también hay vulnerabilidades que solo DAST puede encontrar. Por ejemplo, un error de configuración en el servidor web que permite listar directorios. SAST nunca lo vería, porque no existe en el código fuente. La conclusión es incómoda: no se puede elegir entre uno y otro. Es como elegir entre tener un termómetro o un espejo retrovisor. Sirven para cosas distintas. Y quien le venda una herramienta que “hace SAST y DAST a la vez” probablemente le esté vendiendo humo, o una integración superficial de dos motores que no se comunican bien entre sí.
Pero el problema real, el que duele de verdad, no es técnico. Es cultural y organizativo. La mayoría de las empresas que hemos visto adoptar DAST lo hacen mal de tres formas sistemáticas. La primera: lo ejecutan una vez al mes, sobre la aplicación ya en producción, y cuando encuentran vulnerabilidades críticas, entran en pánico porque arreglarlas requiere reescribir partes enteras que ya están acopladas a otros sistemas. La segunda: lo ejecutan solo sobre la aplicación pública, pero no sobre las API internas, los microservicios de backend, las bases de datos de administración o los endpoints de integración con terceros —exactamente donde suelen estar los errores más profundos. La tercera, y quizás la más triste: compran la herramienta más cara del mercado, la integran en su pipeline de CI/CD, pero la configuran en modo “solo informativo” porque los informes de DAST suelen incluir cientos de hallazgos entre vulnerabilidades reales y ruido, y nadie tiene tiempo de clasificarlos.
Para el público general que nos sigue cada viernes, todo esto puede sonar a disputa de ingenieros. Pero en realidad es mucho más simple: cada vez que usted introduce sus datos en un formulario web, hay un servidor en alguna parte que los procesa. Ese servidor ejecuta código. Ese código fue escrito por alguien que pudo cometer un error. DAST es una de las pocas técnicas que pueden descubrir ese error imitando a un atacante, pero sin necesidad de que el atacante exista todavía. Es una vacuna digital: le exponemos al programa a “virus controlados” para ver cómo reacciona. Si reacciona mal, lo arreglamos antes de que llegue el virus real.
Y aquí llegamos a un punto que ningún artículo honesto sobre DAST puede eludir: el análisis dinámico, por muy avanzado que sea, tiene un límite fundamental. Solo puede encontrar vulnerabilidades conocidas o patrones de ataque predecibles. No puede inventar una nueva clase de vulnerabilidad que nadie haya visto antes. Por eso, al igual que SAST, DAST debe combinarse con pruebas de penetración manuales realizadas por expertos humanos, con revisión de arquitectura, con análisis de dependencias y, cada vez más, con técnicas de análisis híbrido que cruzan información estática y dinámica (lo que se conoce como IAST, Interactive Application Security Testing). Pero ese es tema lo dejaré para un tercer artículo.
Mientras tanto, el mensaje para directores de tecnología, para desarrolladores, para emprendedores y para cualquier persona que confíe su información a sistemas digitales es claro: ejecutar DAST debería ser tan rutinario como ejecutar pruebas unitarias. No es más difícil, no es mucho más caro, y el retorno de inversión es descomunal. Según el estándar OWASP, encontrar y corregir una vulnerabilidad en la fase de pruebas dinámicas cuesta hasta 10 veces menos que hacerlo en producción después de un ataque. Y si a eso le sumamos los costos de reputación, las multas regulatorias y la pérdida de clientes, la cuenta es sencilla: no hacer DAST es un lujo que ninguna organización puede permitirse.
Termino con la misma provocación que usamos en el artículo anterior. Si la ingeniería civil permitiera que los puentes se inspeccionaran solo sobre el papel y nunca sobre la estructura real, estaríamos ante una negligencia criminal. En software, esa negligencia se llama “falta de pruebas dinámicas”. DAST es el equivalente a caminar por el puente ya construido con un martillo, golpeando las uniones para ver si suenan a hueco. No es suficiente, desde luego. Pero no hacerlo es imperdonable. La pregunta no es si su aplicación tiene vulnerabilidades que solo un análisis dinámico puede encontrar. La pregunta es cuántas de ellas va a dejar que lleguen a producción. Porque el adversario, se lo aseguro, no va a leer sus planos. Va a tocar la puerta, como hace DAST, y si la puerta se abre sola, va a entrar.
Este es el segundo artículo de una serie sobre las aristas de la seguridad en el ciclo de vida del software. El primero fue sobre SAST (análisis estático). Este ha sido sobre DAST (análisis dinámico). El próximo podría ser sobre IAST (análisis interactivo, que combina lo mejor de ambos), o sobre SCA (análisis de composición de software, para vulnerabilidades en librerías de terceros), o sobre RASP (protección en tiempo de ejecución). Mientras tanto, quédese con esta idea: el código seguro no nace, se hace. Y se hace con herramientas que lo miran quieto (SAST) y con herramientas que lo miran correr (DAST). Cualquier otra cosa es confiar en la suerte. Y la suerte, en ciberseguridad, tiene el hábito de agotarse justo cuando más la necesita. Por hoy es todo, nos despedimos hasta la próxima semana.
Vea además:
De la línea de código al desastre en producción: Cómo SAST corta el camino antes del primer exploit