GitHub : plus de 543 000 identifiants encore valides exposés
Les dépôts publics de GitHub contiennent toujours des centaines de milliers de secrets fonctionnels, bien que la plateforme ait ajouté des outils censés empêcher les fuites accidentelles. Une nouvelle analyse de Truffle Security a recensé 543 699 identifiants uniques encore valides en juillet.
Les chercheurs ont analysé 224 millions de dépôts et plus de 58 milliards de fichiers. Selon eux, un identifiant divulgué restait publiquement accessible pendant une durée médiane de 784 jours avant que quelqu'un ne le remarque ou ne réagisse.
L'ancienneté de certains de ces secrets est frappante. Environ 10 % des identifiants fonctionnels avaient plus de 6,3 ans, et le plus ancien encore valide remonte à 2009. Les 543 699 secrets uniques apparaissaient de manière répétée dans plus de 1,1 million de fichiers et de dépôts, y compris sous forme de copies dans des forks.
D'où viennent les données
Truffle Security n'a pas exploré GitHub directement pour cette étude. L'entreprise s'est appuyée sur un jeu de données constitué pour entraîner de grands modèles de langage, issu d'une exploration qui s'est achevée le 7 août 2025.
Le chiffre obtenu pour GitHub est plus du double de celui trouvé en août par la même équipe sur Hugging Face, où elle avait identifié 221 303 identifiants fonctionnels.
L'étude met aussi en évidence une hausse régulière de la fréquence des secrets dans le code. Le nombre d'identifiants fonctionnels est passé de 3,72 par million de fichiers en 2015 à un pic de 11,62 par million de fichiers en 2025.
Push Protection aide, mais jusqu'à un certain point
La principale protection de GitHub contre ce problème s'appelle Push Protection. Elle a d'abord été proposée en avril 2022 aux clients d'Advanced Security, a été étendue aux dépôts publics en mai 2023, puis activée par défaut.
La fonctionnalité examine le code entrant à la recherche de motifs de secrets, comme des clés d'API et des jetons d'accès, et bloque le push en cas de correspondance. En revanche, elle ne révoque pas les identifiants déjà exposés avant son intervention.
D'après Truffle Security, 199 843 des identifiants actifs, soit environ 36,8 % du total, ont été exposés après que GitHub a activé Push Protection pour tous les utilisateurs en février 2024.
Un peu plus de la moitié (51,8 %) des secrets fonctionnels appartenaient à des catégories que la configuration par défaut de Push Protection ne bloque pas. On y trouve notamment les chaînes de connexion aux bases de données et les clés d'API Google.
Pour les catégories qu'elle couvre, la fonctionnalité semble porter ses fruits. Le taux d'identifiants exposés dans ces catégories protégées a baissé de 53 % après son activation par défaut par GitHub.
Certains services font le ménage plus vite que d'autres
La probabilité qu'un secret divulgué fonctionne encore dépend fortement du service concerné. Sur 101 886 jetons npm publiés dans des dépôts publics, les chercheurs n'en ont trouvé qu'un seul encore actif.
Du côté des identifiants de comptes de service Google Cloud, le constat est tout autre. Sur 126 963 clés exposées, 69 041 étaient encore valides au moment des vérifications de Truffle Security.
Pour les personnes concernées, la recommandation est de renouveler immédiatement les identifiants exposés, de nettoyer les dépôts, d'analyser l'intégralité de l'historique des commits et de définir une expiration automatique pour tous les secrets actifs.
L'étude montre combien de secrets fonctionnels traînent dans du code public. Elle ne dit pas combien d'entre eux ont réellement été découverts et exploités par des attaquants.
Pourquoi c'est important
Pour les développeurs et les équipes de sécurité, l'enseignement le plus utile est que bloquer les nouvelles fuites ne revient pas à corriger les anciennes. Push Protection semble réduire les expositions dans les catégories qu'elle couvre, mais des centaines de milliers de secrets plus anciens ou non couverts restent actifs. Cela laisse penser que l'analyse de l'historique et la révocation des clés restent en grande partie à la charge des propriétaires de dépôts.
L'écart entre les jetons npm et les identifiants Google Cloud est lui aussi révélateur. Il indique que la détection et la révocation automatique côté fournisseur peuvent faire une grande différence, et que les services dépourvus de tels mécanismes laissent le fardeau aux utilisateurs.
Ces résultats s'inscrivent dans une tendance plus large de données sensibles qui atterrissent dans du code public, des agents d'IA qui divulguent des captures d'écran sur GitHub aux adresses e-mail GitLab exposées utilisées pour pousser du code. Reste à voir si GitHub étendra Push Protection aux chaînes de connexion aux bases de données et aux clés d'API Google, et si davantage de fournisseurs cloud adopteront la révocation automatique des identifiants divulgués.