Dynamic Application Security Testing (DAST) está ampliamente adoptado en los pipelines CI/CD empresariales, pero también es uno de los controles más incomprendidos durante las auditorías. Muchos equipos asumen que los auditores evaluarán DAST en función de la cobertura del análisis o el recuento de vulnerabilidades. En realidad, los auditores evalúan DAST de forma muy diferente.
Este artículo explica qué buscan realmente los auditores, qué ignoran en gran medida y qué desencadena habitualmente hallazgos de auditoría al revisar los controles DAST en entornos regulados.
La perspectiva del auditor sobre DAST
Los auditores no evalúan DAST como un ejercicio de pruebas de penetración ni como una herramienta de descubrimiento de vulnerabilidades. En cambio, evalúan DAST como un mecanismo de gobernanza y control de riesgos integrado en el ciclo de vida de entrega de software.
Desde el punto de vista de la auditoría, DAST responde a tres preguntas fundamentales:
- ¿Las pruebas de seguridad de las aplicaciones se aplican de forma consistente?
- ¿Las decisiones de riesgo son trazables y están justificadas?
- ¿Puede la organización demostrar la ejecución del control a lo largo del tiempo?
La profundidad técnica del escáner importa mucho menos que cómo se diseña, aplica y evidencia el control.
Qué examinan realmente los auditores
1. Ejecución consistente en pipelines CI/CD
Los auditores verifican que los análisis DAST no son opcionales ni ad hoc. Esperan ver:
- DAST integrado en etapas definidas del pipeline (típicamente staging o pre-versión),
- análisis activados automáticamente, no manualmente,
- condiciones claras bajo las cuales deben ejecutarse los análisis (rama, entorno, tipo de versión).
La evidencia típicamente revisada incluye:
- definiciones del pipeline,
- registros de ejecución de trabajos,
- ejecuciones históricas de análisis en múltiples versiones.
La ejecución inconsistente suele interpretarse como un control ineficaz.
2. Lógica de bloqueo y decisión
Los auditores se centran en gran medida en qué ocurre cuando DAST encuentra problemas.
Esperan ver:
- umbrales de severidad definidos,
- reglas explícitas de bloqueo del pipeline,
- excepciones documentadas o procesos de anulación.
Las compilaciones que pasan a pesar de los hallazgos son aceptables solo si hay justificación documentada, aprobación y trazabilidad.
Una pregunta habitual del auditor es:
«Muéstreme por qué se permitió esta versión a pesar de los hallazgos DAST.»
3. Gobernanza de falsos positivos
Los auditores no esperan cero falsos positivos. Lo que evalúan es cómo se gestionan los falsos positivos.
Buscan:
- flujos de trabajo formales de supresión,
- aprobación de supresiones basada en roles,
- revisión periódica o caducidad de los hallazgos suprimidos.
Las supresiones permanentes no documentadas son una señal de alerta frecuente en auditorías.
4. Retención de evidencia y trazabilidad
DAST solo es auditable si existe evidencia.
Los auditores esperan:
- resultados de análisis retenidos,
- vinculación entre los resultados del análisis y compilaciones o versiones específicas,
- correlación entre hallazgos, aprobaciones y decisiones de despliegue.
La evidencia debe ser:
- resistente a manipulaciones,
- retenida según la política,
- recuperable sin reconstrucción manual.
5. Alineación con la gestión del riesgo
Los auditores a menudo mapean DAST a marcos de control más amplios (ISO 27001, SOC 2, DORA, NIS2).
Verifican si:
- DAST está referenciado en las políticas de seguridad,
- las responsabilidades están claramente asignadas,
- las excepciones se aceptan como riesgo en lugar de ignorarse.
DAST sin propiedad documentada se considera un control débil.
Lo que los auditores ignoran en gran medida
1. Marca de la herramienta y afirmaciones de marketing
Los auditores generalmente no les importa qué proveedor DAST se utiliza.
No evalúan:
- popularidad del escáner,
- afirmaciones sobre IA,
- número de vulnerabilidades detectadas.
Una herramienta básica con una gobernanza sólida suele verse más favorablemente que una herramienta avanzada utilizada de forma inconsistente.
2. Recuentos brutos de vulnerabilidades
Los números altos de hallazgos no impresionan a los auditores. Los números bajos tampoco los tranquilizan.
Lo que importa es:
- consistencia de la ejecución,
- claridad de la toma de decisiones,
- evidencia de remediación o aceptación.
Los auditores raramente analizan vulnerabilidades individuales a menos que estén investigando un incidente específico.
3. Afirmaciones de cobertura máxima del análisis
Declaraciones como «analizamos todo» no son convincentes sin pruebas.
Los auditores prefieren:
- alcance definido,
- exclusiones documentadas,
- justificación de lo que no se analiza.
El análisis demasiado amplio y mal controlado suele verse como inmaduro en lugar de avanzado.
Qué desencadena habitualmente hallazgos de auditoría
1. DAST se ejecuta pero no aplica nada
Si los análisis se ejecutan pero nunca bloquean versiones y no hay un proceso formal de excepciones, los auditores a menudo concluyen que DAST es solo informativo.
Esto frecuentemente lleva a hallazgos como:
- «El control existe pero no es efectivo.»
2. Supresiones sin gobernanza
Las señales de alerta típicas incluyen:
- supresiones aplicadas directamente por los desarrolladores,
- sin fechas de caducidad,
- sin registros de revisión.
Los auditores pueden interpretar esto como aceptación de riesgo no controlada.
3. Evidencia histórica faltante
Poder mostrar solo el último análisis es insuficiente.
Los auditores esperan:
- evidencia histórica a través de múltiples versiones,
- capacidad de reconstruir decisiones pasadas.
La evidencia faltante a menudo resulta en hallazgos incluso si los análisis se ejecutaron técnicamente.
4. Ejecución manual o inconsistente
Los análisis DAST activados manualmente o «cuando hay tiempo» raramente se aceptan en entornos regulados.
La automatización y la consistencia son criterios de auditoría críticos.
Cómo superan las auditorías DAST las organizaciones maduras
Las organizaciones que superan consistentemente las auditorías tratan DAST como:
- un control CI/CD aplicado por política,
- un punto de decisión, no solo un escáner,
- una fuente de evidencia, no solo de hallazgos.
Diseñan DAST con los resultados de auditoría en mente desde el principio, en lugar de intentar añadir gobernanza más tarde.
Conclusión clave
Los auditores no preguntan:
«¿Qué tan buena es su herramienta DAST?»
Preguntan:
«¿Puede demostrar que las pruebas de seguridad de las aplicaciones se aplican, gobiernan y son auditables?»
Los equipos que comprenden esta distinción evitan la mayoría de los hallazgos de auditoría relacionados con DAST.
Artículos relacionados sobre DAST
- Mejores herramientas DAST para pipelines CI/CD empresariales
- Selección de una herramienta DAST adecuada para pipelines CI/CD empresariales
- Selección de herramientas DAST — Matriz de evaluación RFP (entornos empresariales y regulados)
- Comparación de herramientas DAST empresariales: evaluación basada en RFP
- Gestión de falsos positivos en pipelines DAST empresariales
- Selección de herramientas DAST para empresas — Lista de verificación de auditoría
