El Artículo 28 de DORA exige a las entidades financieras gestionar los riesgos introducidos por los proveedores terceros de servicios ICT.
En la entrega de software moderna, los pipelines CI/CD se encuentran entre los sistemas más dependientes de terceros de la organización.
Las plataformas Git, los runners de CI, los plugins y los registros de artefactos no son meras decisiones de herramientas: son servicios externos integrados que influyen directamente en la integridad, la disponibilidad y la resiliencia operativa del software.
Este artículo se centra específicamente en el riesgo de terceros dentro de los pipelines CI/CD, explicando dónde surgen estos riesgos, cómo se aplica el Artículo 28 de DORA y qué controles esperan ver aplicados los auditores.
Por qué los pipelines CI/CD son un punto de concentración de riesgo de terceros
Los pipelines CI/CD agregan múltiples dependencias externas en un único flujo de ejecución:
- el código fuente se aloja externamente,
- las compilaciones suelen ejecutarse en infraestructura compartida o gestionada,
- el código de terceros se descarga automáticamente,
- los artefactos se almacenan y distribuyen mediante servicios externos.
Desde la perspectiva de DORA, los pipelines CI/CD representan:
- dependencias ICT de alto impacto,
- con acceso privilegiado,
- que operan a velocidad de máquina,
- y capaces de propagar fallos o compromisos directamente a producción.
En consecuencia, las plataformas CI/CD deben tratarse como servicios ICT de terceros dentro del alcance del Artículo 28.
GitHub / GitLab SaaS como proveedores terceros de ICT
Exposición al riesgo
Las plataformas SaaS de GitHub y GitLab controlan:
- el acceso al código fuente,
- los flujos de aprobación de cambios,
- la aplicación de identidad y permisos.
Un compromiso o una configuración incorrecta pueden provocar:
- cambios de código no autorizados,
- aprobaciones eludidas,
- pérdida de trazabilidad.
Expectativas del Artículo 28
Los auditores esperan:
- las plataformas de hosting Git incluidas en el inventario de terceros,
- una clasificación de riesgo clara (a menudo crítica),
- la aplicación de la segregación de funciones,
- evidencia de control de acceso y aprobaciones.
Los logs de acceso, las aprobaciones de pull requests y la configuración de protección de ramas se tratan como evidencia de auditoría, no como detalles operativos.
Runners de CI basados en cloud
Exposición al riesgo
Los runners de CI gestionados o alojados en cloud:
- ejecutan código no confiable,
- acceden a secretos y credenciales,
- interactúan con sistemas internos y externos.
A menudo se ejecutan en infraestructura compartida, lo que aumenta la exposición.
Expectativas del Artículo 28
Bajo el Artículo 28, las organizaciones deben demostrar:
- aislamiento entre runners,
- acceso controlado a los secretos,
- monitorización de los entornos de ejecución,
- capacidad de restringir o revocar el acceso de los runners.
Los auditores preguntan con frecuencia:
«¿Quién controla el entorno de ejecución donde se compila tu código?»
Acciones y plugins de marketplace
Exposición al riesgo
Los marketplaces de CI/CD introducen código de terceros sin verificar directamente en los pipelines.
Los riesgos incluyen:
- ataques a la cadena de suministro,
- actualizaciones maliciosas,
- falta de control de versiones,
- titularidad poco clara.
Expectativas del Artículo 28
Los auditores esperan:
- gobernanza sobre qué plugins están permitidos,
- evaluación de riesgo para las acciones críticas,
- fijación de versiones y procesos de revisión,
- monitorización de los cambios a lo largo del tiempo.
El uso sin restricciones del marketplace suele señalarse como una debilidad importante del Artículo 28.
Registros de artefactos
Exposición al riesgo
Los registros de artefactos almacenan y distribuyen:
- salidas de compilación,
- imágenes de contenedor,
- bibliotecas internas.
Si se ven comprometidos, pueden:
- propagar artefactos maliciosos,
- romper la integridad del despliegue,
- afectar a múltiples sistemas de forma simultánea.
Expectativas del Artículo 28
Los auditores esperan controles que cubran:
- restricciones de acceso,
- políticas de inmutabilidad,
- firma y verificación de artefactos,
- retención de metadatos de artefactos.
Los registros de artefactos se tratan como componentes centrales de la cadena de suministro, no como almacenamiento pasivo.
Proxies de dependencias y repositorios externos
Exposición al riesgo
Los proxies de dependencias y los repositorios externos:
- descargan código desde fuera de la organización,
- introducen dependencias indirectas de terceros,
- pueden cambiar su contenido sin previo aviso.
Esto genera una exposición oculta a terceros.
Expectativas del Artículo 28
Los auditores esperan:
- visibilidad sobre las fuentes de dependencias,
- controles para restringir o cachear dependencias externas,
- trazabilidad que vincule las dependencias con las compilaciones,
- monitorización de los cambios en las dependencias.
Los SBOM y los logs de dependencias se revisan a menudo como evidencia del Artículo 28.
Controles CI/CD fundamentales que se esperan bajo el Artículo 28
En todos los servicios de terceros relacionados con CI/CD, los auditores esperan ver:
- su inclusión explícita en los inventarios de terceros,
- clasificación y gobernanza basadas en el riesgo,
- aislamiento de acceso y mínimo privilegio,
- políticas aplicables (aprobaciones, gates),
- monitorización continua,
- generación automatizada de evidencia.
Los pipelines CI/CD deben aplicar estos controles por diseño, no mediante procedimientos manuales.
Evidencia que los auditores solicitan habitualmente
Para el riesgo de terceros en CI/CD, los auditores solicitan con frecuencia:
- logs de acceso de las plataformas Git,
- logs de ejecución de CI y metadatos de runners,
- registros de aprobación y resultados de los gates de política,
- datos de firma y procedencia de artefactos,
- alertas de monitorización que involucren servicios CI/CD.
Estos artefactos se utilizan para validar que los controles están operando, no solo definidos.
Relación con otros controles del Artículo 28 de DORA
Los pipelines CI/CD suelen actuar como la capa de aplicación de:
- requisitos contractuales,
- políticas de seguridad,
- restricciones de la estrategia de salida.
Conectan los dominios legal, de seguridad y de ingeniería, lo que los hace centrales para el cumplimiento del Artículo 28.
Conclusión clave
Bajo el Artículo 28 de DORA, los pipelines CI/CD no son herramientas de automatización neutrales.
Son puntos de integración de terceros ICT de alto riesgo.
Las organizaciones que:
- gobiernan explícitamente los servicios de terceros de CI/CD,
- aplican controles dentro de los pipelines,
- y generan evidencia continua
están significativamente mejor posicionadas para superar las auditorías del Artículo 28 y gestionar el riesgo operativo real.
Contenido relacionado
- DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
- DORA Article 28 Evidence Pack — What to Show Auditors
- CI/CD Security Checklist for Enterprises
- CI/CD Audit Red Flags
