Dynamic Application Security Testing (DAST) es un control de seguridad en tiempo de ejecución crítico en entornos de entrega de software regulados. Para los auditores, responsables de cumplimiento y reguladores, la pregunta no es qué herramienta DAST utiliza una organización, sino si los controles DAST son adecuados, aplicados y evidenciados.
Esta guía proporciona un marco estructurado para evaluar los controles DAST de una organización dentro de los pipelines CI/CD — centrándose en la cobertura, la aplicación, la generación de evidencia, el manejo de excepciones y la alineación regulatoria.
Por qué los controles DAST importan en entornos regulados
DAST evalúa las aplicaciones en tiempo de ejecución, descubriendo vulnerabilidades relacionadas con autenticación, autorización, gestión de sesiones y configuración que el análisis estático no puede detectar. En entornos regulados, DAST sirve como una etapa de validación controlada — verificando que los controles en tiempo de ejecución funcionan como se espera antes de que el software sea publicado.
Desde una perspectiva de gobernanza, DAST no es una herramienta opcional. Es evidencia de que la organización prueba el software desplegado en busca de debilidades explotables como parte de un proceso repetible y auditable. Los marcos regulatorios esperan cada vez más que las organizaciones demuestren pruebas en tiempo de ejecución como parte de su ciclo de vida de desarrollo seguro.
Marco de evaluación DAST para auditores
Al evaluar los controles DAST de una organización, los auditores deben evaluar cinco áreas clave:
1. Cobertura
Determinar si el análisis DAST cubre adecuadamente el portafolio de aplicaciones de la organización. Las preguntas clave incluyen:
- ¿Qué porcentaje de las aplicaciones de cara a producción están sujetas al análisis DAST?
- ¿Se incluyen en el alcance tanto las aplicaciones web como las APIs?
- ¿El análisis autenticado cubre todos los roles de usuario relevantes?
- ¿Las nuevas aplicaciones desplegadas se incorporan automáticamente al análisis DAST?
2. Frecuencia y puntos de activación
Evaluar cuándo y con qué frecuencia se ejecutan los análisis DAST:
- ¿Está DAST integrado en los pipelines CI/CD, o se ejecuta solo de forma ad hoc?
- ¿Se activan los análisis en cada candidato de versión, o solo de forma periódica?
- ¿Hay un intervalo máximo definido entre análisis para cada aplicación?
- ¿Los calendarios de análisis están documentados y se siguen de forma consistente?
3. Aplicación y puertas de política
Verificar que los hallazgos DAST influyen en las decisiones de despliegue:
- ¿Los hallazgos de severidad crítica o alta bloquean el despliegue?
- ¿Las puertas de política están definidas en código y controladas por versión?
- ¿Pueden los desarrolladores saltarse las puertas DAST? Si es así, ¿se registra y aprueba la omisión?
- ¿Existe segregación de funciones entre quienes ejecutan los análisis y quienes aprueban las excepciones?
4. Evidencia y rastro de auditoría
Evaluar la calidad y completitud de la evidencia DAST:
- ¿Se retienen los resultados del análisis con una política de retención definida?
- ¿Puede la ejecución del análisis trazarse a versiones o despliegues específicos?
- ¿Se hace seguimiento de los hallazgos hasta su remediación o aceptación documentada?
- ¿Están disponibles los datos históricos de análisis para análisis de tendencias?
5. Gestión de excepciones y supresiones
Evaluar cómo se gestionan los falsos positivos y los riesgos aceptados:
- ¿Existe un proceso formal para suprimir o aceptar hallazgos DAST?
- ¿Las supresiones requieren justificación documentada y aprobación?
- ¿Las supresiones tienen límite de tiempo y se revisan periódicamente?
- ¿Hay visibilidad sobre el número total y la proporción de hallazgos suprimidos?
Tabla de evaluación de controles DAST
La siguiente tabla proporciona una referencia estructurada para que los auditores evalúen los controles DAST:
| Área de evaluación | Qué solicitar | Cómo debe verse un buen control | Señales de alerta |
|---|---|---|---|
| Cobertura del análisis | Inventario de aplicaciones analizadas frente al portafolio total | Todas las aplicaciones de cara a producción y las APIs se analizan; la cobertura supera el 90% | Grandes partes del portafolio excluidas sin aceptación documentada del riesgo |
| Frecuencia del análisis | Registros de ejecución con marcas de tiempo; configuraciones del pipeline CI/CD | Los análisis se ejecutan en cada candidato de versión o al menos semanalmente; los calendarios están documentados | Solo análisis ad hoc; sin calendario definido; largos intervalos entre análisis |
| Análisis autenticado | Evidencia de configuraciones de análisis autenticado; documentación de cobertura de roles | Los análisis cubren múltiples roles de usuario; la autenticación es estable y se mantiene | Solo análisis no autenticados; fallos de autenticación no investigados |
| Aplicación de políticas | Definiciones de pipeline mostrando condiciones de puerta; registros de despliegue | Los hallazgos críticos y altos bloquean el despliegue; las puertas están controladas por versión | Sin puertas; los hallazgos son solo orientativos; las puertas pueden omitirse silenciosamente |
| Retención de evidencia | Informes históricos de análisis; documentación de política de retención de datos | Los resultados se retienen durante el período requerido; trazables a versiones específicas | Sin política de retención; resultados eliminados tras cada análisis; sin vínculo con versiones |
| Remediación de hallazgos | Registros de seguimiento de incidencias; plazos de remediación e informes de cumplimiento de SLA | Hallazgos críticos remediados dentro de los SLAs definidos; el seguimiento es sistemático | Hallazgos sin seguimiento; sin SLAs de remediación; gran acumulación de críticos sin atender |
| Gestión de excepciones | Registros de supresión; flujos de trabajo de aprobación; registros de revisión de excepciones | Las supresiones requieren justificación documentada y aprobación; con límite de tiempo | Supresiones masivas sin revisión; sin caducidad; sin segregación de funciones |
| Propiedad y gobernanza | Matriz RACI; documentos de política; definiciones de roles | Propiedad clara de la política DAST, el análisis y la aprobación de excepciones | Sin propiedad definida; responsabilidad ad hoc; sin documentación de gobernanza |
Mapeo regulatorio — Controles DAST
Los controles DAST se mapean a requisitos en múltiples marcos regulatorios y de cumplimiento. La siguiente tabla resume los mapeos clave:
| Marco | Requisito relevante | Cómo aplican los controles DAST |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Artículo 8 — Gestión del riesgo ICT; Artículo 9 — Protección y prevención | DAST proporciona evidencia de pruebas de seguridad en tiempo de ejecución continuas como parte de la gestión del riesgo ICT. Demuestra que las aplicaciones se prueban en busca de vulnerabilidades antes del despliegue. |
| NIS2 (Directiva de Seguridad de Redes y Sistemas de Información) | Artículo 21 — Medidas de gestión del riesgo de ciberseguridad | DAST apoya el requisito de gestión de vulnerabilidades y prácticas de desarrollo seguro. Proporciona evidencia de detección sistemática de vulnerabilidades en aplicaciones desplegadas. |
| ISO 27001:2022 | Anexo A 8.25 — Ciclo de vida de desarrollo seguro; A 8.8 — Gestión de vulnerabilidades técnicas | DAST es un control clave dentro del ciclo de vida de desarrollo seguro. Demuestra la gestión de vulnerabilidades técnicas en entornos en tiempo de ejecución. |
| SOC 2 (Tipo II) | CC7.1 — Detección de cambios; CC8.1 — Gestión de cambios | DAST proporciona evidencia de que los cambios en las aplicaciones se prueban en busca de vulnerabilidades de seguridad. Apoya la detección de cambios no autorizados o inseguros. |
| PCI DSS 4.0 | Requisito 6.4 — Las aplicaciones web de cara al público están protegidas; 6.5 — Los cambios se gestionan | DAST satisface el requisito de análisis de vulnerabilidades en aplicaciones de cara al público. Demuestra pruebas continuas como parte de la gestión de cambios. |
Deficiencias comunes en los controles DAST encontradas durante auditorías
Basándose en patrones observados en entornos regulados, las siguientes deficiencias en los controles DAST se identifican frecuentemente durante las auditorías:
1. Cobertura incompleta
Las organizaciones analizan un subconjunto de aplicaciones — típicamente las incorporadas inicialmente — mientras que las aplicaciones más nuevas o de uso interno se excluyen. La ausencia de un proceso de incorporación automatizado significa que la cobertura se degrada con el tiempo a medida que crece el portafolio.
2. Solo análisis no autenticado
El análisis DAST está configurado pero solo se ejecuta contra superficies no autenticadas. Esto proporciona una garantía limitada porque la mayoría de las vulnerabilidades críticas — incluyendo el control de acceso roto y la escalada de privilegios — existen detrás de endpoints autenticados.
3. Sin aplicación — los hallazgos son solo orientativos
Los análisis DAST se ejecutan, pero los resultados no influyen en las decisiones de despliegue. Los hallazgos se registran pero nunca bloquean una versión, convirtiendo efectivamente a DAST en un ejercicio de reportes en lugar de un control de seguridad. Esta es una deficiencia significativa en el diseño del control.
4. Gestión de excepciones no gobernada
Los hallazgos se suprimen o marcan como aceptados sin justificación documentada, aprobación o caducidad. Con el tiempo, el número de hallazgos suprimidos crece y la organización pierde visibilidad sobre la exposición real al riesgo.
5. Sin retención de evidencia
Los resultados del análisis se sobrescriben con cada ejecución y no se retienen datos históricos. Cuando los auditores solicitan evidencia de la actividad DAST durante el período de auditoría, la organización no puede proporcionarla. Esto socava completamente la auditabilidad del control.
6. Ejecución ad hoc sin gobernanza definida
DAST se ejecuta manualmente por equipos individuales sin política centralizada, sin propiedad definida y sin consistencia en la configuración o frecuencia del análisis. El resultado es una cobertura impredecible y evidencia poco fiable.
7. Sin integración con el seguimiento de incidencias
Los hallazgos DAST no se enrutan sistemáticamente a los sistemas de seguimiento de incidencias, lo que imposibilita demostrar que los hallazgos fueron triados, asignados y remediados dentro de los plazos definidos.
Lista de verificación de gobernanza
Los auditores que revisan los controles DAST deben verificar lo siguiente:
- Existe una política DAST, está aprobada y define el alcance, la frecuencia y la propiedad
- La cobertura del análisis incluye todas las aplicaciones en el alcance, incluidas las APIs
- Los análisis están automatizados e integrados en los pipelines CI/CD o programados con frecuencia definida
- Existen puertas de política que aplican las decisiones de despliegue basándose en la severidad de los hallazgos
- La evidencia se retiene con trazabilidad a versiones y despliegues específicos
- Se hace seguimiento de los hallazgos hasta su remediación o aceptación documentada del riesgo
- Las supresiones están gobernadas, justificadas, aprobadas y tienen límite de tiempo
- Los roles y responsabilidades están claramente definidos (análisis, política, aprobación de excepciones)
Conclusión
Evaluar los controles DAST en entornos regulados requiere más que confirmar que se ha instalado una herramienta de análisis. Los auditores deben evaluar si DAST se aplica de forma consistente, si los hallazgos se aplican y remedian, si la evidencia se retiene y si las excepciones están gobernadas.
Las organizaciones que tratan DAST como un control aplicable y evidenciado — en lugar de un análisis opcional — están significativamente mejor posicionadas para satisfacer los requisitos regulatorios bajo DORA, NIS2, ISO 27001, SOC 2 y PCI DSS.
Artículos relacionados
- Mejores herramientas DAST para pipelines CI/CD empresariales (edición 2026)
- Lista de verificación para la selección de herramientas DAST en entornos empresariales
- Gestión de falsos positivos en pipelines DAST empresariales
- Cómo revisan realmente los auditores los controles DAST en entornos regulados
Preguntas frecuentes — Auditoría de controles DAST
¿Qué deben verificar primero los auditores al evaluar los controles DAST?
Empezar con la cobertura y la aplicación. Verificar que el análisis DAST cubre el portafolio de aplicaciones de la organización y que los hallazgos influyen en las decisiones de despliegue a través de puertas de política definidas.
¿Cuál es la deficiencia más común en los controles DAST en entornos regulados?
La deficiencia más común es ejecutar DAST solo en modo orientativo — los análisis se ejecutan pero los hallazgos no bloquean el despliegue, haciendo que el control sea ineficaz como puerta de seguridad.
¿Qué marcos regulatorios requieren DAST o pruebas de seguridad en tiempo de ejecución?
DORA, NIS2, ISO 27001, SOC 2 y PCI DSS incluyen requisitos que se mapean a las pruebas de seguridad en tiempo de ejecución. DAST proporciona evidencia de detección continua de vulnerabilidades en aplicaciones desplegadas.
