CI/CD Artículo 28 Señales de Alerta — Lista de Verificación para Auditoría

por

Esta lista de verificación destaca las señales de alerta CI/CD más comunes bajo DORA Artículo 28.

Cada elemento representa una situación frecuentemente identificada durante las auditorías como un fallo de riesgo ICT de terceros.

Si uno o más elementos aplican, los auditores pueden clasificar la plataforma CI/CD o el proveedor como de alto riesgo o no conforme.

CI/CD Red Flags — DORA Article 28 (Third-Party Risk) Enterprise CI/CD diagram highlighting common DORA Article 28 third-party risk red flags: missing exit plan, shared runners, lack of sub-processor visibility, missing audit rights, and missing evidence retention. CI/CD Red Flags — DORA Article 28 Third-party risk failures auditors frequently flag in Git, CI/CD SaaS, runners, registries, and cloud runtime. CROSS-CUTTING (ARTICLE 28) Supplier governance Audit rights Exit strategy Evidence retention Git Hosting GitHub / GitLab SaaS No audit rights CI/CD SaaS Orchestrator No exit plan CI Runners Cloud execution Shared runners Registries Artifacts + images No retention Cloud Runtime Prod services No sub-processor view ENGINEER REMEDIATION HINTS Tested exit strategy (CI/CD) Dedicated / isolated runners Supplier + sub-processor map Centralized logs + retention Auditor rule: if controls cannot produce time-bound evidence on demand, they are treated as ineffective under Article 28. Focus areas: CI/CD platform scope, contractual auditability, runner isolation, sub-processor governance, and evidence retention.
Enterprise CI/CD diagram highlighting common DORA Article 28 third-party risk red flags: missing exit plan, shared runners, lack of sub-processor visibility, missing audit rights, and missing evidence retention.

Lista de Verificación de Señales de Alerta CI/CD de Terceros (Revisión Rápida)

Gobernanza y Estrategia de Salida

  • ⬜ Sin plan de salida documentado para las plataformas SaaS CI/CD
  • ⬜ El plan de salida existe pero nunca ha sido probado técnicamente
  • ⬜ Sin capacidad de exportar logs históricos y artefactos CI/CD
  • ⬜ Los pipelines no pueden ser redespliegados en una plataforma alternativa

Infraestructura CI/CD y Aislamiento

  • ⬜ Los trabajos CI se ejecutan en runners compartidos o multi-inquilino sin garantías claras de aislamiento
  • ⬜ Los mecanismos de aislamiento de runners están sin documentar o son desconocidos
  • ⬜ El entorno de ejecución CI está controlado completamente por el proveedor
  • ⬜ Los secretos están expuestos a contextos de ejecución de terceros

Visibilidad de Proveedores y Subprocesadores

  • ⬜ El proveedor SaaS CI/CD no está incluido en el inventario ICT de terceros
  • ⬜ Los subprocesadores (nube, runners, registros) no están identificados
  • ⬜ Sin clasificación de riesgo para los terceros relacionados con CI/CD
  • ⬜ La criticidad del proveedor no influye en los controles aplicados

Controles Contractuales y Legales

  • ⬜ Los contratos CI/CD no incluyen derechos de auditoría o inspección
  • ⬜ Los derechos de auditoría existen pero no son prácticamente exigibles
  • ⬜ Sin SLA contractual de notificación de incidentes
  • ⬜ Las cláusulas de salida y terminación son inexistentes o poco claras

Evidencias y Auditabilidad

  • ⬜ Los logs CI/CD se conservan durante un periodo corto o indefinido
  • ⬜ Los registros de aprobación y cambios no son trazables
  • ⬜ Los metadatos y la procedencia de los artefactos están ausentes
  • ⬜ La evidencia se recopila manualmente solo durante las auditorías

Gobernanza CI/CD y Aplicación de Políticas

  • ⬜ Sin puertas de aprobación para los cambios de pipeline
  • ⬜ Uso sin restricciones de plugins o acciones del marketplace
  • ⬜ Sin fijación de versiones ni revisión para los componentes CI/CD de terceros
  • ⬜ Los controles varían entre pipelines sin justificación

Lista de Verificación al Estilo Auditor (Sí / No)

Punto de ControlSíNo
Las plataformas CI/CD están incluidas en el inventario ICT de terceros⬜⬜
Los proveedores CI/CD están clasificados por riesgo⬜⬜
Existen estrategias de salida y son técnicamente viables⬜⬜
Los runners CI están aislados y controlados⬜⬜
Los subprocesadores están identificados y gobernados⬜⬜
Los derechos de auditoría están definidos contractualmente⬜⬜
Los SLAs de notificación de incidentes están establecidos⬜⬜
Los logs CI/CD se conservan y protegen⬜⬜
Las aprobaciones y puertas de política se aplican obligatoriamente⬜⬜
La evidencia puede producirse a demanda⬜⬜

Señales de Alerta Explicadas (Interpretación del Auditor)

Señal de AlertaPor qué le importa al AuditorControl Esperado
Sin plan de salidaRiesgo de dependencia del proveedorEstrategia de salida técnica probada
Runners compartidosRiesgo de confidencialidad e integridadRunners aislados o dedicados
Sin visibilidad de subprocesadoresExposición de riesgo ocultaMapeo completo de la cadena de suministro
Sin derechos de auditoríaSin verificación independienteCláusulas de auditoría exigibles
Sin retención de evidenciasLos controles no pueden demostrarseRetención automatizada de logs

Cómo Utilizan los Auditores esta Lista de Verificación

Los auditores no esperan riesgo cero.

Esperan:

  • que los riesgos estén identificados,
  • que los controles estén aplicados,
  • que la evidencia esté disponible y sea coherente.

Múltiples elementos sin marcar en la misma categoría suelen resultar en:

  • clasificación de alto riesgo,
  • planes de remediación,
  • auditorías de seguimiento.

Cómo Utilizar esta Lista de Verificación Internamente

Uso recomendado:

  • ejecutarla antes de una auditoría,
  • ejecutarla después de incorporar un nuevo proveedor CI/CD,
  • incluirla en las revisiones de riesgo de terceros,
  • vincularla a su Lista de Verificación de Seguridad CI/CD y al Paquete de Evidencias.

Contenido Relacionado

Contexto “audit-ready”

Contenido pensado para entornos regulados: controles antes que herramientas, enforcement en CI/CD y evidencia por diseño para auditorías.

Enfoque en trazabilidad, aprobaciones, gobernanza de excepciones y retención de evidencia de extremo a extremo.

Ver la metodología en la página About.