Sur GitLab, les variables CI/CD sont souvent le point de passage entre ton pipeline et des ressources sensibles : registres, serveurs, API, clés SSH, credentials cloud. Le sujet n’est donc pas seulement “comment définir une variable”, mais comment le faire sans exposer tes secrets.

Dans cet article, je reprends une méthode simple et pragmatique : bien utiliser les variables GitLab, limiter leur exposition, et compléter si besoin par un contrôle éprouvé pour repérer des secrets dans les dépôts. Pour ça, mieux vaut s’appuyer sur des solutions reconnues comme GitLab Secret Detection, Gitleaks ou TruffleHog, plutôt que sur un script maison isolé.

Pourquoi les variables GitLab sont un vrai sujet de sécurité

Sur le papier, les variables CI/CD sont une bonne idée : on sort les secrets du dépôt et on les injecte au runtime. En pratique, ça ne règle pas tout. Une variable peut être trop visible, trop large, réutilisée dans trop de projets, ou affichée dans les logs si un job est mal écrit.

Le problème n’est donc pas seulement la présence d’un secret, mais sa surface d’exposition dans le pipeline. Plus une variable est large, réutilisable et peu contrôlée, plus elle devient un risque d’exploitation.

Les bonnes pratiques GitLab CI variables à appliquer

• Limiter la portée : définir la variable au bon niveau (projet ou groupe), pas “partout par défaut”.
• Protéger la variable quand elle ne doit être accessible qu’aux branches ou tags protégés.
• Masquer ce qui doit l’être, en gardant en tête que le masquage n’est pas une protection magique.
• Nommer clairement les variables pour éviter les confusions entre environnement, usage et criticité.
• Éviter les échos inutiles dans les jobs qui finissent par afficher ou reconstruire la valeur dans les logs.
• Prévoir la rotation des secrets vraiment sensibles : token, clé API, credential d’accès.

Dit autrement : GitLab CI variables doit être traité comme un point d’administration de secrets minimal, pas comme une poubelle pratique pour tout stocker vite fait.

Les erreurs les plus fréquentes

• mettre une variable critique au mauvais scope ;
• laisser une variable accessible à des branches non protégées ;
• afficher involontairement des infos sensibles dans les logs ;
• garder des variables obsolètes qui ne servent plus mais restent actives ;
• croire qu’une variable masquée suffit à elle seule à sécuriser le pipeline ;
• ou pire, retrouver encore des secrets directement commités dans un dépôt.

Comment compléter avec un contrôle éprouvé sur les dépôts GitLab

Si tu veux vérifier qu’un secret ou un motif sensible n’est pas déjà présent dans tes dépôts, le plus propre est de t’appuyer sur des outils connus et fiables plutôt que sur un contrôle ad hoc.

Les trois options les plus crédibles dans ce contexte sont généralement :

• GitLab Secret Detection si tu veux rester dans l’écosystème GitLab et intégrer le contrôle directement à la chaîne CI/CD ;
• Gitleaks si tu veux un scanner rapide, populaire et simple à intégrer dans un pipeline ou un audit ponctuel ;
• TruffleHog si tu veux pousser plus loin la détection sur des patterns de secrets et certaines vérifications associées.

L’idée n’est pas d’ajouter une usine à gaz, mais de compléter proprement l’hygiène de tes variables CI/CD par un contrôle régulier sur les dépôts et l’historique Git.

En pratique, ça sert à :

• repérer un secret déjà commité par erreur ;
• vérifier un doute avant rotation ;
• contrôler un groupe de projets avant durcissement ;
• ajouter un garde-fou simple dans les pipelines.

Variables GitLab et détection de secrets : deux problèmes différents

Il faut bien distinguer deux sujets :

1. la gestion correcte des variables GitLab dans les pipelines ;
2. la présence de secrets dans le code ou l’historique Git.

Le premier relève de l’hygiène CI/CD. Le second relève d’un sujet plus large de secret management et d’audit des dépôts. Les deux se complètent, mais ne se remplacent pas : bien gérer les variables ne dispense pas de scanner les repos, et inversement.

Quand durcir encore plus

Si tu as plusieurs projets, plusieurs équipes ou des pipelines qui touchent à des systèmes sensibles, il faut aller plus loin que les variables de base :

• séparer clairement les variables par environnement ;
• réduire les permissions des tokens utilisés ;
• documenter qui peut modifier quoi ;
• surveiller les logs de pipeline ;
• et intégrer un contrôle récurrent sur les dépôts si le risque de fuite est réel.

À partir d’un certain niveau, le sujet n’est plus seulement “mettre des variables dans GitLab”, mais concevoir une chaîne CI/CD où les secrets ont une durée de vie, un périmètre et une traçabilité acceptables.

Mon conseil pragmatique

Si tu veux améliorer rapidement la sécurité de tes pipelines GitLab, commence par trois choses :

1. revoir le scope et la protection de tes variables ;
2. faire le ménage dans les variables obsolètes ;
3. vérifier qu’aucun secret évident n’a fini dans les repos ou les logs.

Ce n’est pas un chantier de conformité “parfait”, mais c’est souvent là que tu gagnes le plus vite sans alourdir toute la chaîne de delivery.

Si tu veux sécuriser tes pipelines GitLab, revoir la gestion des secrets ou faire un audit rapide de l’existant, tu peux me contacter ici : nous contacter.

FAQ