Controles de Riesgo ICT de Terceros para Pipelines CI/CD Regulados
Por qué existe esta lista de verificación
En entornos regulados, los proveedores no son «externos». Son parte de su sistema de entrega.
Cuando servicios de terceros soportan su SDLC (alojamiento Git, CI/CD SaaS, registros de artefactos, tiempo de ejecución en la nube, analizadores de seguridad), los auditores esperan que demuestre:
- Gobernanza de proveedores (inventario, clasificación, contratos, planes de salida)
- Controles técnicos CI/CD (aislamiento de acceso, aplicación de políticas, retención de evidencia)
- Monitorización continua y responsabilidad (subprocesadores, SLAs, incidentes)
Esta lista de verificación está diseñada para ser utilizada por equipos de seguridad, ingeniería, riesgo y auditoría como referencia de control compartida.
Alcance: proveedores que típicamente afectan a CI/CD
Utilice esta lista de verificación para cualquier proveedor que proporcione:
- Alojamiento Git (GitHub/GitLab SaaS)
- Plataforma CI/CD (GitHub Actions, GitLab CI SaaS, CircleCI, etc.)
- Runners (runners alojados / compartidos / en la nube)
- Registros de artefactos (registros de contenedores / Maven / binarios)
- Proxies y mirrors de dependencias
- Tiempo de ejecución en la nube / Kubernetes gestionado / PaaS
- Herramientas de seguridad SaaS (SAST/DAST/SCA, análisis de secretos)
- Observabilidad y logging SaaS (SIEM / monitorización)
1) Inventario de proveedores y propiedad
✅ Lista de verificación
- Existe un inventario completo de proveedores utilizados en SDLC/CI/CD (incluido el uso no declarado).
- Cada proveedor tiene un propietario de negocio y un propietario técnico nombrados.
- El inventario recoge dónde se sitúa el proveedor (Git, CI, registro, tiempo de ejecución, logging).
- La criticidad está definida por proveedor (impacto si no está disponible/comprometido).
- Las ubicaciones de datos del proveedor y el modelo de alojamiento están documentados (UE/EE.UU., multirregión, etc.).
- Las rutas de acceso de terceros a sus sistemas están listadas (SSO, tokens API, agentes, webhooks).
Ejemplos de evidencia
- Hoja de cálculo de inventario de proveedores / entrada CMDB
- Mapa de arquitectura que muestra los puntos de contacto del proveedor
- Registro de propiedad (RACI)
2) Clasificación de riesgo del proveedor
✅ Lista de verificación
- Existe una clasificación de riesgo formal (Crítico / Alto / Medio / Bajo).
- La calificación de riesgo incluye confidencialidad, integridad, disponibilidad e impacto regulatorio.
- Los proveedores de CI/CD y artefactos se tratan como críticos para la integridad por defecto.
- La calificación de riesgo impulsa los requisitos de control obligatorios (p. ej., mayor logging, plan de salida).
- La calificación de riesgo se revisa al menos anualmente o ante cambios importantes.
Ejemplos de evidencia
- Informe / cuestionario de evaluación de riesgos
- Metodología de riesgo de terceros
- Marcas de tiempo de revisión y aprobaciones
3) Base contractual (seguridad + auditabilidad)
✅ Lista de verificación
- El contrato incluye obligaciones de seguridad (controles de base, gestión de vulnerabilidades, cifrado).
- El contrato incluye derechos de auditoría o mecanismo de garantía equivalente.
- El contrato incluye plazos de notificación de brechas/incidentes (incluidos criterios de materialidad).
- El contrato incluye obligaciones de divulgación de subprocesadores.
- El contrato incluye requisitos de retención y eliminación de datos.
- El contrato incluye expectativas de continuidad del servicio (BCP/DR).
- El contrato incluye condiciones de salida/transición (exportación de datos, soporte de migración).
Ejemplos de evidencia
- Cláusulas contractuales firmadas (anexo de seguridad)
- Registro de subprocesadores
- Cláusula de SLA de notificación de incidentes
4) Identidad, acceso y aislamiento (aplicación técnica)
✅ Lista de verificación
- SSO aplicado en consolas de administración de proveedores donde sea posible.
- MFA obligatorio para cuentas privilegiadas.
- Los roles son mínimos y están mapeados a las necesidades del puesto (mínimo privilegio).
- Las revisiones de acceso se realizan regularmente (trimestralmente para proveedores críticos).
- Los runners CI/CD están aislados (sin runners compartidos para cargas de trabajo sensibles).
- Los secretos no se almacenan en interfaces de proveedor a menos que estén controlados (usar vault/inyección).
- Los tokens de terceros tienen alcance limitado, se rotan y se monitorizan.
Ejemplos de evidencia
- Exportaciones / capturas de pantalla de políticas IAM
- Registros de revisión de acceso
- Configuración del runner que muestra el aislamiento
- Política de rotación de tokens + prueba
5) Aplicación de política del pipeline (puertas que no pueden eludirse)
✅ Lista de verificación
- Existen aprobaciones obligatorias para despliegues a producción.
- Las puertas de política bloquean lanzamientos ante fallos críticos de análisis (SAST/SCA/DAST según aplique).
- La firma de artefactos se aplica antes de la promoción del lanzamiento.
- La generación de SBOM está automatizada para los lanzamientos.
- Las ramas protegidas / reglas de fusión se aplican en repositorios regulados.
- Las excepciones se gobiernan (con límite de tiempo, aprobadas, documentadas).
- Los administradores de pipeline no pueden deshabilitar controles silenciosamente (cambios rastreados).
Ejemplos de evidencia
- Configuración del pipeline CI/CD (puertas)
- Configuración de rama protegida
- Registros de aprobación de lanzamiento
- Registro de excepciones
6) Generación y retención de evidencia (diseñado para auditoría)
✅ Lista de verificación
- Los registros CI/CD se conservan durante un período definido alineado con los requisitos.
- Los eventos de aprobación se registran y son exportables.
- Los resultados de análisis de seguridad se almacenan centralmente (no solo en paneles del proveedor).
- Existe trazabilidad: commit → ejecución del pipeline → artefacto → despliegue → producción.
- El almacén de evidencia es resistente a la manipulación o de acceso controlado.
- Las exportaciones de auditoría se prueban (capacidad de producir evidencia rápidamente).
Ejemplos de evidencia
- Política de retención de evidencia
- Configuración de retención SIEM / configuración de archivado
- Informe de trazabilidad (lanzamiento de muestra)
- Registro de prueba de exportación («simulacro de auditoría»)
7) Monitorización, incidentes y responsabilidad del proveedor
✅ Lista de verificación
- El proveedor proporciona notificaciones de incidentes de seguridad dentro del SLA definido.
- Se monitoriza el estado/disponibilidad del proveedor y se integran las señales en los flujos de trabajo operativos.
- Se monitorizan las anomalías del pipeline CI/CD (flujos de trabajo inesperados, nuevos tokens, nuevos runners).
- Se rastrean y evalúan los avisos de seguridad del proveedor.
- Se mantiene un playbook interno de incidentes que referencia las rutas de escalada del proveedor.
- Se pueden correlacionar los eventos del pipeline y del proveedor (línea de tiempo compartida).
Ejemplos de evidencia
- Paneles de monitorización + reglas de alerta
- Plan de respuesta a incidentes con contactos del proveedor
- Postmortems que hacen referencia a la participación del proveedor
- Tickets de seguimiento de avisos
8) Visibilidad de subprocesadores (profundidad de la cadena de suministro)
✅ Lista de verificación
- El proveedor proporciona una lista actualizada de subprocesadores.
- Los cambios en los subprocesadores se notifican y revisan.
- Los subprocesadores críticos se evalúan en cuanto al riesgo.
- Se comprenden los flujos de datos que involucran subprocesadores.
- Los contratos incluyen obligaciones de subprocesadores (seguridad y notificación).
Ejemplos de evidencia
- Exportación de lista de subprocesadores
- Registro de revisión de riesgo
- Diagramas de flujo de datos
9) Prueba de estrategia de salida (realismo DR y BCP)
✅ Lista de verificación
- Existe un plan de salida documentado para cada proveedor CI/CD crítico.
- Se puede exportar código fuente, definiciones de pipeline, artefactos, registros.
- Existe una ruta de migración probada (CI/CD alternativo, registro, modelo de runner).
- Se realizan pruebas de salida (ejercicios de mesa + simulacros técnicos) en intervalos definidos.
- Las expectativas de RTO/RPO están documentadas y validadas con evidencia.
Ejemplos de evidencia
- Documento del plan de salida
- Registros y capturas de pantalla de prueba de exportación
- Informe del ejercicio DR
- Prueba de concepto de migración
Tabla de Auditoría (Sí / No / Notas)
| Área de Control | Verificación | Sí | No | Notas / Enlace de Evidencia |
|---|---|---|---|---|
| Inventario | Inventario de proveedores completo (SDLC/CI/CD) | ☐ | ☐ | |
| Propiedad | Propietario de negocio + técnico definido | ☐ | ☐ | |
| Clasificación | Clasificación de riesgo aplicada a proveedores CI/CD | ☐ | ☐ | |
| Contratos | Obligaciones de seguridad en contrato | ☐ | ☐ | |
| Contratos | Derechos de auditoría / mecanismo de garantía | ☐ | ☐ | |
| Contratos | SLA de notificación de incidentes definido | ☐ | ☐ | |
| Contratos | Cláusulas de salida incluidas | ☐ | ☐ | |
| Acceso | SSO aplicado (donde sea posible) | ☐ | ☐ | |
| Acceso | MFA obligatorio para cuentas privilegiadas | ☐ | ☐ | |
| Acceso | Roles de mínimo privilegio aplicados | ☐ | ☐ | |
| Runners | Aislamiento de runners (sin runners compartidos) | ☐ | ☐ | |
| Secretos | Secretos inyectados en tiempo de ejecución (vault) | ☐ | ☐ | |
| Puertas de política | Aprobaciones obligatorias para producción | ☐ | ☐ | |
| Puertas de política | Puertas bloqueantes ante hallazgos críticos | ☐ | ☐ | |
| Integridad | Firma de artefactos aplicada | ☐ | ☐ | |
| Integridad | SBOM generado automáticamente | ☐ | ☐ | |
| Evidencia | Registros conservados según política | ☐ | ☐ | |
| Evidencia | Registros de aprobación exportables | ☐ | ☐ | |
| Evidencia | Trazabilidad commit→prod demostrada | ☐ | ☐ | |
| Monitorización | Anomalías del proveedor + pipeline monitorizadas | ☐ | ☐ | |
| Subprocesadores | Visibilidad + revisión de subprocesadores | ☐ | ☐ | |
| Prueba de salida | Plan de salida probado con evidencia | ☐ | ☐ |
Guía de Implementación Técnica
Esta lista de verificación define las expectativas de gobernanza.
Para una guía práctica de implementación de ingeniería (GitHub, GitLab, aislamiento de runners, puertas de política, firma de artefactos), consulte:
👉 Engineer Remediation Guide for CI/CD Supplier Controls
Este artículo complementario proporciona ejemplos concretos de configuración y patrones de implementación.
