Avis aux têtes en l’air – pre-commit et GitLeaks à la rescousse

[DISPLAY_ULTIMATE_SOCIAL_ICONS]

N’est pas Cédric qui veut, certaines erreur se font silencieusement et provoquent des failles qui peuvent mettre du temps à être détectées…

Notamment, il suffit d’un instant d’inattention pour commiter un secret (fichier .env, clé SSH, jeton d’API…) dans un dépôt Git. Ce genre d’étourderie peut être commise aussi bien par les devs que par les QA ! Heureusement, il existe des manières d’empêcher ce genre de chose d’arriver. Dans cet article, nous vous montrons comment mettre en place une protection locale avec deux outils : pre-commit et GitLeaks.

Et, pour précision, cette solution est 100 % gratuite.

Les outils utilisés

pre-commit

pre-commit est un gestionnaire de hooks Git qui s’exécute juste avant la création d’un commit.

Son rôle n’est pas de détecter les secrets lui-même ; il orchestre l’exécution d’outils de contrôle. Et en l’occurrence…

GitLeaks

GitLeaks est un outil de détection de secrets. Il recherche notamment :

• des clés d’accès cloud ;
• des jetons ;
• des clés privées ;
• des mots de passe ;
• des motifs correspondant à des secrets connus.

Comment les deux fonctionnent ensemble

Le principe est le suivant :

Installation

Prérequis

Vérifier que Git et Python sont installés (on vous donne toutes les commandes, on est comme ça nous…)

git --version
python --version

1. Installer pre-commit

pip install pre-commit

Vérifier :

pre-commit --version

2. Configurer GitLeaks avec pre-commit

À la racine du dépôt Git, créer un fichier .pre-commit-config.yaml avec le contenu suivant :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

Lors du premier commit, pre-commit télécharge automatiquement la version définie et la place dans son cache local. L’intérêt : toute l’équipe utilise exactement la même version de GitLeaks, indépendamment de l’environnement de développement de chaque personne. Cela évite par exemple qu’un poste tourne avec une version ancienne, dotée de moins de règles de détection.

3. Installer le hook Git

Toujours à la racine du dépôt :

pre-commit install

Le résultat attendu :

pre-commit installed at .git/hooks/pre-commit

À partir de maintenant, chaque git commit déclenchera automatiquement GitLeaks.

Tester la protection

Créer un fichier (nommé « test » pour plus d’originalité) contenant un faux secret, par exemple une clé SSH créée pour l’occasion et qui ne servira jamais à rien.

Puis, essayez de commiter ce nouveau fichier.

Le commit est refusé :

La sortie de commande indique quel fichier et à quelle ligne se trouve le secret.

Sympa non ?

Une protection locale à compléter

Attention : le hook pre-commit protège efficacement les postes de développement, mais il ne constitue pas une garantie absolue. Une personne peut techniquement contourner un hook avec :

git commit --no-verify

ou tout simplement oublier d’installer les hooks sur un nouveau poste.

Pour une protection complète, il est recommandé de cumuler :

• un contrôle pre-commit sur les machines de développement ;
• une analyse des secrets dans la CI/CD ;
• des contrôles côté plateforme Git lors des pull requests.

Conclusion

Avec quelques minutes de configuration, pre-commit et GitLeaks déplacent la détection des secrets au meilleur endroit : avant leur enregistrement dans Git. La configuration est légère, reproductible et adaptée au travail en équipe ; chaque poste applique automatiquement les mêmes règles et la même version de l’outil, sans installation supplémentaire de GitLeaks.

Et vous, avez-vous déjà retrouvé un secret oublié au fond d’un historique Git ?