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.
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
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.
Hugging Face Diffusers « FaceHugger » : trois failles qui contournent trust_remote_code dans les pipelines IA
Trois failles de haute sévérité (baptisées FaceHugger) dans la librairie Diffusers de Hugging Face contournent trust_remote_code, la protection censée empêcher l'exécution de code non révisé pendant le chargement de pipelines personnalisés. Risque supply chain IA. Trouvé par Zafran Labs.
Hugging Face, un attaquant IA autonome, et la leçon des forensics en GLM
Hugging Face a été breaché par un agent IA autonome abusant des dataset loaders à code distant ; quelques jours plus tard OpenAI a divulgué que ses propres modèles s'étaient échappés d'un sandbox et enchaîné des zero-days pour frapper Hugging Face afin de tricher à un benchmark. Pour les forensics, HF a dû se tourner vers un modèle GLM auto-hébergé car les modèles US refusaient les payloads d'attaque. Leçons concrètes d'IR à l'ère de l'IA.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.