Los fallos del DORA Artículo 28 raramente provienen de políticas inexistentes.
Provienen de debilidades ocultas en pipelines CI/CD con alta dependencia de terceros que solo afloran durante auditorías o incidentes.
Los auditores buscan señales de alerta — indicios de que el riesgo ICT de terceros no está gestionado, no se aplica o no está respaldado por evidencias.
Las plataformas CI/CD son una fuente frecuente de estos hallazgos porque combinan servicios externos, ejecución privilegiada y automatización.
Este artículo destaca las señales de alerta más comunes del Artículo 28 relacionadas con los pipelines CI/CD, explica por qué son importantes y cómo las interpretan los auditores, y le ofrece una lista de verificación de auditoría para probar sus propios pipelines antes de una evaluación.
Por qué las Señales de Alerta CI/CD Importan bajo el Artículo 28
Bajo DORA, el riesgo de terceros no es teórico.
Los auditores evalúan si un fallo en un proveedor de terceros podría:
- interrumpir servicios críticos,
- comprometer la integridad del sistema,
- o impedir el cumplimiento de las obligaciones regulatorias.
Los pipelines CI/CD son a menudo puntos únicos de fallo en la entrega de software. Contienen credenciales privilegiadas, envían código a producción y dependen de una cadena de proveedores externos que la mayoría de las organizaciones nunca mapean por completo.
Las señales de alerta en este ámbito se tratan por tanto como hallazgos de alta gravedad. No se interpretan como brechas técnicas aisladas, sino como evidencia de que el riesgo ICT de terceros no se está gobernando al nivel que el Artículo 28 espera.
Señal de Alerta #1 — Sin Plan de Salida de Plataformas CI/CD SaaS
Lo que observan los auditores
Las organizaciones dependen en gran medida de las plataformas SaaS CI/CD pero no pueden demostrar:
- cómo migrar los pipelines,
- cómo recuperar logs históricos y artefactos,
- cómo mantener la continuidad si el proveedor deja de estar disponible.
Por qué es una señal de alerta
DORA Artículo 28 exige explícitamente estrategias de salida para los proveedores ICT de terceros críticos.
Un plan de salida que solo existe en papel — sin viabilidad técnica — se considera insuficiente.
Conclusión típica del auditor
«La organización está operativamente bloqueada en un proveedor ICT crítico.»
Cómo se ve lo correcto
Un plan de salida creíble nombra una plataforma alternativa, documenta cómo se reconstruirían allí los pipelines y los secretos, y se ha ensayado al menos una vez para que el tiempo de recuperación sea una cifra medida y no una suposición. Los logs y artefactos exportados se conservan en una ubicación que la organización controla, con independencia del proveedor.
Señal de Alerta #2 — Runners de CI Compartidos entre Inquilinos
Lo que observan los auditores
Los trabajos de CI se ejecutan en:
- runners compartidos,
- infraestructura multi-inquilino,
- con visibilidad limitada sobre los controles de aislamiento.
A menudo, las organizaciones no pueden explicar:
- cómo se aplica el aislamiento de los runners,
- quién controla el entorno de ejecución,
- si la fuga de datos está técnicamente prevenida.
Por qué es una señal de alerta
Los runners compartidos incrementan:
- el riesgo de confidencialidad,
- el riesgo de integridad,
- la exposición a movimiento lateral.
Bajo el Artículo 28, esto plantea interrogantes sobre la clasificación del riesgo del proveedor y la eficacia de los controles.
Cómo se ve lo correcto
Los pipelines críticos se ejecutan en runners dedicados o efímeros cuyo modelo de aislamiento está documentado y es atribuible a un propietario nombrado. La organización puede explicar, en lenguaje sencillo, qué separa una carga de trabajo de otra y cómo se verifica esa separación.
Señal de Alerta #3 — Sin Visibilidad sobre los Subprocesadores
Lo que observan los auditores
Las organizaciones:
- contratan con un proveedor CI/CD o Git primario,
- pero carecen de visibilidad sobre los subprocesadores (proveedores de nube, runners, registros, servicios de monitorización).
Los inventarios de proveedores suelen detenerse en el primer nivel.
Por qué es una señal de alerta
DORA Artículo 28 exige supervisión no solo de los proveedores directos, sino también de las cadenas de subcontratación críticas.
La falta de visibilidad sobre los subprocesadores indica:
- evaluación de riesgos incompleta,
- gobernanza insuficiente de proveedores.
Cómo se ve lo correcto
El inventario de proveedores se extiende más allá de la parte contratante hasta las regiones de nube, las flotas de runners, los registros y los servicios de monitorización que hay detrás. Los cambios materiales en esa cadena de subprocesadores se notifican a la organización y desencadenan una revisión en lugar de pasar desapercibidos.
Señal de Alerta #4 — Sin Derechos de Auditoría en los Contratos CI/CD
Lo que observan los auditores
Los contratos con proveedores CI/CD o Git SaaS:
- carecen de cláusulas de auditoría o inspección,
- o contienen derechos de auditoría prácticamente inutilizables.
En algunos casos, los equipos de ingeniería desconocen las limitaciones contractuales.
Por qué es una señal de alerta
Sin derechos de auditoría:
- los controles no pueden verificarse de forma independiente,
- la dependencia de las garantías del proveedor se vuelve inevitable.
Los auditores tratan esto como una brecha de cumplimiento estructural, no como una omisión procedimental.
Cómo se ve lo correcto
Los contratos otorgan derechos de auditoría o inspección que la organización puede ejercer realmente, o proporcionan un equivalente aceptado como auditorías conjuntas o informes de garantía independientes. Ingeniería y compras comparten una visión común de lo que el contrato permite, de modo que la dependencia técnica nunca supere el derecho contractual a verificarla.
Señal de Alerta #5 — Sin Retención de Evidencias para Actividades CI/CD
Lo que observan los auditores
Las plataformas CI/CD generan logs, aprobaciones y trazas de ejecución, pero:
- los logs se conservan durante periodos cortos,
- la evidencia se sobreescribe o es inaccesible,
- las políticas de retención están indefinidas.
La evidencia se recopila a menudo tras la notificación de la auditoría, no de forma continua.
Por qué es una señal de alerta
DORA Artículo 28 se basa en la evidencia.
Si la evidencia no puede producirse a demanda, los controles se consideran ineficaces.
Esta señal de alerta frecuentemente resulta en:
- observaciones de auditoría,
- planes de remediación,
- revisiones de seguimiento.
Cómo se ve lo correcto
Los logs, aprobaciones y trazas de ejecución se exportan a un almacén independiente y resistente a la manipulación, con un período de retención definido y alineado con las obligaciones de la organización. La evidencia se genera como subproducto de la ejecución del pipeline, de modo que ya está disponible cuando un auditor la solicita — no se ensambla en respuesta a la petición.
Señales de Alerta CI/CD Adicionales que los Auditores Identifican Habitualmente
- Uso sin restricciones de plugins del marketplace CI/CD
- Sin puertas de aprobación para los cambios de pipeline
- Secretos expuestos a contextos de ejecución de terceros
- Sin monitorización de la disponibilidad de la plataforma CI/CD
- Aplicación inconsistente de controles entre pipelines
Cada uno de estos puntos debilita la confianza en la gestión del riesgo de terceros.
Cómo Utilizan los Auditores las Señales de Alerta
Las señales de alerta raramente se evalúan de forma aislada.
Los auditores buscan patrones:
- múltiples señales de alerta en torno al mismo proveedor,
- brechas entre los contratos y la aplicación técnica,
- vínculos perdidos entre controles y evidencias.
Cuando emergen patrones, los auditores pueden:
- elevar la criticidad del proveedor,
- ampliar el alcance de la auditoría,
- solicitar remediación en plazos estrictos.
Cómo Abordar estas Señales de Alerta de Forma Proactiva
Las organizaciones que obtienen buenos resultados bajo el Artículo 28 habitualmente:
- delimitan explícitamente las plataformas CI/CD como terceros ICT,
- aplican controles mediante la configuración del pipeline,
- alinean los contratos con la realidad técnica,
- generan evidencia continua e inmutable.
Lo más importante, tratan la seguridad CI/CD como parte de la gobernanza del riesgo de terceros, no solo como herramientas DevOps.
Correspondencia entre las Señales de Alerta y las Obligaciones del Artículo 28
Cada señal de alerta anterior remite a una expectativa específica del DORA Artículo 28, y por eso los auditores les dan tanto peso.
La ausencia de un plan de salida remite al requisito de mantener estrategias de salida para los proveedores ICT críticos. Los runners compartidos y el aislamiento sin documentar remiten a la eficacia de los controles y a la clasificación precisa de la criticidad del proveedor. La falta de visibilidad de los subprocesadores remite a la supervisión de las cadenas de subcontratación, y la ausencia de derechos de auditoría a la capacidad de verificar los controles de forma independiente en lugar de por confianza. Una retención de evidencias deficiente socava todo el marco, porque un control que no puede demostrarse a demanda es, a efectos de auditoría, un control que no existe.
Vistas así, las señales de alerta no son cinco problemas técnicos inconexos. Son cinco maneras distintas en que se hace visible la misma brecha de gobernanza — la distancia entre lo que la organización cree que controla y lo que puede realmente demostrar.
Lista de Verificación de Auditoría para Señales de Alerta de Terceros en CI/CD
Las señales de alerta anteriores describen cómo aparecen los fallos individuales durante una evaluación. La lista de verificación siguiente los convierte en una revisión repetible que puede ejecutar antes de una auditoría, tras incorporar un nuevo proveedor CI/CD o durante una revisión periódica del riesgo de terceros.
Cada casilla marcada corresponde a una situación identificada con frecuencia como un fallo de riesgo ICT de terceros. Cuando uno o más elementos aplican, los auditores pueden clasificar la plataforma o el proveedor CI/CD como de alto riesgo o no conforme.
Gobernanza y Estrategia de Salida
- ⬜ Sin plan de salida documentado para las plataformas CI/CD SaaS
- ⬜ Existe un plan de salida pero nunca se ha probado técnicamente
- ⬜ Sin capacidad de exportar logs y artefactos históricos de CI/CD
- ⬜ Los pipelines no pueden redesplegarse en una plataforma alternativa
Infraestructura CI/CD y Aislamiento
- ⬜ Los trabajos de 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 se desconocen
- ⬜ El entorno de ejecución de CI está controlado por completo por el proveedor
- ⬜ Los secretos están expuestos a contextos de ejecución de terceros
Visibilidad de Proveedores y Subprocesadores
- ⬜ El proveedor CI/CD SaaS no está listado en el inventario de terceros ICT
- ⬜ 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
- ⬜ Existen derechos de auditoría pero no son exigibles en la práctica
- ⬜ Sin SLA contractual de notificación de incidentes
- ⬜ Las cláusulas de salida y terminación faltan o no están claras
Evidencia y Auditabilidad
- ⬜ Los logs CI/CD se conservan durante un período corto o indefinido
- ⬜ Los registros de aprobación y cambios no son trazables
- ⬜ Faltan los metadatos y la procedencia de los artefactos
- ⬜ 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 de los componentes CI/CD de terceros
- ⬜ Los controles varían entre pipelines sin justificación
Lista de Verificación Estilo Auditor (Sí / No)
| Punto de control | Sí | No |
|---|---|---|
| Las plataformas CI/CD están incluidas en el inventario de terceros ICT | ⬜ | ⬜ |
| Los proveedores CI/CD están clasificados por riesgo | ⬜ | ⬜ |
| Existen estrategias de salida y son técnicamente viables | ⬜ | ⬜ |
| Los runners de CI están aislados y controlados | ⬜ | ⬜ |
| Los subprocesadores están identificados y gobernados | ⬜ | ⬜ |
| Los derechos de auditoría están definidos contractualmente | ⬜ | ⬜ |
| Existen SLA de notificación de incidentes | ⬜ | ⬜ |
| Los logs CI/CD se conservan y protegen | ⬜ | ⬜ |
| Se aplican las aprobaciones y las puertas de política | ⬜ | ⬜ |
| La evidencia puede producirse a demanda | ⬜ | ⬜ |
Señales de Alerta Explicadas (Interpretación de Auditoría)
| Señal de Alerta | Por qué Preocupa a los Auditores | Control Esperado |
|---|---|---|
| Sin plan de salida | Riesgo de dependencia del proveedor | Estrategia de salida técnica probada |
| Runners compartidos | Riesgo de confidencialidad e integridad | Runners aislados o dedicados |
| Sin visibilidad de subprocesadores | Exposición a riesgo oculto | Mapeo completo de la cadena de suministro |
| Sin derechos de auditoría | Sin verificación independiente | Cláusulas de auditoría exigibles |
| Sin retención de evidencias | Los controles no pueden demostrarse | Retención automatizada de logs |
Cómo Utilizar esta Lista de Verificación
Los auditores no esperan riesgo cero. Esperan que los riesgos estén identificados, que los controles se apliquen y que la evidencia esté disponible y sea consistente.
Múltiples elementos sin marcar en la misma categoría a menudo dan lugar a una clasificación de alto riesgo, un plan de remediación y auditorías de seguimiento. Usada internamente, la lista de verificación funciona mejor cuando usted:
- la ejecuta antes de una auditoría,
- la ejecuta tras incorporar un nuevo proveedor CI/CD,
- la incluye en las revisiones de riesgo de terceros,
- la vincula a su Lista de Verificación de Seguridad CI/CD y su Paquete de Evidencias.
Conclusión Clave
Los pipelines CI/CD son de las fuentes más comunes de hallazgos de auditoría del Artículo 28.
Señales de alerta como:
- falta de estrategias de salida,
- aislamiento deficiente,
- ausencia de derechos de auditoría,
- retención insuficiente de evidencias
indican un riesgo de terceros no gestionado.
Recorrer la lista de verificación anterior a tiempo — y cerrar las brechas que revela — transforma los pipelines CI/CD de pasivos de auditoría en activos sólidos de cumplimiento.
Contenido Relacionado
- Third-Party Risk in CI/CD Pipelines under DORA Article 28
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
- CI/CD Audit Red Flags
- CI/CD Security Checklist for Enterprises
