26 400 clés cloud et IA encore valides traînent dans les dépôts publics Gitee
Le 28 octobre 2026, le chercheur Ben Zimmermann a publié le résultat d’un scan de 7,25 millions de dépôts publics Gitee : 26 400 identifiants cloud et IA fonctionnaient encore, dont 9 473 paires de clés Alibaba Cloud. Retirer une clé du code ne la révoque pas : la seule parade est la rotation côté fournisseur.
28 octobre 2026. Le chercheur indépendant Ben Zimmermann a publié les résultats d’un scan de 7,25 millions de dépôts publics Gitee, la forge de code chinoise. Verdict : 26 400 identifiants laissés dans du code public fonctionnaient encore au moment du test — autrement dit, quiconque les aurait copiés aurait pu les utiliser. Le point qui compte : Zimmermann n’a pas pu confirmer qu’un seul de ces identifiants avait été révoqué. Effacer une clé du code n’est pas la révoquer.
Ce qui traînait en clair
Les identifiants exposés sont massivement des clés de services cloud et IA. En tête, 9 473 paires de clés Alibaba Cloud AccessKey, puis 3 805 clés d’API YouTube, 3 170 clés DeepSeek, 1 489 clés de la plateforme BigModel de Zhipu, et 1 348 clés OpenAI. Des volumes plus faibles ont été trouvés pour GitHub, AWS, Google Cloud et Gemini. Au milieu de cette liste, une anomalie qui change tout : l’une des clés était « un identifiant administrateur d’organisation actif pour une plateforme d’IA d’entreprise majeure » — Zimmermann n’a nommé ni la plateforme ni la portée de l’accès.
La méthode est aussi importante que le résultat. Le scan a duré environ un mois, sans que le chercheur précise les dates. Il a fait tourner deux détecteurs de secrets — TruffleHog et Kingfisher, ce dernier développé avec MongoDB — sur chaque dépôt, en lisant l’historique complet des commits. Chaque identifiant a été testé contre le service qui l’avait émis, et seuls ceux qui répondaient ont été conservés. Conséquence directe : une clé qu’un développeur a retirée du code après l’avoir poussée reste détectable et comptée, car elle vit encore dans l’historique.
Deux scanners, deux moitiés du problème
Le chiffre le plus instructif de l’étude n’est pas le total, c’est le désaccord entre les outils. TruffleHog a trouvé 12 737 identifiants valides, Kingfisher 14 664 — mais seulement 1 001 ont été trouvés par les deux. Chaque outil, seul, n’a vu qu’environ la moitié du total. La raison est structurelle : TruffleHog a repéré la quasi-totalité des clés Alibaba Cloud, tandis que Kingfisher a trouvé les 1 489 clés BigModel parce que TruffleHog ne possède tout simplement pas de détecteur pour les clés de Zhipu.
C’est une leçon pour toute équipe qui s’appuie sur un scanner unique : un outil ne détecte que ce que ses détecteurs savent reconnaître. Vérifier que son scanner couvre les services que l’on utilise réellement n’est pas un détail, c’est la différence entre « rien trouvé » et « rien cherché ». Le bon réflexe est de recouper deux moteurs, comme l’a fait Zimmermann, et de valider les détecteurs contre son propre inventaire de fournisseurs.
La temporalité du risque
La répartition dans le temps est révélatrice. Par date de commit, 12 242 identifiants proviennent de 2025, soit près de la moitié du total ; certains remontent à la fin des années 2000. Une clé poussée par erreur il y a quinze ans peut encore fonctionner aujourd’hui si personne ne l’a révoquée — la durée de vie d’un secret divulgué n’a rien à voir avec la date à laquelle il a fuité.
Le taux de fuite mesuré — 3,64 identifiants valides pour 1 000 dépôts scannés — dépasse celui des scans antérieurs de GitLab (3,11) et de Bitbucket (2,39), qui n’utilisaient pourtant que TruffleHog. Sur la seule base de TruffleHog, le taux de Gitee tombe à 1,76 — mais ce chiffre exclut les services que TruffleHog ne couvre pas, comme Zhipu. Zimmermann conclut prudemment qu’aucun des deux chiffres ne permet de dire quelle plateforme fuit le plus. La comparaison honnête exigerait des scanners identiques sur des corpus identiques.
Ce qu’une clé valide permet de faire
La gravité d’une clé dépend du service qui l’a émise. OpenAI est explicite : une clé compromise permet à autrui de consommer le quota du compte sans le consentement de son propriétaire, ce qui peut causer « perte de données, frais inattendus », l’épuisement du quota mensuel et l’interruption de l’accès à l’API. Une clé d’API YouTube est une clé Google Cloud qui identifie un projet : sans restriction d’API, elle peut être utilisée avec tous les services qui acceptent les clés Google Cloud. Et une paire Alibaba Cloud AccessKey, c’est potentiellement la création ou la suppression de ressources facturées.
La réponse recommandée est uniforme et tient en une phrase, reprise par Truffle Security, l’éditeur de TruffleHog : traiter toute clé qui est passée un jour par un dépôt public comme exposée, et la révoquer chez le fournisseur. Supprimer la clé du code ou réécrire l’historique du dépôt ne la révoque pas. Les procédures sont déclinées par fournisseur : créer une nouvelle paire AccessKey chez Alibaba Cloud, basculer les applications dessus, puis désactiver et supprimer l’ancienne, en contrôlant les frais inattendus via ActionTrail (90 jours d’appels d’API) et les journaux de chaque service de données ; faire tourner la clé chez Google et ajouter des restrictions d’API pour la limiter aux seuls services nécessaires ; faire tourner la clé immédiatement depuis la page des clés chez OpenAI et fixer des plafonds de dépense.
# Scanner un dépôt local avec deux moteurs complémentaires
pip install trufflehog3 kingfisher-secrets 2>/dev/null
trufflehog filesystem . --no-update
kingfisher scan . --verify
# Toute clé remontée et « vérifiée » doit être révoquée chez le fournisseur, pas seulement retirée du codeVerdict
Si vous ou votre équipe avez déjà poussé une clé vers un dépôt public — Gitee ou ailleurs — partez du principe qu’elle est compromise et faites-la tourner chez le fournisseur dès maintenant : le scan de Ben Zimmermann montre que des milliers de clés poussées restent valides des années plus tard, et qu’aucune n’était confirmée révoquée. Si vous exploitez des modèles ou des API cloud payantes, ajoutez les deux réflexes qui coûtent presque rien : des plafonds de dépense chez OpenAI et des restrictions d’API chez Google Cloud pour plafonner le préjudice d’une clé qui fuit malgré vous. Et si vous avez la charge d’un pipeline de sécurité, ne faites pas confiance à un scanner unique : croisez TruffleHog et Kingfisher, et vérifiez leurs détecteurs contre la liste des services que votre organisation paie réellement. La fuite de secrets n’est pas un problème de code, c’est un problème de cycle de vie — et le cycle de vie d’une clé ne se termine que chez celui qui l’a émise.