Gitleaks : scanner les secrets dans Git, et ce que signifie un projet en fin de vie

Un secret commité ne se retire pas d'un historique

Un mot de passe poussé dans un dépôt reste dans les objets Git même après un commit de suppression. Les interfaces d'hébergement masquent le fichier, pas l'objet. Gitleaks vise ce moment précis : retrouver ces chaînes dans l'historique, dans un répertoire de travail ou dans un flux d'entrée, avant ou après la fuite. Le README le présente comme un outil de détection de secrets dans les dépôts git, les fichiers et tout ce qu'on peut lui envoyer via stdin. Le public visé est l'équipe qui doit répondre à une question simple : qu'avons-nous commité qui n'aurait pas dû l'être. Le binaire s'adresse autant à la personne qui audite un dépôt hérité qu'à celle qui veut bloquer le commit fautif avant qu'il ne parte.

Regex, entropie, et une empreinte stable par finding

Le moteur repose sur des règles. Le README renvoie à un article intitulé Regex is (almost) all you need, ce qui situe la méthode : chaque règle porte un identifiant, un motif, et parfois un seuil d'entropie. La sortie verbeuse montre les champs produits pour un résultat : Finding, Secret, RuleID, Entropy, File, Line, Commit, Author, Email, Date et Fingerprint. L'exemple du README attribue au finding la règle sidekiq-secret avec une entropie de 2.609850 sur une ligne de cmd/generate/config/rules/sidekiq.go. Le Fingerprint combine commit, chemin de fichier, identifiant de règle et numéro de ligne, par exemple cd5226711335c68be1e720b318b7bc3135a30eb2:cmd/generate/config/rules/sidekiq.go:sidekiq-secret:23. C'est cette chaîne qui rend une baseline exploitable : elle survit aux déplacements de lignes tant que le triplet reste identique. Le champ Entropy explique aussi la limite : une chaîne à faible entropie passera sous le seuil d'une règle qui l'exige, et une chaîne aléatoire anodine pourra le franchir.

Trois commandes, quatre emplacements de configuration

L'interface tient en quelques sous-commandes : git pour un dépôt, dir pour des répertoires ou des fichiers, stdin pour un flux, plus completion, help et version. L'installation passe par brew install gitleaks, par les images zricethezav/gitleaks ou ghcr.io/gitleaks/gitleaks sur Docker Hub, ou par une compilation depuis les sources avec make build après git clone. Le README donne l'exemple docker run -v ${path_to_host_folder_to_scan}:/path ghcr.io/gitleaks/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH]. La configuration se cherche dans un ordre strict : le drapeau --config/-c, puis la variable GITLEAKS_CONFIG, puis GITLEAKS_CONFIG_TOML qui contient le contenu du fichier, puis le .gitleaks.toml du chemin ciblé. Sans aucune de ces quatre sources, la configuration par défaut s'applique. Ce dernier point mérite attention : un dépôt sans .gitleaks.toml est scanné avec les règles embarquées, pas avec les vôtres.

Baseline, gitleaks:allow et le fichier .gitleaksignore

Un scan sur un historique ancien remonte du bruit légitime. Trois mécanismes le traitent. Le drapeau --baseline-path pointe vers un rapport contenant les findings déjà connus, qui seront ignorés aux exécutions suivantes. Le commentaire gitleaks:allow, placé dans le code, exclut une ligne, et --ignore-gitleaks-allow désactive globalement ce mécanisme quand on veut un rapport brut. Le fichier .gitleaksignore, localisé par --gitleaks-ignore-path (valeur par défaut : le répertoire courant), liste des empreintes à ignorer. Ces trois leviers ne se valent pas. La baseline est un instantané qui vieillit et qu'il faut régénérer ; le commentaire gitleaks:allow vit dans le code et suit les revues ; le .gitleaksignore est un fichier de configuration à part. Une équipe qui empile les trois sans convention finit avec des exclusions dont personne ne sait plus laquelle masque quoi.

Le blocage au commit, et la porte de sortie SKIP=gitleaks

L'intégration pre-commit est documentée pas à pas : un .pre-commit-config.yaml à la racine avec le dépôt gitleaks, une rev (l'exemple du README indique v8.24.2), et l'identifiant de hook gitleaks, ou gitleaks-docker pour passer par l'image officielle. Ensuite pre-commit autoupdate puis pre-commit install. Le README montre le résultat : Detect hardcoded secrets.................................................Failed. Le hook est donc bloquant par défaut. La documentation précise aussi l'échappatoire : préfixer la commande par SKIP=gitleaks, ce qui donne Detect hardcoded secrets................................................Skipped. C'est un choix de conception à assumer. Un contrôle qui s'écrit sur une ligne de commande n'est pas un contrôle fort, et l'historique ne dira pas combien de fois il a été contourné. Pour un dépôt public ou un monorepo où plusieurs équipes commitent, la question du contournement se pose avant le déploiement, pas après.

Ce que le moteur ne fait pas, et pourquoi la profondeur d'analyse se paie

Deux drapeaux encadrent des analyses plus coûteuses. --max-decode-depth autorise le décodage récursif jusqu'à une profondeur donnée, avec 0 par défaut, donc aucun décodage. --max-archive-depth autorise l'entrée dans des archives imbriquées, également à 0 par défaut, donc aucune traversée. Un secret encodé en base64 dans un fichier, ou enfoui dans une archive, ne sera pas vu avec les réglages par défaut. Les activer augmente le travail par cible, et --max-target-megabytes permet de plafonner la taille des fichiers traités. Le README ne donne aucune mesure de temps ni de mémoire pour ces modes, et je ne peux pas en produire. La limite structurelle est ailleurs : un moteur à base de motifs ne comprend pas le contexte. Une clé privée collée dans un ticket, un secret passé par variable d'environnement, un jeton dans un binaire compilé : rien de tout cela n'est un motif dans un fichier texte. Gitleaks est le mauvais outil pour qui cherche une analyse sémantique du code plutôt qu'une correspondance de chaînes.

Betterleaks, et ce que signifie « feature complete »

Le README porte un avertissement explicite : Gitleaks is feature complete, l'auteur n'intègre plus de nouvelles fonctionnalités, les prochaines versions seront des correctifs de sécurité, et son travail se déplace vers Betterleaks. Les versions récentes confirment ce rythme : v8.30.1 datée du 21 mars 2026, v8.30.0 du 26 novembre 2025, v8.29.1 du 19 novembre 2025. Une version corrective isolée après une version mineure correspond à un projet en maintenance, pas en développement actif. La différence avec Betterleaks n'est pas une question de rapidité ou de précision, c'est une question de gouvernance : là où Gitleaks gèle ses règles et son moteur, Betterleaks est le dépôt où l'auteur place son effort. Concrètement, une règle de détection manquante dans Gitleaks a peu de chances d'arriver par une version ultérieure ; la réponse praticable est de l'écrire soi-même dans son .gitleaks.toml, pas d'attendre. La licence MIT, indiquée dans le dépôt et le badge du README, autorise ce type d'adaptation, y compris la redistribution d'une version modifiée, à condition de conserver l'avis de licence. Ce paragraphe décrit la licence telle qu'elle est déclarée, il ne constitue pas un avis juridique.

Conclusion éditoriale

Adoptez Gitleaks si vous voulez un binaire Go unique, une licence MIT et un scan de secrets branché sur pre-commit ou en CI, en acceptant que seuls des correctifs de sécurité arrivent désormais. Évitez-le si vous attendez de nouvelles règles de détection ou un moteur d'analyse plus riche que la regex et l'entropie. Avant tout déploiement, vérifiez deux choses sur votre propre dépôt : le contenu réel de votre .gitleaks.toml et le chemin exact de votre .gitleaksignore, car ce sont eux qui décideront des findings que vous verrez ou non.

Sources officielles

1. gitleaks/gitleaks on GitHub
2. License: MIT
3. Project website
4. README
5. Releases