Seguridad de CI/CD

Por qué los pipelines son un objetivo

• Guardan las llaves. Las credenciales de la nube, los tokens de registros y las claves de firma pasan todos por CI.
• Ejecutan código ajeno. Cada dependencia, script de instalación y acción de terceros se ejecuta en el runner.
• Llegan a producción. Lo que sale del pipeline se considera de confianza, se firma y se distribuye. Un atacante en el build llega a todos los clientes a la vez.
• Pocas personas los vigilan. Los archivos de workflow cambian poco y se revisan menos que el código de la aplicación.

Tanto el ataque a tj-actions como el gusano de npm Shai-Hulud fueron a por los secretos en CI. Consulte qué es un ataque a la cadena de suministro para ver cómo se desarrollan estos ataques.

Los principales riesgos de seguridad de CI/CD

El OWASP Top 10 CI/CD Security Risks es la referencia estándar. Agrupados según lo que falla:

Área	Riesgos de OWASP	Cómo se manifiesta
Quién puede cambiar qué	Control de flujo insuficiente, gestión inadecuada de identidades y accesos	El código llega a producción sin revisión, o las cuentas antiguas conservan su acceso
Qué se ejecuta en el pipeline	Abuso de la cadena de dependencias, ejecución de pipeline envenenado	Un paquete malicioso o un workflow modificado se ejecuta con el acceso del job
A qué puede acceder un job	Controles de acceso insuficientes basados en el pipeline, higiene insuficiente de las credenciales	Un job puede leer todos los secretos, y los tokens duran años
Cómo está configurado	Configuración insegura del sistema, uso sin control de servicios de terceros	Runners sin parches e integraciones con más acceso del que necesitan
Qué puede demostrar	Validación inadecuada de la integridad de los artefactos, registro y visibilidad insuficientes	Nadie sabe decir qué entró en una versión ni a qué se conectó un job

Para ver cada riesgo asociado a los controles del runner, consulte la comparativa de seguridad de los runners.

Buenas prácticas de seguridad de CI/CD

1. Trate las definiciones de pipeline como código de producción. Exija revisión de los archivos de workflow y mantenga las pull requests que no son de confianza lejos de los secretos.
2. Limite lo que puede hacer cada job. Dé a los tokens el mínimo permiso que necesiten y prefiera las credenciales de corta duración a los secretos almacenados.
3. Fije las acciones de terceros a un hash de commit. Las etiquetas se pueden mover a otro código.
4. Aísle los jobs. Ejecute cada job en un entorno nuevo, de modo que nada pase al siguiente.
5. Controle el tráfico saliente. Un build necesita fuentes conocidas y destinos conocidos. Bloquear todo lo demás impide que salgan los secretos robados. Consulte política de salida de GitHub Actions.
6. Registre lo que ha ocurrido. Conserve una SBOM de cada build y un registro de su actividad de red, para poder responder preguntas después.

Para ver la versión paso a paso, consulte la lista de comprobación de seguridad del pipeline de CI/CD.

Tipos de herramientas de seguridad de CI/CD

Tipo	Qué hace	Ejemplos
Seguridad de los runners	Aísla los jobs y controla a qué pueden acceder mientras se ejecutan	CRACI, StepSecurity
Gestión de la postura	Detecta ajustes arriesgados en pipelines y repositorios	Legit Security, Cycode, Apiiro, OX Security
Escaneo de código y dependencias	Comprueba el código, las dependencias y los secretos en cada cambio	GitHub Advanced Security, Snyk, Semgrep
SBOM y evidencias	Registra qué entró en cada versión	CRACI, Syft, Anchore

Actúan en etapas distintas, por lo que la mayoría de los equipos las combina. Un escáner examina los archivos antes del build, las herramientas de postura examinan los ajustes, y la seguridad de los runners actúa mientras se ejecuta el job, que es cuando actúa un paquete malicioso. Consulte la comparativa de herramientas de seguridad de la cadena de suministro de software y la comparativa de herramientas de DevSecOps.

Dónde encaja CRACI

CRACI protege el build mientras se ejecuta. Sustituye sus runners alojados en GitHub por otros más rápidos y de menor coste: cada job se ejecuta en su propia máquina virtual aislada, una política de salida bloquea las conexiones que el build no necesita, y cada paquete que descarga el job entra en una SBOM. Como la política solo permite lo que el build necesita, le protege incluso frente a un ataque que nadie ha visto antes.

CRACI no comprueba la configuración de sus workflows, no escanea el código fuente ni los secretos, y no firma la procedencia, así que conserve o añada herramientas para ello. GitHub Actions es el sistema de CI compatible hoy, y otros sistemas de CI están en la hoja de ruta.

Seguridad de CI/CD: preguntas frecuentes

¿Qué es la seguridad de CI/CD?

Es la práctica de proteger los pipelines que compilan, prueban y distribuyen software, incluidas sus credenciales, el código que ejecutan y los artefactos que producen.

¿Cuáles son los mayores riesgos de seguridad de CI/CD?

Las dependencias y acciones de terceros maliciosas, los pipelines envenenados, los tokens con demasiados permisos y los secretos de larga duración, y la falta de visibilidad sobre lo que hizo un build. OWASP Top 10 CI/CD Security Risks es la lista de referencia.

¿Qué es la ejecución de pipeline envenenado?

Un atacante cambia lo que ejecuta un pipeline, por ejemplo editando mediante una pull request un archivo de workflow o un script al que este llama, de modo que su código se ejecuta con el acceso del pipeline.

¿Cómo se protege un pipeline de CI/CD?

Revise los cambios en el pipeline, dé a cada job el mínimo acceso que necesite, fije las acciones de terceros por hash de commit, aísle los jobs, restrinja el tráfico saliente y conserve un registro de lo que hizo cada build.

¿Cuál es la diferencia entre la seguridad de CI/CD y DevSecOps?

DevSecOps es la práctica más amplia de integrar la seguridad en la forma de desarrollar software. La seguridad de CI/CD se centra en el propio pipeline, del que también dependen las herramientas de DevSecOps.

¿GitHub Actions necesita seguridad adicional?

GitHub ofrece controles como los permisos de tokens y el escaneo de secretos, pero hay que configurarlos, y los runners alojados no restringen el tráfico saliente de forma predeterminada. La mayoría de los equipos añade fijación, reglas de revisión y controles en el runner.