Un identifiant supprimé d'un code public peut rester utilisable si personne ne le révoque. Sur la plateforme chinoise Gitee, un scan a découvert 26 400 clés cloud et IA qui se sont authentifiées lors des tests.
Le chercheur indépendant Ben Zimmermann a publié ces résultats le 28 octobre après avoir examiné 7,25 millions de dépôts publics. Les identifiants comprenaient Alibaba Cloud, DeepSeek et des services internationaux. Le scan n'a pas établi que des attaquants les avaient utilisés ni qu'ils étaient encore valides à ce jour.
Pour les développeurs chinois et les entreprises de la région APAC qui travaillent avec des fournisseurs régionaux, du code exposé peut également signifier que des comptes cloud ou des services d'IA sont exposés.
Des milliers de clés opérationnelles étaient enfouies dans l'historique Git
Dans le cadre de recherches menées avec l'équipe Kingfisher de MongoDB, Zimmermann a exécuté TruffleHog et Kingfisher sur l'historique complet des dépôts. Les deux scanners ont vérifié les identifiants suspects auprès du fournisseur émetteur et comptabilisé chaque clé opérationnelle une seule fois. Supprimer un secret du code actuel n'efface pas les anciens commits.
Fournisseur | Identifiants vérifiés |
Alibaba Cloud | 9,473 |
YouTube API | 3,805 |
DeepSeek | 3,170 |
Zhipu BigModel | 1,489 |
OpenAI | 1,348 |
Les découvertes comprenaient un identifiant doté de droits d'administration de l'organisation pour une plateforme d'IA d'entreprise non nommée. Une clé opérationnelle ne donne pas toujours accès aux fonctions d'administration : les clés API standard de Google identifient les projets pour la gestion des quotas et la facturation, et les risques dépendent de leurs restrictions.
L'écosystème Gitee chinois relie les développeurs régionaux aux services mondiaux
Choisi pour soutenir l'initiative nationale chinoise d'hébergement open source, Gitee indique compter plus de 14 millions de membres et 40 millions de projets. L'étude a examiné 7,25 millions de dépôts publics, et non l'ensemble des projets hébergés.
Des clés Alibaba Cloud, DeepSeek ou Zhipu pouvaient permettre une utilisation et une facturation non autorisées, selon les permissions. Le risque dépasse également les frontières : le dépôt Gitee d'un sous-traitant peut contenir des clés destinées à des applications exploitées ailleurs dans la région APAC. Les entreprises devraient donc examiner les projets Gitee de leurs fournisseurs, même si leur propre code est hébergé ailleurs.
Zimmermann a constaté que de nombreux commits étaient associés à des services de messagerie personnels, ce qui rendait difficile la détermination de leur propriétaire. La localisation de Gitee ne permet pas d'établir combien d'organisations concernées sont chinoises ni de prouver que les systèmes d'une entreprise citée ont été compromis.
Deux scanners ont révélé des angles morts différents en matière de sécurité
TruffleHog a identifié 12 737 identifiants opérationnels, contre 14 664 pour Kingfisher, avec seulement 1 001 identifiants en commun. Kingfisher a trouvé les 1 489 clés Zhipu, car TruffleHog ne disposait pas de détecteur pour ce service, ainsi que bien davantage de clés DeepSeek (2 940 contre 230). TruffleHog s'est montré plus performant pour Alibaba Cloud.
Près de la moitié des résultats, soit 12 242 clés, provenaient de commits de 2025. Pour les équipes chinoises de l'IA, ces écarts montrent pourquoi s'appuyer sur un seul scanner ou vérifier uniquement les fichiers sources actuels pourrait laisser des identifiants exposés indétectés.
The Hacker News a indiqué que les dates exactes du scan, qui a duré un mois, n'avaient pas été communiquées. Zimmermann a informé les principaux fournisseurs concernés, mais les développeurs individuels n'ont pas été contactés et la révocation n'a pas été confirmée. Une alerte fournisseur ne doit pas être confondue avec une correction effective.
Les développeurs chinois et les entreprises de la région APAC doivent enquêter sur les accès exposés
Les organisations doivent d'abord déterminer à qui appartient chaque clé exposée et quelles applications en dépendent. Supprimer du code ne permet pas d'invalider un identifiant copié ; les équipes doivent donc traiter l'accès sous-jacent auprès de son fournisseur.
- Développeurs et sous-traitants chinois : Recherchez les anciens commits, forks et projets partagés de Gitee. Vérifiez que les scanners reconnaissent les clés Alibaba Cloud, DeepSeek et Zhipu, puis stockez les clés de remplacement en dehors du code source.
- Administrateurs cloud : Suivez les instructions d'Alibaba Cloud pour remplacer les AccessKeys dans les applications avant de désactiver les anciennes. Examinez les 90 derniers jours d'ActionTrail à la recherche d'appels API inhabituels et de nouveaux utilisateurs ; vérifiez séparément les journaux des services OSS et SLS.
- Responsables des plateformes d'IA : Révoquez les clés API exposées, examinez leur utilisation et les frais associés, puis appliquez les limites et restrictions disponibles. OpenAI recommande des clés distinctes, des contrôles des dépenses et des vérifications avant la publication du code.
Les entreprises de la région APAC ayant des fournisseurs basés en Chine devraient demander des preuves de scans des dépôts, de révocation des clés et d'examen de l'activité. Cette vérification doit inclure les scripts CI/CD, les dépôts miroir et les projets de développement partagés. La révocation n'ayant pas été vérifiée pour l'ensemble de l'étude, un incident n'est pas résolu simplement parce que la ligne de code problématique a disparu.
À lire aussi : Des milliers de clés d'accès AWS divulguées restent actives, ce qui souligne pourquoi les entreprises doivent révoquer les identifiants exposés plutôt que de simplement les supprimer des dépôts publics.