Votre pipeline CI/CD est l'un des systèmes les plus puissants — et les plus dangereux — de votre infrastructure. Il a accès au code source, aux secrets, aux identifiants cloud, aux environnements de production et aux registres de conteneurs. Un pipeline compromis peut déployer du code malveillant directement en production, exfiltrer des secrets ou fournir à un attaquant un accès persistant à l'ensemble de votre infrastructure. Le durcissement de votre pipeline n'est pas optionnel — c'est une exigence de sécurité critique.
Comprendre la surface d'attaque
Les pipelines CI/CD présentent une surface d'attaque large que de nombreuses organisations sous-estiment :
- Dépôts de code source — des comptes développeurs compromis ou des pull requests malveillantes peuvent injecter du code que le pipeline compilera et déploiera.
- Configuration du pipeline — si les définitions de pipeline (Jenkinsfiles, workflows GitHub Actions, YAML GitLab CI) sont stockées dans le dépôt, toute personne ayant un accès en écriture peut modifier le processus de build.
- Dépendances — les attaques de supply chain via des paquets compromis, des images de base de conteneurs ou des outils de build peuvent injecter du code malveillant lors de la compilation.
- Secrets et identifiants — les clés API, identifiants cloud et tokens de déploiement stockés dans le pipeline sont des cibles de haute valeur.
- Environnements de build — les runners de build partagés peuvent fuiter des secrets entre les projets ou permettre un mouvement latéral entre les équipes.
Sécuriser le code source et la configuration du pipeline
- Exiger la revue de code — imposez des revues de pull request obligatoires avant que du code n'atteigne la branche principale. Utilisez des règles de protection de branche pour empêcher les push directs vers les branches de production.
- Protéger les définitions de pipeline — traitez les fichiers de configuration CI/CD avec la même rigueur que le code applicatif. Les modifications des fichiers de workflow devraient nécessiter une revue supplémentaire de l'équipe sécurité ou plateforme.
- Signer les commits — implémentez la signature de commits avec des clés GPG ou SSH pour vérifier l'identité des auteurs du code et prévenir la falsification de commits.
- Limiter les permissions du dépôt — suivez le principe du moindre privilège. Tous les développeurs n'ont pas besoin d'un accès en écriture à chaque dépôt, et les contributeurs externes ne devraient jamais déclencher automatiquement des exécutions de pipeline.
Gestion des secrets
Une gestion correcte des secrets est sans doute l'aspect le plus important de la sécurité du pipeline :
- Ne jamais stocker de secrets dans le code — cela inclut les fichiers de configuration du pipeline, les Dockerfiles et le code applicatif. Utilisez la gestion de secrets intégrée de votre plateforme CI/CD ou un coffre-fort externe.
- Utiliser des gestionnaires de secrets externes — intégrez HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault plutôt que de vous fier uniquement au stockage de secrets de la plateforme CI.
- Limiter la portée des secrets — limitez quels pipelines et environnements peuvent accéder à chaque secret. Les identifiants de production ne devraient pas être disponibles pour les builds de branches de développement.
- Rotation régulière — automatisez la rotation des secrets et assurez-vous que votre pipeline peut gérer les mises à jour d'identifiants sans intervention manuelle.
- Auditer les accès — loguez chaque accès à un secret et examinez ces logs régulièrement pour détecter des anomalies.
Sécuriser le processus de build
- Utiliser des environnements de build isolés — exécutez chaque build dans un conteneur ou une VM fraîche et éphémère. Ne réutilisez jamais les environnements de build entre les projets ou les exécutions. Cela empêche les fuites de secrets entre les builds.
- Épingler les dépendances — utilisez des fichiers de verrouillage (package-lock.json, Pipfile.lock, go.sum) et vérifiez les checksums. Pour les images de base de conteneurs, épinglez des digests SHA spécifiques plutôt que des tags mutables.
- Scanner les vulnérabilités — intégrez le scan de dépendances (Snyk, Trivy, Grype) et l'analyse statique (SonarQube, Semgrep) dans chaque exécution de pipeline. Échouez les builds qui introduisent des vulnérabilités critiques.
- Signer les artefacts — signez les images de conteneurs avec Cosign ou Notary et vérifiez les signatures avant le déploiement. Cela garantit que seules les images compilées par votre pipeline peuvent être déployées en production.
- Implémenter la génération de SBOM — générez un Software Bill of Materials pour chaque build afin de maintenir la visibilité sur les composants inclus dans vos déploiements, ce qui est de plus en plus important pour la conformité NIS2.
Sécurité du déploiement
- Séparer les environnements — utilisez des identifiants et comptes de service distincts pour les déploiements de développement, staging et production. Un pipeline de dev compromis ne devrait pas pouvoir accéder à la production.
- Implémenter des portes d'approbation — exigez une approbation manuelle pour les déploiements en production, surtout pour les services sensibles. De nombreuses plateformes CI/CD supportent nativement les workflows d'approbation.
- Utiliser GitOps pour la production — envisagez une approche GitOps où le pipeline ne met à jour qu'un dépôt Git, et un opérateur séparé déploie en production. Cela élimine la nécessité pour le système CI d'avoir un accès direct à la production.
- Surveiller les déploiements — implémentez des rollbacks automatisés déclenchés par des échecs de vérification de santé et la détection d'anomalies dans votre stack de monitoring.
Comment ICTLAB peut vous aider
ICTLAB fournit des évaluations de sécurité et services de durcissement de pipelines CI/CD pour les organisations belges. Nous examinons vos pipelines existants pour identifier les vulnérabilités, implémentons des contrôles de sécurité à travers le processus de build et de déploiement, et intégrons le scan de sécurité dans vos workflows — le tout dans le cadre d'une approche DevSecOps complète.