SleeperGem : attaque supply chain via comptes RubyGems

Une chaîne d'approvisionnement Ruby ciblée par des comptes oubliés

Le 20 juillet 2026, des chercheurs en sécurité de la société Aikido Security ont publié l'analyse complète d'une attaque supply chain sophistiquée baptisée SleeperGem, ciblant l'écosystème Ruby et son registre officiel de packages, RubyGems. La campagne a permis à des acteurs malveillants d'introduire du code compromis dans trois gems légitimes, menaçant potentiellement les environnements de développement d'une large communauté de développeurs Ruby à travers le monde.

Les trois packages concernés sont : git_credential_manager, publié en quatre versions successives (2.8.0, 2.8.1, 2.8.2 et 2.8.3) le 18 juillet 2026 ; Dendreo, dont les versions 1.1.3 et 1.1.4 ont reçu des mises à jour malveillantes ; et fastlane-plugin-run_tests_firebase_testlab, dont la version 0.3.2 a été compromise. Le premier est un gem entièrement frauduleux qui usurpe l'identité de l'outil Microsoft Git Credential Manager. Les deux autres étaient des packages authentiques, bien établis dans l'écosystème, dont les comptes propriétaires avaient simplement cessé d'être actifs depuis plusieurs années.

La chronologie de l'attaque révèle une préparation méthodique. Dès le 14 juillet 2026, cinq versions de packages — représentant collectivement environ deux millions de téléchargements hebdomadaires — intégraient déjà un dropper obfusqué. Le gem Dendreo n'avait reçu aucune mise à jour depuis le 24 octobre 2020, soit près de six ans d'inactivité totale. Le plugin fastlane-plugin-run_tests_firebase_testlab était resté en sommeil depuis le 9 mars 2019, plus de sept ans sans la moindre modification. C'est précisément cette longue inactivité qui a rendu ces comptes attractifs pour les attaquants : des packages établis, avec un historique propre, dont personne ne surveille plus le tableau de bord d'administration.

Charlie Eriksen, chercheur chez Aikido Security à l'origine de la découverte, a résumé la logique de l'attaque : « Un compte RubyGems qui s'est tu pendant six ou sept ans ne paraît risqué pour personne. C'est exactement le profil qui vaut la peine d'être pris en main. C'est de là que vient le nom SleeperGem : non pas un attaquant planté dans la durée, mais un vrai compte ordinaire qui était simplement devenu dormant et paraissait assez inoffensif pour être détourné sans que personne ne s'en aperçoive. »

Le mécanisme d'infection est conçu pour rester sous le radar. Chaque version malveillante se comporte comme un loader à deux étages. Lors de l'installation du gem, le code embarqué établit une connexion vers un serveur Forgejo — une forge logicielle auto-hébergée — contrôlé par les attaquants, pour récupérer une charge utile de second stade. Avant d'exécuter quoi que ce soit, le loader effectue une vérification critique : il détermine s'il s'exécute dans un pipeline CI/CD ou un environnement de build automatisé. Si tel est le cas, il s'arrête silencieusement, sans laisser de trace.

Cette logique de détection d'environnement est délibérée et sophistiquée : les attaquants ne ciblent pas les pipelines d'intégration continue mais exclusivement les machines physiques des développeurs. Sur une machine de développeur identifiée comme cible, le malware dépose un daemon natif persistant adapté au système d'exploitation détecté et installe un mécanisme de persistance robuste pour survivre aux redémarrages — via launchd sur macOS ou systemd sur les distributions Linux. La combinaison d'un vol de credentials potentiel via l'usurpation du Git Credential Manager et d'un accès persistant à distance représente un vecteur d'intrusion majeur vers les systèmes de production.

L'usurpation du Microsoft Git Credential Manager mérite une attention particulière. Cet outil gère les authentifications auprès des forges Git (GitHub, GitLab, Azure DevOps) et stocke des tokens d'accès OAuth potentiellement très puissants. Un développeur qui installe involontairement le faux git_credential_manager pourrait voir ses tokens interceptés, offrant aux attaquants un accès direct aux dépôts de code source de son organisation, avec les risques d'injection de backdoors dans le code applicatif que cela implique.

Un élément aggravant a été mis en évidence par l'analyse des comptes impliqués : les gems Dendreo et fastlane-plugin-run_tests_firebase_testlab appartiennent à deux mainteneurs distincts — respectivement les comptes « LR-DEV » et « pinkroom » — ce qui confirme qu'au moins deux comptes RubyGems indépendants ont été compromis dans cette campagne. L'étendue réelle du compromis fait l'objet d'une investigation active. RubyGems a procédé au retrait de toutes les versions malveillantes identifiées. La plateforme avait déjà suspendu temporairement les nouvelles inscriptions en mai 2026 à la suite d'une vague distincte de packages malveillants, signe d'une pression continue sur cet écosystème.

Les registres de packages face au défi de la gouvernance longue durée

SleeperGem s'inscrit dans une tendance de fond particulièrement alarmante qui s'est accélérée depuis 2024. Les attaques ciblant les chaînes d'approvisionnement logicielles via les registres de packages open source ont explosé en nombre et en sophistication. PyPI, npm, NuGet, Composer et désormais RubyGems sont tous devenus des cibles prioritaires pour des acteurs dont le niveau de ressource va de la cybercriminalité organisée aux groupes étatiques.

Ce qui distingue fondamentalement SleeperGem des attaques classiques par typosquatting ou par création de nouveaux comptes malveillants, c'est l'exploitation de la confiance implicite accordée aux packages anciens. La plupart des politiques de sécurité des dépendances recommandent de favoriser les packages anciens et établis, disposant d'un historique long et d'une communauté active. Ce conseil, parfaitement rationnel dans son principe, devient ici le vecteur d'attaque lui-même. Un gem dont le compte mainteneur est inactif depuis des années n'a personne pour détecter une connexion suspecte au tableau de bord d'administration, recevoir une alerte d'authentification compromise, ou réagir à une notification de nouveau commit inattendu.

La décision délibérée de cibler les machines des développeurs plutôt que les pipelines CI/CD révèle une évolution stratégique dans les tactiques des attaquants supply chain. Les environnements CI/CD modernes bénéficient généralement d'une surveillance active, d'environnements d'exécution éphémères et de contrôles d'accès stricts. Les postes de travail des développeurs concentrent en revanche des actifs d'une valeur considérable : tokens GitHub et GitLab, clés AWS et GCP, secrets d'accès aux bases de données de production, clients VPN d'entreprise, certificats de signature de code. Un attaquant qui compromet durablement le poste d'un développeur senior peut potentiellement pivoter vers l'ensemble de l'infrastructure de l'organisation.

Pour les responsables de la sécurité et les équipes DevSecOps, cet incident souligne la nécessité urgente d'adopter des politiques de gestion active du cycle de vie des dépendances. Tout package non mis à jour depuis plusieurs années et dont le mainteneur est injoignable représente un risque de gouvernance latent. Les outils de surveillance automatisée des dépendances doivent être configurés pour alerter non seulement sur les nouvelles vulnérabilités CVE, mais aussi sur les mises à jour inattendues de packages normalement dormants — c'est précisément ce signal anormal que SleeperGem aurait pu déclencher si les équipes avaient surveillé l'activité de leurs dépendances stabilisées. Des solutions comme Bundler Audit, Socket.dev ou Snyk permettent d'automatiser une partie de cette surveillance, mais ne remplacent pas une politique humaine de validation des mises à jour inattendues.

Ce qu'il faut retenir

• Auditer immédiatement l'usage des gems git_credential_manager, Dendreo et fastlane-plugin-run_tests_firebase_testlab sur toutes les machines de développeurs et dans tous les Gemfiles du parc.
• Procéder à une rotation complète des credentials (tokens GitHub/GitLab, clés cloud AWS/GCP/Azure, secrets CI/CD) sur toutes les machines potentiellement exposées, même sans confirmation d'infection avérée.
• Mettre en place une surveillance des mises à jour inattendues sur les dépendances normalement stables, et revoir les politiques d'approbation des mises à jour de packages dans les Gemfiles de production.