Ou comment un simple pip install
 peut ruiner tout votre SI. Et si c’Ă©tait Banana Squad ?
Ah, GitHub. Ce formidable vivier de projets open source, de scripts miracles et de README réconfortants. Un petit git clone
, un pip install
, et hop : le problème est résolu. Ou plutôt remplacé par un RAT silencieux, une exfiltration de vos secrets AWS et un accès SSH ouvert sur toute la prod.
Bienvenue dans le monde merveilleux de la supply chain compromise version 2025, propulsée par un petit groupe bien organisé nommé Banana Squad. Non, ce n’est pas une série Netflix. C’est pire : c’est du Python toxique avec un badge de couverture de code et un guide d’installation clair. Et ça cible vous.
🧬 La recette du crime : une bibliothèque Python, un nom crédible, un peu de feinte
Banana Squad ne fait rien de révolutionnaire. Leur talent, c’est le mimétisme.
Ils créent de faux dépôts GitHub avec :
- des noms quasi-identiques à des bibliothèques connues (
reqeusts
,Âflaks
,Âdjango-guard
) - un README soigné, avec des badges de qualité (
Build: Passing
,ÂCoverage: 98%
,ÂPyPI version: 1.0.3
) - et un code sournois glissĂ© dansÂ
setup.py
, dansÂ__init__.py
, ou dans des hooks d’installation pip.
Résultat : quand vous installez leur package en croyant gagner du temps, eux gagnent l’accès à votre machine. Et bien souvent, à bien plus.
🎯 Les cibles ? Les devs comme vous
Pourquoi viser des développeurs ? Parce que ce sont des portes d’entrée dorées :
- Leurs postes contiennent des clĂ©s API, des secrets dansÂ
.env
,Â.aws
,Â.npmrc
, des jetons GitHub. - Ils ont parfois un accès SSH direct vers les serveurs de staging ou de prod.
- Ils utilisent des pipelines CI/CD qui déploient du code automatiquement.
- Et surtout… ils sont pressés, débordés, et n’ont pas le temps de lire les issues d’un dépôt GitHub avant de l’installer en prod. (Avouez.)
J’en parlais justement dans mes dernier articles :
🧪 Chaîne de confiance en ruine : GitHub, PyPI et la prolifération des malwares open source
« Chimera, mais en réalité Chimère » : quand un paquet PyPI se prend pour un help‑dev et finit en Robin des Secrets
🛠️ Et si ce n’était pas que Banana Squad…
Le cas de Banana Squad est symptomatique d’un problème bien plus large.
On t’en a déjà parlé ici sur SecuSlice :
- Dans l’article sur le Shadow SaaS et les outils installés en douce par des devs pressés ;
- Dans notre dossier sur les identitĂ©s non humaines, oĂą l’on montre Ă quel point unÂ
.env
 mal protégé vaut un open bar pour un attaquant ; - Et dans notre série « How to write Secure Code », où on vous suppliait de ne pas importer des libs au hasard comme on goûte des tapas dans un buffet douteux.
La compromission de la chaîne d’approvisionnement logicielle, ce n’est pas une théorie. C’est le quotidien de 2025. Et ça commence par un copier-coller innocent depuis StackOverflow.
🔓 Du poste de dev à la prod en 3 étapes
- Vous installez un paquet foireux.
Il vole vos secrets locaux, modifie vosÂ~/.ssh/config
 et exfiltre vos clés GitHub. - Il pousse une backdoor dans un repo pro.
Grâce à votre token GitHub, il modifie un script dans un projet d’équipe. - Le script est déployé en prod.
Boom. Ransomware. Data breach. Reputation down. C’est la supply chain à l’envers.
🧯 Ce qu’il fallait faire (avant le drame)
Parce que les leçons apprises après une compromission, c’est un peu tard.
- Utilisez des outils d’analyse de dĂ©pendances comme socket.dev, deps.dev, ou encoreÂ
pip-audit
. - Activez le 2FA sur vos GitHub, GitLab, JetBrains, etc. Oui, même pour les comptes secondaires.
- Mettez en place des politiques de sécurité sur vos CI/CD : pas d’installation de dépendances non validées, pas de secrets en clair.
- Passez vosÂ
requirements.txt
 à la moulinette régulièrement. Une dépendance, c’est aussi du code que vousportez juridiquement. - Sensibilisez vos équipes, avec des cas comme Banana Squad. Faites-leur lire cet article (et les deux autres, aussi).
🎤 En conclusion : README ≠sécurité
Il est temps d’arrêter de croire que la sécurité se mesure à la beauté du badge Travis.
Les groupes comme Banana Squad misent sur l’aveuglement volontaire de développeurs bien intentionnés, mais pressés. Et ça marche.
Parce que la confiance aveugle dans GitHub, PyPI et les écosystèmes open source sans processus de vérification est une faille… humaine.
Prochain article ? Peut-être un tuto sur comment auditer vos packages avec un minimum de sueur et un maximum d’ironie.
Ou mieux : un cas concret d’analyse d’un paquet vérolé en Python, avec détection de code obfusqué. Tenté ?