En bref

  • Le chercheur Ben Zimmermann a scanné 7,25 millions de dépôts publics sur Gitee et découvert 26 400 identifiants cloud et IA encore actifs au moment de la publication, le 28 octobre 2026.
  • Les services les plus touchés sont Alibaba Cloud (9 473 paires AccessKey), mais aussi OpenAI, DeepSeek, YouTube et BigModel — tous exposés en clair dans du code source public.
  • La majorité des identifiants n'avaient pas été révoqués au moment de la publication : les développeurs concernés doivent immédiatement auditer leurs dépôts et faire tourner leurs clés.

Ce qui s'est passé

Le chercheur indépendant Ben Zimmermann a publié le 28 octobre 2026 les résultats d'une analyse exhaustive des dépôts publics hébergés sur Gitee, la principale plateforme de gestion de code source en Chine, souvent présentée comme l'équivalent local de GitHub. Sur 7,25 millions de dépôts publics analysés au cours d'un scan d'un mois, il a identifié 26 400 identifiants de services cloud et d'intelligence artificielle encore valides au moment où il les a testés. Ce chiffre ne représente que les secrets fonctionnels : de nombreux autres identifiants avaient probablement déjà été révoqués ou avaient expiré avant l'analyse, ce qui suggère que le volume total de secrets jamais exposés est nettement supérieur.

La méthodologie employée repose sur deux outils spécialisés dans la détection de secrets dans le code source : TruffleHog et Kingfisher. Ces outils analysent le contenu textuel des fichiers à la recherche de patterns correspondant à des identifiants de services connus — clés API, tokens d'authentification, identifiants de bases de données, certificats, etc. Une fois les candidats identifiés, chaque secret a été activement vérifié contre le service émetteur pour confirmer sa validité. Seuls les identifiants ayant passé cette vérification d'authenticité ont été comptabilisés dans les 26 400 credentials exposés.

Les services les plus représentés dans la fuite sont révélateurs de l'écosystème technologique dans lequel s'inscrivent les développeurs utilisant Gitee. En tête, Alibaba Cloud concentre à lui seul 9 473 paires de clés AccessKey valides — des identifiants qui permettent un accès programmatique complet aux ressources cloud d'un compte Alibaba, pouvant inclure des instances de calcul, des bases de données, des buckets de stockage et bien d'autres services. La compromission d'une paire AccessKey offre potentiellement un accès à l'ensemble de l'infrastructure cloud d'une organisation, avec les risques d'exfiltration de données, de destruction de ressources et de facturation frauduleuse que cela implique.

Au-delà d'Alibaba Cloud, Zimmermann a retrouvé des milliers d'identifiants pour des services d'IA populaires : OpenAI (dont les clés API permettent des appels facturés sur le compte du développeur exposé), DeepSeek (le modèle chinois dont la popularité a explosé en 2025-2026), BigModel (la plateforme de Zhipu AI), ainsi que des tokens YouTube permettant l'accès à l'API Google. La présence de clés OpenAI et DeepSeek dans cette liste illustre un phénomène récent : avec la démocratisation des LLM et des applications IA, les clés API vers les fournisseurs de modèles sont devenues des actifs de valeur, susceptibles d'être exploitées pour du cryptojacking sémantique — utilisation frauduleuse des crédits API d'un tiers pour générer massivement du contenu ou mener des attaques d'inférence adversariale.

Zimmermann a adopté une approche de divulgation responsable partielle : il a contacté les fournisseurs de services ayant le plus grand nombre d'identifiants exposés pour leur transmettre les listes correspondantes, leur permettant de révoquer les clés concernées ou de prévenir leurs clients. En revanche, il n'a pas contacté directement les développeurs ayant commis ces secrets dans leurs dépôts publics. Au moment de la publication de ses résultats, il n'avait pas encore confirmé que l'ensemble des identifiants signalés avait été révoqué, suggérant que de nombreux secrets exposés restaient actifs et potentiellement exploitables par des acteurs malveillants.

Cette analyse s'inscrit dans un contexte plus large d'exposition de secrets dans les plateformes de gestion de code. GitHub a observé et signalé depuis plusieurs années des millions de secrets dans des dépôts publics, conduisant à la création de son programme Secret Scanning, qui notifie automatiquement les fournisseurs partenaires lorsque leurs patterns d'identifiants sont détectés. L'analyse de Gitee révèle que ce problème n'est pas limité aux plateformes occidentales et que l'écosystème de développement chinois, avec ses propres services cloud dominants, connaît des phénomènes similaires à très grande échelle.

Les patterns d'erreur humaine qui conduisent à ces expositions sont bien documentés : un développeur travaille en local, teste son code avec des clés réelles incluses en dur dans les fichiers de configuration ou directement dans le code source, puis pousse l'ensemble vers un dépôt public sans supprimer ces secrets, ou sans réaliser que le dépôt est en accès public. Git conservant l'intégralité de l'historique des commits, même une suppression ultérieure du fichier ne suffit pas à effacer un secret qui a été committé — il faut procéder à une réécriture complète de l'historique git, opération nettement plus complexe que la simple suppression du fichier incriminé.

D'après les informations publiées par The Hacker News et RuntimeWire, le scan de Gitee réalisé par Zimmermann constitue la première analyse publique et systématique de cette plateforme à cette échelle. Avec 7,25 millions de dépôts analysés, c'est un échantillon représentatif mais non exhaustif, Gitee hébergeant un volume total bien supérieur. Il est probable que le nombre réel de secrets exposés sur la plateforme dépasse significativement les 26 400 identifiants valides identifiés. MongoDB a également publié une analyse détaillée de la méthodologie de scan utilisée, soulignant la combinaison de TruffleHog et Kingfisher comme approche de référence pour ce type d'audit à grande échelle.

Pourquoi c'est important

L'exposition de 26 400 identifiants valides dans des dépôts publics représente un risque opérationnel immédiat pour les organisations concernées. Contrairement à une fuite de données personnelles qui nécessite des étapes intermédiaires pour être monétisée, des clés API cloud ou IA peuvent être exploitées directement pour générer des coûts frauduleux, exfiltrer des données, modifier ou détruire des environnements de production. Le temps entre la découverte d'une clé exposée et son exploitation malveillante peut se mesurer en minutes lorsque des bots automatisés scannent en continu les dépôts publics à la recherche de tels secrets — une pratique documentée depuis plusieurs années dans les rapports des équipes de threat intelligence.

La prédominance des clés Alibaba Cloud dans les résultats est particulièrement significative. Alibaba Cloud est le premier fournisseur de cloud public en Asie et l'un des acteurs majeurs au niveau mondial. Ses clients incluent des entreprises ayant des activités en Chine ou dans la région Asie-Pacifique, mais aussi un nombre croissant d'entreprises occidentales utilisant ses services pour servir des marchés asiatiques. Une paire AccessKey compromise offre un vecteur d'accès très large : elle peut permettre l'accès à des données sensibles, la création de ressources pour du minage de cryptomonnaies, le pivotement vers d'autres systèmes de l'organisation, ou la perturbation d'environnements de production critiques.

Sur le plan de la chaîne d'approvisionnement logicielle, cette découverte illustre comment des pratiques de développement insuffisamment sécurisées créent des risques pour l'ensemble de l'écosystème. Un développeur exposant sa clé OpenAI ne compromet pas seulement son propre budget : dans le cas d'une application multi-tenant, les données des utilisateurs finaux peuvent également être exposées. La frontière entre sécurité du développeur individuel et sécurité de l'infrastructure collective est de plus en plus floue dans un monde où les API constituent la colonne vertébrale des applications modernes.

Pour les équipes de sécurité françaises et européennes, cet incident rappelle l'importance d'intégrer des outils de détection de secrets dans les pipelines CI/CD, d'activer les fonctionnalités de secret scanning proposées par les plateformes de gestion de code, et de former les développeurs aux bonnes pratiques de gestion des identifiants. Des outils comme les variables d'environnement chiffrées, les gestionnaires de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et les pre-commit hooks de détection permettent de réduire drastiquement le risque d'exposition accidentelle. La prévention reste de loin moins coûteuse que la gestion de crise consécutive à une fuite d'identifiants cloud ou IA.

Ce qu'il faut retenir

  • 26 400 identifiants cloud et IA valides exposés sur Gitee : si vous avez des dépôts publics sur cette plateforme ou d'autres, auditez-les immédiatement avec TruffleHog ou un outil équivalent.
  • Les clés API cloud (Alibaba Cloud, AWS, GCP) et IA (OpenAI, DeepSeek) committées dans du code source sont exploitables en quelques minutes par des bots automatisés.
  • Intégrer la détection de secrets dans les pipelines CI/CD et activer le secret scanning des plateformes Git est une mesure préventive fondamentale à mettre en place sans délai.

Comment détecter si j'ai des secrets exposés dans mes dépôts publics ?

Utilisez des outils spécialisés comme TruffleHog, Gitleaks ou detect-secrets pour scanner l'historique complet de vos dépôts git, pas seulement les fichiers actuels. Ces outils analysent tous les commits et peuvent retrouver des secrets même supprimés dans des versions ultérieures. Pour la prévention, activez le secret scanning natif de GitHub ou GitLab, configurez des pre-commit hooks avec detect-secrets, et ne commitez jamais de clés en dur — utilisez des variables d'environnement ou un gestionnaire de secrets dédié.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact