Secret Scanning

Qu'est-ce que le Secret Scanning ?

Le Secret Scanning (ou détection de secrets) désigne l'ensemble des techniques automatisées permettant d'identifier des informations d'authentification exposées par erreur dans du code source, des fichiers de configuration, des journaux applicatifs ou l'historique d'un dépôt Git. Ces secrets recouvrent les clés d'API, les jetons OAuth, les mots de passe de bases de données, les clés privées SSH ou TLS, les chaînes de connexion cloud et les certificats. L'objectif est simple : détecter la fuite avant qu'un attaquant ne l'exploite, idéalement avant même que le code ne soit publié.

Cette discipline s'inscrit pleinement dans une démarche DevSecOps, où les contrôles de sécurité sont déplacés au plus près du développeur (shift left) plutôt qu'appliqués en fin de chaîne. Un secret codé en dur dans un dépôt public reste l'une des causes les plus fréquentes de compromission initiale, devant même certaines vulnérabilités applicatives classiques.

Pourquoi les secrets fuient-ils ?

Les causes sont presque toujours humaines et banales : une clé collée temporairement « pour tester », un fichier .env non ajouté au .gitignore, un dump de configuration commité par inadvertance, un dépôt interne passé en public lors d'une migration, ou encore un jeton présent dans un fichier de build CI/CD. Le point critique : supprimer le secret dans un commit ultérieur ne le supprime pas de l'historique Git. Il reste consultable via git log -p ou dans n'importe quel clone déjà réalisé.

Fonctionnement technique

Un moteur de détection de secrets combine généralement trois approches complémentaires :

• Détection par motifs (regex) : chaque fournisseur émet des jetons au format reconnaissable. Une clé AWS commence par AKIA, un jeton d'accès personnel GitHub par ghp_, une clé Stripe par sk_live_, une clé privée par -----BEGIN RSA PRIVATE KEY-----. Ces signatures offrent un taux de faux positifs très faible.
• Analyse d'entropie : pour les secrets sans format normalisé, l'outil calcule l'entropie de Shannon d'une chaîne. Une valeur élevée (caractères aléatoires, base64, hexadécimal long) trahit une donnée générée cryptographiquement plutôt qu'un texte humain. Cette méthode est plus bruyante et génère davantage de faux positifs.
• Vérification active : les outils modernes vont plus loin en interrogeant l'API du fournisseur pour déterminer si le secret trouvé est encore valide. Cette validation distingue une clé révoquée depuis deux ans d'une clé de production active — la différence entre une remarque et un incident de sécurité.

L'analyse ne porte pas seulement sur l'arborescence courante : elle parcourt l'intégralité des objets Git, branches et commits inclus, afin de retrouver les secrets purgés en surface mais persistants en profondeur.

Les outils de référence

• GitHub Secret Scanning : intégré nativement, gratuit sur les dépôts publics. GitHub notifie automatiquement le fournisseur partenaire (AWS, Stripe, Slack…), qui peut révoquer le jeton en quelques minutes. La Push Protection bloque le git push avant même l'écriture du secret dans l'historique distant.
• GitLeaks : outil open source en Go, très rapide, pilotable par un fichier .gitleaks.toml pour ajouter des règles maison ou déclarer des exceptions. Commande typique : gitleaks detect --source . --redact.
• TruffleHog : réputé pour sa vérification active auprès de plusieurs centaines d'API. Il analyse également les images Docker, les buckets S3 et les fichiers hors dépôt.
• detect-secrets (Yelp) : s'appuie sur une baseline permettant d'accepter l'existant et de ne bloquer que les nouvelles occurrences — approche pragmatique sur les bases de code anciennes.

Exemples concrets

Le cas le plus documenté reste celui d'un développeur publiant sur un dépôt public un notebook contenant ses identifiants AWS : des robots scannant GitHub en continu récupèrent la clé en moins de cinq minutes et lancent des instances de minage de cryptomonnaie, générant plusieurs dizaines de milliers d'euros de facture. Autre scénario courant : un jeton d'API interne exposé dans un docker-compose.yml d'exemple, réutilisé par un attaquant pour accéder à un service de messagerie d'entreprise et y collecter des informations exploitables en phase de reconnaissance.

Que faire en cas de détection ?

1. Révoquer immédiatement le secret côté fournisseur. C'est la seule action réellement efficace : tout secret ayant transité par un dépôt doit être considéré comme compromis.
2. Générer une nouvelle valeur et la stocker dans un coffre approprié.
3. Réécrire l'historique avec git filter-repo ou BFG Repo-Cleaner, puis forcer la mise à jour du dépôt distant.
4. Analyser les journaux d'accès du service concerné pour vérifier une éventuelle utilisation frauduleuse pendant la fenêtre d'exposition.

Bonnes pratiques

• Externaliser tous les secrets dans un gestionnaire dédié : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ou les secrets chiffrés de la plateforme CI/CD.
• Installer un hook pre-commit local pour bloquer la fuite à la source, avant même le commit.
• Ajouter une étape de scan bloquante dans le pipeline d'intégration continue, en complément du SAST et de l'analyse de composition logicielle (SCA).
• Privilégier des identités éphémères (OIDC, rôles IAM temporaires) plutôt que des clés statiques à durée de vie illimitée.
• Appliquer une rotation régulière et documentée des secrets restants.

Concepts liés

Le Secret Scanning se combine avec le SAST (analyse statique du code), la SCA (dépendances vulnérables), la sécurisation de la chaîne d'approvisionnement logicielle et la gestion des identités machine. Il alimente également la surveillance de la surface d'attaque externe : une fuite de credentials constitue souvent le vecteur d'accès initial d'une attaque par rançongiciel ou d'une exfiltration de données.