Dynamic Application Security Testing (DAST) es un control de seguridad utilizado en los pipelines CI/CD para probar aplicaciones en ejecución en busca de vulnerabilidades. Para los auditores y responsables de cumplimiento, DAST se encuentra frecuentemente durante las revisiones de seguridad de aplicaciones y gobernanza de entrega de software — aunque sigue siendo uno de los controles más incomprendidos en entornos regulados.
Estas preguntas frecuentes abordan las preguntas más comunes que tienen los auditores y responsables de cumplimiento sobre DAST, con énfasis en qué verificar, qué evidencia esperar y cómo DAST encaja en los marcos de cumplimiento y gobernanza más amplios.
¿Qué es DAST y por qué importa para los auditores?
DAST (Dynamic Application Security Testing) es un control de seguridad que prueba las aplicaciones en ejecución interactuando con ellas externamente, simulando escenarios de ataque del mundo real. A diferencia del análisis a nivel de código (SAST), DAST valida el comportamiento en tiempo de ejecución de las aplicaciones — incluyendo flujos de autenticación, gestión de sesiones y endpoints expuestos.
Para los auditores, DAST importa porque proporciona evidencia de que las aplicaciones han sido probadas bajo condiciones realistas antes del despliegue en producción. Es un control detectivo y preventivo que, cuando se aplica correctamente, demuestra que una organización valida la seguridad de las aplicaciones como parte de su proceso de versión.
¿En qué se diferencia DAST de SAST y SCA?
Los auditores frecuentemente encuentran los tres controles juntos. Así es como difieren:
- SAST (Static Application Security Testing) analiza el código fuente para encontrar vulnerabilidades antes de que la aplicación se ejecute. Es un control preventivo a nivel de código.
- SCA (Software Composition Analysis) identifica riesgos en bibliotecas y dependencias de terceros. Es un control de riesgo en la cadena de suministro.
- DAST prueba la aplicación en ejecución externamente, sin acceso al código fuente. Es un control de validación en tiempo de ejecución.
En entornos regulados, estos tres controles son complementarios. Los auditores deben esperar ver los tres (o alternativas justificadas) como parte de un programa maduro de seguridad de aplicaciones. La ausencia de cualquiera de ellos debe generar preguntas sobre cómo se aborda esa área de riesgo.
¿Cuándo debe ejecutarse DAST en un pipeline CI/CD?
Desde una perspectiva de auditoría, DAST debe ejecutarse en puntos de control definidos dentro del proceso de entrega de software — típicamente antes de las versiones de producción, después de cambios significativos, o de forma programada para aplicaciones críticas.
Los auditores deben verificar que la ejecución de DAST está vinculada al proceso de versión, no realizada como una actividad aislada desconectada de los despliegues. La pregunta clave es: ¿puede la organización demostrar que DAST se ejecutó y sus resultados se revisaron antes de que una versión específica llegara a producción?
¿Puede DAST bloquear versiones en entornos regulados?
Sí. Cuando se gobierna correctamente, DAST actúa como un control con puerta en los pipelines CI/CD. Las versiones pueden bloquearse cuando los hallazgos superan umbrales de severidad predefinidos, o cuando la aceptación de riesgo requerida no ha sido aprobada.
Los auditores deben verificar:
- Los umbrales de bloqueo están definidos en la política y aplicados en el pipeline
- Las excepciones (versiones que proceden a pesar de los hallazgos) están documentadas con aprobaciones
- El mecanismo de bloqueo no puede omitirse fácilmente por los equipos de desarrollo
Las organizaciones que permiten que las versiones procedan con excepciones documentadas no son necesariamente incumplidoras — pero esas excepciones deben estar correctamente gobernadas, aprobadas y ser trazables.
¿Cómo deben gobernarse los falsos positivos en DAST?
Los falsos positivos (hallazgos que no representan vulnerabilidades reales) son inherentes a DAST. La preocupación de gobernanza no es si existen falsos positivos, sino cómo se gestionan.
Los auditores deben esperar ver:
- Un proceso definido para revisar y clasificar los hallazgos como falsos positivos
- Aprobaciones de supresión basadas en roles (no autoservicio por parte de los desarrolladores)
- Justificaciones documentadas para cada hallazgo suprimido
- Fechas de caducidad en las supresiones, con revisión periódica
- Un rastro de auditoría mostrando quién aprobó cada supresión y cuándo
Señal de alerta: Gran cantidad de hallazgos suprimidos sin justificación documentada, o supresiones que nunca caducan.
¿Qué esperan típicamente los auditores de los controles DAST?
Los auditores evalúan DAST como un control de gobernanza, no como una herramienta de pruebas de penetración. El enfoque de evaluación se centra en:
- Ejecución consistente — ¿Se ejecuta DAST de forma fiable como parte del proceso de versión?
- Lógica de bloqueo documentada — ¿Los umbrales de severidad están definidos y se aplican?
- Decisiones de supresión trazables — ¿Las excepciones están gobernadas y son auditables?
- Evidencia retenida — ¿Pueden recuperarse los resultados del análisis para cualquier versión dada?
- Adecuación del alcance — ¿DAST cubre las aplicaciones más importantes?
Los auditores generalmente no evalúan la marca del escáner, el recuento de vulnerabilidades ni la profundidad del análisis de forma aislada. El enfoque está en la gobernanza, la aplicación y la calidad de la evidencia del control.
¿Es DAST obligatorio bajo DORA, NIS2, ISO 27001 o PCI DSS?
La mayoría de las regulaciones y estándares no exigen DAST por nombre. En cambio, requieren que las organizaciones demuestren pruebas de seguridad de aplicaciones efectivas, gestión del riesgo y retención de evidencia.
DAST se usa comúnmente como un componente de una estrategia más amplia de seguridad de aplicaciones y gobernanza CI/CD. Su relevancia varía según el marco:
- DORA: Requiere gestión del riesgo ICT y pruebas — DAST apoya la evidencia de validación en tiempo de ejecución
- NIS2: Requiere gestión del riesgo y desarrollo seguro — DAST valida la exposición de los servicios
- ISO 27001: Requiere demostración de efectividad del control (Anexo A, A.8.25–28) — DAST contribuye con evidencia
- PCI DSS: Requiere explícitamente pruebas de seguridad de aplicaciones web (Requisitos 6.4, 11.3) — DAST se usa habitualmente para cumplir este requisito
¿Qué deben buscar los auditores en los informes DAST?
Al revisar los informes DAST, los auditores deben ir más allá de los recuentos brutos de vulnerabilidades. Los elementos clave a evaluar son:
- Alcance de las pruebas: ¿Qué aplicaciones y endpoints se probaron? ¿Se incluyeron las aplicaciones críticas y de cara al exterior?
- Clasificación de severidad: ¿Los hallazgos están clasificados por severidad, y las clasificaciones siguen un estándar definido?
- Resultado del bloqueo: ¿El análisis resultó en una decisión de aprobado o rechazado? Si había hallazgos, ¿fue la versión aprobada mediante una excepción documentada?
- Datos de tendencia: ¿Se están abordando los hallazgos recurrentes, o los mismos problemas aparecen en múltiples versiones?
- Detalles de supresión: ¿Los hallazgos suprimidos están documentados con justificaciones y aprobaciones?
- Trazabilidad: ¿Puede el informe vincularse a una versión, entorno y fecha específicos?
¿Cómo verifican los auditores que DAST se aplica correctamente?
Verificar la aplicación de DAST requiere ir más allá de los documentos de política. Los auditores deben:
- Solicitar configuraciones del pipeline — verificar que DAST está definido como un paso obligatorio que no puede omitirse
- Muestrear versiones recientes — para una selección de despliegues recientes en producción, solicitar los resultados DAST correspondientes
- Buscar evidencia de omisión — buscar versiones que procedieron sin ejecución DAST o con resultados anulados
- Revisar registros de excepciones — si existen excepciones, verificar que siguen el proceso de aprobación documentado
- Evaluar la cobertura del alcance — verificar que DAST cubre todas las aplicaciones dentro del alcance definido, particularmente los sistemas de cara al exterior y los críticos
Señal de alerta: La organización tiene una política DAST pero no puede producir resultados de análisis para versiones recientes, o las configuraciones del pipeline muestran DAST como un paso opcional.
¿Cuáles son los hallazgos de auditoría comunes en DAST?
Basándose en observaciones de auditoría comunes, los hallazgos más frecuentes relacionados con DAST incluyen:
- DAST no se aplica en el pipeline — está disponible pero es opcional, y los equipos pueden omitirlo sin aprobación
- Sin umbrales de bloqueo definidos — DAST se ejecuta pero todas las versiones proceden independientemente de los resultados
- Los resultados del análisis no se retienen — la organización no puede producir evidencia DAST histórica para versiones pasadas
- Alcance incompleto — DAST cubre solo algunas aplicaciones, dejando sistemas críticos o de cara al exterior sin probar
- Supresión de falsos positivos no gobernada — los hallazgos se suprimen sin justificación documentada ni aprobación
- Sin conexión con el proceso de versión — DAST se ejecuta de forma programada pero no está vinculado a despliegues reales, por lo que los resultados no pueden vincularse a versiones específicas
- Hallazgos recurrentes sin resolver — las mismas vulnerabilidades aparecen en múltiples versiones sin remediación ni aceptación documentada del riesgo
¿Cómo deben preparar las organizaciones sus controles DAST para una auditoría?
Las organizaciones que se preparan para una auditoría deben asegurarse de poder demostrar:
- DAST está integrado en el pipeline CI/CD en puntos de control definidos
- Los umbrales de bloqueo y los flujos de trabajo de aprobación están documentados y se aplican
- Los resultados del análisis se retienen y pueden recuperarse para cualquier versión específica
- Las supresiones de falsos positivos están gobernadas con aprobaciones documentadas
- El alcance de DAST cubre todas las aplicaciones dentro del límite de cumplimiento
- El manejo de excepciones sigue procedimientos documentados con la autorización apropiada
¿Qué evidencia debe producir DAST para los auditores?
DAST debe producir evidencia estructurada, retenida y trazable. Los auditores deben esperar los siguientes artefactos de evidencia de un control DAST correctamente gobernado:
- Informes de análisis por versión: Cada versión de producción debe tener un informe DAST correspondiente mostrando qué se probó, qué se encontró y cuál fue el resultado del bloqueo
- Hallazgos clasificados por severidad: Los hallazgos deben categorizarse por severidad usando un estándar definido (p. ej., CVSS, matriz de severidad interna)
- Decisiones de bloqueo: Un registro claro de aprobado/rechazado para cada análisis, con documentación de cualquier anulación o excepción
- Registros de supresión: Documentación de los hallazgos suprimidos incluyendo justificación, aprobador y fecha de caducidad
- Documentación del alcance: Evidencia de qué aplicaciones y endpoints se incluyeron en las pruebas
- Datos de tendencia: Resultados históricos de análisis mostrando si los hallazgos se están abordando con el tiempo
- Metadatos de trazabilidad: Vínculos entre los resultados del análisis y la versión, entorno, ejecución del pipeline y fecha específicos
Si una organización no puede producir estos artefactos para una versión dada, el control DAST puede existir en la política pero no está funcionando como evidencia de gobernanza efectiva.
¿Cuáles son las señales de alerta comunes de DAST durante las auditorías?
Durante las revisiones de auditoría, las siguientes señales de alerta indican que la gobernanza DAST es débil, incompleta o ineficaz:
- DAST existe en la política pero no en la práctica: La organización tiene una política DAST pero no puede producir resultados de análisis para versiones recientes de producción
- Paso del pipeline opcional: DAST está configurado en el pipeline CI/CD pero puede omitirse o evitarse sin aprobación
- Sin umbrales de bloqueo: DAST se ejecuta pero todas las versiones proceden independientemente de los hallazgos — el control no tiene poder de aplicación
- Desconectado de las versiones: DAST se ejecuta de forma programada (p. ej., semanalmente) pero no está vinculado a despliegues reales, haciendo que los resultados no sean trazables a versiones específicas
- Supresiones masivas sin gobernanza: Gran cantidad de hallazgos suprimidos sin justificación documentada, identidad del aprobador o fechas de caducidad
- Alcance incompleto: Las aplicaciones críticas o de cara al exterior están excluidas de las pruebas DAST sin aceptación documentada del riesgo
- Sin retención de evidencia: Los resultados del análisis son efímeros y no pueden recuperarse para versiones pasadas
- Hallazgos recurrentes sin resolver: Las mismas vulnerabilidades aparecen en múltiples versiones sin remediación ni escalada
- Supresión de autoservicio: Los desarrolladores pueden suprimir hallazgos sin revisión ni aprobación independiente
Cualquiera de estas señales de alerta justifica una investigación adicional y debe documentarse como un hallazgo u observación de auditoría.
¿Cómo se mapea DAST a los requisitos de DORA, NIS2 e ISO 27001?
DAST no suele ser exigido por nombre en los marcos regulatorios, pero apoya directamente los requisitos clave en las principales regulaciones y estándares:
DORA (Digital Operational Resilience Act)
DORA requiere que las entidades financieras mantengan marcos de gestión del riesgo ICT que incluyan pruebas de los sistemas ICT. DAST apoya el cumplimiento de DORA:
- Proporcionando evidencia de validación en tiempo de ejecución para las aplicaciones desplegadas
- Demostrando que las aplicaciones se prueban en condiciones realistas antes del despliegue en producción
- Apoyando el requisito de identificación y gestión continua del riesgo ICT
NIS2 (Directiva de Seguridad de Redes y Sistemas de Información)
NIS2 requiere que las entidades esenciales e importantes implementen medidas de gestión del riesgo incluyendo prácticas de desarrollo seguro y gestión de vulnerabilidades. DAST apoya NIS2:
- Validando que los servicios de cara al exterior se prueban en busca de clases de vulnerabilidades conocidas
- Produciendo evidencia de identificación proactiva de vulnerabilidades en sistemas desplegados
- Apoyando la prevención de incidentes identificando debilidades explotables antes que los atacantes
ISO 27001 (Anexo A, A.8.25-28)
ISO 27001 requiere que las organizaciones demuestren prácticas de desarrollo seguro y efectividad del control. DAST apoya ISO 27001:
- Contribuyendo a la evidencia de desarrollo y pruebas seguras de aplicaciones (A.8.25-28)
- Proporcionando resultados de control medibles que demuestran la efectividad de los procesos de pruebas de seguridad
- Apoyando la mejora continua mediante análisis de tendencias de hallazgos en tiempo de ejecución
Los auditores deben tener en cuenta que DAST por sí solo no satisface ninguno de estos marcos — es un componente de un conjunto más amplio de controles de seguridad de aplicaciones que también debe incluir SAST, SCA y otros controles complementarios.
Recursos relacionados para auditores
- Glosario de términos de seguridad y cumplimiento CI/CD
- Cómo revisan realmente los auditores los controles DAST en entornos regulados
- Antes de que llegue el auditor — Lista de verificación de preparación para auditorías CI/CD
- Cumplimiento continuo mediante CI/CD
