Le code public sur GitHub contenait encore 543 699 identifiants actifs

Truffle Security a identifié 543 699 identifiants uniques dans des dépôts GitHub publics. Lors de tests effectués fin juillet 2026, les services qui les avaient émis les acceptaient toujours.

Ce résultat met en évidence l’écart entre la détection d’un secret publié et sa désactivation effective. Les clés d’API, les identifiants de comptes de service, les jetons et les chaînes de connexion à des bases de données peuvent continuer à donner accès à des ressources tant que leur propriétaire ou le fournisseur du service ne les a pas renouvelés ou révoqués.

L’analyse s’appuyait sur un jeu de données constitué pour entraîner de grands modèles de langage. Selon le compte rendu de BleepingComputer sur l’étude, le crawl à l’origine de ces données couvrait 224 millions de dépôts et plus de 58 milliards de fichiers avant de s’achever le 7 août 2025.

SecurityWeek rapporte que l’analyse a détecté 1 103 438 identifiants exposés au total. Truffle a ensuite établi que 543 699 étaient toujours actifs. L’étude a mesuré leur exposition publique et leur validité persistante, mais pas si des attaquants les avaient découverts ou exploités.

Certains identifiants sont restés publics pendant des années

Un identifiant unique restait accessible publiquement pendant 784 jours en médiane. Environ 10 % des identifiants encore actifs avaient plus de 6,3 ans, tandis qu’un quart des identifiants détectés avaient plus de quatre ans.

Certains étaient bien plus anciens. Truffle a trouvé 2 636 identifiants actifs dans des fichiers dont la dernière modification remontait à avant 2015. Le plus ancien était une clé AWS publiée en 2009 et jamais modifiée depuis, selon SecurityWeek.

Ces chiffres font du code historique un élément central du problème d’exposition. Truffle a trouvé des identifiants dans plus de 1,1 million de fichiers et de dépôts, y compris des copies dans des forks. Supprimer un secret de la version actuelle d’un projet ne suffit donc pas à le faire disparaître de tous les endroits où il a pu être publié.

La suppression ne révoque pas non plus l’identifiant concerné. Si le service émetteur accepte toujours la valeur d’origine, une copie récupérée dans un ancien fichier ou dépôt public peut rester utilisable.

La concentration d’identifiants actifs a augmenté au fil de la période étudiée. Truffle a relevé 3,72 identifiants actifs par million de fichiers en 2015, un chiffre qui a atteint un pic de 11,62 par million en 2025.

Les résultats concernant GitHub dépassent également ceux de la précédente analyse de Truffle sur Hugging Face. Cette analyse avait détecté 221 303 identifiants actifs, soit moins de la moitié du nombre relevé dans les données de GitHub.

Le taux de validité variait fortement selon le type d’identifiant

La probabilité qu’un secret exposé fonctionne encore variait considérablement selon sa catégorie et le service qui l’avait émis.

Sur les 126 963 identifiants de comptes de service Google Cloud exposés, 69 041 étaient toujours valides. SecurityWeek indique qu’il s’agissait de la catégorie la plus importante d’identifiants actifs parmi celles recensées. Les autres catégories signalées comprenaient :

• 51 067 chaînes de connexion MongoDB actives
• 33 343 clés d’API Google toujours valides
• Un jeton npm encore fonctionnel sur les 101 886 jetons npm publiés

Le résultat concernant npm contraste fortement avec celui des autres catégories. Presque tous les jetons npm publiés dans le jeu de données avaient cessé de fonctionner, alors que des dizaines de milliers d’identifiants Google Cloud, de chaînes de connexion MongoDB et de clés d’API Google étaient toujours acceptés.

Les pratiques de révocation des fournisseurs déterminent en partie la durée pendant laquelle une exposition reste dangereuse. GitHub peut détecter ou signaler certains secrets, mais ne peut pas invalider de lui-même les identifiants émis par un autre service.

Les articles ne détaillent pas les droits associés à chaque identifiant encore actif. Le chiffre de 543 699 ne peut donc pas être interprété comme le nombre de comptes, de systèmes ou d’environnements cloud compromis. Chaque secret ne donne accès qu’aux ressources et aux privilèges qui lui sont associés, lesquels peuvent varier considérablement.

Il n’en reste pas moins qu’un identifiant toujours valide ouvre la voie à un accès non autorisé. Un identifiant accessible publiquement n’a pas besoin d’être contourné si le service correspondant le reconnaît toujours.

Push Protection a limité l’exposition, mais uniquement dans son périmètre

La fonctionnalité Push Protection de GitHub analyse le code envoyé à la recherche de motifs caractéristiques de secrets, comme des clés d’API et des jetons d’accès. Lorsqu’elle repère un secret pris en charge, elle peut bloquer l’envoi avant que l’identifiant ne devienne public.

BleepingComputer rapporte que la fonctionnalité a été lancée pour les utilisateurs d’Advanced Security en avril 2022, puis rendue disponible pour les dépôts publics en mai 2023. L’article indique également que GitHub a activé Push Protection pour tous les utilisateurs en février 2024. Une autre description de son déploiement, dans ce même article, ne correspond pas exactement à ces dates.

Truffle a réparti les identifiants actifs en trois groupes :

• 245 959 étaient antérieurs aux alertes gratuites d’analyse des secrets.
• 97 897 ont été publiés alors que l’analyse était gratuite, mais que Push Protection n’était pas encore activée par défaut.
• 199 843 ont été exposés après l’activation du blocage par défaut.

Le dernier groupe représentait environ 36,8 % du total des identifiants actifs. Près de 200 000 identifiants publiés pendant la période où le blocage était activé par défaut étaient donc toujours acceptés au moment des tests de Truffle.

Cela ne signifie pas que la mesure était inefficace. Pour les catégories d’identifiants couvertes par Push Protection, le taux d’exposition a baissé de 53 % après l’activation par défaut de la fonctionnalité. Cette baisse ne concerne que les catégories protégées, et non l’ensemble des expositions d’identifiants.

La couverture constitue une limite importante. BleepingComputer rapporte que 51,8 % des identifiants encore actifs appartenaient à des catégories non bloquées par défaut par Push Protection, notamment les chaînes de connexion à des bases de données et les clés d’API Google.

Push Protection vise également à bloquer les nouvelles tentatives de publication de secrets pris en charge. Elle ne révoque pas les identifiants exposés avant son intervention.

Les alertes sur les secrets nécessitent toujours l’intervention des propriétaires et des fournisseurs

GitHub dispose d’un programme d’analyse des secrets qui transmet les jetons exposés aux services qui les ont émis. Toutefois, GitHub n’oblige pas ces fournisseurs à révoquer les identifiants signalés.

Truffle attribue une partie de l’exposition persistante au fait que certains fournisseurs n’ont peut-être pas de procédure pour invalider les jetons divulgués. Comme le décrit l’article de SecurityWeek sur ces résultats, le traitement des alertes concernant d’anciennes fuites dépend aussi de l’activation de ces alertes par les propriétaires des dépôts, de l’examen des résultats et du renouvellement des identifiants concernés.

La correction peut donc échouer à plusieurs étapes :

1. GitHub ou un autre outil d’analyse doit reconnaître l’identifiant.
2. Une alerte doit parvenir au propriétaire du dépôt ou au fournisseur qui a émis l’identifiant.
3. Quelqu’un doit évaluer le signalement.
4. L’identifiant exposé doit être révoqué ou renouvelé.

La détection seule ne désactive pas l’identifiant. Supprimer la chaîne de caractères du code visible sans l’invalider présente la même limite.

Ces résultats doivent également être interprétés avec prudence. Truffle a vérifié que les identifiants étaient exposés et fonctionnels, mais l’étude n’a pas établi dans quelle proportion ils avaient été volés ou utilisés à mauvais escient par des attaquants.

Le renouvellement des identifiants et l’analyse de l’historique sont prioritaires

Truffle recommande en premier lieu de renouveler immédiatement les identifiants exposés. Les organisations devraient traiter toute publication publique comme un incident touchant au cycle de vie des identifiants, et non comme une simple tâche de nettoyage du code.

Les équipes concernées devraient :

1. Renouveler immédiatement les identifiants exposés. La valeur publiée doit cesser de fonctionner auprès du service qui l’a émise.
2. Supprimer les secrets des dépôts. Cela réduit leur visibilité persistante, mais ne remplace pas leur révocation.
3. Analyser l’historique des dépôts. Vérifier uniquement la version actuelle peut laisser passer des identifiants présents dans d’anciens fichiers ou commits.
4. Configurer une expiration automatique. Des secrets à durée de vie limitée réduisent la période pendant laquelle une exposition passée inaperçue reste exploitable.
5. Utiliser Push Protection et les alertes d’analyse des secrets. Ces mesures peuvent bloquer ou détecter certains types de secrets, mais elles doivent s’inscrire dans un processus de renouvellement opérationnel.

Lors de leurs vérifications, les équipes devraient aussi tenir compte des forks et des copies multiples relevés pendant l’enquête. Elles devraient également examiner les journaux d’activité des fournisseurs concernés afin de repérer toute utilisation des identifiants exposés, car l’étude globale ne permet pas de déterminer si les secrets d’une organisation en particulier ont été détournés.

Les deux articles publiés ne recensent ni les valeurs des identifiants ni les URL des dépôts concernés. Les organisations doivent donc examiner leur propre code public, l’historique de leurs dépôts et leurs inventaires d’identifiants, plutôt que d’attendre la publication d’une liste exhaustive de secrets exposés.

Le problème ne tient pas seulement au fait que des développeurs ont publié des valeurs sensibles. Il tient aussi au fait que des centaines de milliers de ces valeurs sont restées fonctionnelles, parfois pendant des années après leur première mise en ligne.