¿Qué es DAST (pruebas dinámicas de seguridad de aplicaciones)?

El Dynamic Application Security Testing (DAST) es un método de pruebas de caja negra que encuentra vulnerabilidades interactuando desde fuera con una aplicación en ejecución (enviando solicitudes preparadas y analizando las respuestas) sin ningún acceso al código fuente. Prueba el software tal como lo vive un atacante externo, y precisamente por eso detecta una clase de problemas distinta de la del análisis de código.

¿No sabes si necesitas primero DAST, SAST, IAST o SCA? Prueba el selector de pruebas de seguridad de aplicaciones.

Qué es el DAST y cómo funciona el escaneo de caja negra

Un escáner DAST trata la aplicación como una caja negra. Rastrea la aplicación para descubrir páginas, parámetros y endpoints, y después envía una amplia gama de entradas preparadas (valores malformados, cargas de inyección, cabeceras y parámetros manipulados) e inspecciona las respuestas en busca de indicios de una debilidad. Un mensaje de error que filtra una traza de pila, una respuesta que refleja un script inyectado, una diferencia de tiempo que revela una consulta a la base de datos, un endpoint que sirve datos sin autenticación: esas son las señales que lee el DAST.

Como trabaja desde fuera contra un sistema en vivo, el DAST ve la aplicación tal como se comporta realmente en ejecución, incluido el servidor web, su configuración y la forma en que interactúan los componentes: cosas que son invisibles cuando solo lees el código fuente.

DAST frente a SAST, IAST y SCA

Los cuatro enfoques principales de pruebas de aplicaciones se diferencian por el punto de observación, y se superponen en lugar de competir:

• SAST (estático). Lee y analiza el código fuente sin ejecutarlo. Encuentra problemas muy pronto, incluso en rutas de código difíciles de alcanzar de forma dinámica, pero no puede observar el comportamiento real en ejecución y tiende a producir hallazgos más teóricos.
• DAST (dinámico). Ejecuta la aplicación y la prueba desde fuera sin ver el código. Encuentra problemas alcanzables de ejecución y de configuración, pero señala síntomas y no la línea vulnerable exacta.
• IAST (interactivo). Instrumenta la aplicación en ejecución desde dentro mientras se ejercita, combinando la visibilidad a nivel de código con el contexto de ejecución: más preciso, pero requiere un agente dentro de la aplicación.
• SCA (análisis de composición de software). Inventaría las dependencias de terceros y de código abierto y señala los componentes con versiones vulnerables conocidas. Es un trabajo totalmente distinto: trata de lo que importaste, no de cómo se comporta tu código.

Un programa maduro ejecuta varios a la vez, y cada uno cubre los puntos ciegos de los demás. Gestionar el resultado combinado de todos ellos es el problema que existe para resolver la ASPM.

Fortalezas y límites

El DAST se gana su sitio por unas cuantas razones claras. Es independiente del lenguaje y del framework: como prueba la aplicación en ejecución y no el código, funciona igual con cualquier pila tecnológica. Encuentra problemas reales de ejecución y de configuración que las herramientas estáticas no ven, como las malas configuraciones del servidor, los fallos de autenticación y de sesión, y la inyección que solo se manifiesta en un sistema en ejecución. Y como un hallazgo procede de una respuesta real que produjo la aplicación, tiende a ser alcanzable y demostrable y no hipotético.

Los límites son igual de importantes de entender. El DAST solo cubre lo que puede alcanzar y ejercitar: la funcionalidad que no puede rastrear, o que está detrás de una autenticación que no se le dio, puede quedar sin probar. Identifica un síntoma, no la línea de código exacta, así que corregir un hallazgo suele requerir que un desarrollador investigue. Puede ser lento con aplicaciones grandes, porque un escaneo exhaustivo envía muchísimas solicitudes. Y necesita un entorno en ejecución y representativo, idealmente con credenciales válidas, para pasar del inicio de sesión y probar la funcionalidad real. Interpreta un informe DAST limpio como «este escaneo no encontró nada alcanzable», no como «la aplicación es segura».

Dónde encaja el DAST en la CI/CD

El DAST encaja mejor en la canalización a dos velocidades. Los escaneos ligeros y rápidos pueden ejecutarse automáticamente contra un despliegue de preproducción o de pruebas en cada pull request o build, para detectar pronto las regresiones evidentes. Los escaneos completos y autenticados (que rastrean la funcionalidad profunda tras el inicio de sesión y ejecutan un conjunto amplio de pruebas) tardan demasiado para condicionar cada commit, así que suelen programarse cada noche o cada semana. El requisito innegociable es un entorno en ejecución y representativo al que apuntar el escáner; el DAST no puede probar lo que no está desplegado.

Usado así, el DAST se sitúa más tarde en la canalización que el SAST y el SCA y los complementa: las comprobaciones estáticas y de composición detectan problemas en el momento del commit, y las pruebas dinámicas validan el sistema montado y en ejecución. La exposición más amplia en ejecución y en la nube la cubren después las plataformas que describimos en nuestro explicativo sobre CNAPP.

El DAST y las pruebas humanas

El DAST automatizado es excelente en amplitud (sondea de forma sistemática patrones detectables), pero no razona sobre la lógica de negocio, no encadena debilidades de forma creativa ni aplica el criterio humano. Ese es el terreno de las pruebas de penetración, que añaden cadenas de ataque creativas y el descubrimiento de fallos de lógica que ningún escáner reproduce. Para probar el DAST antes de comprar nada, OWASP ZAP es gratuito; nuestra lista de herramientas gratuitas de pruebas de seguridad de aplicaciones que puedes usar sin prueba lo incluye junto a escáneres SAST, SCA y de secretos. Los dos son complementarios: ejecuta el DAST de forma continua para tener una cobertura barata y repetible, y encarga pruebas humanas periódicas para la profundidad. Si estás planificando estas últimas, un alcance claro importa muchísimo, y eso es lo que te ayuda a definir un ejercicio de definición del alcance de una prueba de penetración.

La conclusión

El DAST prueba tu aplicación tal como la encuentra un atacante: desde fuera, en ejecución y sin ver el código. Eso lo hace fuerte encontrando problemas alcanzables y demostrables, y débil señalando las causas exactas o cubriendo lo que no puede alcanzar. Es una capa entre varias: combínalo con el análisis estático, el análisis de composición y las pruebas humanas periódicas, y ejecútalo contra un entorno real y representativo, para obtener resultados en los que puedas confiar y sobre los que puedas actuar.

Preguntas frecuentes

¿Qué es el DAST? El Dynamic Application Security Testing: un método de caja negra que encuentra vulnerabilidades interactuando desde fuera con una aplicación en ejecución (solicitudes preparadas, respuestas analizadas) sin acceso al código fuente.

¿En qué se diferencia del SAST, el IAST y el SCA? El SAST lee el código de forma estática; el DAST ejecuta la aplicación y la prueba desde fuera; el IAST la instrumenta desde dentro mientras se ejecuta; el SCA inventaría las dependencias en busca de versiones vulnerables conocidas. Son capas complementarias.

¿Cuáles son sus fortalezas y límites? Fortalezas: independiente del lenguaje, encuentra problemas reales de ejecución y configuración, y los hallazgos suelen ser alcanzables. Límites: solo cubre lo que puede alcanzar, señala síntomas y no líneas, puede ser lento y necesita un entorno en ejecución con credenciales.

¿Dónde encaja en la CI/CD? Escaneos rápidos contra preproducción en cada build y escaneos completos y autenticados programados cada noche o cada semana, siempre contra un entorno en ejecución y representativo.

¿Sustituye a las pruebas de penetración? No. El DAST aporta amplitud automatizada; las pruebas de penetración humanas añaden la creatividad, el razonamiento sobre la lógica de negocio y el encadenamiento de ataques que los escáneres no pueden.