Ataques a la cadena de suministro en CI/CD: cómo llegan los atacantes a tu pipeline

Qué podría hacer un atacante con tu pipeline en una hora

Si alguien entrara en tu sistema de compilación durante una hora, ¿qué podría llevarse y qué podría cambiar?

Ilustración conceptual de tres vías de entrada a un pipeline de compilación. No es un diagrama de ningún sistema real. Las etiquetas de la imagen están en inglés y forman parte de la ilustración.

Un pipeline de CI/CD es el recorrido automatizado que compila, prueba y entrega tu software. Para hacer ese trabajo, guarda tu código fuente, los secretos necesarios para llegar a otros sistemas y el derecho a desplegar. Aquí, un secreto es una contraseña, un token o una clave que demuestra quién eres ante otro servicio.

Esa combinación convierte el pipeline en un buen objetivo. Un atacante que llega a él puede que ni siquiera necesite entrar en tu aplicación. Puede llevarse las claves o cambiar lo que se entrega.

Tres incidentes de la misma quincena muestran cómo ocurre. Parecen distintos, pero terminan en el mismo sitio. Este artículo los recorre uno por uno y después te propone una revisión de una hora.

Por qué los atacantes van a por los pipelines

Un pipeline es de confianza por diseño. Puede leer código privado, llamar a servicios en la nube y publicar paquetes, y nadie vigila cada paso que da. Un secreto guardado en un pipeline suele tener más poder que uno guardado en la computadora portátil de un desarrollador.

Un ataque a la cadena de suministro consiste en atacar algo de lo que depende tu software, en lugar de atacar directamente tu software. En este artículo eso significa los archivos de flujo de trabajo (workflows) de tu repositorio, los paquetes que instala tu compilación y el propio sistema de CI. El atacante llega hasta ti por una puerta que tú ya abriste.

Texto alternativo accesible para esta figura

Un pipeline avanza de izquierda a derecha: un repositorio de código fuente que contiene el código y los archivos de workflow, un paso de compilación y pruebas que instala, compila y prueba, y un paso de despliegue que llega a registros, a la nube y a clústeres. Secretos como tokens, claves de nube y claves de publicación se guardan en el entorno de compilación.

Tres ataques entran por puntos distintos. Ataque 1: un token robado añade un archivo de workflow falso en el repositorio. Ataque 2: un paquete de confianza ejecuta código al instalarse durante la compilación. Ataque 3: un fallo del propio sistema de CI, por ejemplo GitLab o Argo CD, se explota en el servidor de CI.

Los tres ataques llevan a los secretos; por eso los secretos del entorno de compilación son el objetivo común.

Patrón 1: un token robado añade un workflow falso (GhostAction)

GitHub Actions ejecuta tu pipeline a partir de archivos de workflow guardados en el repositorio, en .github/workflows/. Cualquiera que pueda escribir en el repositorio puede añadir uno. Esa es la debilidad que aprovecha GhostAction.

La campaña se notificó por primera vez en septiembre de 2025. GitGuardian cuenta una oleada en agosto de 2026, y la actividad de esta quincena alcanzó su punto máximo el 8 y el 9 de octubre.

Según StepSecurity, los atacantes añadieron a los repositorios un workflow llamado «Security Audit» o «Github Actions Security». Parece una comprobación útil. Se ejecuta con cada push y envía datos a la dirección de un servidor escrita directamente en el código.

La versión anterior enviaba los secretos con nombre del repositorio. La versión de octubre fue más allá. También buscaba en los archivos de trabajo y en todo el historial de git unos 13 tipos de credenciales, como claves de nube, de servicios de IA y de software como servicio. El consejo de StepSecurity es claro: borrar un secreto de la rama actual no sirve de nada, porque también se analiza el historial.

¿Cómo consiguieron los atacantes acceso de escritura? StepSecurity dice que no está confirmado para las cuentas de octubre. El origen más probable son tokens de acceso personal filtrados a través de malware que roba credenciales o de volcados de datos. En un caso, la cuenta comprometida podía escribir en el repositorio de una gran empresa, así que el nuevo workflow entró sin revisión.

Hay dos series de cifras, y miden cosas distintas:

• StepSecurity contó 345 repositorios afectados en dos barridos el 8 de octubre. Unos 378 repositorios tenían el workflow malicioso activo el 9 de octubre.
• GitGuardian, en su actualización del 13 de octubre, dice que unas 1900 cuentas fueron comprometidas. Dice que más de 30 000 repositorios fueron objetivo del ataque y que la campaña intentó extraer 3174 secretos. Son objetivos e intentos, no robos confirmados, y GitGuardian no da ninguna cifra de secretos realmente sustraídos en octubre.

GitGuardian también informa de que GitHub empezó a bloquear el workflow malicioso a partir del 9 de octubre, y de que las oleadas del 10 y el 12 de octubre no extrajeron ningún secreto. Es el informe de GitGuardian, y aquí no se cita a GitHub al respecto.

GitGuardian señala que algunas víctimas sufrieron el ataque tanto en 2025 como en 2026, lo que sugiere que los secretos de la primera oleada nunca se rotaron. También advierte de que rotar los secretos robados no basta. Tienes que encontrar y revocar la credencial de GitHub que se usó para añadir el workflow, o alguien podrá volver a usarla.

GitHub también tiene protecciones propias. Desde julio, retiene las ejecuciones de workflows que considera potencialmente maliciosas hasta que un colaborador con acceso de escritura las aprueba, en los repositorios públicos de github.com y sin ninguna configuración. Sus protecciones de ejecución de workflows, disponibles de forma general desde el 17 de septiembre, te permiten fijar reglas sobre quién y qué puede activar workflows. Ayudan, pero no sustituyen a la revisión de los cambios en los archivos de workflow.

Patrón 2: un paquete de confianza ejecuta código al instalarlo (TensorLake)

La mayoría de los gestores de paquetes pueden ejecutar un pequeño script al instalar un paquete. Se llaman scripts de instalación. Existen por buenas razones, como compilar código nativo. Pero también se ejecutan en tu computadora portátil de desarrollo y en tu servidor de compilación antes de que nadie haya mirado lo que hacen.

El 8 de octubre apareció en npm la versión 0.5.144 del paquete tensorlake. Aikido la describe como portadora de una variante del gusano Shai-Hulud, una familia de malware de robo de credenciales que ya se había visto antes. StepSecurity lo llama gusano y describe el mismo comportamiento. Su script preinstall descargaba un entorno de ejecución de JavaScript y ejecutaba una carga útil ofuscada. Esa carga útil buscaba variables de entorno, credenciales de nube y de Kubernetes, claves SSH y datos del navegador.

Dos detalles importan a quienes defienden.

Primero, el paquete tenía una atestación de procedencia de npm válida. La procedencia es un registro firmado de dónde y cómo se compiló un paquete. StepSecurity informa de que los atacantes subieron su código directamente a la rama principal con la identidad de un mantenedor, sin ningún pull request.

El propio workflow de publicación del proyecto compiló y publicó entonces el paquete. La procedencia decía la verdad sobre dónde se había compilado. No podía decirte que el código fuera seguro.

Segundo, el malware incluía lo que StepSecurity llama un «token rehén» (hostage token). Comprueba el token de GitHub robado cada 60 segundos durante un máximo de 24 horas y, si GitHub rechaza el token, borra el directorio personal. El consejo habitual tras un robo es revocar primero el token, pero aquí eso podría desencadenar el daño.

La recomendación de StepSecurity es eliminar el servicio de vigilancia del malware, tras hacer una copia de seguridad, antes de revocar nada.

El resto de los consejos es más sencillo. Fija la última versión buena, 0.5.143. Desactiva los scripts de instalación. Rota todas las credenciales a las que pudiera llegar la máquina y reconstruye cualquier máquina de la que no puedas demostrar que está limpia.

StepSecurity comprobó que la versión 0.5.144 todavía se podía descargar cuando redactó su informe. El registro de npm ya no muestra esa versión (comprobado el 19 de octubre), y el paquete ha pasado a versiones posteriores.

También hay buenas noticias. npm 12, que GitHub puso a disposición general el 8 de julio de 2026, desactiva los scripts de instalación de forma predeterminada y bloquea las dependencias de git y de URL remotas salvo que las permitas. Eso detiene el paso del que dependía este ataque. Solo ayuda si tu pipeline ejecuta de verdad npm 12 o posterior, y no una versión más antigua en una imagen de compilación fijada.

Patrón 3: un fallo del propio sistema de CI (GitLab y Argo CD)

El tercer patrón es distinto. Nadie engaña al pipeline. Es el software que ejecuta el pipeline el que tiene un error.

GitLab. El 12 de octubre, GitLab publicó las versiones 19.4.2, 19.3.5 y 19.2.8 para corregir CVE-2026-97229. Tiene la puntuación de gravedad más alta posible, CVSS 10.0. El título del aviso de GitLab describe un desbordamiento de enteros en el compilador de expresiones regulares que se usa para la configuración de CI/CD, y GitLab dice que, en determinadas condiciones, podría permitir que un usuario no autenticado ejecutara código en el servidor.

GitLab.com ya tiene el parche, y todos los tenants de GitLab Dedicated (las instancias dedicadas de cada cliente) recibieron el parche antes de la publicación. GitLab recomienda encarecidamente que las instalaciones autogestionadas se actualicen de inmediato.

La puntuación supone que no hace falta iniciar sesión, pero Rapid7 encontró una condición. El atacante debe poder confirmar (commit) en una rama de un proyecto público un archivo .gitlab-ci.yml manipulado y una ruta de repositorio con un nombre especial. Una cuenta corriente puede cumplirla en las instancias donde los usuarios pueden crear proyectos públicos.

Rapid7 reprodujo la ejecución de código en una versión 19.4.1 sin parchear y publicó una prueba de concepto. En su actualización del 16 de octubre, no se había confirmado ningún ataque en entornos reales.

Argo CD. Argo CD es una herramienta que despliega aplicaciones en Kubernetes a partir de un repositorio de git. Sus mantenedores publicaron correcciones en las versiones 3.5.4, 3.4.10 y 3.3.15 el 6 de octubre. Uno de los problemas es CVE-2026-55797, una inyección de comandos en el repo server a través de la URL de proxy de un repositorio en repositorios git por SSH, con una puntuación de 8.8.

Las notas de la versión enumeran ocho correcciones de seguridad en total, cuatro de ellas calificadas como críticas. Incluyen formas de ejecutar comandos o leer archivos en el servidor de repositorios y una forma de eludir las restricciones de proyecto. No se ha informado de ataques para ninguna de ellas. Si usas Argo CD, lee las notas de la versión y actualiza.

Ninguno de los dos es una prueba de ataques. Importan porque los sistemas que ejecutan tu pipeline tienen los mismos poderes que tu pipeline.

Lo que comparten los tres patrones

Cada ataque siguió una ruta distinta. GhostAction llegó a través de un token robado y un archivo de workflow. TensorLake llegó a través de un paquete que instala tu compilación. GitLab y Argo CD llegarían a través de la plataforma.

Todos terminan en los secretos del entorno de compilación. Ese es el punto común. Los controles creados para proteger el código de la aplicación, como la revisión de código y los análisis de vulnerabilidades de tus dependencias, no cubren ese punto por sí solos. El pipeline necesita su propia protección.

Cuánto necesitas saber

Conocer. Todo desarrollador debería entender que el pipeline es un objetivo, qué es un secreto y por qué la instalación de un paquete puede ejecutar código. No necesitas configurar nada.

Usar. Los ingenieros de plataforma y de DevOps que escriben o revisan workflows necesitan las habilidades prácticas: limitar los permisos de los tokens, proteger los archivos de workflow, desactivar los scripts de instalación, restringir el acceso de red desde los runners de compilación y rotar los secretos en el orden correcto.

Dominar. Las personas responsables de la seguridad del pipeline necesitan diseñar pensando en el fallo. Deciden cómo se emiten los secretos, cuánto tiempo duran y cómo se contendría y reconstruiría una compilación comprometida.

Una revisión de una hora

Puedes hacer casi todo esto en una hora. Empieza por los puntos que no cuestan nada.

1. Comprueba quién puede cambiar los archivos de workflow. Asegúrate de que los cambios en .github/workflows/ requieran una revisión, por ejemplo con una regla de code owners (propietarios del código) y protección de ramas. Para ver cuándo se añadieron archivos de workflow, ejecuta git log --all --diff-filter=A --name-only -- .github/workflows. Busca nombres que no reconozcas, como una «security audit» que nunca pediste.
2. Comprueba el alcance de los tokens. Usa tokens de granularidad fina (fine-grained) con la vida más corta y el menor número de repositorios que necesiten. Configura los permissions predeterminados del token del workflow como de solo lectura y amplíalos solo donde un job necesite más.
3. Comprueba los scripts de instalación. Ejecuta npm --version en la misma imagen que usa tu pipeline. Si es anterior a la 12, configura ignore-scripts=true en .npmrc y permite solo los paquetes que de verdad necesiten un script.
4. Comprueba a qué puede llegar la compilación. Si tus runners pueden enviar datos a cualquier dirección de internet, un secreto robado sale con facilidad. Permite solo los destinos que necesita la compilación.
5. Conoce tu orden de rotación. Si tienes que rotar, empieza por las credenciales que pueden publicar o desplegar (registro de paquetes, registro de contenedores, roles de despliegue en la nube), luego el acceso a la nube y a los clústeres, y después todo lo demás. Tras un paquete malicioso, lee primero los pasos de eliminación del proveedor.
6. Comprueba tu propio sistema de CI. Si gestionas tú mismo GitLab o Argo CD, confirma que usas una versión corregida.

Qué puedes ignorar por ahora

No necesitas seguir cada prueba de concepto ni aprender el funcionamiento interno de cada familia de malware. Los detalles cambian de una semana a otra, pero las comprobaciones anteriores no.

Tampoco necesitas abandonar las comprobaciones de procedencia por culpa de TensorLake. Te dicen dónde se compiló un paquete, lo que sigue siendo útil. Solo no las tomes como una declaración de que el código es seguro.

Qué hacer a continuación

Elige un repositorio y recorre la lista de comprobación. Empieza por la revisión de los archivos de workflow y el alcance de los tokens, porque no cuestan nada y cierran la puerta que usó GhostAction.

Si esta semana solo revisas una cosa de tu propia configuración, averigua a qué secretos puede llegar tu compilación y qué antigüedad tienen.

El pipeline forma parte de tu superficie de ataque. Protégelo como si fuera producción.

Para profundizar

• StepSecurity, GhostAction Returns
• GitGuardian, GhostAction Returns
• GitHub, GitHub Actions holds potentially malicious workflows for approval y Workflow execution protections generally available
• Aikido, tensorlake NPM package compromised with Shai Hulud worm
• StepSecurity, Tensorlake npm package compromised: a worm with a hostage token
• GitHub, npm install-time security and GAT bypass-2FA deprecation
• GitLab, Critical patch release 19.4.2, 19.3.5, 19.2.8
• Rapid7, CVE-2026-97229: Critical unauthenticated remote code execution in GitLab
• Argo CD, v3.5.4 release notes y advisory GHSA-j6cw-g6p4-7hch
• npm, tensorlake package metadata, donde la versión 0.5.144 ya no aparece (comprobado el 19 de octubre de 2026)

Como lectura relacionada, consulta GitHub Actions está cambiando (en inglés), que trata otro cambio de la plataforma que afecta a los pipelines.