CI/CD et fuites de secrets : sécuriser vos pipelines

Les incidents liés à des secrets exposés dans GitHub ou GitLab font encore les gros titres : clés cloud, PAT OAuth, certificats embarqués dans des artefacts. Les pipelines CI/CD amplifient le risque : un secret volé permet de reconstruire, signer ou déployer du code au nom de l’organisation.

Causes fréquentes

• Commits contenant .env ou clés en dur — parfois supprimés visuellement mais toujours présents dans l’historique Git.
• Forks et miroirs publics qui répliquent l’historique sensible.
• Variables d’environnement loguées par erreur dans les sorties de job.
• Comptes de service partagés avec des permissions administrateur excessives.

Contrôles prioritaires

1. Scan de secrets sur chaque push (Gitleaks, TruffleHog, intégrations natives GitHub Advanced Security).
2. Rotation automatique ou procédure documentée dès qu’un secret a touché une branche distante — la suppression du commit ne suffit pas.
3. Secrets managers (Vault, cloud KMS) et OIDC entre CI et cloud plutôt que clés longue durée dans les variables de pipeline.
4. Moindre privilège sur les rôles IAM utilisés par les runners : un job de build ne doit pas pouvoir effacer la production.

Menaces en aval

Un attaquant qui compromet le pipeline peut introduire du code malveillant signé ou approuvé par vos processus — dépassant la simple exfiltration. Surveillez les comportements réseau des builds (connexions vers des domaines rares) et corrélez avec la réputation des destinations : les fuites DNS ou callbacks vers des C2 connus peuvent être détectés tôt si vous enrichissez les journaux proxy avec des bases type isMalicious.

Conclusion

La sécurité CI/CD est un programme : outillage, revue des permissions, culture « pas de secret dans le repo ». Les équipes qui mesurent le nombre de secrets détectés en pré-production — et le temps de remédiation — réduisent mécaniquement la probabilité d’incident en production.