Je vais être direct. Si vous avez déjà commité un .env, une clé AWS, un token GitHub, un mot de passe MySQL ou même juste un fichier config.php un peu trop bavard… ce n’est pas « juste un fichier ». C’est un secret qui peut vivre très longtemps, même si vous l’avez supprimé ensuite.
Et oui, même si votre dépôt est privé. Même si vous avez « revert ». Même si vous avez supprimé la ligne le lendemain matin en panique.
Git se souvient.
Dans cet article, on va voir comment détecter les secrets dans un historique Git, comment les purger proprement, et surtout comment éviter de refaire la même erreur. Je vais volontairement rester pratique, avec des commandes, des checklists, et quelques pièges réels que j’ai vus passer côté SysAdmin et côté freelancing.
Petite note au passage : sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), je publie aussi des contenus Linux, productivité, SEO, growth, et tout ce qui aide à bosser mieux, plus proprement, plus vite. Si vous aimez ce style « terrain », vous savez où me trouver.
Le vrai problème : supprimer un fichier ne le supprime pas
Git est un système de versioning. Donc quand vous faites :
bash git rm .env git commit -m "remove env"
Vous retirez le fichier de la version courante. Mais les commits précédents contiennent encore le fichier. Et n’importe qui qui a accès à l’historique peut le récupérer. Parfois sans même cloner, juste en parcourant l’historique via l’interface web.
Deux conséquences importantes :
- Un secret commité doit être considéré comme compromis.
- Le bon réflexe n’est pas « supprimer », c’est « remplacer et purger ».
Pour vous aider dans cette tâche de purging et d'évitement d'erreurs futures, voici une ressource utile que j'ai trouvée : Tech talents: 7 outils et... qui fournit des outils précieux pour gérer ces situations délicates.
À faire tout de suite si vous suspectez une fuite
Avant de jouer avec l’historique, priorité au damage control. Checklist rapide :
- Révoquer le secret : token, clé, mot de passe.
- Rotation : générer une nouvelle clé.
- Vérifier où il est utilisé : CI/CD, serveur, app mobile, cron, etc.
- Chercher des usages inattendus : logs, scripts, wiki interne.
- Si dépôt public : supposer que c’est déjà aspiré par des bots.
Même un dépôt privé n’est pas une garantie. Une fuite de token dans un dépôt privé, ça arrive via partage, accès trop large, machine compromise, ou simplement un collègue qui clone sur un poste pas clean.
Détecter les secrets : méthodes simples (et efficaces)
1) Rechercher dans l’historique avec git log -S
Pour des chaînes connues :
bash git log -S "AKIA" --all git log -S "BEGIN PRIVATE KEY" --all git log -S "stripe" --all
-S cherche les commits où la chaîne apparaît ou disparaît.
2) Grep sur tout l’historique avec git rev-list
Quand vous voulez scanner tous les commits :
bash git rev-list --all | while read commit; do git grep -n "AKIA" "$commit" done
C’est brut, un peu lent, mais ça marche.
3) Trouver des fichiers suspects (env, key, p12, etc.)
Lister les fichiers présents dans l’historique :
bash git rev-list --objects --all | awk '{print $2}' | sort -u | head
Puis filtrer :
bash git rev-list --objects --all | awk '{print $2}' | sort -u | grep -E ".env|id_rsa|.pem|.p12|config.php|secrets|credentials"
Image suggérée
Détecter automatiquement : outils recommandés
Vous pouvez faire ça « à la main », mais en équipe, ou sur plusieurs repos, c’est vite pénible. Les outils suivants sont devenus des standards.
1) Gitleaks
Probablement le plus simple pour démarrer.
Installation (exemple Linux) :
bash gitleaks version
Scan :
bash gitleaks detect --source . --no-git
Pour scanner l’historique Git :
bash gitleaks detect --source . --redact
Le --redact évite d’afficher le secret en clair dans le rapport, ce qui est… logique.
2) TruffleHog
Très bon aussi, surtout si vous voulez croiser plusieurs heuristiques.
Exemple :
bash trufflehog git file://. --only-verified
3) GitHub secret scanning (si GitHub)
Si dépôt GitHub, activez ce qui peut l’être :
- Secret scanning
- Push protection (bloque le push si secret détecté)
- Dependabot alerts, tant qu’on y est
Purger proprement : la méthode moderne avec git filter-repo
Oubliez git filter-branch. C’est lent, casse tout, et c’est l’enfer à maintenir.
La bonne approche aujourd’hui : git filter-repo.
Installer git-filter-repo
Sur beaucoup de distributions :
bash pip install git-filter-repo
Ou via package manager selon votre OS.
Étape 1 : travailler sur un clone miroir ou une copie
Ne faites pas ça sur votre clone principal sans filet.
bash git clone --mirror https://github.com/user/repo.git repo.git cd repo.git
Étape 2 : supprimer un fichier de tout l’historique
Exemple avec .env :
bash git filter-repo --path .env --invert-paths
Ça va réécrire l’historique et enlever ce fichier partout.
Étape 3 : supprimer une chaîne dans des fichiers (cas token dans un config)
Si le secret est dans un fichier que vous devez garder, utilisez un remplacement.
Créer un fichier replacements.txt :
txt regex:AKIA[0-9A-Z]{16}==>REMOVED_AWS_KEY regex:-----BEGIN PRIVATE KEY-----[\s\S]*?-----END PRIVATE KEY-----==>REMOVED_PRIVATE_KEY
Puis :
bash git filter-repo --replace-text replacements.txt
Attention : ce genre de regex peut être dangereux si mal écrit. Testez sur une copie. Toujours.
Étape 4 : forcer le push de l’historique réécrit
Une fois satisfait :
bash git push --force --mirror
Oui, --force. Vous réécrivez l’histoire.
Après la purge : ce que tout le monde oublie
Ok, vous avez purgé. Très bien. Mais Git a encore des objets, des caches, des clones ailleurs, des forks, des pipelines.
1) Nettoyer les refs et garbage collect (sur votre copie)
Souvent filter-repo gère déjà pas mal, mais vous pouvez vérifier :
bash git reflog expire --expire=now --all git gc --prune=now --aggressive
2) Faire invalider les caches côté plateforme
Selon GitHub, GitLab, Bitbucket, il peut y avoir des caches, des indexations, etc. Sur GitHub, si secret exposé, vous pouvez aussi passer par les recommandations officielles, et surtout… révoquer la clé.
3) Prévenir l’équipe : il faut re-cloner
C’est là que ça pique un peu.
Tout le monde doit :
- soit re-cloner le repo
- soit faire une procédure de resynchronisation plus avancée (mais franchement, re-cloner est plus simple)
Parce que l’historique a changé. Les anciens commits n’existent plus dans la nouvelle réalité.
Image suggérée
Cas fréquent : le secret est dans un tag ou une release
Les tags pointent vers des commits. Si vous réécrivez l’historique, vos tags doivent suivre. Un --mirror pousse en général tout, mais vérifiez :
bash git show-ref --tags
Et comparez avant après.
Purger un secret d’un dépôt déjà cloné par des gens
Soyons honnêtes : vous ne pouvez pas effacer la copie locale de quelqu’un.
Vous pouvez :
- purger l’origine
- révoquer le secret
- demander suppression des clones, ou au moins nettoyage
- auditer les accès
C’est pour ça que la rotation des secrets est non négociable. Pour plus d'informations sur la gestion des secrets, vous pouvez consulter cet article sur les secrets numériques.
Prévenir plutôt que guérir : les bonnes pratiques simples
1) .gitignore bien pensé
Exemples typiques :
gitignore .env .env.* *.pem *.key .p12 credentials.json config.local.
Mais attention : si le fichier a déjà été commité, l’ignorer ne le retire pas.
2) Utiliser des fichiers d’exemple
Au lieu de commiter .env, commitez .env.example :
env DB_HOST=localhost DB_USER=app DB_PASSWORD=change_me
Et le vrai .env reste local.
3) Secrets dans le manager de secrets, pas dans Git
Selon votre contexte :
- GitHub Actions secrets
- GitLab CI variables
- Vault, Doppler, AWS SSM Parameter Store, GCP Secret Manager
- même un
.envlocal chiffré si vous êtes solo, mais évitez les bricolages
Ces pratiques sont essentielles pour éviter les fuites de données sensibles. Pour approfondir ce sujet, je vous recommande cet article sur les secrets du contenu viral qui offre des conseils précieux sur la gestion des informations confidentielles en ligne. De plus, il est intéressant de noter que ces stratégies peuvent également s'appliquer aux micro-influenceurs, qui doivent souvent gérer des informations sensibles tout en construisant leur présence en ligne.
4) Hooks de pré-commit
Le combo « efficace et pas trop lourd » :
pre-commit(framework)gitleaksen hook
Exemple .pre-commit-config.yaml (simple) :
yaml repos:
repo: https://github.com/gitleaks/gitleaks rev: v8.24.0 hooks: id: gitleaks
Puis :
bash pre-commit install
Image suggérée
Petit piège : les secrets dans les messages de commit
Oui… ça arrive. Un copier coller rapide.
Pour les détecter :
bash git log --all --grep="AKIA" git log --all --grep="password"
Et pour purger, filter-repo peut aussi réécrire les messages, mais c'est un cas plus rare. Disons que si vous en êtes là, faites une purge complète avec remplacement de texte.
Petit piège 2 : les secrets dans l'historique CI
Même si vous purgez Git, votre CI peut avoir loggé le secret (build logs, artifacts).
À vérifier : logs de jobs, artifacts zippés, caches, et images Docker poussées au registry.
Ça, Git ne peut pas le réparer.
Une procédure propre, résumée (checklist)
- Identifier le secret, et où il apparaît (fichier, commit, tag).
- Révoquer et remplacer le secret.
- Scanner le dépôt (gitleaks ou trufflehog).
- Réécrire l'historique avec
git filter-repo. - Forcer le push (
--force/--mirror). - Demander à l'équipe de re-cloner.
- Mettre des garde fous (pre-commit, secret scanning, bonnes pratiques).
Conclusion : Git n’oublie rien, donc il faut être méthodique
Une fuite de secret, ce n’est pas forcément dramatique. Ce qui devient dramatique, c’est quand on fait semblant que supprimer le fichier suffit. Ou quand on purge sans rotation. Ou quand on oublie les logs CI.
Si vous voulez, je peux faire une version « playbook » encore plus carrée (GitHub vs GitLab, mono repo vs multi repos, cas Docker images, etc.) sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com). Et si vous bossez en freelance ou en petite équipe, ce genre de procédure vaut de l’or. Une fois que c’est en place, vous respirez. Vous codez mieux, et vous dormez mieux aussi.
Questions fréquemment posées
Pourquoi ne faut-il pas considérer un fichier .env ou une clé AWS comme « juste un fichier » une fois commité dans Git ?
Parce que ces fichiers contiennent des secrets sensibles qui restent dans l'historique Git même après suppression ou modification. Git conserve toutes les versions, donc ces secrets peuvent être récupérés longtemps après, exposant potentiellement vos données à des tiers.
Comment puis-je détecter la présence de secrets dans l'historique de mon dépôt Git ?
Vous pouvez utiliser des commandes comme git log -S "chaine" --all pour rechercher des chaînes spécifiques dans les commits, ou parcourir tous les commits avec git rev-list --all combiné à git grep. Il existe aussi des outils spécialisés comme Gitleaks qui automatisent cette détection.
Quelle est la bonne méthode pour supprimer proprement un secret déjà commité dans Git ?
La bonne pratique est de remplacer le secret par une valeur sans risque et de purger complètement l'historique Git pour éliminer toute trace. Supprimer simplement le fichier dans un commit ne suffit pas car les anciennes versions restent accessibles.
Que faire immédiatement si vous suspectez qu'un secret a fuité via votre dépôt Git ?
Il faut d'abord révoquer le secret compromis (token, clé, mot de passe), générer une nouvelle clé (rotation), vérifier tous les usages du secret (CI/CD, serveurs, applications), et supposer que le secret est déjà aspiré par des bots surtout si le dépôt est public.
Quels outils recommandez-vous pour détecter automatiquement les secrets dans un dépôt Git ?
Gitleaks est l'un des outils les plus simples et efficaces pour débuter. Il permet de scanner à la fois le contenu actuel et l'historique du dépôt afin d'identifier rapidement les secrets exposés.
Un dépôt privé garantit-il la sécurité totale de mes secrets committés ?
Non. Même un dépôt privé n'est pas une garantie absolue. Des accès non autorisés, des machines compromises ou des partages involontaires peuvent exposer vos secrets. Il faut donc toujours appliquer les bonnes pratiques de gestion et rotation des clés.
0 Commentaires