Comparación de los controles de pruebas de seguridad de CI/CD: lo que auditores, responsables de cumplimiento y reguladores necesitan saber
Los controles de pruebas de seguridad en los pipelines de CI/CD — comúnmente denominados SAST, DAST y SCA — se comparan con frecuencia en función de sus capacidades técnicas de detección. Para los auditores y los responsables de cumplimiento, las dimensiones de comparación relevantes son distintas: objetivos de control, calidad de la evidencia, capacidad de aplicación (enforcement), trazabilidad para auditoría y alineación con los marcos de cumplimiento.
Este artículo compara SAST (pruebas estáticas de seguridad de aplicaciones), DAST (pruebas dinámicas de seguridad de aplicaciones) y SCA (análisis de composición de software) desde una perspectiva de gobernanza y auditoría, ayudando a los auditores a entender qué hace cada control, qué evidencia debería producir y cómo verificar que está implementado correctamente.
SAST — Propiedades del control para auditores
| Propiedad del control | SAST (pruebas estáticas de seguridad de aplicaciones) |
|---|---|
| Objetivo del control | Detectar vulnerabilidades de seguridad en el código fuente antes del despliegue |
| Calidad de la evidencia | Alta: produce informes de escaneo detallados con clasificaciones de severidad y decisiones de política de aprobado/rechazado |
| Capacidad de aplicación en CI/CD | Fuerte: puede bloquear compilaciones e impedir el despliegue cuando se superan los umbrales |
| Trazabilidad para auditoría | Alta: los resultados pueden vincularse a compilaciones, commits y versiones específicas |
| Alineación con marcos de cumplimiento | DORA (control preventivo de codificación), NIS2 (SDLC seguro), ISO 27001 (A.8.25-28), SOC 2 (CC8.1), PCI DSS (6.3) |
| Requisitos de gobernanza | Umbrales de severidad definidos, políticas de supresión documentadas, retención de los resultados de escaneo |
Qué deberían verificar los auditores en SAST:
- SAST se ejecuta automáticamente en cada compilación o pull request, no solo bajo demanda
- Los umbrales de severidad están definidos y se aplican (las compilaciones fallan cuando se superan los umbrales)
- Los hallazgos suprimidos cuentan con justificaciones documentadas, con fechas de revisión y de caducidad
- Los resultados de escaneo se conservan y se vinculan a versiones específicas
- Todas las bases de código de producción están cubiertas por el escaneo de SAST
Señales de alerta en SAST:
- SAST está configurado pero no se aplica: las compilaciones continúan con independencia de los hallazgos
- Gran número de hallazgos suprimidos sin justificación documentada ni fechas de caducidad
- Los resultados de escaneo no pueden rastrearse hasta versiones o compilaciones específicas
- Existen bases de código de producción que no están cubiertas por el escaneo de SAST
- SAST se ejecuta solo bajo demanda en lugar de automáticamente como parte de cada compilación
DAST — Propiedades del control para auditores
| Propiedad del control | DAST (pruebas dinámicas de seguridad de aplicaciones) |
|---|---|
| Objetivo del control | Validar la seguridad en tiempo de ejecución de aplicaciones desplegadas o en entorno de preproducción |
| Calidad de la evidencia | Media a alta: produce hallazgos en tiempo de ejecución, pero puede requerir contexto para su interpretación |
| Capacidad de aplicación en CI/CD | Media: normalmente se usa como puerta de publicación, no como puerta en tiempo de compilación |
| Trazabilidad para auditoría | Media: los resultados se vinculan a entornos y versiones, pero el rastreo hasta cambios de código específicos es indirecto |
| Alineación con marcos de cumplimiento | DORA (validación en tiempo de ejecución), ISO 27001 (A.8.25-28), SOC 2 (CC7.1), PCI DSS (6.4, 11.3) |
| Requisitos de gobernanza | Puntos de ejecución definidos, lógica de gating documentada, flujos de excepción y aprobación |
Qué deberían verificar los auditores en DAST:
- DAST se ejecuta antes de las publicaciones a producción, no solo bajo demanda o según un calendario desconectado de los despliegues
- Existen umbrales definidos para bloquear o retrasar las publicaciones
- Las excepciones al gating de DAST se documentan con aprobaciones y justificaciones
- La gestión de falsos positivos sigue un proceso gobernado (supresión basada en roles, justificación documentada, caducidad)
- El alcance de DAST cubre todas las aplicaciones críticas y expuestas al exterior
Señales de alerta en DAST:
- DAST se ejecuta solo ocasionalmente o según un calendario desconectado del proceso de publicación
- No existe lógica de gating: todas las publicaciones continúan con independencia de los hallazgos de DAST
- Los resultados de DAST no pueden vincularse a despliegues o versiones específicos
- Las aplicaciones críticas o expuestas al exterior quedan excluidas del alcance de DAST
- Los falsos positivos se suprimen sin aprobaciones documentadas ni fechas de caducidad
SCA — Propiedades del control para auditores
| Propiedad del control | SCA (análisis de composición de software) |
|---|---|
| Objetivo del control | Gestionar el riesgo de terceros y de la cadena de suministro identificando dependencias vulnerables y no conformes |
| Calidad de la evidencia | Muy alta: produce inventarios de dependencias, SBOM, informes de vulnerabilidades y registros de cumplimiento de licencias |
| Capacidad de aplicación en CI/CD | Fuerte: puede bloquear compilaciones cuando se detectan dependencias vulnerables o no conformes |
| Trazabilidad para auditoría | Muy alta: los SBOM y los inventarios de dependencias proporcionan registros claros y auditables por versión |
| Alineación con marcos de cumplimiento | NIS2 (riesgo de la cadena de suministro), DORA (riesgo de terceros de TIC), ISO 27001 (A.8.25-28), SOC 2 (CC3.2), PCI DSS (6.3) |
| Requisitos de gobernanza | Políticas de aprobación de dependencias, generación y retención de SBOM, procedimientos de respuesta ante vulnerabilidades |
Qué deberían verificar los auditores en SCA:
- SCA se ejecuta automáticamente durante las compilaciones y produce inventarios de dependencias actualizados
- Los SBOM se generan y se conservan para cada versión
- Las dependencias vulnerables conocidas desencadenan respuestas definidas (bloqueo, alerta o aceptación de riesgo documentada)
- El cumplimiento de licencias se monitoriza activamente y las infracciones se abordan
- Las políticas de dependencias definen los componentes aceptables y los procesos de aprobación para las excepciones
Señales de alerta en SCA:
- No existe inventario de dependencias ni SBOM para las aplicaciones de producción
- Las vulnerabilidades críticas conocidas en las dependencias no se abordan ni se documentan
- SCA no está integrado en CI/CD: se ejecuta manualmente o no se ejecuta en absoluto
- No hay gobernanza sobre qué componentes de terceros pueden utilizarse
- El cumplimiento de licencias no se monitoriza, lo que genera riesgo legal y regulatorio
Comparación lado a lado: SAST frente a DAST frente a SCA desde la perspectiva de la auditoría
| Dimensión de auditoría | SAST | DAST | SCA |
|---|---|---|---|
| Objetivo del control | Seguridad preventiva a nivel de código | Validación en tiempo de ejecución | Gestión del riesgo de la cadena de suministro |
| Calidad de la evidencia | Alta | Media-alta | Muy alta |
| Capacidad de aplicación en CI/CD | Fuerte (gating de compilación) | Media (gating de publicación) | Fuerte (bloqueo de dependencias) |
| Trazabilidad para auditoría | Alta (vinculada a commits) | Media (vinculada al entorno) | Muy alta (vinculada al SBOM) |
| Alineación con marcos de cumplimiento | Amplia | Amplia | Crítica para las regulaciones de cadena de suministro |
| Complejidad de gobernanza | Media (gestión de supresiones) | Media-alta (gobernanza de falsos positivos) | Media (gestión de la política de dependencias) |
Qué controles importan más en cada regulación
DORA (Ley de Resiliencia Operativa Digital)
DORA hace hincapié en la gestión del riesgo de TIC y en la resiliencia operativa de las entidades financieras. Desde la perspectiva de la auditoría:
- SCA es crítico: DORA exige visibilidad sobre el riesgo de terceros de TIC, incluidas las dependencias de software
- SAST es importante: respalda los controles preventivos dentro del ciclo de vida de desarrollo seguro
- DAST aporta validación complementaria: demuestra la realización de pruebas en tiempo de ejecución sobre los servicios desplegados
NIS2 (Directiva de Seguridad de las Redes y Sistemas de Información)
NIS2 se centra en la seguridad de la cadena de suministro, la gestión de incidentes y la gestión del riesgo para las entidades esenciales e importantes:
- SCA es esencial: aborda directamente los requisitos de riesgo de la cadena de suministro y de las dependencias
- SAST respalda el desarrollo seguro: se alinea con los requisitos de prácticas de seguridad desde el diseño
- DAST valida la exposición de servicios: ayuda a demostrar que los servicios expuestos al exterior se someten a pruebas
ISO 27001
ISO 27001 exige que las organizaciones demuestren la eficacia de los controles en todo el sistema de gestión de la seguridad de la información:
- Los tres controles son relevantes: en conjunto demuestran prácticas de desarrollo seguro (controles del Anexo A A.8.25-28)
- SCA suele aportar la evidencia más clara: los SBOM y los inventarios de dependencias son artefactos tangibles y auditables
- Los auditores deberían verificar que los controles están integrados en CI/CD, no realizados como actividades manuales separadas
SOC 2
SOC 2 evalúa los controles relacionados con la seguridad, la disponibilidad, la integridad del procesamiento, la confidencialidad y la privacidad:
- SAST y SCA respaldan los criterios de servicios de confianza de Seguridad e Integridad del Procesamiento
- DAST respalda la evidencia de las pruebas de seguridad en tiempo de ejecución
- Los auditores deberían centrarse en si los controles se aplican de forma coherente y producen evidencia conservada
PCI DSS
PCI DSS incluye requisitos explícitos para las pruebas de seguridad de aplicaciones:
- SAST se referencia directamente (Requisito 6.3): se exigen revisiones de código o análisis automatizado de código
- DAST se referencia directamente (Requisitos 6.4, 11.3): las pruebas de seguridad de aplicaciones web son obligatorias
- SCA respalda los requisitos de gestión de vulnerabilidades al hacer seguimiento de las vulnerabilidades conocidas en las dependencias
Orientación práctica para auditores
- Ningún control por sí solo es suficiente: las organizaciones deberían demostrar un enfoque por capas
- SAST y SCA son fundamentales: deberían estar presentes en todo pipeline de CI/CD maduro
- DAST añade validación en tiempo de ejecución, pero no debería ser el único control de pruebas
- La aplicación en CI/CD importa más que la profundidad del escaneo: un control que se ejecuta pero no actúa como puerta es débil
- La calidad de la evidencia importa más que el recuento de vulnerabilidades: busque trazabilidad, retención y gobernanza
Los pipelines más auditables utilizan:
SAST + SCA aplicados por defecto, DAST en puntos de control definidos, con todos los resultados conservados y trazables.
Mapeo de herramientas → controles
La comparación anterior se centra en lo que SAST, DAST y SCA logran como controles individuales. En un pipeline real, esos controles de pruebas conviven con un conjunto más amplio de categorías de herramientas, y los auditores no evalúan ninguno de forma aislada: evalúan qué controles se aplican, dónde y con qué coherencia. Una herramienta de seguridad solo tiene valor de auditoría cuando aplica un control concreto y genera evidencia fiable. El mapeo siguiente muestra cómo cada categoría de herramientas de seguridad de CI/CD respalda los controles fundamentales que se esperan en entornos empresariales y regulados, y qué evidencia debería producir cada una.
Por qué importa el mapeo de herramienta a control
Sin un mapeo claro:
- las herramientas se convierten en «seguridad de casilla marcada»
- los controles se quedan en algo teórico
- la evidencia de auditoría queda fragmentada
- la responsabilidad no queda clara
Los auditores suelen preguntar:
¿Qué control aplica esta herramienta y dónde está la evidencia?
Esta sección responde a esa pregunta.
Las principales categorías de herramientas de seguridad de CI/CD se mapean con los controles fundamentales del siguiente modo. Para cada categoría, las preguntas relevantes para un auditor son las mismas: ¿qué control aplica esta herramienta y dónde está la evidencia?
1. Herramientas de seguridad del código fuente y de los repositorios
Herramientas habituales
- Funciones de seguridad de la plataforma Git
- Protección de ramas
- Detección de secretos
Controles aplicados
- Gestión de identidades y accesos
- Gestión de cambios y aprobaciones
- Segregación de funciones
- Trazabilidad de los cambios
Evidencia de auditoría
- historial de commits
- aprobaciones de pull requests
- reglas de protección de ramas
- registros de acceso
2. Funciones de seguridad nativas de la plataforma de CI/CD
Herramientas habituales
- RBAC de la plataforma de CI/CD
- Puertas de aprobación
- Protección de entornos
Controles aplicados
- Uso obligatorio de CI/CD
- Gestión de cambios y aprobaciones
- Segregación de funciones
Evidencia de auditoría
- registros de ejecución del pipeline
- registros de aprobación
- historial de despliegues
3. Herramientas de gestión y detección de secretos
Herramientas habituales
- Escáneres de secretos
- Bóvedas (vaults) / gestores de secretos en la nube
Controles aplicados
- Protección de secretos
- Gestión de identidades y accesos
Evidencia de auditoría
- registros de acceso a secretos
- historial de rotación
- ausencia de secretos en el código
4. Pruebas estáticas de seguridad de aplicaciones (SAST)
Herramientas habituales
- Motores de análisis de código
- Escáneres basados en políticas
Controles aplicados
- Pruebas de seguridad automatizadas
- Aplicación de un SDLC seguro
Evidencia de auditoría
- informes de escaneo
- decisiones de política
- compilaciones bloqueadas
5. Análisis de composición de software (SCA)
Herramientas habituales
- Escáneres de dependencias
- Herramientas de cumplimiento de licencias
Controles aplicados
- Riesgo de la cadena de suministro y de terceros
- Pruebas de seguridad automatizadas
Evidencia de auditoría
- inventarios de dependencias
- informes de vulnerabilidades
- SBOM
6. Herramientas de integridad de compilación y seguridad de artefactos
Herramientas habituales
- Firma de artefactos
- Herramientas de procedencia y atestación
- Registros inmutables
Controles aplicados
- Integridad y procedencia de los artefactos
- Mitigación del riesgo de la cadena de suministro
Evidencia de auditoría
- artefactos firmados
- SBOM
- atestaciones de procedencia
7. Pruebas dinámicas de seguridad de aplicaciones (DAST)
Herramientas habituales
- Escáneres de vulnerabilidades web/API
Controles aplicados
- Pruebas de seguridad automatizadas
- Validación en tiempo de ejecución
Evidencia de auditoría
- registros de ejecución de escaneos
- informes de vulnerabilidades
- decisiones de la puerta de publicación
8. Herramientas de registro, monitorización y evidencia
Herramientas habituales
- Plataformas de agregación de registros
- SIEM
- Sistemas de monitorización y alertas
Controles aplicados
- Registro y retención de evidencias
- Detección y respuesta ante incidentes
Evidencia de auditoría
- registros centralizados
- alertas
- registros de incidentes
9. Herramientas de gobernanza de terceros y de la cadena de suministro
Herramientas habituales
- Plataformas de gestión del riesgo de proveedores
- Sistemas de seguimiento de dependencias
Controles aplicados
- Riesgo de la cadena de suministro y de terceros
- Gobernanza y supervisión
Evidencia de auditoría
- inventarios de proveedores
- evaluaciones de riesgo
- controles contractuales
Herramientas → controles de un vistazo
| Categoría de herramienta | Controles clave aplicados |
|---|---|
| Seguridad de repositorios | IAM, gestión de cambios, segregación de funciones |
| Plataforma de CI/CD | Pipeline obligatorio, aprobaciones |
| Herramientas de secretos | Protección de secretos, IAM |
| SAST | SDLC seguro, pruebas automatizadas |
| SCA | Riesgo de la cadena de suministro, pruebas |
| Seguridad de artefactos | Integridad, procedencia |
| DAST | Pruebas de seguridad en tiempo de ejecución |
| Registro y SIEM | Evidencia, respuesta ante incidentes |
| Gobernanza de proveedores | Riesgo de terceros |
Cómo usan los auditores este mapeo
Los auditores normalmente:
- parten de un control
- preguntan qué sistema lo aplica
- solicitan evidencia de ese sistema
Un mapeo claro:
- reduce el tiempo de auditoría
- evita la duplicación de evidencia
- refuerza la propiedad de los controles
Conclusión
SAST, DAST y SCA cumplen objetivos de control distintos pero complementarios dentro de los pipelines de CI/CD. Para los auditores, el valor de cada control no reside en sus capacidades de detección, sino en su aplicación, calidad de la evidencia, trazabilidad y alineación con las regulaciones aplicables.
Al evaluar los controles de pruebas de seguridad de CI/CD, céntrese en: ¿Se aplica el control? ¿Produce evidencia fiable? ¿Puede esa evidencia rastrearse hasta versiones específicas? ¿Y existe gobernanza para las excepciones y supresiones?
Relacionado para auditores
- Glosario de términos de seguridad y cumplimiento de CI/CD
- Arquitectura de doble cumplimiento explicada
- Cómo revisan realmente los auditores los pipelines de CI/CD
