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 | ☐ | ☐ |
La Versión del Auditor Estricto
La lista de verificación anterior refleja una base sólida. Un auditor exigente —particularmente bajo DORA, NIS2, o una evaluación rigurosa de ISO 27001 o SOC 2— va más allá: cada control debe llevar un propietario nombrado, una referencia de evidencia específica y una decisión documentada al final de la revisión. Esta hoja de trabajo más estricta reorganiza las mismas expectativas en un formato de evaluación que un auditor puede completar en la sala, registrando una referencia de evidencia en cada línea en lugar de aceptar una garantía verbal.
Utilice la columna de Referencia de Evidencia para señalar el artefacto exacto —una exportación de registros, una captura de pantalla de configuración, una cláusula contractual firmada o un ticket— que demuestra el control. Una referencia en blanco se trata como una brecha, no como una aprobación.
Sección A — Gobernanza e Inventario
Un auditor estricto comienza confirmando que la población de proveedores es plenamente conocida y tiene propietarios asignados. Las brechas aquí socavan todos los controles posteriores, porque un proveedor que no ha inventariado no puede ser gobernado, monitorizado ni sujeto a salida.
| Control | Sí | No | Referencia de Evidencia |
|---|---|---|---|
| Existe un inventario completo de proveedores relacionados con CI/CD | ☐ | ☐ | |
| Clasificación de criticidad del proveedor definida | ☐ | ☐ | |
| Propietario de negocio asignado formalmente | ☐ | ☐ | |
| Propietario técnico asignado formalmente | ☐ | ☐ | |
| Evaluación de riesgos anual realizada | ☐ | ☐ | |
| Lista de subprocesadores documentada | ☐ | ☐ |
Sección B — Controles Contractuales y Regulatorios
Más allá de las medidas técnicas, el contrato debe otorgarle derechos exigibles. El auditor verifica que las obligaciones de garantía, notificación de brechas, ubicación de datos y salida estén redactadas en el acuerdo en lugar de asumirse a partir del marketing de un proveedor.
| Control | Sí | No | Referencia de Evidencia |
|---|---|---|---|
| Obligaciones de seguridad incluidas en el contrato | ☐ | ☐ | |
| SLA de notificación de incidentes definido | ☐ | ☐ | |
| Cláusula de derechos de auditoría presente | ☐ | ☐ | |
| Transparencia de ubicación de datos incluida | ☐ | ☐ | |
| Cláusula de estrategia de salida definida contractualmente | ☐ | ☐ |
Sección C — Aplicación Técnica en CI/CD
Aquí el auditor comprueba que la gobernanza se aplica realmente en el pipeline, no que esté meramente documentada. Se espera que cada control sea demostrable en la configuración en vivo.
| Control | Sí | No | Referencia de Evidencia |
|---|---|---|---|
| SSO aplicado en cuentas de administración CI/CD | ☐ | ☐ | |
| MFA obligatorio para roles privilegiados | ☐ | ☐ | |
| Acceso basado en roles con mínimo privilegio | ☐ | ☐ | |
| Ramas protegidas aplicadas | ☐ | ☐ | |
| Aprobaciones obligatorias de producción configuradas | ☐ | ☐ | |
| Las puertas de política bloquean hallazgos críticos | ☐ | ☐ | |
| Firma de artefactos aplicada | ☐ | ☐ | |
| Generación de SBOM automatizada | ☐ | ☐ | |
| Aislamiento de runners implementado | ☐ | ☐ |
Sección D — Evidencia y Retención
El auditor confirma que usted puede producir evidencia bajo demanda y que esta se conserva durante el tiempo suficiente para cubrir todo el período de revisión, con independencia de cualquier panel de un único proveedor.
| Control | Sí | No | Referencia de Evidencia |
|---|---|---|---|
| Registros CI/CD conservados según política | ☐ | ☐ | |
| Registros de aprobación exportables | ☐ | ☐ | |
| Resultados de análisis de seguridad archivados centralmente | ☐ | ☐ | |
| Trazabilidad completa commit → artefacto → prod | ☐ | ☐ | |
| Período de retención de evidencia documentado | ☐ | ☐ |
Sección E — Estrategia de Salida y Pruebas DR
Por último, el auditor busca pruebas de que la dependencia del proveedor ha sido probada, no solo planificada: rutas de exportación y migración que realmente se han ejercitado y evidenciado.
| Control | Sí | No | Referencia de Evidencia |
|---|---|---|---|
| Existe un plan de salida documentado | ☐ | ☐ | |
| Exportación de código probada | ☐ | ☐ | |
| Exportación de configuración del pipeline probada | ☐ | ☐ | |
| Exportación de artefactos probada | ☐ | ☐ | |
| Ejercicio de DR / migración realizado | ☐ | ☐ |
Bloque de Decisión del Auditor
Una revisión exigente se cierra con una decisión documentada en lugar de una lista abierta de observaciones. Registrar estas cuatro líneas convierte la hoja de trabajo en una conclusión de auditoría defendible:
- Calificación de riesgo global: ___
- Hallazgos críticos: ___
- Remediación requerida antes de: ___
- Fecha de auditoría de seguimiento: ___
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.
