Secrets dans Git : la clé API que vous avez supprimée est toujours là
« On l'a supprimée il y a deux ans »
Scénario vécu en audit : une clé AWS commitée dans un .env en 2023, « supprimée » trois jours plus tard par un commit remove secrets. En 2026, elle est toujours valide, toujours présente dans l'historique Git, et accessible à quiconque clone le dépôt.
Git est conçu pour ne rien oublier. Un git rm crée un nouveau commit *par-dessus* — le fichier reste dans tous les commits précédents, récupérable en une commande.
Comment les attaquants trouvent vos clés
Sur les dépôts publics : en minutes
Des bots scannent en continu les commits publics GitHub et GitLab à la recherche de patterns de clés (AWS, Stripe, OpenAI, Supabase, tokens npm…). Le délai entre le push d'une clé AWS publique et sa première utilisation malveillante se mesure en minutes. Le secret scanning de GitHub en révoque certaines automatiquement, mais ne couvre ni tous les formats ni tous les fournisseurs.
Sur les dépôts privés : via un accès secondaire
« Notre repo est privé » n'est une protection que tant que le repo le reste. Les fuites arrivent par : un laptop de développeur compromis, un token CI/CD trop permissif, un prestataire dont l'accès n'a jamais été révoqué, un repo re-publié en public des années plus tard. L'historique complet part avec le clone.
Cas 2026 : les projets générés par IA
Les applications construites avec des outils de génération de code sont surreprésentées dans nos constats : clés en dur « pour tester » suggérées par l'assistant, puis commitées avec tout le reste. Si vous avez vibe-codé votre MVP, l'historique de votre dépôt mérite une inspection.
Quoi faire, dans le bon ordre
L'erreur classique est de commencer par réécrire l'historique. Non :
git filter-repo — utile pour l'hygiène, mais inutile pour la sécurité si la clé n'est pas révoquée, et insuffisant : les forks, clones locaux et caches de CI gardent l'ancienne version.Checklist
gitleaks git .), pas seulement le HEAD.env* dans le .gitignore de vos templates de projetNotre Premier diagnostic inclut la recherche de secrets exposés liés à votre produit — dépôts, bundles JavaScript, historiques publics. 48h pour savoir ce qui traîne.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Corriger les vulnérabilités : guide de remédiation pas à pas pour développeurs
Comment implémenter les corrections après un audit de sécurité. Code RLS, authentification, API. Exemples concrets.
Supply chain : npm, composer, pip, quand vos dépendances sont l'attaque
Les attaques supply chain via les gestionnaires de paquets : typosquatting, dependency confusion, compromission de mainteneurs, et comment s'en protéger.
Zero Trust pour une petite équipe SaaS : par où commencer
Le Zero Trust n'est pas réservé aux grands groupes. Voici comment une équipe de 5 à 30 personnes peut appliquer les principes du Zero Trust sans infrastructure lourde.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.