Su aplicación es de bajo riesgo. Su pipeline de build no.

El razonamiento es válido, hasta cierto punto

Lo oímos a menudo, y suele tener una base sensata. La aplicación es un panel interno, un pipeline de datos o un pequeño servicio con unos pocos usuarios. No contiene nada que un atacante quiera. El presupuesto de seguridad va primero al producto de cara al cliente.

Esa lógica vale para la aplicación. No vale para la forma en que se construye la aplicación. Todo equipo, distribuya lo que distribuya, tiene un pipeline de CI con credenciales dentro y un árbol de dependencias que no escribió. Vale la pena atacarlos porque son compartidos, y comprometerlos da acceso a todo lo demás a lo que llegan esas credenciales: sus registros, sus cuentas en la nube y sus otros repositorios.

Ataques a los que no les importaba qué hacía la aplicación

Ninguno de estos incidentes iba dirigido a un tipo concreto de aplicación. Cada uno llegó a los equipos a través de una herramienta o un paquete que usaban para construir software.

tj-actions/changed-files, 2025

Se comprometió una GitHub Action muy utilizada que detecta archivos modificados. Según CISA, las versiones maliciosas estuvieron activas entre el 12 y el 15 de marzo de 2025, y el ataque expuso secretos como claves de acceso, tokens de acceso personal de GitHub, tokens de npm y claves RSA privadas. Wiz informó de que el código volcaba la memoria del runner de CI, de modo que en los repositorios públicos los secretos acabaron en los registros de los workflows. Los workflows que hacían referencia a la acción mediante una etiqueta de versión ejecutaron el código malicioso, fuera cual fuera el contenido del repositorio.

Gusano de npm Shai-Hulud, 2025

En septiembre de 2025, CISA advirtió de un gusano autorreplicante que había comprometido más de 500 paquetes de npm. Recopilaba tokens de acceso personal de GitHub y claves de API en la nube de AWS, Google Cloud y Azure. Unit 42 de Palo Alto Networks describió cómo usaba tokens de npm robados para publicar versiones infectadas de los demás paquetes de la víctima, y cómo una oleada posterior se ejecutaba durante la preinstalación, lo que amplió su alcance a los pipelines de CI/CD.

3:27

Codecov Bash Uploader, 2021

Un atacante extrajo una credencial aprovechando un error en el proceso de build de la imagen Docker de Codecov y modificó el script Bash Uploader que muchos equipos ejecutaban en CI. Del 31 de enero al 1 de abril de 2021, el script alterado podía enviar a un tercero variables de entorno, incluidas credenciales, tokens y claves disponibles en el entorno de CI. Se descubrió cuando un cliente notó que la suma de comprobación del script no coincidía.

xz utils, 2024

Se incrustó código malicioso en las versiones 5.6.0 y 5.6.1 de XZ Utils, una biblioteca de compresión de datos que puede estar presente en distribuciones de Linux. CISA recomendó volver a una versión no comprometida, como la 5.4.6, y buscar actividad maliciosa. Una biblioteca de compresión es de lo menos glamuroso que puede ser una dependencia, y aun así fue un objetivo.

event-stream, 2018

Una persona que se hizo pasar por un mantenedor servicial se hizo con el popular paquete de npm event-stream y añadió una dependencia maliciosa, flatmap-stream, en la versión 3.3.6. El equipo de npm informó de que la carga útil iba dirigida a una aplicación concreta, el monedero de bitcoin Copay. Todos los demás que instalaron event-stream también recibieron el código malicioso.

Qué tienen en común estos incidentes

• Ocurrieron durante el build o la instalación. El código malicioso se ejecutó en máquinas de desarrolladores y runners de CI, no en la aplicación en producción.
• Iban a por las credenciales. Los tokens y las claves del pipeline eran el botín, porque abren puertas más allá del proyecto que se está compilando.
• Llegaron a través de nombres de confianza. Una acción conocida, un paquete conocido, un script conocido. Nadie decidió instalar malware.
• La primera pregunta posterior fue la misma. ¿Alguno de nuestros builds descargó la versión maliciosa, y a qué podía llegar? Los equipos sin un registro de lo que usó cada build tuvieron que reconstruirlo.

Cómo es el esfuerzo mínimo

No necesita un equipo de seguridad para cubrir lo básico. La mayoría de los consejos de GitHub y CISA caben en una lista breve:

1. Fije las GitHub Actions de terceros a un SHA de commit completo en lugar de a una etiqueta, para que una etiqueta movida no pueda cambiar lo que se ejecuta.
2. Incluya los lockfiles en el repositorio y fije las versiones de las dependencias a versiones que sepa que son buenas.
3. Dé a los tokens de CI los permisos más limitados que funcionen, y rótelos cuando un incidente afecte a algo que utiliza.
4. Exija autenticación multifactor resistente al phishing en las cuentas de desarrollo y publicación.
5. Conserve un registro de lo que instaló cada build, para poder responder «¿nos afectó?» a partir de datos y no de la memoria.

Los cuatro primeros son configuración. El quinto es el que se saltan la mayoría de los equipos pequeños, porque requiere herramientas.

Dónde encaja CRACI con poco esfuerzo

CRACI se encarga del registro y añade un límite de red, sin pedirle que cambie su aplicación ni sus workflows.

• Una línea por job. Cambie runs-on a craci. Sus workflows de GitHub Actions se quedan como están, y las ejecuciones siguen apareciendo en GitHub.
• Una SBOM de cada build. CRACI registra los paquetes que cada job descarga realmente, incluidos los restaurados desde cachés, y exporta el resultado en CycloneDX o SPDX.
• Una traza de red por job. Cuando se anuncia un incidente, puede comprobar qué builds descargaron el paquete afectado y a dónde se conectó cada job.
• Una política de egress que puede cambiar a denegación por defecto. Permita las fuentes de paquetes que necesita un job, y un paso comprometido tendrá menos lugares a los que enviar lo que encuentre. Si las políticas fallan, bloquean, y las infracciones activan una alerta.
• Reevaluación continua. Las SBOM monitorizadas se vuelven a comprobar a medida que se publican nuevas vulnerabilidades, para que un build antiguo no siga «limpio» solo porque nadie miró.

Para ser claros sobre los límites: una política de egress no habría impedido que el ataque a tj-actions imprimiera secretos en un registro público, y ninguna herramienta deshace un token filtrado. Fijar versiones y rotar credenciales sigue siendo importante. Lo que cambia CRACI es la rapidez con la que puede responder si estuvo expuesto, y hasta dónde puede llegar un paso comprometido.

Poner en marcha un primer workflow solo requiere instalar la GitHub App y cambiar una línea a runs-on: craci.

Cuánto cuesta

CRACI solo cobra por los minutos de build: $0.002 por minuto de vCPU ($0.004 para un runner de 2 vCPU por defecto), medidos por segundos, sin cuota mensual ni cargo por SBOM. Consulte los precios para ver todas las condiciones. Las startups que cumplan los requisitos pueden solicitar el programa para startups, con un mínimo de 100k minutos de build gratuitos y un onboarding personalizado.

Si vende software en la UE, también merece la pena comprobar si se le aplica el Cyber Resilience Act. Nuestra guía sobre el CRA explica el alcance y los plazos.