Comment durcir la securite de vos serveurs CI/CD en 7 etapes — guide pratique pour les equipes DevSecOps en 2026

Vos pipelines CI/CD sont le systeme nerveux de votre delivery logicielle. Ils compilent votre code, executent vos tests, deploient en production, et pour cela, ils disposent d'acces privilegies a vos repositories, vos registres d'images Docker, vos clusters Kubernetes, vos bases de donnees et vos services cloud. Un attaquant qui compromet votre serveur CI/CD n'a pas besoin de chercher plus loin : il a acces a tout.

En 2026, les attaques ciblant les pipelines CI/CD ont explose. La compromission de SolarWinds en 2020 a ete le signal d'alarme. Depuis, les incidents se sont multiplies : Codecov (2021), CircleCI (2023), la faille critique TeamCity CVE-2024-27198, et plus recemment les 15 plugins malveillants decouverts sur le marketplace JetBrains. La tendance est claire : les attaquants ne ciblent plus seulement les applications — ils ciblent les systemes qui construisent les applications.

Ce guide presente 7 etapes concretes et actionnables pour durcir la securite de vos serveurs CI/CD, que vous utilisiez Jenkins, GitLab CI, TeamCity, GitHub Actions ou une autre plateforme. Chaque etape est illustree avec des exemples concrets et des references aux pratiques des entreprises francaises qui excellent en matiere de DevSecOps.

— Etape 1 : Inventorier et cartographier votre infrastructure CI/CD

Avant de durcir quoi que ce soit, vous devez savoir exactement ce que vous avez. L'inventaire complet de votre infrastructure CI/CD est le prerequis absolu de toute strategie de durcissement. Dans la plupart des entreprises, l'infrastructure CI/CD s'est construite organiquement au fil des annees, et personne ne dispose d'une vue d'ensemble a jour.

Identifiez chaque composant. Listez tous vos serveurs CI/CD (Jenkins master, controleurs GitLab, serveurs TeamCity), tous vos runners et agents (localisation, OS, privilegies ou non), tous vos pipelines actifs, et toutes les integrations avec des services tiers (registres Docker, cloud providers, outils de deploiement). N'oubliez pas les instances "shadow IT" — les serveurs Jenkins installes discretement par une equipe de developpeurs sur un poste de travail ou un VM de test.

Cartographiez les flux de donnees. Pour chaque pipeline, documentez : quels secrets sont utilises, quels repositories sont accedes, quels environnements sont deployes, quels artefacts sont produits. Cette cartographie revele immediatement les sur-privilegiements et les vecteurs d'attaque latents. Chez Doctolib, cette cartographie initiale a permis d'identifier 23 pipelines utilisant des tokens d'acces avec des permissions excessives — dont certains avec des acces en ecriture sur des repositories de production.

Evaluez la criticite. Classez chaque pipeline selon l'impact d'une compromission : un pipeline qui deploie en production un service financier n'a pas la meme criticite qu'un pipeline qui genere de la documentation interne. Cette classification oriente l'allocation des ressources de durcissement.

— Etape 2 : Isoler les runners et agents dans des reseaux dedies

Les runners CI/CD executent du code arbitraire — c'est leur raison d'etre. Un pipeline compile, installe des dependances, execute des scripts. Si un attaquant parvient a injecter du code malveillant dans un pipeline (via une pull request empoisonnee, une dependance compromise, ou une injection de commande dans un fichier .gitlab-ci.yml), le runner execute ce code avec les memes privileges que les builds legitimes.

Segmentation reseau stricte. Placez vos runners dans un VLAN dedie, isole du reseau d'entreprise et du reseau de production. Les runners ne doivent pouvoir communiquer qu'avec les services strictement necessaires : le serveur CI/CD (sur le port specifique), le registre d'artefacts, et les repositories Git. Tout autre trafic doit etre bloque par des regles de pare-feu explicites. Chez OVHcloud, les runners de build sont isoles dans un reseau dedie avec un micro-segmentation zero-trust : chaque runner ne peut atteindre que les 3 a 5 services dont son pipeline a besoin, rien de plus.

Runners ephemeres. Privilegiez les runners ephemeres (jetables apres chaque build) plutot que les runners persistants. Avec les executeurs Docker ou Kubernetes de GitLab CI, ou les agents cloud de Jenkins (AWS EC2, GCP), chaque build demarre dans un environnement vierge et est detruit a la fin. Cela elimine le risque de persistence d'un malware entre deux builds et empeche un attaquant de laisser une backdoor sur le runner.

Pas de mode privilegied Docker. N'executez jamais vos runners Docker en mode --privileged. Ce mode donne au conteneur un acces complet au noyau de la machine hote, annulant toute isolation. Pour les builds necessitant Docker-in-Docker (DinD), utilisez des solutions comme Kaniko, Buildah ou Podman qui ne necessitent pas de privileges root.

— Etape 3 : Securiser l'authentification et les secrets

Les secrets sont le nerf de la guerre en CI/CD. Tokens d'API, cles SSH, mots de passe de bases de donnees, credentials cloud, cles de signature — vos pipelines en manipulent des dizaines, et chacun est un vecteur de compromission potentiel. Selon une etude de GitGuardian, 72% des entreprises ont au moins un secret expose dans leur infrastructure CI/CD.

Utilisez un gestionnaire de secrets dedie. Ne stockez jamais de secrets dans les variables d'environnement du serveur CI/CD, dans les fichiers de configuration, ou pire, dans le code source. Utilisez des solutions comme HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou le Secret Manager de GCP. Le pipeline demande le secret au moment de l'execution, l'utilise en memoire, et ne le persiste nulle part. Vault permet en plus de generer des credentials ephemeres (dynamic secrets) qui expirent automatiquement apres le build.

Principe du moindre privilege radical. Chaque pipeline ne doit avoir acces qu'aux secrets dont il a strictement besoin. Un pipeline de tests unitaires n'a pas besoin du token de deploiement en production. Un pipeline de build frontend n'a pas besoin de la cle SSH vers le serveur de base de donnees. Configurez des politiques d'acces granulaires dans votre gestionnaire de secrets : par pipeline, par branche, par environnement.

Rotation automatique des secrets. Implementez une rotation automatique de tous vos secrets CI/CD au minimum tous les 90 jours, et idealement tous les 30 jours pour les secrets les plus critiques (tokens de deploiement production, cles de signature). La rotation automatique via Vault ou les services cloud natifs garantit que meme en cas de fuite, la fenetre d'exploitation est limitee dans le temps.

MFA et SSO pour l'acces aux plateformes CI/CD. L'acces a Jenkins, GitLab ou TeamCity doit etre protege par l'authentification multi-facteurs via votre fournisseur d'identite (Okta, Azure AD, Google Workspace). Desactivez l'authentification locale par mot de passe. Chez Thales, l'acces aux plateformes CI/CD requiert une authentification FIDO2 via YubiKey, eliminant tout risque de compromission par phishing ou credential stuffing.

— Etape 4 : Durcir les configurations de Jenkins, GitLab CI et TeamCity

Chaque plateforme CI/CD a ses particularites en matiere de securite. Les configurations par defaut sont rarement suffisantes pour un environnement de production. Voici les durcissements specifiques a appliquer sur les trois plateformes les plus utilisees en France.

Jenkins

Jenkins est historiquement la plateforme CI/CD la plus deployee et aussi la plus attaquee. Son architecture a base de plugins et son systeme de permissions complexe en font une cible de choix. Actions essentielles : activez la matrice de securite (Matrix Authorization Strategy) pour un controle d'acces granulaire par projet. Desactivez la Script Console pour les utilisateurs non-administrateurs — elle permet l'execution de code Groovy arbitraire sur le master. Activez le CSRF Protection (crumb). Restreignez l'API distante aux seules adresses IP autorisees. Desactivez la CLI Jenkins (-Djenkins.CLI.disabled=true) si vous ne l'utilisez pas. Auditez regulierement les plugins installes et supprimez ceux qui ne sont plus maintenus.

GitLab CI

GitLab CI a l'avantage d'etre integre nativement a la gestion du code source, mais cette integration cree des vecteurs d'attaque specifiques. Configurez les protected variables pour que les secrets de production ne soient accessibles que depuis les branches protegees. Activez la verification des pipelines sur les merge requests provenant de forks (ci_pipeline_from_fork) pour empecher le vol de secrets via des MR malveillantes. Restreignez les runners partages aux seuls projets autorises via les tags. Activez le Secret Detection et le Dependency Scanning natifs de GitLab Ultimate.

TeamCity

Apres la faille critique CVE-2024-27198 qui a permis des prises de controle a distance de serveurs TeamCity non patches, le durcissement de cette plateforme est devenu une priorite. Activez l'authentification a deux facteurs pour tous les comptes, en particulier les super-administrateurs. Restreignez les permissions de creation de projets et de configurations de build aux seuls administrateurs autorises. Activez les audit logs et exportez-les vers votre SIEM. Configurez les agents de build pour qu'ils ne communiquent qu'avec le serveur TeamCity et les repositories necessaires. Desactivez le guest login et l'acces anonyme.

— Etape 5 : Mettre en place le monitoring et l'alerting

Un pipeline compromis peut fonctionner pendant des semaines sans etre detecte si aucun systeme de surveillance n'est en place. Le monitoring de votre infrastructure CI/CD doit couvrir trois dimensions : la securite, les performances et la conformite.

Logs centralises et immutables. Exportez tous les logs de vos plateformes CI/CD (logs d'authentification, logs de builds, logs d'API, logs d'audit) vers un SIEM central (Splunk, Elastic SIEM, ou un solution cloud comme Google Chronicle). Les logs doivent etre immutables — un attaquant qui compromet le serveur CI/CD ne doit pas pouvoir effacer ses traces. Conservez les logs au minimum 12 mois pour les obligations NIS2 et les besoins de forensique.

Alertes sur les evenements critiques. Configurez des alertes en temps reel pour : la creation de nouveaux comptes administrateurs, les echecs d'authentification repetes, l'execution de commandes sur la Script Console Jenkins, la modification de configurations de securite, la creation de nouveaux runners ou agents, les builds declenchees depuis des branches non protegees, et les acces a des secrets inhabituels. Chez BlaBlaCar, chaque acces a un secret de production via le CI/CD declenche une notification Slack a l'equipe securite avec le contexte complet (qui, quoi, quand, quel pipeline).

Metriques de securite du pipeline. Suivez des indicateurs comme le pourcentage de pipelines avec des secrets hardcodes detectes, le temps moyen de rotation des secrets, le nombre de runners avec des versions obsoletes, et le pourcentage de builds executees dans des environnements ephemeres. Ces metriques alimentent vos rapports de conformite NIS2 et demontrent une amelioration continue aux regulateurs.

— Etape 6 : Automatiser les mises a jour et le patch management

Les plateformes CI/CD sont des logiciels comme les autres — elles ont des vulnerabilites qui sont corrigees regulierement. La difference est que les consequences d'une vulnerabilite non corrigee sur un serveur CI/CD sont exponentiellement plus graves que sur un serveur applicatif classique, car le CI/CD a acces a tout.

Mises a jour Jenkins. Jenkins publie des correctifs de securite toutes les quelques semaines. Abonnez-vous a la mailing list jenkinsci-advisories et appliquez les patches dans les 72 heures suivant leur publication. Testez d'abord sur votre instance de staging — les mises a jour Jenkins peuvent occasionnellement casser des plugins. Automatisez le deploiement via un pipeline dedie (oui, vous pouvez utiliser Jenkins pour mettre a jour Jenkins via un Blue/Green deployment).

Mises a jour des plugins. Les plugins sont le premier vecteur de vulnerabilites dans Jenkins et TeamCity. Mettez en place un processus de revue mensuelle des plugins : lesquels ont des mises a jour de securite disponibles, lesquels ne sont plus maintenus (et doivent etre remplaces), lesquels ne sont plus utilises (et doivent etre supprimes). Utilisez le Plugin Health Score de Jenkins pour evaluer la fiabilite de chaque plugin.

Images de base des runners. Si vos runners utilisent des images Docker, automatisez la reconstruction de ces images avec les derniers patches de securite de l'OS de base. Un pipeline dedie peut reconstruire et tester vos images de runners chaque nuit, garantissant que chaque build du lendemain utilise un environnement a jour. Integrez Trivy ou Grype dans ce pipeline pour scanner les images et bloquer toute image avec des vulnerabilites critiques non corrigees.

— Etape 7 : Auditer regulierement avec des tests d'intrusion

Les etapes 1 a 6 renforcent votre posture de securite CI/CD. L'etape 7 la valide. Un test d'intrusion specifiquement cible sur votre infrastructure CI/CD est le seul moyen de verifier que vos mesures de durcissement resistent a un attaquant determine.

Scope d'un pentest CI/CD. Un audit d'intrusion CI/CD couvre : la tentative de compromission du serveur CI/CD depuis le reseau interne et depuis Internet, l'injection de code malveillant dans les pipelines via des pull requests empoisonnees, le vol de secrets via les logs de build ou les variables d'environnement, le bypass des controles d'acces et des protections de branches, le mouvement lateral depuis un runner compromis vers le reseau de production, et l'exploitation de vulnerabilites dans les plugins et extensions.

Frequence recommandee. Un pentest CI/CD complet doit etre realise au minimum une fois par an, et idealement a chaque changement majeur de l'infrastructure (migration de plateforme, ajout de nouvelles integrations, changement d'architecture reseau). Pour les entreprises soumises a NIS2, cette frequence est souvent une obligation reglementaire. Entre les pentests complets, des scans automatises mensuels (avec des outils comme Prowler pour AWS, ScoutSuite pour le multi-cloud, ou Gitleaks pour la detection de secrets) maintiennent une surveillance continue.

Remediation et suivi. Le pentest n'a de valeur que si les vulnerabilites identifiees sont corrigees. Etablissez un SLA de remediation : vulnerabilites critiques corrigees sous 48 heures, elevees sous 2 semaines, moyennes sous 30 jours. Chaque vulnerabilite doit etre trackee dans un systeme de ticketing avec un responsable designe et une date d'echeance. Le pentest suivant verifie que les corrections sont effectives.

— Recapitulatif : votre checklist de durcissement CI/CD

Conclusion

La securite de votre infrastructure CI/CD n'est pas un sujet DevOps de niche — c'est un enjeu strategique de cybersecurite d'entreprise. Un pipeline compromis donne a un attaquant un acces direct a votre code source, vos secrets, vos environnements de production et votre supply chain logicielle. Les 7 etapes presentees dans ce guide — inventaire, isolation, secrets, durcissement, monitoring, patching, audit — forment un cadre structure et progressif pour reduire drastiquement cette surface d'attaque.

L'investissement n'est pas negligeable, mais il est proportionnel a l'enjeu. Les entreprises francaises comme Doctolib, OVHcloud, Thales et BlaBlaCar ont demontre qu'il est possible de concilier agilite DevOps et securite rigoureuse. Avec l'entree en vigueur de NIS2 et la multiplication des attaques de supply chain logicielle, le durcissement de votre CI/CD n'est plus optionnel — c'est une obligation de diligence que les regulateurs, les assureurs et vos clients attendent.

Commencez par l'etape 1 — l'inventaire. Vous ne pouvez pas proteger ce que vous ne connaissez pas. Puis avancez methodiquement, une etape a la fois. Dans 8 a 12 semaines, vous aurez transforme votre infrastructure CI/CD d'un angle mort de securite en un bastion durci.