Un dépôt public peut conserver une clé secrète longtemps après son oubli. Truffle Security a retrouvé 543 699 accès toujours actifs sur GitHub. Pour les PME, cette exposition transforme une erreur de code en risque opérationnel durable.
Truffle Security a repéré 1 103 438 secrets dans 224 millions de dépôts publics, puis testé leur activité. Fin juillet 2026, 543 699 identifiants répondaient encore auprès de leurs services. Ces clés, jetons d’accès et mots de passe exigent une révocation réelle, pas seulement une alerte. Pour une PME ou une ETI, le risque touche les données, les services cloud et la chaîne logicielle.
Le résultat révèle une faille de gouvernance autant qu’un défaut de code. Pour mieux comprendre les risques liés au vol d’identifiants dans les PME, il faut suivre le cycle complet d’une clé, de son dépôt à sa révocation.
GitHub : 543 699 identifiants encore actifs
Truffle Security a analysé 224 millions de dépôts publics en août 2025. L’équipe a recensé 1 103 438 secrets publiés dans des dépôts publics. Fin juillet 2026, elle a vérifié leur statut auprès des services concernés. Au total, 543 699 identifiants fonctionnaient encore lors du contrôle.
Ce décalage change la lecture du chiffre initial. Une clé présente sur GitHub ne constitue pas forcément un accès valide. Le test auprès des fournisseurs distingue la trace historique du risque opérationnel encore actif. Pour un dirigeant, seule cette seconde catégorie peut ouvrir un accès immédiat.
L’ensemble comprend 69 041 accès de comptes de service Google Cloud. Truffle a aussi relevé 51 067 chaînes de connexion MongoDB. Les chercheurs ont identifié 33 343 clés API Google encore actives. Ces données montrent la diversité des environnements touchés.
Des secrets anciens toujours utilisables
La plus vieille clé recensée concerne AWS et remonte à 2009. Elle n’avait pas été modifiée depuis son ajout au dépôt. La durée médiane d’exposition atteint 784 jours, soit plus de deux ans. Le temps ne neutralise pas une clé oubliée : seul son retrait le fait.
Truffle compte 2 636 accès actifs dans des fichiers modifiés avant 2015. Un quart des éléments recensés a plus de quatre ans. Une application peut donc porter des accès oubliés par plusieurs équipes successives. L’historique du dépôt devient alors une carte des dettes techniques.
Pour une PME, un ancien jeton peut relier un dépôt à un stockage cloud. Un accès MongoDB peut exposer des dossiers clients ou des données internes. Le préjudice dépend des droits associés, pas de l’âge du fichier. La date du code ne dit rien sur la portée actuelle du secret.
Les protections GitHub n’annulent pas l’exposition
Alertes gratuites et blocage par défaut
GitHub propose des alertes gratuites pour repérer des secrets exposés. Sa protection des envois bloque certains dépôts de clés détectées. Pourtant, près de la moitié des éléments recensés sont apparus après ces mesures. Le contrôle prévient certaines erreurs, mais il ne répare pas le passé.
Les chiffres de Truffle détaillent cette limite. 245 959 secrets sont antérieurs aux alertes gratuites. 97 897 ont été publiés lorsque la protection restait une option. Après son activation par défaut, 199 843 ont encore rejoint des dépôts publics.
Cette dernière catégorie répondait toujours aux fournisseurs plus de deux ans après sa mise en ligne. Un blocage peut empêcher un nouvel envoi, mais il ne supprime pas une clé déjà publiée. L’entreprise doit traiter chaque alerte comme une demande d’intervention. Un dépôt propre ne prouve pas que ses anciens accès sont révoqués.
La révocation dépend aussi des fournisseurs
Le programme de détection GitHub transmet certains jetons aux services qui les ont émis. Ces partenaires peuvent alors retirer les accès concernés. Mais le dispositif ne les oblige pas à le faire. La détection ne vaut pas révocation : cette distinction explique une part du stock actif.
Certains fournisseurs ne disposent pas d’un processus automatique pour couper une clé divulguée. D’autres attendent une action du propriétaire du compte. Une alerte ignorée ne modifie donc pas les droits d’accès. La gestion des accès doit inclure une procédure de remplacement et de vérification.
Une ETI peut ainsi recevoir une alerte sans savoir quelle équipe possède le service visé. Si le responsable a quitté l’entreprise, le jeton peut rester valide. Les rôles flous prolongent l’exposition, même avec des outils adaptés. Chaque secret doit avoir un propriétaire identifié et un délai de révocation.
Cette logique rejoint les incidents où la fuite d’un compte ouvre d’autres systèmes. Les équipes peuvent comparer leurs pratiques aux réflexes après un vol de données. La réponse doit couvrir l’accès initial, ses dépendances et ses traces.
Révoquer les clés exposées et réduire le risque
Les premières actions pour une PME ou une ETI
Les équipes doivent commencer par tester les secrets repérés, puis classer les accès selon leurs droits. Une clé d’administration mérite une réaction prioritaire. Un jeton limité à un service demande tout de même une vérification. La priorité dépend du pouvoir de chaque clé, pas du seul nom du fichier.
Ensuite, le propriétaire doit révoquer l’accès auprès du service émetteur. Il crée une nouvelle clé, la stocke dans un coffre adapté, puis vérifie les journaux. Cette séquence limite le risque de coupure imprévue. La rotation doit s’accompagner d’un contrôle des usages passés.
Les équipes peuvent aussi analyser l’historique Git, pas uniquement la branche courante. Une suppression du fichier visible ne retire pas ses anciennes versions. Les outils de détection doivent couvrir les dépôts publics et privés. Le nettoyage du dépôt ne suffit pas sans révocation côté fournisseur.
Installer une défense qui suit tout le cycle
La prévention repose sur des droits minimaux, des clés courtes et des alertes suivies. Les hooks locaux réduisent les erreurs avant l’envoi vers GitHub. La protection native bloque certains cas, mais les équipes doivent contrôler ses réglages. La prévention fonctionne avec une réponse claire, pas en autonomie.
Chaque alerte doit rejoindre un circuit avec un responsable, une échéance et une preuve de clôture. Le journal des actions permet de confirmer le retrait effectif du jeton. Une revue périodique aide à repérer les accès sans propriétaire. Une alerte close exige une preuve de révocation ou de validité contrôlée.
Les PME peuvent inscrire ces gestes dans leur procédure d’incident. Elles réduisent aussi les droits des comptes de service et séparent les environnements. Cette discipline limite l’effet d’une compromission sur les données et les opérations. La cybersécurité dépend ici d’une routine vérifiable, pas d’un outil isolé.
Enfin, le pilotage doit rapprocher les équipes de développement, de sécurité et des métiers. Un tableau de suivi peut indiquer l’âge des secrets, leur propriétaire et leur statut. Les dirigeants obtiennent ainsi une mesure concrète du risque résiduel. Un accès oublié devient gérable dès qu’il est suivi.
