Pruebas dinámicas de seguridad con DAST en GitLab

Entiende cómo GitLab integra DAST para detectar vulnerabilidades mientras tu aplicación está en runtime sin arriesgar la estabilidad. Aquí se explica la diferencia frente a pruebas estáticas, el rol de OWASP SAP Proxy y SAP Baseline, y por qué estas verificaciones ocurren tras el deployment y se potencian con review apps.

¿Qué es DAST y por qué importa en GitLab?

Las pruebas dinámicas de seguridad (DAST) analizan una aplicación en ejecución asumiendo un escenario de atacante externo y un enfoque de black box. A diferencia del análisis estático, no requieren acceso al código: inspeccionan el comportamiento real mientras el sistema corre.

¿Qué diferencias hay con pruebas estáticas?

• Las estáticas analizan código, dependencias y contenedores sin ejecutarlos.
• Las dinámicas simulan un atacante externo con la app en runtime.
• Las estáticas tienen acceso total al código; las dinámicas no.

¿Qué limita GitLab al evitar escaneos activos?

• GitLab no ejecuta pruebas dinámicas activas para no saturar el sistema.
• Evita “escaneos duros” que podrían tirar el servicio o dejarlo no apto para producción.
• Prioriza estabilidad del entorno en ejecución.

¿Qué valida DAST pasivo?

• Revisión de headers de seguridad bien configurados.
• Verificación de cookies seguras y transmisión por canales seguros.
• Restricción de acceso de JavaScript a cookies cuando no corresponde.
• Envío de reporte al Merge Request para su evaluación.

¿Cómo funcionan OWASP SAP Proxy y SAP Baseline?

GitLab usa dos componentes: OWASP SAP Proxy y SAP Baseline. Ambos colaboran para analizar el tráfico de la aplicación mientras está corriendo, con un flujo claro de intermediación y prueba.

¿Qué rol cumple cada componente?

• OWASP SAP Proxy: actúa como intermediario entre las comunicaciones del análisis dinámico y el servidor. Captura el tráfico para su evaluación.
• SAP Baseline: ejecuta las pruebas sobre las comunicaciones capturadas por el proxy.
• Integración: el proxy “cacha” el tráfico y Baseline realiza el análisis efectivo para detectar vulnerabilidades.

¿Cuándo correr DAST en el pipeline de GitLab CI?

DAST se ejecuta cuando la aplicación ya está desplegada y accesible. Por ello, las pruebas dinámicas aparecen en el pipeline después del deployment y se benefician de usar review apps.

¿Qué requisitos hacen posible DAST?

• Aplicación corriendo en un clúster de Kubernetes conectada a Internet.
• Configuración del job DAST en .gitlabci.yml indicando Dynamic Application Testing.
• Visibilidad del entorno desde GitLab CI para inspeccionar tráfico vía proxies.

¿Por qué usar review apps?

• Permiten correr DAST por rama sin esperar staging o producción.
• Alinea la práctica con DevSecOps: seguridad como parte integral del desarrollo.
• Facilita feedback temprano en el Merge Request.

¿Qué lugar ocupa en el flujo del pipeline?

• Construcción del contenedor.
• Ejecución de pruebas iniciales.
• Deployment del entorno.
• Trabajo post-deployment: DAST pasivo y pruebas de performance sobre la app en ejecución.

¿Tienes una experiencia aplicando DAST con review apps en GitLab o dudas sobre el flujo post-deployment? Comparte tus preguntas y casos en los comentarios.