¿Cuáles son los riesgos de la cadena de suministro en CI/CD en la nube y cómo se reducen?
Respuesta breve
La CI/CD es de alto valor porque guarda las credenciales de despliegue y ejecuta código no confiable. Los riesgos incluyen dependencias y acciones de build comprometidas, secretos filtrados o demasiado amplios, acciones de terceros mutables, y runners o confianza OIDC con privilegios excesivos. Redúcelos con dependencias fijadas y verificadas, federación OIDC de corta duración en vez de claves de larga duración, privilegio mínimo acotado a repos/ramas concretos, runners efímeros aislados, y artefactos firmados con procedencia rastreada (SLSA).
La pipeline de CI/CD es uno de los objetivos más atractivos en un entorno de nube: normalmente guarda las credenciales que pueden desplegar a producción, y rutinariamente ejecuta código de muchas fuentes. Compromete la pipeline y podrás enviar una puerta trasera con la propia firma del proyecto.
De dónde viene el riesgo
- Dependencias y acciones de build. Un paquete npm/PyPI envenenado o una acción de CI de terceros secuestrada se ejecuta dentro de tu pipeline de confianza. Los tags mutables (
actions/checkout@v4) pueden reapuntarse a código malicioso después de que los adoptes. - Secretos en la pipeline. Las claves de administrador de la nube de larga duración almacenadas como secretos de CI son un único objetivo de alto valor; se filtran a través de registros, forks o flujos de pull request.
- Runners y confianza con privilegios excesivos. Un runner compartido que procesa muchos repos, o una política de confianza OIDC acotada de forma demasiado amplia, permite que un repo comprometido alcance mucho más allá de sí mismo.
Cómo reducirlo
- Fija y verifica. Fija las dependencias y las acciones de terceros a digests inmutables / SHA de commit, y verifica las sumas de comprobación o las firmas para que un tag reapuntado no pueda colar código nuevo.
- Usa federación OIDC, no claves estáticas. El runner intercambia un token OIDC firmado por credenciales de nube de corta duración, acotadas a un repo y una rama concretos. Nada de larga duración queda en CI para robar.
- Privilegio mínimo y aislamiento. Acota el rol de nube de la pipeline a exactamente lo que un despliegue necesita, y usa runners efímeros de un solo uso para que el estado del build nunca se filtre entre jobs.
- Firma los artefactos y rastrea la procedencia. Genera procedencia de build firmada (SLSA) para que los consumidores puedan verificar que un artefacto vino de tu pipeline real y no fue sustituido.
Qué buscan los entrevistadores
Reconocer la pipeline como un activo que guarda credenciales y ejecuta código, mencionar las credenciales OIDC de corta duración frente a las claves estáticas, el fijado por digest, y la procedencia/firma de artefactos.
Posibles preguntas de seguimiento
- ¿Por qué fijar una GitHub Action a un SHA de commit completo es más seguro que a un tag?
- ¿Cómo elimina la federación OIDC la necesidad de claves de nube de larga duración en CI?
- ¿Qué es la procedencia de build / SLSA y contra qué ataque defiende?