La entrega de software moderna se apoya en pipelines de integración continua y entrega continua (CI/CD) para construir, probar y desplegar código a gran escala. Estos pipelines se han convertido en la columna vertebral de DevOps, permitiendo a las organizaciones distribuir funcionalidades más rápido y de forma más fiable que nunca. Pero este poder conlleva un compromiso crítico: los sistemas CI/CD se han convertido en una de las superficies de ataque más atractivas de los entornos empresariales.
A diferencia de la infraestructura tradicional, los pipelines CI/CD se sitúan en la intersección del código, las credenciales y los sistemas de producción. Un único pipeline comprometido puede dar a un atacante todo lo que necesita: acceso a los repositorios de código fuente, credenciales de la nube, claves de firma y la capacidad de publicar artefactos maliciosos directamente en producción. Esto no es una preocupación teórica. Los últimos cinco años han visto una escalada drástica de los ataques que apuntan a las cadenas de suministro de software a través de la infraestructura CI/CD, desde SolarWinds hasta XZ Utils.
Esta guía ofrece una taxonomía completa de las amenazas y ataques a CI/CD, los relaciona con marcos del sector como el OWASP CI/CD Top 10, repasa incidentes reales y esboza estrategias defensivas que puedes implementar hoy mismo. Tanto si eres un ingeniero de seguridad, un profesional de DevOps o el responsable de un equipo de plataforma, comprender estos vectores de ataque es el primer paso para construir pipelines resilientes.
Por qué los atacantes apuntan a los pipelines CI/CD
Para comprender el panorama de amenazas, necesitas pensar en los pipelines CI/CD como lo hace un atacante. Los pipelines no son solo automatización: son entornos de ejecución privilegiados con propiedades únicas que los convierten en objetivos extraordinariamente valiosos.
Acceso privilegiado a todo
Los pipelines CI/CD poseen habitualmente credenciales de proveedores de nube (AWS, GCP, Azure), container registries, repositorios de paquetes, bases de datos y clústeres de Kubernetes de producción. Un solo runner de pipeline suele tener más acceso que cualquier desarrollador individual. Los atacantes que comprometen un pipeline heredan al instante todos estos privilegios.
La automatización como arma
Los pipelines están diseñados para ejecutar código automáticamente en respuesta a triggers: un push a una rama, un pull request, un tag o un cron programado. Esta automatización, que es la razón de ser de CI/CD, se convierte en un arma cuando un atacante puede influir en lo que se ejecuta. A diferencia de un revisor humano, un pipeline ejecutará fielmente cualquier instrucción que se le dé, incluidas las maliciosas.
Suposiciones de confianza implícita
La mayoría de las arquitecturas CI/CD se construyen sobre una base de confianza implícita. Las organizaciones confían en que los archivos de configuración del pipeline no han sido manipulados. Confían en que las dependencias resueltas durante el build son legítimas. Confían en que las GitHub Actions de terceros o las plantillas de pipeline compartidas son seguras. Cada una de estas suposiciones de confianza representa un posible vector de ataque.
Postura de seguridad débil
Los sistemas CI/CD suelen existir en un punto ciego de seguridad. Los gestionan equipos de ingeniería en lugar de equipos de seguridad, carecen de la monitorización y el logging que reciben los sistemas de producción y acumulan deuda técnica en forma de configuraciones demasiado permisivas, credenciales obsoletas y runners sin parchear. Esto los convierte en objetivos fáciles en comparación con la infraestructura de producción fortalecida.
Amplificación por la cadena de suministro
Quizá el aspecto más peligroso de los ataques a CI/CD sea su potencial de amplificación. Comprometer un único pipeline que construye una biblioteca o servicio de uso extendido puede propagar código malicioso a miles o millones de consumidores downstream. Este efecto de amplificación en la cadena de suministro es lo que hace que incidentes como SolarWinds y XZ Utils sean tan devastadores.
Taxonomía de ataques CI/CD: relación con el OWASP CI/CD Top 10
El OWASP CI/CD Top 10 proporciona un marco estructurado para comprender los riesgos más críticos en los entornos CI/CD. Cada categoría de riesgo representa una clase de vectores de ataque que los adversarios explotan activamente. Así es como los principales tipos de ataque se relacionan con este marco:
| Riesgo OWASP CI/CD | Categoría de ataque | Preocupación principal |
|---|---|---|
| CICD-SEC-1 | Control de flujo insuficiente | Falta de aprobaciones, sin protección de ramas |
| CICD-SEC-2 | Gestión inadecuada de identidades y accesos | Service accounts demasiado permisivas |
| CICD-SEC-3 | Abuso de la cadena de dependencias | Confusión de dependencias, typosquatting |
| CICD-SEC-4 | Ejecución de pipeline envenenada | Configuración de pipeline maliciosa en PRs/ramas |
| CICD-SEC-5 | PBAC insuficiente | Controles de acceso basados en pipeline ausentes |
| CICD-SEC-6 | Higiene de credenciales insuficiente | Secretos hardcodeados, tokens sin rotar |
| CICD-SEC-7 | Configuración de sistema insegura | Configuraciones por defecto, servidores CI sin parchear |
| CICD-SEC-8 | Uso no gobernado de servicios de terceros | Actions comprometidas, integraciones sin evaluar |
| CICD-SEC-9 | Validación inadecuada de la integridad de artefactos | Artefactos sin firmar, mutación de tags |
| CICD-SEC-10 | Logging y visibilidad insuficientes | Sin traza de auditoría, puntos ciegos en la monitorización |
Para un análisis en profundidad de cada uno de estos riesgos con ejemplos reales, consulta nuestra guía detallada: Los 10 riesgos CI/CD del OWASP explicados con ejemplos reales.
Las secciones siguientes exploran en detalle las categorías de ataque más impactantes, examinando la mecánica, los ejemplos reales y las estrategias de detección de cada una.
Ejecución de pipeline envenenada (PPE)
La ejecución de pipeline envenenada (Poisoned Pipeline Execution, PPE) es una de las clases de ataques CI/CD más peligrosas y prevalentes. Se produce cuando un atacante manipula la configuración del pipeline CI/CD o las instrucciones de build para ejecutar código malicioso dentro del entorno del pipeline. El ataque aprovecha el hecho de que los pipelines ejecutan automáticamente las instrucciones definidas en los archivos de configuración, y esos archivos a menudo pueden ser modificados por los contribuidores.
PPE directa (D-PPE)
En la PPE directa, el atacante tiene acceso de escritura al repositorio y modifica directamente el archivo de configuración del pipeline (por ejemplo, .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile o azure-pipelines.yml). El atacante inyecta pasos maliciosos que se ejecutan con todos los privilegios del pipeline. Esto podría incluir la exfiltración de secretos, la inyección de backdoors en los artefactos de build o el establecimiento de persistencia en el entorno CI/CD.
La D-PPE es especialmente eficaz cuando:
- Las reglas de protección de ramas son débiles o inexistentes
- Las ejecuciones del pipeline se disparan ante eventos push en cualquier rama
- Se utilizan runners autoalojados con estado persistente
- Los archivos CODEOWNERS no protegen la configuración del pipeline
PPE indirecta (I-PPE)
La PPE indirecta es más sutil y más difícil de detectar. En lugar de modificar directamente la configuración del pipeline, el atacante modifica archivos que el pipeline consume durante la ejecución. Esto incluye:
- Scripts de build referenciados en el pipeline (por ejemplo,
Makefile,build.sh, scripts depackage.json) - Manifiestos de dependencias que incorporan paquetes maliciosos durante el build
- Archivos de configuración consumidos por las herramientas de build (por ejemplo,
.npmrc,setup.py,build.gradle) - Fixtures de test o archivos de datos que procesan los pasos del pipeline
La I-PPE es especialmente peligrosa porque los procesos de revisión de código suelen centrarse en los cambios del código de la aplicación, no en las implicaciones de seguridad de los scripts de build o los archivos de dependencias modificados. Un atacante puede ocultar instrucciones maliciosas en un cambio aparentemente inocente de un Makefile que se ejecuta con todos los privilegios del pipeline.
PPE a través de pull requests
Muchos sistemas CI/CD están configurados para ejecutar pipelines sobre pull requests procedentes de forks, una característica necesaria para los proyectos open source. Sin embargo, esto crea un vector de ataque directo: un contribuidor externo puede enviar un pull request que modifique la configuración del pipeline o los scripts de build, y el pipeline ejecutará el código malicioso antes de que se produzca ninguna revisión humana. Aunque algunas plataformas restringen el acceso a secretos para los PRs de forks, las configuraciones incorrectas exponen secretos con frecuencia, o el propio entorno del pipeline aporta suficiente valor al atacante.
Para explorar las técnicas de ataque PPE de forma práctica y aprender contramedidas defensivas, trabaja con nuestro lab dedicado: Lab: explotación y defensa frente a la ejecución de pipeline envenenada (PPE).
Confusión de dependencias y envenenamiento de artefactos
Los ataques de confusión de dependencias y de envenenamiento de artefactos explotan la confianza que los sistemas de build depositan en los registries de paquetes y en los mecanismos de resolución de dependencias. Estos ataques apuntan a la cadena de suministro en su nivel más fundamental: los componentes que se incorporan a tu software durante el build.
Confusión de dependencias
La confusión de dependencias (también llamada confusión de namespace o ataques de sustitución) explota la forma en que los gestores de paquetes resuelven las dependencias cuando hay configurados tanto registries públicos como privados. El atacante publica un paquete malicioso en un registry público (npm, PyPI, RubyGems) usando el mismo nombre que un paquete interno/privado utilizado por la organización objetivo. Si el gestor de paquetes no está configurado para priorizar el registry privado, puede descargar en su lugar la versión pública maliciosa, especialmente si el atacante publica un número de versión superior.
Este ataque fue demostrado de forma célebre por el investigador de seguridad Alex Birsan en 2021, quien utilizó la confusión de dependencias para ejecutar código dentro de los sistemas de build de Apple, Microsoft, PayPal y decenas de otras grandes organizaciones. El ataque no requería ningún acceso a la organización objetivo, solo el conocimiento de los nombres de los paquetes internos, que a veces pueden descubrirse a través de lock files filtrados, source maps de JavaScript o mensajes de error.
Typosquatting
Relacionado con la confusión de dependencias, el typosquatting consiste en publicar paquetes maliciosos con nombres muy similares a los de paquetes legítimos populares (por ejemplo, lodahs en lugar de lodash, reqeusts en lugar de requests). Cuando un desarrollador o un script de build comete un error tipográfico en una declaración de dependencia, se instala el paquete malicioso en su lugar.
Envenenamiento de artefactos
El envenenamiento de artefactos adopta un enfoque diferente, apuntando a los artefactos producidos por los pipelines de build en lugar de a sus entradas. Los atacantes que obtienen acceso al almacenamiento de artefactos (container registries, repositorios de paquetes, almacenamiento de binarios) pueden reemplazar los artefactos legítimos por versiones con backdoor. Esto es particularmente eficaz contra las imágenes de contenedor almacenadas en registries con tags mutables: un atacante que obtenga acceso de escritura puede reemplazar la imagen detrás de un tag :latest o :v1.2.3 sin cambiar el propio tag.
Para una exploración exhaustiva de estos vectores de ataque y sus defensas, consulta: Confusión de dependencias y envenenamiento de artefactos: ataques y defensas.
Robo de credenciales y exfiltración de secretos
Los pipelines CI/CD son auténticos tesoros de credenciales. Necesitan acceso a los repositorios de código fuente, a los proveedores de nube, a los container registries, a las bases de datos, a los destinos de despliegue y a servicios externos. Estas credenciales —claves de API, tokens, contraseñas, certificados y claves de firma— son el objetivo principal de muchos ataques a CI/CD.
Técnicas habituales de exfiltración de secretos
Los atacantes utilizan diversas técnicas para robar secretos de los entornos CI/CD:
- Volcado de variables de entorno: muchos sistemas CI/CD inyectan los secretos como variables de entorno. Un simple comando
envoprintenven un paso de pipeline comprometido revela todos los secretos disponibles. - Escaneo del sistema de archivos: los secretos pueden escribirse en disco como archivos (por ejemplo,
~/.docker/config.json,~/.aws/credentials,~/.kube/config). Los atacantes escanean el sistema de archivos en busca de archivos de credenciales. - Inspección de memoria: en los runners autoalojados, los atacantes pueden inspeccionar la memoria de los procesos o
/procpara encontrar secretos que se descifraron en tiempo de ejecución. - Interceptación de red: si los pipelines se comunican con servicios por canales sin cifrar, los atacantes con acceso a la red pueden interceptar credenciales en tránsito.
- Exfiltración por logs: los secretos que aparecen accidentalmente en los logs de build (algo deprimentemente habitual) pueden ser extraídos por cualquiera con acceso a los logs.
- Exfiltración por DNS/HTTP: en entornos restringidos donde las conexiones salientes son limitadas, los atacantes codifican los secretos robados en consultas DNS o cabeceras HTTP para eludir los controles de egress.
El problema acumulativo de la proliferación de credenciales
Un reto clave en la seguridad CI/CD es la proliferación de credenciales (credential sprawl): la tendencia de los secretos a acumularse con el tiempo entre configuraciones de pipeline, variables de entorno, almacenes de secretos y archivos de configuración. Las credenciales de larga duración que nunca se rotan, las service accounts demasiado permisivas y los secretos compartidos entre múltiples pipelines aumentan el radio de impacto de un incidente de robo de credenciales.
La solución es un enfoque disciplinado de la gestión de secretos que combine credenciales de corta duración, acceso de mínimo privilegio, rotación de secretos e inyección en tiempo de ejecución desde un vault centralizado. Para orientación detallada de implementación, consulta nuestra guía sobre Gestión de secretos en pipelines CI/CD: patrones con Vault.
Para practicar la detección y prevención de filtraciones de secretos en un entorno controlado, trabaja con nuestro lab práctico: Lab: detección y prevención de filtraciones de secretos en pipelines CI/CD.
Manipulación de artefactos y ataques a registries
La integridad de los artefactos es una piedra angular de la seguridad de la cadena de suministro. Si un atacante puede modificar los artefactos que produce tu pipeline —imágenes de contenedor, paquetes, binarios o manifiestos de despliegue—, puede inyectar código malicioso que se propaga a todos los entornos que consumen esos artefactos.
Ataques de mutación de tags
Los container registries permiten por defecto sobrescribir los tags de imagen. Un atacante con acceso de escritura a un registry puede reemplazar la imagen detrás de cualquier tag mutable (como :latest, :stable o incluso un tag de versión aparentemente específico como :v2.1.0) por una versión con backdoor. Los sistemas downstream que descarguen ese tag recibirán silenciosamente la imagen comprometida.
Por eso los tags inmutables y las referencias basadas en digest (image@sha256:abc123...) son controles de seguridad críticos. Los mecanismos de content trust como Docker Content Trust (DCT) y Sigstore/cosign proporcionan la verificación criptográfica de la procedencia de las imágenes.
Compromiso del registry
El compromiso directo de los registries de artefactos —ya sea mediante credenciales robadas, la explotación de vulnerabilidades del registry o amenazas internas— da a los atacantes la capacidad de modificar cualquier artefacto almacenado. Los registries autoalojados que carecen de autenticación, usan credenciales por defecto o ejecutan software sin parchear son particularmente vulnerables.
Manipulación del proceso de build
En lugar de manipular los artefactos después de construirlos, los atacantes sofisticados modifican el propio proceso de build para producir artefactos comprometidos. Esto puede implicar manipular Dockerfiles, inyectar capas maliciosas en builds multietapa o modificar los flags de compilación para insertar backdoors. Estos ataques son particularmente insidiosos porque los artefactos resultantes parecen productos legítimos del pipeline CI/CD.
Defenderse frente a la manipulación de artefactos requiere una combinación de almacenamiento inmutable, firma criptográfica, atestación de procedencia (como SLSA) y verificación continua. Para practicar la detección de manipulación de artefactos en un entorno práctico, consulta: Lab: detección de manipulación de artefactos — intercambio de imágenes de contenedor en un registry.
Actions e integraciones de terceros comprometidas
Los pipelines CI/CD modernos no son monolíticos: se ensamblan a partir de decenas de componentes de terceros: GitHub Actions, plantillas de GitLab CI, plugins de Jenkins, providers de Terraform y diversas integraciones SaaS. Cada uno de estos componentes representa una frontera de confianza que los atacantes pueden explotar.
Ataques a la cadena de suministro de GitHub Actions
Las GitHub Actions son un objetivo prioritario porque ejecutan código arbitrario dentro del contexto del workflow que las invoca. Entre los vectores de ataque están:
- Repositorios de actions comprometidos: un atacante que obtenga acceso al repositorio de una action popular puede publicar código malicioso que se ejecute en todos los workflows que usen esa action. El incidente de tj-actions/changed-files en 2023 lo demostró a gran escala.
- Manipulación de tags: las actions referenciadas por tags mutables (por ejemplo,
@v3) pueden reemplazarse silenciosamente. El atacante mueve el tag para que apunte a un commit malicioso. - Typosquatting: las actions maliciosas publicadas con nombres similares a los de las populares explotan los errores tipográficos de los desarrolladores.
- Apropiación de actions abandonadas: cuando los mantenedores de una action abandonan sus proyectos, los atacantes a veces pueden reclamar el namespace y publicar actualizaciones maliciosas.
Riesgos de plugins y extensiones
Los plugins de Jenkins, los componentes de GitLab CI y otras extensiones CI/CD afrontan riesgos similares. Muchos plugins los mantienen contribuidores individuales con prácticas de seguridad dispares. Las vulnerabilidades en los plugins pueden exponer toda la infraestructura CI/CD, ya que los plugins de Jenkins han sido históricamente una rica fuente de vulnerabilidades de robo de credenciales y ejecución remota de código.
La estrategia defensiva consiste en fijar todos los componentes de terceros a referencias inmutables (SHAs de commit en lugar de tags), auditar las dependencias con regularidad y usar herramientas que detecten actions maliciosas conocidas. Para practicar de forma directa la detección de GitHub Actions maliciosas, trabaja con: Lab: detección de GitHub Actions maliciosas con análisis estático.
Cronología de ataques CI/CD reales
La siguiente cronología recorre los principales ataques a CI/CD y a la cadena de suministro de software de 2020 a 2024. Cada incidente ilustra distintos vectores de ataque y refuerza por qué la seguridad CI/CD merece una atención específica.
SolarWinds / SUNBURST (diciembre de 2020)
El ataque a SolarWinds sigue siendo el compromiso de cadena de suministro CI/CD por antonomasia. Los atacantes (atribuidos al servicio de inteligencia SVR de Rusia) se infiltraron en la infraestructura de build de SolarWinds e inyectaron el backdoor SUNBURST en el proceso de actualización del software Orion. El pipeline de build comprometido produjo actualizaciones troyanizadas que se distribuyeron a aproximadamente 18 000 organizaciones, incluidas agencias gubernamentales de EE. UU., empresas de la lista Fortune 500 y operadores de infraestructuras críticas.
Lecciones clave: la infraestructura de build debe tratarse como un activo crítico. La verificación de la integridad de los artefactos y los builds reproducibles podrían haber detectado la manipulación. El ataque demostró que comprometer un único pipeline de build puede tener un impacto a nivel de estado-nación.
Codecov Bash Uploader (enero–abril de 2021)
Los atacantes comprometieron el script Bash Uploader de Codecov, un componente utilizado por miles de pipelines CI/CD para subir informes de cobertura de código. Durante tres meses, el script modificado exfiltró variables de entorno (incluidos secretos, tokens y claves CI/CD) de cada pipeline que lo ejecutaba. El ataque afectó a empresas como Twitch, HashiCorp, Confluent y muchas otras.
Lecciones clave: los scripts de terceros ejecutados en los pipelines deben verificarse en su integridad (por ejemplo, mediante checksums). Los secretos nunca deberían estar disponibles de forma amplia como variables de entorno. La monitorización de egress en los runners CI/CD podría haber detectado la exfiltración.
Secuestro de ua-parser-js (octubre de 2021)
El paquete npm ua-parser-js, descargado más de 7 millones de veces por semana, fue secuestrado cuando se comprometió la cuenta npm del mantenedor. Se publicaron versiones maliciosas que instalaban criptomineros y malware de robo de credenciales. Como este paquete es una dependencia de miles de otros paquetes y procesos de build CI/CD, el radio de impacto fue enorme.
Lecciones clave: incluso los paquetes confiables y de uso extendido pueden verse comprometidos. Los lock files, la comprobación de integridad y el escaneo automatizado de dependencias en CI/CD son esenciales. La seguridad de las cuentas npm (2FA, acotación de tokens) es una preocupación de la cadena de suministro.
Incidente de seguridad de CircleCI (enero de 2023)
CircleCI, una de las mayores plataformas CI/CD, reveló que un atacante había obtenido acceso a datos de clientes, incluidas variables de entorno, claves y tokens almacenados en CircleCI. La brecha se originó a partir de malware en el portátil de un ingeniero que robó un token de sesión SSO válido, que luego se utilizó para acceder a los sistemas internos. CircleCI instó a todos sus clientes a rotar de inmediato todos los secretos almacenados en la plataforma.
Lecciones clave: los proveedores de plataformas CI/CD son objetivos de alto valor. Las organizaciones deberían implementar defensa en profundidad y no depender únicamente de la seguridad de su plataforma CI/CD. Las credenciales de corta duración y acotadas limitan el impacto de los compromisos de la plataforma. Contar con un plan de respuesta a incidentes para la rotación de secretos es fundamental.
Compromiso de tj-actions/changed-files (marzo de 2023)
La popular GitHub Action tj-actions/changed-files (usada por más de 23 000 repositorios) fue comprometida cuando un atacante obtuvo acceso a la cuenta del mantenedor y publicó código malicioso. La action comprometida volcaba los secretos CI/CD en los logs de los workflows, donde podían ser recolectados. Como muchos workflows referenciaban la action mediante tags de versión mutables, el código malicioso se incorporó automáticamente a miles de ejecuciones de pipeline.
Lecciones clave: fija siempre las GitHub Actions a SHAs de commit, no a tags de versión. Monitoriza las dependencias de actions en busca de cambios inesperados. Implementa los permisos de workflow siguiendo el principio de mínimo privilegio.
Backdoor en XZ Utils (marzo de 2024)
El backdoor de XZ Utils (CVE-2024-3094) fue un sofisticado ataque a la cadena de suministro de varios años. Un contribuidor que había ganado confianza dentro del proyecto XZ a lo largo de dos años introdujo gradualmente un backdoor en el sistema de build. El código malicioso se ocultaba en archivos de fixtures de test y se activaba mediante scripts de build cuidadosamente elaborados: un ejemplo de manual de ejecución de pipeline envenenada indirecta. El backdoor apuntaba al daemon SSH de los sistemas Linux y habría afectado a prácticamente todas las distribuciones de Linux de no haberse descubierto por casualidad.
Lecciones clave: la ingeniería social y la infiltración a largo plazo de los proyectos open source son amenazas reales. La integridad del sistema de build es tan importante como la integridad del código fuente. El ataque demostró que las técnicas de I-PPE pueden ser extraordinariamente sutiles y pacientes.
Patrones defensivos y mitigaciones
Defenderse frente a los ataques a CI/CD requiere un enfoque por capas que aborde cada categoría de ataque. Los siguientes patrones constituyen la base de una postura de seguridad CI/CD robusta.
Configuración del pipeline como código con controles estrictos
- Protege los archivos de configuración del pipeline con CODEOWNERS y reglas de protección de ramas
- Exige revisión de código para todos los cambios en la configuración CI/CD
- Usa plantillas de pipeline gestionadas centralmente en lugar de configuraciones por repo siempre que sea posible
- Separa las definiciones de pipeline del código de la aplicación en los repositorios sensibles
Fortalecimiento de credenciales
- Usa credenciales de corta duración y acotadas (federación OIDC con los proveedores de nube)
- Implementa la inyección de secretos just-in-time desde un vault centralizado
- Nunca expongas secretos como variables de entorno cuando esté disponible la inyección basada en archivos
- Rota todas las credenciales según un calendario definido e inmediatamente después de cualquier incidente
- Implementa el escaneo de secretos en los logs CI/CD y en las salidas de artefactos
Controles de dependencias y cadena de suministro
- Fija todas las dependencias a versiones exactas con hashes de integridad
- Usa proxies de registry privados con acotación de namespace para prevenir la confusión de dependencias
- Fija las GitHub Actions y otros componentes de pipeline de terceros a SHAs de commit
- Implementa el escaneo automatizado de vulnerabilidades de dependencias en cada pipeline
- Genera y verifica listas de materiales de software (SBOMs)
Integridad de artefactos
- Firma criptográficamente todos los artefactos de build (Sigstore/cosign para contenedores, GPG para paquetes)
- Usa tags inmutables y referencias basadas en digest para las imágenes de contenedor
- Implementa la atestación de procedencia SLSA para verificar el origen de los artefactos
- Despliega admission controllers (por ejemplo, Kyverno, OPA Gatekeeper) que verifiquen las firmas antes del despliegue
Monitorización y detección
- Monitoriza la ejecución del pipeline en busca de comportamientos anómalos (conexiones de red inesperadas, accesos al sistema de archivos, jobs de larga duración)
- Implementa controles de egress en los runners CI/CD para detectar la exfiltración
- Audita todos los cambios en las configuraciones del pipeline, los secretos y los permisos
- Correlaciona los eventos CI/CD con un SIEM para la detección entre sistemas
Para un análisis exhaustivo de cada uno de estos patrones defensivos con ejemplos de implementación, consulta: Patrones defensivos y mitigaciones para ataques a pipelines CI/CD.
Modelado de amenazas para CI/CD
La seguridad CI/CD eficaz empieza con el modelado de amenazas: identificar de forma sistemática las fronteras de confianza, los flujos de datos y las rutas de ataque dentro de tu arquitectura de pipeline. Sin una comprensión clara de tu modelo de amenazas CI/CD, los esfuerzos defensivos tienden a ser reactivos e incompletos.
Fronteras de confianza clave que evaluar
Todo sistema CI/CD tiene fronteras de confianza que los atacantes intentan cruzar:
- De la estación de trabajo del desarrollador al repositorio: ¿puede una máquina de desarrollador comprometida publicar código malicioso?
- Del repositorio al pipeline: ¿qué cambios disparan la ejecución del pipeline, y con qué privilegios?
- Del pipeline al almacén de secretos: ¿qué pipelines pueden acceder a qué secretos, y bajo qué condiciones?
- Del pipeline al registry de artefactos: ¿quién puede publicar artefactos, y se verifican antes de usarlos?
- Del registry de artefactos al despliegue: ¿se verifican los artefactos desplegados contra su procedencia de build?
- De los servicios de terceros al pipeline: ¿qué acceso tienen las integraciones externas?
Análisis de rutas de ataque
Una vez cartografiadas las fronteras de confianza, el siguiente paso es enumerar las rutas de ataque: las secuencias de acciones que un atacante podría llevar a cabo para lograr sus objetivos. Entre los objetivos habituales están:
- Inyectar código malicioso en los despliegues de producción
- Exfiltrar credenciales para el movimiento lateral
- Establecer persistencia en la infraestructura CI/CD
- Interrumpir la entrega de software (sabotaje/denegación de servicio)
- Comprometer a los consumidores downstream mediante la propagación por la cadena de suministro
Para una guía completa sobre el modelado de amenazas CI/CD con marcos y plantillas prácticos, consulta: Modelado de amenazas CI/CD: fronteras de confianza y rutas de ataque.
Labs prácticos: practica el ataque y la defensa
Comprender los ataques a CI/CD en teoría es importante, pero no hay sustituto para la práctica directa. Los siguientes labs proporcionan entornos controlados donde puedes explorar de forma segura las técnicas de ataque e implementar defensas:
- Lab: explotación y defensa frente a la ejecución de pipeline envenenada (PPE) — practica los ataques de PPE tanto directa como indirecta, y luego implementa protección de ramas, CODEOWNERS y controles de configuración del pipeline para defenderte de ellos.
- Lab: confusión de dependencias y envenenamiento de artefactos — ejecuta un ataque de confusión de dependencias contra una configuración de build vulnerable, y luego implementa la acotación de namespace, la verificación de integridad y los controles de registry privado.
- Lab: detección y prevención de filtraciones de secretos en pipelines CI/CD — descubre secretos expuestos a través de variables de entorno, logs y artefactos, y luego implementa la detección con herramientas como gitleaks, truffleHog y guards de pipeline personalizados.
- Lab: detección de manipulación de artefactos — intercambio de imágenes de contenedor en un registry — realiza un ataque de mutación de tags contra un container registry, y luego implementa content trust, fijado por digest y verificación mediante admission controller.
- Lab: detección de GitHub Actions maliciosas con análisis estático — analiza las GitHub Actions en busca de patrones maliciosos, implementa el fijado por SHA e incorpora la detección automatizada a tu proceso de aprobación de workflows.
Cada lab incluye instrucciones paso a paso, un entorno preconfigurado y escenarios tanto de ataque como de defensa. Están diseñados para completarse de forma independiente, aunque trabajarlos en el orden indicado arriba te aportará una comprensión integral de la seguridad CI/CD.
Conclusión: construir una arquitectura CI/CD defendible
Los pipelines CI/CD se han convertido en la superficie de ataque más trascendental de las organizaciones de software modernas. Los incidentes catalogados en esta guía —de SolarWinds a XZ Utils— demuestran que los atacantes han reconocido esta realidad y están invirtiendo recursos significativos en técnicas de explotación de CI/CD.
Pero el panorama no es del todo sombrío. La comunidad de seguridad CI/CD ha respondido con marcos (OWASP CI/CD Top 10, SLSA), herramientas (Sigstore, gitleaks, StepSecurity) y patrones arquitectónicos que pueden reducir drásticamente tu exposición. Los principios clave que conviene recordar son:
- Trata los pipelines como infraestructura de producción. Aplica a CI/CD el mismo rigor de seguridad que aplicas a los sistemas de producción: acceso de mínimo privilegio, monitorización, parcheo y respuesta a incidentes.
- Elimina la confianza implícita. Verifícalo todo: dependencias, actions de terceros, artefactos y configuraciones de pipeline. Fija a referencias inmutables. Firma y verifica en cada etapa.
- Minimiza el radio de impacto. Usa credenciales de corta duración, permisos acotados, runners aislados y segmentación de red para limitar lo que un atacante puede lograr desde cualquier compromiso individual.
- Invierte en visibilidad. No puedes defender lo que no puedes ver. El logging, la monitorización y las alertas exhaustivas para los sistemas CI/CD son innegociables.
- Practica tu respuesta. Usa los labs enlazados a lo largo de esta guía para desarrollar memoria muscular tanto en la detección de ataques como en la implementación de defensas. Cuando llegue el próximo incidente CI/CD, estarás listo.
La seguridad CI/CD no es un proyecto puntual: es una disciplina continua que debe evolucionar a medida que avanzan las técnicas de ataque. Empieza con un modelo de amenazas, implementa los patrones defensivos que aborden tus mayores riesgos y valida continuamente tus defensas a través de los labs prácticos de arriba. Tus pipelines son demasiado importantes como para dejarlos sin defensa.
