Lista de comprobación de seguridad del pipeline de CI/CD

Workflows

• Fije las acciones de terceros a un SHA de commit completo. GitHub lo describe como la única forma actual de usar una acción como versión inmutable. Una etiqueta se puede cambiar para que apunte a otro código. En marzo de 2025, CISA informó de que todas las versiones de tj-actions/changed-files estuvieron comprometidas durante tres días.
• Dé a GITHUB_TOKEN el mínimo privilegio. Establezca por defecto solo lectura para el contenido y conceda más por job.
• Nunca descargue código no fiable en pull_request_target. Estos workflows se ejecutan con secretos y permisos elevados.
• Mantenga las entradas no fiables fuera de los scripts. Pase los títulos, los nombres de rama y otros valores controlados por el usuario mediante una variable de entorno, en lugar de expandirlos en un comando de shell.
• Revise los cambios en los archivos de workflow. Exija la revisión de los propietarios del código para .github/workflows.

Secretos

• Dé preferencia a las credenciales de corta duración. Utilice OpenID Connect para que los jobs obtengan de su proveedor de nube tokens de corta duración y alcance limitado, en lugar de claves de larga duración almacenadas como secretos.
• Limite los secretos a entornos. Coloque las credenciales de producción tras un entorno con revisores obligatorios.
• Rote tras un incidente. El consejo de CISA tras el ataque a tj-actions fue tratar los secretos expuestos como comprometidos y rotarlos de inmediato.

Runners

• Utilice runners efímeros. Una máquina nueva por job no deja nada para el siguiente.
• Mantenga los runners autoalojados fuera de los repositorios públicos. GitHub dice que casi nunca deben usarse en ellos, porque cualquiera puede abrir una pull request contra el repositorio.
• Aísle los jobs. Un job no debe poder leer el espacio de trabajo ni las credenciales de otro job.

Red

• Controle el tráfico de salida. Permita las fuentes de paquetes y los servicios que necesita un job y bloquee el resto, de modo que una dependencia comprometida no pueda enviar secretos al exterior. Cómo detiene la exfiltración una política de salida
• Registre las conexiones. Conserve una traza de a qué se conectó cada job, para poder investigarlo más adelante.

Dependencias

• Añada los lockfiles al repositorio. Los builds deben resolver las mismas versiones cada vez.
• Revise las dependencias nuevas. Compruebe qué añade una pull request antes de fusionarla.
• Condicione los builds a los hallazgos. Bloquee un build cuando incorpore un paquete con una vulnerabilidad crítica conocida, antes de que se distribuya el artefacto.

Evidencias del build

• Registre una SBOM de lo que descargó el build. Un escaneo posterior de los archivos describe lo que se declaró, no lo que utilizó el build.
• Firme la procedencia. Vincule cada artefacto con el build que lo produjo, para poder comprobar después que lo que se ejecuta es lo que se compiló.
• Monitorice lo distribuido. Vuelva a comprobar los builds publicados cuando se divulguen nuevas vulnerabilidades.

Qué herramientas cubren qué puntos

Los escáneres cubren los puntos de dependencias, las herramientas de refuerzo de pipelines cubren los puntos de workflows, y los agentes en el runner o un runner seguro cubren los puntos de red y evidencias. CRACI es el runner: aplica una política de salida que bloquea si falla, registra una SBOM de lo que descargó cada job, permite que los controles de política bloqueen un build por sus hallazgos y devuelve SBOM, trazas de red y procedencia a través de su API. No escanea código ni workflows. Consulte la comparativa de herramientas de seguridad de CI/CD para ver qué herramienta cubre qué.

Seguridad del pipeline de CI/CD: preguntas frecuentes

¿Qué es la seguridad del pipeline de CI/CD?

Es la protección de los sistemas que compilan y distribuyen su software: las definiciones de workflow, los secretos que utilizan, los runners que los ejecutan, las dependencias que descargan y los artefactos que producen. Un pipeline comprometido puede distribuir código malicioso en su nombre sin tocar su código fuente.

¿Por qué fijar las GitHub Actions a un SHA de commit?

Las etiquetas se pueden cambiar para que apunten a otro código. GitHub indica que fijar una acción a un SHA de commit completo es actualmente la única forma de usar una acción como versión inmutable. En marzo de 2025, CISA informó de que todas las versiones de tj-actions/changed-files estuvieron comprometidas durante tres días.

¿Qué permisos debe tener GITHUB_TOKEN?

Los mínimos que necesite cada job. Establezca por defecto solo lectura para el contenido del repositorio y conceda más por job, únicamente donde un job lo necesite.

¿Necesito controlar el tráfico de salida en CI?

Si sus jobs tienen acceso a secretos y ejecutan código de terceros, sí. La mayoría de los jobs solo necesitan acceder a un conjunto conocido de registros de paquetes y servicios. Una política de salida bloquea todo lo demás, de modo que una dependencia comprometida no puede enviar secretos al servidor de un atacante.