Las pruebas dinámicas de seguridad de aplicaciones (DAST) constituyen un control de seguridad crítico en tiempo de ejecución en los entornos regulados de entrega de software. Para los auditores, los responsables de cumplimiento y los reguladores, la pregunta no es qué herramienta DAST utiliza una organización, sino si los controles DAST son adecuados, exigibles y están evidenciados.
Esta guía ofrece un marco estructurado para evaluar los controles DAST de una organización dentro de las canalizaciones CI/CD, centrándose en la cobertura, la exigibilidad, la generación de evidencia, el tratamiento de las excepciones y la alineación regulatoria. También explica cómo abordan los auditores una revisión de DAST en la práctica, de modo que los equipos puedan anticipar las preguntas que se plantearán y la evidencia que se solicitará.
Por qué importan los controles DAST en los entornos regulados
DAST evalúa las aplicaciones en tiempo de ejecución y descubre vulnerabilidades relacionadas con la autenticación, la autorización, la gestión de sesiones y la configuración que el análisis estático no puede detectar. En los entornos regulados, DAST actúa como una etapa de validación controlada, verificando que los controles en tiempo de ejecución funcionan como se espera antes de publicar el software.
Desde la perspectiva de la gobernanza, DAST no es una herramienta opcional. Es la evidencia de que la organización pone a 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 examinar cinco áreas clave:
1. Cobertura
Determine si el análisis DAST cubre de forma adecuada el porfolio de aplicaciones de la organización. Las preguntas clave incluyen:
- ¿Qué porcentaje de las aplicaciones de cara a producción está sujeto al análisis DAST?
- ¿Se incluyen en el alcance tanto las aplicaciones web como las API?
- ¿El análisis autenticado cubre todos los roles de usuario relevantes?
- ¿Las aplicaciones recién desplegadas se incorporan automáticamente al análisis DAST?
2. Frecuencia y puntos de activación
Evalúe cuándo y con qué frecuencia se ejecutan los análisis DAST:
- ¿Está DAST integrado en las canalizaciones CI/CD o se ejecuta solo de forma ad hoc?
- ¿Los análisis se activan en cada candidata a versión o solo según una programación periódica?
- ¿Existe un intervalo máximo definido entre análisis para cada aplicación?
- ¿Las programaciones de análisis están documentadas y se siguen de forma coherente?
3. Exigibilidad y puertas de política
Verifique que los hallazgos de DAST influyen en las decisiones de despliegue:
- ¿Los hallazgos críticos o de gravedad alta bloquean el despliegue?
- ¿Las puertas de política están definidas en el código y bajo control de versiones?
- ¿Pueden los desarrolladores eludir las puertas DAST? Si es así, ¿la elusión se registra y se aprueba?
- ¿Existe segregación de funciones entre quienes ejecutan los análisis y quienes aprueban las excepciones?
4. Evidencia y rastro de auditoría
Evalúe la calidad y la exhaustividad de la evidencia de DAST:
- ¿Los resultados de los análisis se conservan conforme a una política de retención definida?
- ¿La ejecución de los análisis puede rastrearse hasta versiones o despliegues específicos?
- ¿Los hallazgos se rastrean hasta su remediación o una aceptación documentada?
- ¿Se dispone de datos históricos de los análisis para el análisis de tendencias?
5. Gestión de excepciones y supresiones
Evalúe cómo se tratan los falsos positivos y los riesgos aceptados:
- ¿Existe un proceso formal para suprimir o aceptar los hallazgos de DAST?
- ¿Las supresiones requieren justificación documentada y aprobación?
- ¿Las supresiones tienen vigencia limitada y se revisan periódicamente?
- ¿Existe visibilidad sobre el número total y la proporción de hallazgos suprimidos?
Tabla de evaluación de controles DAST
La siguiente tabla ofrece una referencia estructurada para los auditores que evalúan los controles DAST:
| Área de evaluación | Qué solicitar | Cómo es una buena práctica | Señales de alerta |
|---|---|---|---|
| Cobertura del análisis | Inventario de aplicaciones analizadas frente al total del porfolio de aplicaciones | Todas las aplicaciones de cara a producción y las API se analizan; la cobertura supera el 90 % | Se excluyen grandes porciones del porfolio sin una aceptación de riesgo documentada |
| Frecuencia del análisis | Registros de ejecución de los análisis con marcas de tiempo; configuraciones de la canalización CI/CD | Los análisis se ejecutan en cada candidata a versión o, al menos, semanalmente; las programaciones están documentadas | Solo análisis ad hoc; sin programación definida; largas lagunas entre análisis |
| Análisis autenticado | Evidencia de configuraciones de análisis autenticado; documentación de la cobertura de roles | Los análisis cubren varios roles de usuario; la autenticación es estable y se mantiene | Solo análisis no autenticados; los fallos de autenticación no se investigan |
| Aplicación de políticas | Definiciones de la canalización que muestran las condiciones de las puertas; registros de despliegue | Los hallazgos críticos y altos bloquean el despliegue; las puertas están bajo control de versiones | Sin puertas establecidas; los hallazgos son solo consultivos; las puertas pueden eludirse de forma silenciosa |
| Retención de evidencia | Informes históricos de análisis; documentación de la política de retención de datos | Los resultados de los análisis se conservan durante el periodo requerido; son trazables hasta versiones específicas | Sin política de retención; los resultados se eliminan tras cada análisis; sin vínculo con las versiones |
| Remediación de hallazgos | Registros de seguimiento de incidencias; plazos de remediación e informes de cumplimiento de los ANS | Los hallazgos críticos se remedian dentro de los ANS definidos; el seguimiento es sistemático | Los hallazgos no se rastrean; sin ANS de remediación; gran acumulación de hallazgos críticos sin atender |
| Gestión de excepciones | Registros de supresiones; flujos de aprobación; registros de revisión de excepciones | Las supresiones requieren justificación documentada y aprobación; tienen vigencia limitada | 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 con requisitos de múltiples marcos regulatorios y de cumplimiento. La siguiente tabla resume los mapeos clave:
| Marco | Requisito relevante | Cómo se aplican los controles DAST |
|---|---|---|
| DORA (Ley de Resiliencia Operativa Digital) | Artículo 8: gestión del riesgo de las TIC; Artículo 9: protección y prevención | DAST aporta evidencia de pruebas de seguridad continuas en tiempo de ejecución como parte de la gestión del riesgo de las TIC. Demuestra que las aplicaciones se ponen a prueba en busca de vulnerabilidades antes del despliegue. |
| NIS2 (Directiva de Seguridad de las Redes y de la Información) | Artículo 21: medidas de gestión del riesgo de ciberseguridad | DAST respalda el requisito de gestión de vulnerabilidades y prácticas de desarrollo seguro. Aporta evidencia de la detección sistemática de vulnerabilidades en las aplicaciones desplegadas. |
| ISO 27001:2022 | Anexo A 8.25: ciclo de vida de desarrollo seguro; A 8.8: gestión de las 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 los entornos de ejecución. |
| SOC 2 (Tipo II) | CC7.1: detección de cambios; CC8.1: gestión de cambios | DAST aporta evidencia de que los cambios en las aplicaciones se ponen a prueba en busca de vulnerabilidades de seguridad. Respalda la detección de cambios no autorizados o inseguros. |
| PCI DSS 4.0 | Requisito 6.4: se protegen las aplicaciones web de cara al público; 6.5: se gestionan los cambios | DAST satisface el requisito de análisis de vulnerabilidades de las aplicaciones de cara al público. Demuestra pruebas continuas como parte de la gestión de cambios. |
Cómo revisan realmente los auditores los controles DAST
El marco y los mapeos anteriores describen cómo es una buena gobernanza de DAST sobre el papel. Igual de importante es comprender cómo abordan los auditores una revisión en la práctica: qué examinan, qué pasan por alto en gran medida y qué produce hallazgos de forma fiable. DAST es uno de los controles peor comprendidos durante las auditorías: muchos equipos suponen que se juzgará por la cobertura de los análisis o por el recuento bruto de vulnerabilidades, cuando en realidad los auditores lo evalúan como un control de gobernanza y riesgo integrado en el ciclo de vida de entrega de software.
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 su lugar, lo evalúan como un mecanismo de control de gobernanza y riesgo 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 aplicaciones se aplican de forma coherente?
- ¿Las decisiones de riesgo son trazables y están justificadas?
- ¿Puede la organización probar la ejecución del control a lo largo del tiempo?
La profundidad técnica del escáner importa mucho menos que la forma en que el control se diseña, se aplica y se evidencia.
Qué examinan realmente los auditores
Ejecución coherente en las canalizaciones CI/CD. Los auditores verifican que los análisis DAST no son opcionales ni ad hoc. Esperan análisis integrados en etapas definidas de la canalización (normalmente preproducción o previas a la versión), activados de forma automática y no manual, con condiciones claras bajo las cuales deben ejecutarse. La evidencia revisada suele incluir definiciones de la canalización, registros de ejecución de los trabajos y ejecuciones históricas de análisis en múltiples versiones. La ejecución incoherente a menudo se interpreta como un control ineficaz.
Puertas y lógica de decisión. Los auditores se centran mucho en qué ocurre cuando DAST encuentra problemas. Esperan umbrales de gravedad definidos, reglas explícitas de aplicación de puertas en la canalización y procesos de excepción o anulación documentados. Aprobar una compilación a pesar de los hallazgos solo es aceptable cuando existe 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 de DAST.»
Gobernanza de los falsos positivos. Los auditores no esperan cero falsos positivos. Lo que evalúan es cómo se tratan los falsos positivos: flujos de supresión formales, aprobación de las supresiones basada en roles y revisión periódica o caducidad de los hallazgos suprimidos. Las supresiones permanentes y sin documentar son una señal de alerta frecuente.
Retención y trazabilidad de la evidencia. DAST solo es auditable si existe evidencia. Los auditores esperan resultados de análisis conservados, vinculación entre los resultados y compilaciones o versiones específicas, y correlación entre los hallazgos, las aprobaciones y las decisiones de despliegue. Esa evidencia debe ser resistente a la manipulación, conservarse conforme a la política y poder recuperarse sin reconstrucción manual.
Alineación con la gestión del riesgo. Los auditores suelen mapear DAST con marcos de control más amplios, como ISO 27001, SOC 2, DORA y NIS2. Comprueban si DAST se menciona en las políticas de seguridad, si las responsabilidades están claramente asignadas y si las excepciones se aceptan formalmente como riesgo en lugar de ignorarse. DAST sin una propiedad documentada se considera un control débil.
Qué ignoran en su mayoría los auditores
Comprender qué pasan por alto los auditores es tan útil como saber qué examinan. En la práctica, tres cosas tienen mucho menos peso del que esperan los equipos.
- Marca de la herramienta y afirmaciones de marketing. A los auditores por lo general no les importa qué proveedor de DAST se utiliza, y no evalúan la popularidad del escáner, las afirmaciones sobre IA ni el número de vulnerabilidades detectadas. Una herramienta básica con una gobernanza sólida suele valorarse más favorablemente que una herramienta avanzada utilizada de forma incoherente.
- Recuentos brutos de vulnerabilidades. Un número elevado de hallazgos no impresiona a los auditores, y un número bajo no los tranquiliza. Lo que importa es la coherencia de la ejecución, la claridad de la toma de decisiones y la evidencia de remediación o aceptación. Los auditores rara vez analizan vulnerabilidades individuales, salvo que investiguen un incidente específico.
- Afirmaciones de cobertura máxima del análisis. Frases como «lo analizamos todo» no resultan convincentes sin pruebas. Los auditores prefieren un alcance definido, exclusiones documentadas y una justificación de lo que no se analiza. Un análisis excesivamente amplio y mal controlado suele considerarse inmaduro en lugar de avanzado.
Qué suele desencadenar hallazgos de auditoría
Ciertos patrones casi siempre conducen a hallazgos, incluso cuando una herramienta de análisis está técnicamente instalada:
- DAST se ejecuta pero no aplica nada. Si los análisis se ejecutan pero nunca bloquean las versiones y no existe un proceso formal de excepciones, los auditores a menudo concluyen que el control «existe pero no es eficaz».
- Supresiones sin gobernanza. Las supresiones aplicadas directamente por los desarrolladores, sin fechas de caducidad ni registros de revisión, se interpretan como una aceptación de riesgo incontrolada.
- Evidencia histórica ausente. Poder mostrar solo el análisis más reciente es insuficiente. Los auditores esperan evidencia histórica a lo largo de múltiples versiones y la capacidad de reconstruir decisiones pasadas; la evidencia ausente a menudo da lugar a hallazgos incluso cuando los análisis se ejecutaron técnicamente.
- Ejecución manual o incoherente. Los análisis activados de forma manual o «cuando hay tiempo» rara vez se aceptan en los entornos regulados, donde la automatización y la coherencia son criterios de auditoría críticos.
Cómo superan las organizaciones maduras las auditorías de DAST
Las organizaciones que superan las auditorías de forma constante tratan DAST como un control CI/CD aplicado por política, como un punto de decisión y no solo como un escáner, y como una fuente de evidencia y no únicamente como una fuente de hallazgos. Diseñan DAST teniendo en cuenta los resultados de la auditoría desde el principio, en lugar de intentar añadir la gobernanza más tarde. La distinción queda recogida en las preguntas que formulan los auditores. Rara vez preguntan: «¿Qué tan buena es su herramienta DAST?». Preguntan: «¿Puede demostrar que las pruebas de seguridad de aplicaciones se aplican, se gobiernan y son auditables?». Los equipos que interiorizan esa diferencia evitan la mayoría de los hallazgos relacionados con DAST.
Deficiencias habituales de los controles DAST detectadas en las auditorías
A partir de los patrones observados en entornos regulados, las siguientes deficiencias de los controles DAST se identifican con frecuencia durante las auditorías:
1. Cobertura incompleta
Las organizaciones analizan un subconjunto de aplicaciones —normalmente las incorporadas al principio—, mientras que las aplicaciones más nuevas o de uso interno quedan excluidas. La ausencia de un proceso de incorporación automatizado hace que la cobertura se degrade con el tiempo a medida que crece el porfolio.
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 —incluidos el control de acceso roto y la escalada de privilegios— existen tras puntos de conexión autenticados.
3. Sin exigibilidad: los hallazgos son solo consultivos
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, lo que convierte a DAST en un ejercicio de generación de informes en lugar de un control de seguridad. Esta es una deficiencia significativa del diseño del control.
4. Gestión de excepciones sin gobernanza
Los hallazgos se suprimen o se marcan como aceptados sin justificación documentada, aprobación ni caducidad. Con el tiempo, el número de hallazgos suprimidos crece y la organización pierde visibilidad sobre su exposición real al riesgo.
5. Sin retención de evidencia
Los resultados de los análisis se sobrescriben con cada ejecución y no se conservan datos históricos. Cuando los auditores solicitan evidencia de la actividad de DAST durante el periodo de auditoría, la organización no puede aportarla. Esto socava por completo la auditabilidad del control.
6. Ejecución ad hoc sin gobernanza definida
DAST se ejecuta manualmente por equipos individuales sin una política centralizada, sin propiedad definida y sin coherencia en la configuración o la frecuencia de los análisis. El resultado es una cobertura impredecible y una evidencia poco fiable.
7. Sin integración con el seguimiento de incidencias
Los hallazgos de DAST no se derivan de forma sistemática a los sistemas de seguimiento de incidencias, lo que hace imposible demostrar que los hallazgos se clasificaron, asignaron y remediaron dentro de plazos definidos.
Lista de verificación de la gobernanza
Los auditores que revisan los controles DAST deben verificar lo siguiente:
- Existe una política DAST aprobada que define el alcance, la frecuencia y la propiedad
- La cobertura del análisis incluye todas las aplicaciones dentro del alcance, incluidas las API
- Los análisis están automatizados e integrados en las canalizaciones CI/CD o programados con una frecuencia definida
- Existen puertas de política que imponen las decisiones de despliegue en función de la gravedad de los hallazgos
- La evidencia se conserva con trazabilidad hasta versiones y despliegues específicos
- Los hallazgos se rastrean hasta su remediación o hasta una aceptación de riesgo documentada
- Las supresiones están gobernadas, justificadas, aprobadas y tienen vigencia limitada
- Los roles y las 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 una herramienta de análisis está instalada. Los auditores deben valorar si DAST se aplica de forma coherente, si los hallazgos se exigen y se remedian, si la evidencia se conserva y si las excepciones están gobernadas.
Las organizaciones que tratan DAST como un control exigible y evidenciado —en lugar de como un análisis opcional— están mucho mejor posicionadas para satisfacer los requisitos regulatorios de DORA, NIS2, ISO 27001, SOC 2 y PCI DSS.
Artículos relacionados
- Mejores herramientas DAST para canalizaciones CI/CD empresariales (edición 2026)
- Gobernanza de herramientas DAST: lista de selección, despliegue y por qué fracasan las implementaciones
- Gestión de los falsos positivos en las canalizaciones DAST empresariales
Preguntas frecuentes: auditoría de los controles DAST
¿Qué deben verificar primero los auditores al evaluar los controles DAST?
Empiece por la cobertura y la exigibilidad. Verifique que el análisis DAST cubre el porfolio de aplicaciones de la organización y que los hallazgos influyen en las decisiones de despliegue mediante puertas de política definidas.
¿Cuál es la deficiencia de control DAST más habitual en los entornos regulados?
La deficiencia más habitual es ejecutar DAST solo en modo consultivo: los análisis se ejecutan, pero los hallazgos no bloquean el despliegue, lo que hace que el control sea ineficaz como puerta de seguridad.
¿Qué marcos regulatorios exigen DAST o pruebas de seguridad en tiempo de ejecución?
DORA, NIS2, ISO 27001, SOC 2 y PCI DSS incluyen requisitos que se mapean con las pruebas de seguridad en tiempo de ejecución. DAST aporta evidencia de la detección continua de vulnerabilidades en las aplicaciones desplegadas.
¿Les importa a los auditores qué proveedor de DAST utiliza una organización?
Por lo general, no. Los auditores evalúan cómo se gobierna, se aplica y se evidencia el control, más que la marca del escáner. Una herramienta básica con una gobernanza sólida se valora más favorablemente que una herramienta avanzada utilizada de forma incoherente.
