Red team frente a blue team
Los atacantes rara vez van a por su empresa. Van a por el paquete, la GitHub Action o la herramienta de build de los que dependen empresas de todo el mundo, y luego prueban el exploit en todas a la vez. No necesitan su lista de dependencias. Usted sí.
Un ataque a la cadena de suministro de software compromete algo con lo que se construye un producto, como un paquete de código abierto, un componente de CI/CD o el sistema de build, en lugar de atacar directamente el producto. El software moderno es en su mayoría código ajeno: la mayor parte procede de paquetes de código abierto, y la mayoría de ellos son dependencias transitivas que nadie del equipo eligió. Comprometa un componente muy utilizado y llegará a todas las organizaciones que se apoyan en él.
Eso cambia cómo eligen sus objetivos los atacantes. No investigan las dependencias de una empresa. Eligen un paquete o una herramienta con mucha presencia, lo explotan en todas partes y ven qué responde.
Se divulga un fallo en un paquete popular de código abierto y los atacantes lo explotan en todos los productos que distribuyen la versión vulnerable, normalmente como una dependencia transitiva que nadie eligió directamente.
Un atacante se hace con la cuenta de un mantenedor, o un gusano roba tokens de publicación, y publica una versión envenenada de un paquete de confianza. Se ejecuta en cuanto un build la instala, como ocurrió con el gusano de npm Shai-Hulud.
Un colaborador se gana la confianza en un proyecto de código abierto con el tiempo y luego introduce código malicioso en una versión que recogen las distribuciones y los productos posteriores, como ocurrió con la puerta trasera de xz utils.
Los paquetes con nombres parecidos a los de otros populares aprovechan las erratas. La confusión de dependencias va más allá: un paquete público con el mismo nombre que uno interno de una empresa se instala en su lugar.
Se secuestra una GitHub Action u otra herramienta de build, y todos los pipelines que la utilizan ejecutan el código del atacante con sus secretos al alcance, como ocurrió con tj-actions y Codecov.
Se altera el propio build, o se sustituye el artefacto entre el build y el despliegue, de modo que un árbol de código fuente limpio sigue generando una versión comprometida, como ocurrió con SolarWinds.
SolarWinds es el ataque a la cadena de suministro más conocido: código malicioso insertado en el build y distribuido a los clientes como una actualización normal. Los ataques más recientes van a por los registros de paquetes y los pipelines de CI, donde un solo paquete o una sola acción comprometidos llegan a todos los builds que los utilizan. Del más reciente al más antiguo:
Un gusano que se propaga solo, se ejecuta al instalar un paquete npm infectado, roba tokens de npm, GitHub y la nube, y publica versiones infectadas de los demás paquetes de la víctima. La mayoría de las infecciones se produjeron en CI.
Cómo comprobar sus builds →CISA informó de que todas las versiones de esta popular GitHub Action estuvieron comprometidas durante tres días, con secretos expuestos en los registros de los workflows. Los workflows que la referenciaban por etiqueta ejecutaron el código del atacante.
Andres Freund encontró una puerta trasera en las versiones 5.6.0 y 5.6.1 de xz tras observar que los inicios de sesión SSH consumían demasiada CPU. Se había introducido en el propio proyecto upstream.
Un fallo en Apache Log4j 2 permitía a un atacante que controlara un mensaje registrado ejecutar código arbitrario, con una puntuación CVSS de 10.0. Lo difícil para la mayoría de los equipos fue averiguar qué aplicaciones contenían log4j-core, normalmente como dependencia de una dependencia.
Los atacantes alteraron el script Bash Uploader que los equipos ejecutaban en sus pipelines de CI para que enviara el entorno de CI, incluidas credenciales, tokens y claves, a un servidor externo a la infraestructura de Codecov. Pasó inadvertido desde el 31 de enero hasta que un cliente lo notificó el 1 de abril.
Los atacantes tuvieron durante mucho tiempo acceso encubierto al proceso de build de SolarWinds Orion e insertaron código malicioso en las versiones de Orion de la 2019.4 a la 2020.2.1 HF1, que los clientes instalaron como actualizaciones normales. CISA emitió una directiva de emergencia en respuesta.
Red team frente a blue team
Cada etapa en palabras del atacante, y la defensa que le responde.
Etapa 1 de 3
No hace falta conocer al objetivo. Elija el paquete, y los objetivos se eligen solos.
Red team
No necesita el lockfile del objetivo. Los paquetes populares están en lo más profundo del árbol transitivo de casi todo, y la mayoría de los equipos no sabe decir cuáles distribuye. Las pistas públicas acotan la búsqueda: versiones en bundles de JavaScript y cabeceras HTTP, repositorios públicos e imágenes de contenedor. Y todo lo que el build del objetivo descarga fuera del lockfile, como el binario que baja un script postinstall o las capas bajo la imagen base, su escáner nunca lo vio, así que nadie lo está parcheando.
Blue team
CRACI ve el tráfico que entra en cada build y registra cada paquete y archivo que incorpora, incluidas las dependencias ocultas que se les escapan a las herramientas basadas en lockfiles, a cualquier profundidad del árbol transitivo. Su SBOM procede del build que se distribuyó, de modo que usted tiene la lista que un atacante nunca necesitó, antes de que nadie se ponga a buscar.
SBOM durante el build →Red team
Un aviso nuevo le indica exactamente qué versiones son vulnerables. Cree el exploit, escanee todo lo que responda y deje que el escaneo le diga quiénes son. Usted empieza el mismo día, mientras el equipo del objetivo sigue preguntando «¿nos afecta?» en un hilo de Slack.
Blue team
CRACI reevalúa de forma continua las SBOM monitorizadas con los nuevos datos de vulnerabilidades. El historial de builds muestra qué builds contenían la dependencia vulnerable, directa o transitiva, de modo que usted sabe dónde se distribuyó y durante cuánto tiempo.
¿Nos afecta? →Etapa 2 de 3
Explote el fallo antes de que se parchee, o sáltese el fallo y aprovéchese del pipeline del objetivo.
Red team
La IA convierte un aviso y el diff de un parche en un ataque funcional antes de que el equipo de seguridad del objetivo haya hecho el triaje del ticket. La divulgación es su pistoletazo de salida. La planificación del sprint del objetivo es la semana que viene.
Blue team
Los controles de política pueden bloquear cualquier build que contenga una CVE concreta, de modo que la versión vulnerable deja de distribuirse en el momento en que usted lo decide, por muy abajo que esté en el árbol.
Corrección de CVE →Red team
Los workflows confían en etiquetas como @v4, y las etiquetas se pueden mover. Comprometa una GitHub Action popular y todos los workflows que la usan ejecutarán su código, con los secretos de ellos al alcance.
Blue team
CRACI registra en la SBOM del build las GitHub Actions que ejecuta un workflow, fijadas al commit que realmente se ejecutó. Cuando una acción se ve comprometida, usted puede ver qué builds ejecutaron el código malicioso en lugar de deducirlo de una etiqueta.
Lista de comprobación de seguridad de CI/CD →Etapa 3 de 3
Llévese los secretos y quédese por si hay más.
Red team
Una versión maliciosa de un paquete ejecuta su script de instalación dentro del build, donde están los tokens y las credenciales de nube. Los runners de CI suelen poder llegar a todo internet, así que los secretos salen hacia su servidor antes de que nadie sepa que el paquete es malicioso.
Blue team
Una política de egress de denegación por defecto permite a un build llegar a sus fuentes de paquetes y destinos de publicación, y bloquea todo lo demás. El malware que envía sus secretos al host de un atacante queda bloqueado, incluso como paciente cero de un ataque que nadie ha visto antes, y usted recibe una alerta de la infracción de la política.
Políticas de egress →Red team
Los runners autoalojados de larga duración son un regalo: plante algo en el espacio de trabajo o en la caché de herramientas y espere a que el siguiente job, y el siguiente conjunto de secretos, vengan a usted.
Blue team
Cada job de CRACI se ejecuta en su propia máquina virtual aislada, de modo que nada de lo que deja un job espera al siguiente. Tampoco hay una flota de runners que usted tenga que parchear y reforzar.
Runners gestionados frente a autoalojados →Después de la divulgación
El atacante no necesita saber que usted ejecuta la dependencia. Prueba el exploit en todas partes y ve qué responde. Su equipo necesita saber dónde se distribuyó esa dependencia. La diferencia está en si tiene que ponerse a buscar, y cada año hay más carreras que correr: vea cuántas CVE se publican cada día.
Red team
Blue team, sin registro del build
Blue team, con CRACI
Ningún control por sí solo detiene todos los ataques a la cadena de suministro. Combínelos, y cada etapa anterior se vuelve más difícil. Para ver en detalle la parte del pipeline, consulte la lista de comprobación de seguridad del pipeline de CI/CD.
Los atacantes vigilan cada aviso y prueban el exploit en todo el mundo el día en que se divulga una vulnerabilidad. Nunca necesitaron su lista de dependencias. Usted sí. CRACI le da a su equipo esa lista, obtenida del propio build, y cierra las puertas con las que cuentan los atacantes: el egress abierto y los runners compartidos.
Un ataque al código, las herramientas o los servicios con los que se construye un producto, como un paquete de código abierto, un componente de CI/CD o el sistema de build, en lugar de al propio producto. Un solo compromiso llega a todas las organizaciones que utilizan el componente afectado.
El gusano Shai-Hulud (desde 2025) se propagó por paquetes npm infectados y robó secretos de CI. El compromiso de tj-actions/changed-files (CVE-2025-30066) secuestró una GitHub Action popular. La puerta trasera de xz utils (CVE-2024-3094) se introdujo en una biblioteca de compresión upstream. Log4Shell (CVE-2021-44228) explotó un fallo en una biblioteca de registro de Java muy utilizada. El Bash Uploader de Codecov (2021) se alteró para enviar credenciales de CI a un servidor externo, y SolarWinds Orion (2020) distribuyó código malicioso insertado en el build.
SolarWinds. En 2020, unos atacantes con acceso encubierto al proceso de build de SolarWinds Orion insertaron código malicioso en sus versiones, y los clientes lo instalaron como una actualización normal. Demostró que un árbol de código fuente limpio no basta: el propio build tiene que ser fiable y verificable.
Normalmente no, y no les hace falta. La mayoría de los ataques van a por un paquete y no a por una empresa: una vez publicado un aviso, los atacantes prueban el exploit contra todo lo que pueda ejecutar una versión vulnerable y ven qué responde. Las pistas públicas, como las versiones en bundles de JavaScript o en repositorios de código abierto, les ayudan a apuntar. La asimetría es que usted sí necesita la lista: para saber si le afecta, tiene que saber qué distribuyó cada build, incluido lo que descargó fuera del lockfile.
Ningún control por sí solo los detiene todos. Conserve una SBOM de lo que distribuye cada build y monitorícela con los nuevos avisos, fije las dependencias y las GitHub Actions, bloquee las versiones vulnerables en el build, restrinja a qué pueden conectarse los jobs de CI, aísle los jobs y limite sus secretos, y verifique que los artefactos desplegados son los que usted compiló.
Confirme un lockfile en el repositorio e instale a partir de él en CI, y desactive los scripts de instalación donde un build no los necesite (--ignore-scripts de npm). Conserve un registro de qué versiones de paquetes instaló realmente cada build, para poder comprobarlo rápidamente cuando se anuncie una nueva oleada como Shai-Hulud. Restrinja a qué pueden conectarse los jobs de CI, para que un script de instalación malicioso no pueda enviar sus tokens fuera, y rote cualquier token al que una versión infectada haya podido llegar.
En los ejercicios de seguridad, el red team hace de atacante y el blue team defiende. Esta página usa la misma división: cada etapa de un ataque a la cadena de suministro en palabras del atacante, con la respuesta de la defensa.
Los conocidos, sí. Una versión maliciosa que tiene una CVE publicada, como la puerta trasera de xz, se señala como cualquier otra vulnerabilidad, y un control de política puede bloquear los builds que la contengan. CRACI no analiza el comportamiento de los paquetes ni puntúa su reputación, por lo que un paquete malicioso totalmente nuevo no se señala hasta que existe un aviso. Para eso está la política de egress: con la denegación por defecto, el build solo puede llegar a los hosts que necesita, así que el paquete no puede enviar sus secretos fuera, incluso en un ataque que nadie ha visto antes.