GitGuardian vient de publier son rapport annuel State of Secrets Sprawl 2026. Le chiffre central : 17 millions de secrets ont été détectés dans des dépôts GitHub publics sur les 12 derniers mois. C'est 34% de plus qu'en 2025. Malgré les outils, les formations et les politiques de sécurité, le problème s'aggrave chaque année.
Ce que les développeurs exposent le plus
Les secrets les plus fréquemment retrouvés ne sont pas des mots de passe d'administrateur. Ce sont des credentials qui trainent dans le quotidien du développeur : clés API de services cloud, tokens d'accès GitHub et GitLab, credentials de bases de données de développement, secrets de variables d'environnement copiés depuis un fichier .env oublié dans un commit.
AWS, Google Cloud et Azure représentent à eux trois 38% des secrets détectés. Un credential AWS non protégé peut en quelques minutes donner accès à des buckets S3, des bases RDS, des fonctions Lambda. Le coût d'un incident de ce type dépasse souvent les 100 000 euros avant même de compter l'atteinte à la réputation.
La durée de vie du problème : le vrai scandale
GitGuardian mesure depuis plusieurs années le temps moyen entre le commit d'un secret et sa révocation. En 2026, ce délai est de 27 jours. Cela signifie qu'un secret exposé reste valide et exploitable pendant presque un mois en moyenne après avoir été rendu public.
Plus préoccupant : 90% des secrets détectés dans des commits publics ne sont jamais révoqués, même après notification. Les développeurs effacent le commit ou le fichier, ce qui ne suffit pas : l'historique git reste accessible, et des scrapers automatisés collectent les secrets en temps réel dès le push.
Pourquoi les outils existants ne suffisent pas
GitHub propose depuis 2023 la détection de secrets par défaut sur tous les dépôts publics. Le service envoie une notification et, pour les partenaires intégrés (AWS, Stripe, Google), révoque automatiquement le credential. C'est utile, mais insuffisant : la fenêtre entre le push et la révocation automatique est de plusieurs minutes, suffisante pour qu'un scraper automatique ait déjà collecté le secret.
Les hooks pre-commit (git-secrets, detect-secrets, gitleaks) sont plus efficaces car ils bloquent le commit avant qu'il parte. Mais leur installation reste opt-in, manuelle, et souvent absente des projets personnels ou des repos d'apprentissage.
Ce qu'il faut mettre en place
- Ne jamais stocker de secret dans le code source. Utiliser des variables d'environnement ou un gestionnaire de secrets (Vault, AWS Secrets Manager, Doppler).
- Installer gitleaks comme hook pre-commit et dans le pipeline CI pour bloquer tout commit contenant un pattern de secret reconnu.
- Activer la détection de secrets GitHub sur tous ses dépôts, y compris les privés (disponible sur GitHub Advanced Security).
- Utiliser des secrets à courte durée de vie (tokens temporaires, rotation automatique) plutôt que des clés permanentes.
- Faire un audit régulier de l'historique git avec
gitleaks detect --source .sur les repos existants.
- State of Secrets Sprawl 2026 — GitGuardian, 1er août 2026
- GitHub Secret Scanning documentation — GitHub, 2026
