En avril, l’équipe de recherche de Phylum a révélé la prolifération de paquets de spam sur npm associés au protocole Tea. Ce protocole décentralisé promet de récompenser les développeurs de logiciels en cryptomonnaie pour leurs contributions open-source. Fin juillet, dans son rapport trimestriel, Phylum estimait qu'environ un paquet sur quatre publié sur npm au deuxième trimestre était associé à Tea, dont la quasi-totalité servait à gonfler artificiellement la contribution d'un développeur de logiciel. Grâce à de nouvelles recherches menées dans une perspective nouvelle, Phylum assure pouvoir désormais affirmer que le volume de ces paquets est probablement plus important que ses estimations initiales.Le protocole Tea
L'un des principes fondamentaux du Protocole Tea est que les logiciels libres doivent être reconnus pour leur impact réel, et pas seulement pour leur visibilité ou leur utilité immédiate. Ce principe s'applique à l'ensemble des logiciels, qu'il s'agisse des interfaces utilisateur élégantes ou des bibliothèques souvent invisibles qui rendent tout cela possible. Il est essentiel pour le protocole de déterminer avec précision la valeur des logiciels libres, afin de remplir sa mission qui consiste à récompenser équitablement ses mainteneurs, et il s'appuie sur l'oracle Proof of Contribution (preuve de contribution).
Contrairement aux mécanismes onchain traditionnels qui reposent sur la puissance de calcul ou les enjeux financiers, Proof of Contribution évalue l'impact des contributions logicielles au sein de l'open-source en utilisant le teaRank, une métrique basée sur le réseau qui reflète la quantité et la qualité des dépendants d'un projet. Le score s'adapte au fil du temps, encourage les nouveaux projets à défier les projets établis et garantit que la reconnaissance s'étend à l'ensemble de la pile open-source, de la glibc aux dernières bibliothèques javascript UI.
Pourquoi une nouvelle approche est-elle nécessaire ?
L'écosystème Open Source qui sous-tend tous les logiciels peut être représenté comme une tour de briques où les couches inférieures sont (souvent) oubliées depuis longtemps, mais toujours maintenues par des ingénieurs dévoués, et sur lesquelles le reste de la pile s'appuie. Seuls les projets situés au sommet de la tour sont généralement connus et bénéficient d'un parrainage. Cette sélection biaisée fait que les briques essentielles qui soutiennent la tour n'attirent aucun don, tandis que les favoris reçoivent plus que ce dont ils ont besoin. Les modèles de financement existants permettent aux consommateurs de projets de proposer des paiements aux développeurs pour qu'ils créent des fonctionnalités spécifiques, ce qui ne rémunère les projets que pour les actions qu'ils entreprennent, pas nécessairement dans leur meilleur intérêt. Et une fois de plus, ils ne récompensent que les favoris.
tea change la donne. Inspiré par PageRank, l'oracle modélise les logiciels libres comme un graphe orienté, où chaque nœud représente un projet et chaque arête une relation de dépendance. Ces données sur les dépendances sont glanées auprès des gestionnaires de paquets individuels et consolidées en une seule vue du graphe des logiciels libres. Avec teaRank, les contributeurs, les utilisateurs et le protocole disposent d'une note de 1 à 100 pour quantifier l'impact d'un paquet individuel par rapport à d'autres au sein du logiciel libre.
Un principe déjà détourné
Le protocole Tea incite de manière perverse les développeurs de logiciels à exagérer leur contribution au développement de logiciels libres. À l'aide d'un PageRank modifié appelé teaRank, les développeurs de logiciels sont récompensés en fonction de leur « preuve de contribution ». Comme les premiers spammeurs SEO qui ont compris comment jouer avec le PageRank à leur avantage, l'histoire se répète et quelques développeurs de logiciels ont pollué les dépôts de logiciels libres avec des quantités absurdes de paquets sans valeur.
C'est npm, le plus grand écosystème open-source, qui a le plus souffert de cette pollution de la part de divers acteurs. Ces paquets de spam se caractérisent notamment par des noms absurdes de paquets, des paquets nommés avec des combinaisons aléatoires de mots d'une liste, des listes invraisemblables de paquets dépendants, un nombre douteux de paquets dépendants et, dans ce marasme de dépendances transitives, l'omniprésent fichier tea.yaml qui identifie en fin de compte le propriétaire du code.
Lorsque Phylum a commencé à enquêter sur cette situation en février, le spécialiste de cybersécurité indique avoir nous avons été « continuellement surpris par le volume de paquets qui pouvaient être publiés, clairement en raison de l'automatisation ». Il a donc cherché à comprendre l'étendue de ce problème de spam.
L’ampleur du problème
En guise de référence, au début de l'année 2024, le nombre total de paquets ingérés quotidiennement dans Phylum à partir de npm était d'environ 1 500 chaque jour ouvrable et d'environ la moitié pendant les week-ends. À partir de février 2024, Phylum a commencé à remarquer une augmentation régulière des publications de paquets npm de quelques milliers à des dizaines de milliers. Le point culminant de cette augmentation s'est produit le 8 avril 2024, avec plus de 48 000 paquets publiés sur npm. Cette explosion de paquets a conduit le spécialiste à sa première découverte des incitations perverses du protocole Tea.
Le mois dernier, en préparation de son rapport trimestriel, Phylum a pris un échantillon aléatoire de tous les paquets npm publiés au deuxième trimestre, et a trié manuellement 1600 paquets. Si un paquet contenait des marqueurs d'abus du protocole Tea, comme indiqué ci-dessus, Phylum l'a marqué comme spam. Phylum a ainsi obtenu un intervalle de confiance à 95 % pour l'estimation du pourcentage de paquets de spam dans npm au deuxième trimestre, compris entre 21,25 % et 25,5 %, soit plus de 500 000 paquets de spam.
Après réflexion, Phylum a considéré que de nombreux projets npm ont des nightly builds ou des versions alpha, beta et canary. Ainsi, ces paquets légitimes qui bénéficient d'un cycle de développement robuste pourraient diluer l'ampleur de l'impact réel du spam. Et si la recherche était limitée aux nouveaux paquets ? Des paquets qui n'ont jamais été vus auparavant dans npm ?
Phylum a élargi les recherches dans ses données npm jusqu'en février, date à laquelle le spécialiste a vu le premier spam du protocole Tea, puis il a supprimé tous les paquets dont au moins une version avait été publiée auparavant. Cela lui a laissé plus de 890 000 nouveaux paquets, jamais vus auparavant, entre février 2024 et aujourd'hui. À partir de cet ensemble, Phylum a prélevé un échantillon aléatoire de 900 paquets et appliqué les mêmes critères que précédemment. Dans cette nouvelle perspective, son intervalle de confiance à 95 % pour l'estimation du spam lié au protocole Tea dans les nouveaux paquets au cours des six derniers mois est passé à une valeur comprise entre 68,66 % et 74,67 %, soit entre 613 000 et 667 000 paquets.
En d'autres termes, parmi tous les nouveaux paquets publiés sur npm au cours des six derniers mois, environ cinq paquets sur sept sont des spams Tea.
Des exploitations potentiellement dangereuses
Tout d'abord, contrairement aux campagnes de typosquattage malveillantes, dans lesquelles un développeur peu méfiant pourrait accidentellement installer reaxt au lieu de react, il est peu probable qu'un développeur fasse la même erreur avec, par exemple, quasar-fig-0e1t. En revanche, un paquet comme web3-cover est plus plausible, car le développeur obtiendrait également les 170 dépendances ainsi que l'arbre de dépendance transitif complet pour chacune d'entre elles.
Ensuite, parce que le train de l'intelligence artificielle est à plein régime, le spécialiste tient à souligner l'évidence. Les modèles d'IA qui sont formés sur ces paquets vont presque certainement fausser les résultats dans des directions inattendues. En fin de compte, ces paquets sont des déchets, et le mantra "garbage in, garbage out" se vérifie.
Enfin, ces campagnes de spam à grande échelle entravent la capacité du registre des paquets open-source à raisonner sur la sécurité de tous les paquets d'un écosystème, malgré le fait qu'aucune personne raisonnable ne s'efforcerait jamais d'installer l'un de ces paquets de spam. Elles augmentent le niveau de bruit et créent un environnement dans lequel un adversaire pourrait subrepticement dissimuler une réelle malveillance.
Pourquoi cette prolifération ?
Plusieurs facteurs contribuent à cette invasion de paquets indésirables :
- Automatisation : Les auteurs de spam utilisent des scripts pour publier automatiquement des paquets, inondant l’écosystème.
- Faible barrière à l’entrée : La facilité de publication sur npm permet aux spammeurs de créer rapidement de nouveaux paquets.
- Récompenses financières : Le protocole Tea offre des incitations monétaires, ce qui attire les opportunistes malveillants.
Mesures à prendre
Pour lutter contre cette pollution, voici quelques actions que la communauté peut entreprendre :
- Filtrage automatique : npm pourrait mettre en place des filtres pour détecter les paquets suspects et les bloquer avant leur publication.
- Signalement communautaire : Encourager les utilisateurs à signaler les paquets de spam afin de les examiner plus attentivement.
- Audit de sécurité : Effectuer des audits réguliers pour identifier les paquets problématiques.
Conclusion
La pollution de l'écosystème des logiciels libres est un problème qui concerne tout le monde. Le projet de protocole Tea prend des mesures pour remédier à ce problème. Il serait injuste pour les participants légitimes au protocole Tea de voir leur rémunération réduite parce que d'autres escroquent le système. Par ailleurs, npm a commencé à supprimer certains de ces spammeurs, mais le taux de suppression ne correspond pas au nouveau taux de publication. Et ce problème ne se limite pas à npm. Par exemple, un utilisateur a publié près de 1800 paquets de spam sur Rubygems à la fin du mois de février et au début du mois de mars 2024.
Sources : Phylum, protocole Tea, Rubygems
Et vous ?
Quelle est votre expérience avec les paquets npm ? Avez-vous déjà rencontré des paquets de spam lors de vos projets ? Si oui, comment avez-vous géré la situation ? Pensez-vous que la communauté open-source devrait être plus proactive dans la lutte contre les paquets de spam ? Partagez vos opinions sur la responsabilité collective de maintenir la qualité de l’écosystème npm. Comment pouvons-nous différencier les paquets utiles des paquets de spam ? Indiquez les critères que vous utilisez pour évaluer la fiabilité d’un paquet et partagez vos meilleures pratiques. Quelles mesures concrètes pouvons-nous prendre pour réduire la prolifération des paquets de spam ? Proposez des solutions, telles que des filtres automatiques, des signalements communautaires ou des audits de sécurité. Quel est l’impact des paquets de spam sur la confiance des développeurs envers npm ? Avez-vous déjà hésité à utiliser un paquet en raison de la présence de spam ? Comment cela a-t-il influencé votre perception de la plateforme ?