Quels sont les risques liés à la chaîne d'approvisionnement dans la CI/CD cloud et comment les réduire ?
Réponse courte
La CI/CD est de grande valeur car elle détient les identifiants de déploiement et exécute du code non fiable. Les risques incluent les dépendances et actions de build compromises, les secrets divulgués ou trop larges, les actions tierces mutables, et les runners ou la confiance OIDC surprivilégiés. Réduisez-les avec des dépendances épinglées et vérifiées, une fédération OIDC à courte durée de vie au lieu de clés à longue durée de vie, le moindre privilège restreint à des dépôts/branches précis, des runners éphémères isolés, et des artefacts signés à provenance tracée (SLSA).
Le pipeline CI/CD est l'une des cibles les plus attrayantes d'un environnement cloud : il détient habituellement les identifiants capables de déployer en production, et il exécute régulièrement du code de nombreuses sources. Compromettez le pipeline et vous pouvez livrer une porte dérobée avec la signature même du projet.
D'où vient le risque
- Dépendances et actions de build. Un paquet npm/PyPI empoisonné ou une action CI tierce détournée s'exécute à l'intérieur de votre pipeline de confiance. Les tags mutables (
actions/checkout@v4) peuvent être repointés vers du code malveillant après que vous les avez adoptés. - Secrets dans le pipeline. Des clés admin cloud à longue durée de vie stockées comme secrets de CI sont une cible unique de grande valeur ; elles fuitent via les journaux, les forks ou les workflows de pull request.
- Runners et confiance surprivilégiés. Un runner partagé qui traite de nombreux dépôts, ou une politique de confiance OIDC trop largement définie, permet à un dépôt compromis d'atteindre bien au-delà de lui-même.
Comment le réduire
- Épinglez et vérifiez. Épinglez les dépendances et les actions tierces à des empreintes immuables / SHA de commit, et vérifiez les sommes de contrôle ou les signatures pour qu'un tag repointé ne puisse pas glisser du nouveau code.
- Utilisez la fédération OIDC, pas des clés statiques. Le runner échange un jeton OIDC signé contre des identifiants cloud à courte durée de vie, restreints à un dépôt et une branche précis. Rien de durable ne reste dans la CI à voler.
- Moindre privilège et isolation. Restreignez le rôle cloud du pipeline à exactement ce qu'un déploiement requiert, et utilisez des runners éphémères à usage unique pour que l'état de build ne fuite jamais entre les jobs.
- Signez les artefacts et tracez la provenance. Générez une provenance de build signée (SLSA) pour que les consommateurs puissent vérifier qu'un artefact provient de votre vrai pipeline et n'a pas été substitué.
Ce que recherchent les recruteurs
Reconnaître le pipeline comme un actif détenant des identifiants et exécutant du code, citer les identifiants OIDC à courte durée de vie plutôt que les clés statiques, l'épinglage par empreinte, et la provenance/signature des artefacts.
Questions de suivi probables
- Pourquoi épingler une GitHub Action à un SHA de commit complet est-il plus sûr qu'à un tag ?
- Comment la fédération OIDC supprime-t-elle le besoin de clés cloud à longue durée de vie dans la CI ?
- Qu'est-ce que la provenance de build / SLSA et contre quelle attaque protège-t-elle ?