Clés d’API qui fuient sur GitHub : les trouver et réagir

Un développeur copie un fichier .env qui fonctionne dans un projet de test, le pousse sur un dépôt public « juste une minute » et le supprime l’après-midi même. Le mot de passe de la base de données, la clé de paiement et les identifiants SMTP de votre entreprise sont maintenant publics, et ils le restent : dans l’historique du dépôt, dans chaque copie (fork), et dans les archives des robots qui lisent en continu le flux public de GitHub.

C’est l’une des façons les plus courantes dont les petites entreprises sont piratées, et l’une des moins chères à éviter.

Comment des secrets finissent dans du code public

• Des fichiers de configuration publiés par erreur : .env, config.yml, settings.py, wp-config.php, appsettings.json.
• Des dépôts personnels ou de prestataires : un indépendant publie dans son portfolio un projet fait pour vous, avec vos vrais identifiants dedans.
• Supprimés au commit suivant : le fichier a disparu de la version actuelle, mais n’importe qui peut lire le commit précédent.
• Des scripts de test et des notebooks : un petit script pour envoyer un e-mail, avec le mot de passe SMTP écrit dedans.
• Des chaînes de connexion : postgres://app:motdepasse@db.votredomaine.fr/app, qui donnent à la fois le mot de passe et l’endroit où s’en servir.

À quelle vitesse ils sont trouvés

Des scanners automatiques surveillent chaque publication publique. Les études sur les clés cloud divulguées montrent régulièrement des essais dans les minutes qui suivent. L’analyse des secrets de GitHub vérifie désormais les dépôts publics pour les clés de centaines de fournisseurs et prévient certains d’entre eux, qui peuvent révoquer la clé ; elle ne couvre ni les mots de passe de base de données, ni les comptes SMTP, ni vos propres jetons internes.

Cherchez votre propre domaine

Les attaquants cherchent votre entreprise par son nom de domaine, parce que les fichiers de configuration nomment les serveurs auxquels ils se connectent. Vous pouvez faire de même. Sur GitHub, cherchez dans le code :

"votredomaine.fr" password
"votredomaine.fr" secret
"votredomaine.fr" filename:.env

Regardez chaque résultat hors de votre propre organisation. Un fichier qui nomme votre domaine à côté de password= ou d’une clé mérite d’être ouvert.

Quand vous en trouvez un : révoquer d’abord

L’ordre compte, et la plupart des gens le prennent à l’envers.

1. Révoquez ou changez le secret immédiatement. Générez une nouvelle clé, changez le mot de passe, renouvelez le jeton, dans le service concerné. Tant que ce n’est pas fait, rien d’autre ne compte : supprimer le fichier ne rend pas l’ancien secret de nouveau secret.
2. Vérifiez s’il a servi. Regardez les journaux du service : connexions, appels d’API, e-mails envoyés, nouveaux utilisateurs, factures inattendues, depuis la date du commit.
3. Retirez-le du code. Si le dépôt est à vous, réécrivez son historique avec git filter-repo (GitHub le documente sous « removing sensitive data from a repository ») et demandez au support de GitHub de purger les vues en cache. S’il appartient à quelqu’un d’autre, demandez au propriétaire de le retirer ; si la personne ne répond pas, GitHub accepte les demandes de retrait de données sensibles dans des dépôts qui ne sont pas les vôtres.
4. Comprenez comment c’est arrivé et empêchez le suivant : un .gitignore pour les fichiers d’environnement, l’analyse des secrets avec protection à la publication sur vos dépôts, et des secrets rangés dans un gestionnaire plutôt que dans des fichiers.

Éviter la prochaine fuite

• Gardez les secrets hors du code : variables d’environnement injectées au déploiement, ou gestionnaire de secrets.
• Activez la protection à la publication (push protection) de GitHub sur les dépôts de votre organisation : elle bloque une publication qui contient une clé reconnue.
• Faites tourner un outil comme gitleaks dans votre intégration continue, pour qu’un secret fasse échouer la construction avant d’être fusionné.
• Donnez aux prestataires leurs propres identifiants, aux droits limités, et révoquez-les à la fin de la mission.
• Préférez des clés restreintes à ce dont elles ont besoin : un domaine, une plage d’adresses, la lecture seule quand c’est possible.

Comment Perimetry surveille pour vous

Chaque semaine, Perimetry Cloud cherche dans le code public de GitHub les fichiers qui citent vos domaines prouvés, les lit et reconnaît les mots de passe et les clés : clés AWS, Stripe, GitHub, GitLab, Slack, SendGrid, OpenAI et Anthropic, clés privées, mots de passe dans des chaînes de connexion et en configuration à côté de votre domaine. Il ne garde jamais le secret lui-même, seulement son type, ses premiers caractères et son emplacement, et vous prévient quand un nouveau secret grave apparaît. Le même audit regarde aussi les fichiers que l’Internet Archive a gardés de vos sites (anciennes sauvegardes et fichiers de configuration), qui fuient de la même façon.