Passer au contenu principal

Sécurité et Gouvernance (GitLab)

Secret Detection

La fuite de secrets dans le code source (tokens API, cles SSH, mots de passe, credentials cloud) est l'une des causes les plus courantes d'incidents de securite. GitLab propose deux mecanismes complementaires : le Secret Detection dans les pipelines CI et le Push Rules au niveau du depot.

Secret Detection en CI

Le template Secret Detection scanne les commits du pipeline a la recherche de secrets connus. Il utilise Gitleaks, un outil open source qui applique des regles regex sur le diff :

include:
  - template: Security/Secret-Detection.gitlab-ci.yml

Par defaut, le job scanne uniquement le diff du commit courant (mode historique desactive). Pour scanner l'historique complet d'un depot existant, activer SECRET_DETECTION_HISTORIC_SCAN: "true" ponctuellement, pas en continu (trop couteux en CI).

Les regles couvertes incluent : cles AWS, tokens GitHub/GitLab, cles Stripe, tokens Slack, credentials Google Cloud, certificats prives, etc. L'ensemble des regles est maintenu dans le projet Gitleaks.

Push Rules (EE)

Les Push Rules permettent de bloquer les pushes en fonction de criteres evalues cote serveur avant l'acceptation du commit. Pour les secrets :

  • Bloquer les commits qui correspondent a des patterns de secrets connus
  • Bloquer les fichiers par extension (*.pem, *.key, *.p12)
  • Bloquer les fichiers au-dela d'une certaine taille (prevention LFS bypass)

Les Push Rules sont configurables au niveau de l'instance, du groupe ou du projet. Les regles d'instance s'appliquent a tous les projets et peuvent etre renforcees mais pas assouplies au niveau inferieur.

Que faire si un secret est pousse

Supprimer un commit ne suffit pas : le secret est dans l'historique Git et potentiellement deja indexe ou clone. La procedure correcte :

  • Revoquer immediatement le secret compromis (rotation du token, revocation de la cle)
  • Nettoyer l'historique si necessaire (BFG Repo Cleaner ou git filter-repo)
  • Auditer les acces avec ce secret depuis sa date de creation
  • Verifier que le secret n'a pas ete exfiltre (logs cloud, provider)

La rotation vient toujours avant le nettoyage de l'historique. Un historique nettoye mais un secret encore valide ne resout rien.

Sources