Des secrets exposés dans un dépôt public : c’est l’incident qui a rappelé cette semaine, avec des clés d’administration AWS GovCloud retrouvées en clair sur GitHub, à quel point une seule fuite de credentials peut ouvrir tout un environnement cloud. Le pire ? Les clés sont souvent restées valides plusieurs dizaines d’heures après le retrait du dépôt. Pour une PME ou une ETI, la question n’est pas de savoir si un développeur va un jour committer un token par erreur, mais comment détecter et bloquer ces secrets exposés avant qu’un attaquant ne les moissonne. Ce tutoriel vous donne la chaîne de défense complète, du poste développeur jusqu’au dépôt distant.
Pourquoi les secrets exposés sont la porte d’entrée préférée des attaquants
Un secret, c’est une clé d’API, un mot de passe de base de données, un token OAuth, une clé SSH privée ou un jeton cloud (AWS, Azure, GCP). Quand ces éléments se retrouvent dans le code source, ils héritent de tous ses défauts : ils sont clonés, forkés, mis en cache et indexés. Les attaquants l’ont bien compris et scannent GitHub, GitLab et les registres publics en continu, souvent en quelques secondes après un push.
- Persistance : supprimer un commit ne suffit pas. Le secret reste dans l’historique Git et dans les caches des plateformes.
- Automatisation : des bots indexent les nouveaux commits et testent immédiatement les clés trouvées.
- Effet domino : une seule clé cloud sur-privilégiée peut permettre l’exfiltration de données, le déploiement de mineurs ou un rançongiciel.
La leçon des secrets exposés AWS GovCloud est claire : la détection et la rotation doivent être immédiates, pas planifiées pour le lendemain.
Étape 1 — Bloquer les secrets exposés avant le commit
La meilleure fuite est celle qui n’atteint jamais le dépôt. On installe donc un garde-fou côté poste développeur avec un pre-commit hook qui analyse chaque modification avant validation.
Installer gitleaks en pre-commit
Gitleaks est un scanner open source qui détecte les secrets exposés par motifs et par entropie. Ajoutez-le via le framework pre-commit dans un fichier .pre-commit-config.yaml :
- Déclarez le dépôt
gitleakset le hookgitleaks. - Lancez
pre-commit installpour activer le contrôle à chaquegit commit. - Tout commit contenant une clé détectée est rejeté localement, avant même d’atteindre GitHub.
Complétez avec un fichier .gitignore rigoureux (fichiers .env, *.pem, *.key, dossiers de configuration) pour éviter l’ajout accidentel de fichiers sensibles.
Étape 2 — Détecter les secrets exposés côté serveur
Les hooks locaux peuvent être contournés (option --no-verify). Il faut donc une seconde ligne de défense côté plateforme.
- GitHub / GitLab Secret Scanning : activez la détection native et le push protection, qui bloque directement un push contenant un secret reconnu.
- Analyse de l’historique complet : lancez
gitleaks detect --source . --log-opts="--all"pour scanner l’intégralité de l’historique, pas seulement le dernier commit. - Intégration CI/CD : ajoutez un job de scan bloquant dans votre pipeline pour qu’aucune fusion ne passe avec un secret détecté. Cette logique de blocage automatique rejoint celle décrite dans notre analyse du compromis npm jscrambler.
Étape 3 — Réagir vite quand un secret a fuité
Si un secret a été poussé, considérez-le comme compromis, définitivement. Le nettoyage de l’historique ne remplace jamais la rotation.
- Révoquer et régénérer immédiatement la clé concernée chez le fournisseur (AWS IAM, Azure, GCP, fournisseur d’API).
- Auditer les logs (CloudTrail, journaux d’accès) pour repérer tout usage anormal pendant la fenêtre d’exposition.
- Purger l’historique avec
git filter-repoou l’outil BFG, puis forcer la mise à jour du dépôt. - Appliquer le moindre privilège : une clé compromise fait bien moins de dégâts si elle n’avait que les droits strictement nécessaires.
Étape 4 — Supprimer les secrets du code, durablement
La vraie correction consiste à ne plus stocker de secrets dans le code. Adoptez une gestion centralisée :
- Coffre-fort de secrets : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou GCP Secret Manager injectent les credentials à l’exécution.
- Variables d’environnement : pour les petites structures, un fichier
.envhors du dépôt (et dans le.gitignore) reste un minimum viable. - Identités éphémères : privilégiez les tokens OIDC à courte durée de vie plutôt que des clés statiques longue durée.
- Rotation automatique : planifiez le renouvellement régulier des secrets, sans attendre un incident.
Cette discipline de gestion des identités machine prolonge la logique de défense que nous détaillions à propos des attaques par identité, nouvelle porte des ransomwares.
Checklist anti-secrets exposés pour PME-ETI
- ✅ Pre-commit gitleaks déployé sur tous les postes développeurs.
- ✅ Push protection et secret scanning activés sur GitHub/GitLab.
- ✅ Job de scan bloquant dans chaque pipeline CI/CD.
- ✅ Procédure de rotation documentée et testée (révoquer d’abord, nettoyer ensuite).
- ✅ Secrets centralisés dans un coffre-fort, jamais en clair dans le code.
- ✅ Principe du moindre privilège sur chaque clé cloud.
En combinant blocage local, détection serveur, réaction rapide et suppression durable, vous transformez la fatalité des secrets exposés en un risque maîtrisé. La clé que vous ne committerez jamais est celle qu’aucun attaquant ne pourra moissonner.