Tema 17
Un pipeline CI/CD puede compilar código, acceder a secretos, publicar imágenes, modificar infraestructura y desplegar en producción. Por eso debe protegerse como una ruta privilegiada, no como una simple automatización técnica.
Los pipelines CI/CD automatizan build, pruebas, publicación y despliegue. Esa automatización acelera la entrega, pero también concentra permisos sensibles. Un pipeline comprometido puede modificar código, robar secretos, publicar artefactos maliciosos o desplegar cambios en producción.
La seguridad del pipeline debe tratar el flujo de entrega como una cadena de confianza: repositorio, configuración del pipeline, runners, secretos, artefactos, aprobaciones, entornos y registros.
El objetivo es que solo código autorizado, construido por procesos confiables y validado por controles definidos pueda avanzar hacia ambientes críticos.
Un pipeline puede ser atacado desde varias rutas: código malicioso, configuración alterada, credenciales filtradas, runners inseguros o artefactos reemplazados.
| Amenaza | Impacto | Control inicial |
|---|---|---|
| Modificación del workflow | Ejecutar pasos maliciosos o saltar controles | Protección de ramas y revisión obligatoria |
| Robo de secretos | Acceso a cloud, registries o producción | Secretos protegidos, OIDC y scopes mínimos |
| Runner comprometido | Manipulación de builds o exfiltración de credenciales | Runners efímeros, aislamiento y limpieza |
| Artefacto alterado | Despliegue de binario o imagen no confiable | Firmas, digest y promoción controlada |
| Despliegue no autorizado | Cambio directo en producción | Aprobaciones, ambientes protegidos y separación de roles |
Un pipeline debe tener solo los permisos necesarios para cada etapa. No es aceptable usar un token administrativo único para build, test, publicación y producción.
Buenas prácticas:
Un runner ejecuta los jobs del pipeline. Puede ser hospedado por el proveedor de CI/CD, autogestionado, compartido o dedicado. Su seguridad es crítica porque procesa código potencialmente no confiable.
| Tipo de runner | Ventaja | Riesgo |
|---|---|---|
| Hospedado | Menos mantenimiento operativo | Menor control sobre red y entorno |
| Autogestionado | Mayor control de red, herramientas y acceso | Responsabilidad de hardening, parches y aislamiento |
| Compartido | Optimiza costos | Riesgo de contaminación entre proyectos |
| Efímero | Reduce persistencia entre jobs | Requiere automatización madura |
Los runners deben ejecutarse con aislamiento y limpieza. Un runner persistente que ejecuta múltiples proyectos puede conservar credenciales, caches o artefactos de trabajos anteriores.
Controles recomendados:
Los secretos de CI/CD suelen tener acceso a registries, cloud, repositorios, firmas y despliegues. Deben estar protegidos por entorno, rama, aprobación y mínimo privilegio.
Buenas prácticas:
OIDC permite que un pipeline obtenga credenciales temporales desde un proveedor cloud sin almacenar access keys permanentes. El proveedor valida identidad del workflow, repositorio, rama, audiencia y condiciones.
Ventajas:
Los artefactos son resultados del pipeline: binarios, paquetes, imágenes, SBOM, reportes, manifiestos o bundles de despliegue. Deben protegerse contra modificación y pérdida de trazabilidad.
Controles recomendados:
Las aprobaciones agregan control humano donde el riesgo lo justifica. Deben usarse especialmente para producción, cambios de infraestructura crítica y excepciones de seguridad.
Una aprobación útil debe indicar:
Los entornos deben tener reglas distintas según criticidad. Desarrollo puede permitir más flexibilidad; producción requiere controles estrictos.
| Entorno | Control típico | Riesgo si se omite |
|---|---|---|
| Desarrollo | Secretos limitados y datos no sensibles | Exposición por experimentación |
| Staging | Controles similares a producción sin datos reales innecesarios | Validaciones poco representativas |
| Producción | Aprobaciones, roles específicos y auditoría fuerte | Despliegues no autorizados o irreversibles |
| Sandbox | Cuotas, aislamiento y limpieza automática | Costos, exposición o persistencia de recursos inseguros |
Los archivos que definen pipelines son código privilegiado. Cambiar un workflow puede modificar controles, exfiltrar secretos o alterar artefactos.
Controles recomendados:
Los caches aceleran builds, pero también pueden contaminar resultados si no se aíslan correctamente. Un cache manipulado puede introducir dependencias o artefactos no esperados.
Buenas prácticas:
Los logs del pipeline deben permitir investigar qué ocurrió sin exponer secretos. Deben conservar evidencia de ejecución, aprobación, artefactos y decisiones de seguridad.
Registrar:
La seguridad de CI/CD protege el camino por el que el software llega a producción. Runners, permisos, secretos, artefactos, entornos y aprobaciones deben diseñarse como controles críticos de la cadena de suministro.
En el próximo tema estudiaremos seguridad de la cadena de suministro: SCA, SBOM, SLSA, firmas y dependencias confiables.