Una Guía Orientada a la Gobernanza sobre las Categorías de Controles de Seguridad CI/CD para Auditores, Responsables de Cumplimiento y Reguladores
Los pipelines CI/CD son la columna vertebral de la entrega moderna de software. Para los auditores y responsables de cumplimiento, comprender los controles de seguridad integrados en estos pipelines es esencial para evaluar si una organización gestiona adecuadamente el riesgo de entrega de software.
Esta guía explica las principales categorías de controles de seguridad CI/CD, no como recomendaciones de productos, sino como dominios de gobernanza que los auditores deben comprender, verificar y evaluar durante las revisiones de cumplimiento.
Por Qué los Auditores Necesitan Comprender los Controles de Seguridad CI/CD
Los pipelines CI/CD modernos gestionan:
- acceso a repositorios de código fuente
- procesos automatizados de compilación y empaquetado
- integración con servicios y dependencias de terceros
- implementación en sistemas de producción
Cada una de estas etapas introduce riesgos. Los auditores deben ser capaces de verificar que existen controles de seguridad apropiados en cada etapa, que dichos controles se aplican de manera consistente (no solo están disponibles) y que producen evidencia fiable y conservada.
En entornos regulados, la pregunta no es qué herramientas están instaladas, sino si los controles correctos están activos, aplicados y auditables.
Categoría de Control 1: Seguridad del Código Fuente y Repositorios
Qué controla: Acceso al código fuente, autorización de cambios de código, prevención de modificaciones no autorizadas y detección de secretos confirmados en repositorios.
Qué evidencia produce: Registros de control de acceso, configuraciones de protección de ramas, registros de aprobación de pull requests y resultados de análisis de detección de secretos.
Qué deben verificar los auditores:
- Las reglas de protección de ramas se aplican (no solo se documentan)
- Todos los cambios de código requieren revisión y aprobación por pares antes de fusionarse
- El análisis de secretos se ejecuta automáticamente en cada commit o pull request
- El acceso a los repositorios sigue los principios de mínimo privilegio
- Los registros de auditoría de los cambios de código se conservan durante el período requerido
Señales de alerta:
- Commits directos a ramas principales sin revisión
- Reglas de protección de ramas que pueden ser anuladas por administradores
- Sin análisis de secretos, o análisis que se ejecuta solo bajo demanda
- Permisos de acceso al repositorio excesivamente amplios
Categoría de Control 2: Pruebas de Seguridad de Aplicaciones Estáticas (SAST)
SAST (Static Application Security Testing) es un control que analiza el código fuente para identificar vulnerabilidades de seguridad antes de que las aplicaciones se compilen o implementen. Opera durante las etapas de desarrollo y compilación.
Qué controla: Defectos de seguridad a nivel de código, patrones de codificación inseguros y cumplimiento de políticas del código personalizado.
Qué evidencia produce: Informes de análisis que muestran vulnerabilidades identificadas, clasificaciones de gravedad, decisiones de aprobación/rechazo de políticas y datos de tendencias a lo largo del tiempo.
Qué deben verificar los auditores:
- SAST se ejecuta automáticamente en cada compilación o pull request, no solo bajo demanda
- Existen umbrales de gravedad definidos que pueden bloquear compilaciones o implementaciones
- Los hallazgos suprimidos o aceptados tienen justificaciones documentadas y fechas de expiración
- Los resultados del análisis se conservan y vinculan a compilaciones y versiones específicas
- El alcance del análisis SAST cubre todas las bases de código de producción
Señales de alerta:
- SAST está configurado pero no se aplica: las compilaciones continúan independientemente de los hallazgos
- Gran número de hallazgos suprimidos sin justificación documentada
- Los resultados del análisis no se conservan o no pueden vincularse a versiones específicas
- La cobertura de SAST no incluye todas las aplicaciones de producción
Categoría de Control 3: Análisis de Composición de Software (SCA)
SCA (Software Composition Analysis) identifica riesgos en bibliotecas de terceros, componentes de código abierto y sus dependencias transitivas. Este control es fundamental para la gestión de riesgos de la cadena de suministro.
Qué controla: Vulnerabilidades conocidas en dependencias, cumplimiento de licencias y visibilidad de la cadena de suministro de software.
Qué evidencia produce: Inventarios de dependencias, Listas de Materiales de Software (SBOMs), informes de vulnerabilidades para componentes de terceros y registros de cumplimiento de licencias.
Qué deben verificar los auditores:
- SCA se ejecuta automáticamente durante las compilaciones y produce inventarios de dependencias actuales
- Las dependencias vulnerables conocidas activan respuestas definidas (bloqueo, alertas o aceptación documentada)
- Los SBOMs se generan y conservan para cada versión
- El cumplimiento de licencias se monitorea activamente
- Las políticas de dependencias definen qué es aceptable y qué requiere aprobación
Señales de alerta:
- No existe inventario de dependencias ni SBOM para aplicaciones de producción
- Las vulnerabilidades críticas conocidas en dependencias no se abordan ni se documentan
- El análisis SCA no está integrado en CI/CD: se ejecuta manualmente o no se ejecuta en absoluto
- Sin gobernanza sobre qué componentes de terceros pueden utilizarse
Categoría de Control 4: Gestión y Detección de Secretos
Los secretos, como claves API, credenciales, tokens y certificados, son objetivos de alto valor en entornos CI/CD. Esta categoría de control abarca tanto la detección de secretos expuestos como la gobernanza sobre cómo se almacenan, acceden y rotan los secretos.
Qué controla: Prevención de la exposición de credenciales en código y pipelines, acceso controlado a secretos, y procedimientos de rotación y revocación.
Qué evidencia produce: Resultados de análisis de secretos, registros de acceso a sistemas de almacenamiento de secretos, registros de rotación y registros de respuesta a incidentes por exposiciones detectadas.
Qué deben verificar los auditores:
- El análisis de secretos está automatizado y se ejecuta en cada cambio de código
- Se utiliza un sistema centralizado de gestión de secretos: los secretos nunca están codificados de forma fija
- El acceso a los secretos está basado en roles y registrado
- Existen políticas de rotación y se aplican
- Las exposiciones de secretos detectadas activan una respuesta a incidentes documentada
Señales de alerta:
- Secretos encontrados en código fuente, archivos de configuración o registros del pipeline
- Sin gestión centralizada de secretos: los equipos gestionan credenciales de forma independiente
- Sin política de rotación ni evidencia de rotación
- El análisis de secretos no se aplica o puede eludirse
Categoría de Control 5: Integridad de Compilación y Seguridad de Artefactos
Los controles de integridad de compilación garantizan que lo que se implementa coincide con lo que se probó y aprobó. Esto incluye la firma de artefactos, la verificación de integridad, el almacenamiento inmutable y el seguimiento de procedencia.
Qué controla: Prevención de manipulación de resultados de compilación, trazabilidad desde el código fuente hasta el artefacto implementado, y garantía de que los artefactos no han sido modificados tras las pruebas.
Qué evidencia produce: Artefactos firmados, atestaciones de procedencia, sumas de verificación de integridad y registros de repositorios de artefactos inmutables.
Qué deben verificar los auditores:
- Los artefactos están firmados y las firmas se verifican antes de la implementación
- El almacenamiento de artefactos es inmutable: los artefactos publicados anteriormente no pueden sobrescribirse
- Existen registros de procedencia que vinculan cada artefacto con su código fuente, compilación y resultados de pruebas
- Las comprobaciones de integridad se aplican en el momento de la implementación, no solo en el momento de la compilación
Señales de alerta:
- Los artefactos no están firmados o las firmas no se verifican
- Sin procedencia ni trazabilidad del artefacto al código fuente
- Los repositorios de artefactos permiten la sobrescritura de versiones existentes
- Manejo manual de artefactos fuera del pipeline
Categoría de Control 6: Pruebas de Seguridad de Aplicaciones Dinámicas (DAST)
DAST (Dynamic Application Security Testing) prueba las aplicaciones en ejecución interactuando con ellas externamente, simulando escenarios de ataque del mundo real. Valida la postura de seguridad en tiempo de ejecución, incluyendo los flujos de autenticación, el manejo de sesiones y las debilidades de configuración.
Qué controla: Vulnerabilidades en tiempo de ejecución, configuraciones de seguridad incorrectas y problemas de control de acceso en aplicaciones implementadas o en entornos de prueba.
Qué evidencia produce: Resultados del análisis que documentan los hallazgos en tiempo de ejecución, decisiones de control (aprobación/rechazo) y registros de las excepciones concedidas.
Qué deben verificar los auditores:
- DAST se ejecuta antes de los lanzamientos a producción, no solo bajo demanda
- Existen umbrales definidos que pueden bloquear o retrasar los lanzamientos en función de los hallazgos
- Las excepciones al control de DAST están documentadas con aprobaciones
- Los resultados de DAST se conservan y son trazables a versiones específicas
Señales de alerta:
- DAST se ejecuta solo ocasionalmente o en absoluto para aplicaciones críticas
- Sin lógica de control: todos los lanzamientos continúan independientemente de los hallazgos de DAST
- Los resultados de DAST no se conservan o no pueden vincularse a implementaciones específicas
- El alcance de DAST no cubre las aplicaciones orientadas al exterior
Categoría de Control 7: Registro, Monitoreo y Retención de Evidencias
Cada control en el pipeline CI/CD debe producir evidencia, y esa evidencia debe recopilarse, almacenarse y ponerse a disposición para la auditoría. Esta categoría abarca la agregación centralizada de registros, el monitoreo, las alertas y la retención de evidencias.
Qué controla: Visibilidad de las actividades del pipeline, detección de incidentes y disponibilidad de evidencias de auditoría.
Qué evidencia produce: Registros centralizados, paneles de monitoreo, historiales de alertas y registros conservados de todas las ejecuciones del pipeline y sus resultados.
Qué deben verificar los auditores:
- Los registros del pipeline se recopilan de forma centralizada y no pueden manipularse
- Los períodos de retención cumplen con los requisitos regulatorios
- El monitoreo cubre tanto los eventos de seguridad como el estado del pipeline
- Las evidencias de todos los controles de seguridad (SAST, SCA, DAST, secretos, integridad de artefactos) están agregadas y accesibles
Señales de alerta:
- Los registros se almacenan solo localmente en los agentes de compilación y no están centralizados
- Los períodos de retención son más cortos que los requisitos regulatorios
- Sin alertas sobre fallos del pipeline o elusión de controles de seguridad
- Las evidencias de los controles de seguridad no pueden recuperarse para una versión determinada
Resumen: Mapeo de Categorías de Control a Verificación de Auditoría
| Categoría de Control | Objetivo del Control | Evidencia Clave | Verificación de Auditoría |
|---|---|---|---|
| Seguridad del Código Fuente | Prevenir cambios de código no autorizados | Registros de acceso, aprobaciones de PR, configuraciones de protección de ramas | Verificar la aplicación de flujos de trabajo de revisión y aprobación |
| SAST | Detectar vulnerabilidades a nivel de código antes de la implementación | Informes de análisis, decisiones de control, registros de supresión | Confirmar la ejecución automatizada y la aplicación de umbrales |
| SCA | Gestionar el riesgo de terceros y de la cadena de suministro | Inventarios de dependencias, SBOMs, informes de vulnerabilidades | Verificar el inventario actual, la generación de SBOM y la respuesta a vulnerabilidades conocidas |
| Gestión de Secretos | Prevenir la exposición de credenciales y el acceso no autorizado | Resultados de análisis, registros de acceso, registros de rotación | Confirmar la ausencia de secretos codificados de forma fija, verificar la rotación y la gobernanza de acceso |
| Integridad de Compilación | Garantizar que los artefactos son confiables y trazables | Artefactos firmados, atestaciones de procedencia, sumas de verificación | Verificar la firma, la inmutabilidad y la trazabilidad desde el código fuente al artefacto |
| DAST | Validar la seguridad en tiempo de ejecución de las aplicaciones implementadas | Resultados del análisis, decisiones de control, registros de excepciones | Confirmar la ejecución pre-lanzamiento y el manejo documentado de excepciones |
| Registro y Evidencias | Proporcionar pista de auditoría y visibilidad de incidentes | Registros centralizados, registros de monitoreo, evidencias conservadas | Verificar períodos de retención, centralización y resistencia a manipulaciones |
Conclusión
Los controles de seguridad CI/CD no tienen que ver con qué productos implementa una organización. Se trata de si las categorías de control correctas están implementadas, si esos controles se aplican de manera consistente dentro del pipeline y si producen evidencia fiable que los auditores puedan verificar.
Al revisar la seguridad CI/CD, los auditores deben centrarse en la aplicación, la calidad de la evidencia, la trazabilidad y la gobernanza, no en nombres de productos o listas de características.
Recursos Relacionados para Auditores
- Glosario de Términos de Seguridad CI/CD y Cumplimiento Normativo
- Controles de Seguridad Fundamentales de CI/CD
- Cómo los Auditores Realmente Revisan los Pipelines CI/CD
- Cumplimiento Continuo a través de CI/CD
