Slopsquatting : quand l'IA invente des packages npm que les pirates exploitent

VentureBeat consacre une enquête au slopsquatting, cette variante du typosquatting qui ne repose plus sur une faute de frappe humaine, mais sur l'hallucination d'une intelligence artificielle. Le principe est simple à comprendre et redoutable dans ses conséquences : un assistant de code suggère d'installer un package qui n'existe pas, et un pirate a déjà pris soin de le publier avant vous, avec un contenu malveillant à l'intérieur.

Note de rédaction : le contenu détaillé de l'article de VentureBeat n'a pas pu être intégralement récupéré au moment de la rédaction. Cet article s'appuie donc sur le mécanisme du slopsquatting tel qu'il est documenté publiquement par la communauté de la sécurité open source. Nous vous invitons à consulter l'article original en source primaire pour les éléments les plus récents.

Le typosquatting, l'ancêtre bien connu

Sur npm comme sur PyPI, le typosquatting existe depuis des années : un pirate publie un package au nom presque identique à une dépendance populaire, en pariant sur une faute de frappe humaine. Un développeur pressé tape npm install expres au lieu de express, et installe autre chose que ce qu'il croyait. Les registres ont appris à surveiller ce genre de proximité orthographique. Le slopsquatting change la donne : il ne cible plus une faute de frappe, il cible une réponse générée par IA.

Slopsquatting : l'IA invente, le pirate exploite

Les modèles de langage utilisés pour générer du code peuvent, comme dans n'importe quelle autre tâche, produire des réponses plausibles mais fausses. Appliqué aux dépendances logicielles, ce phénomène se traduit par des noms de packages qui sonnent juste, qui ressemblent à une bibliothèque légitime, mais qui n'ont jamais été publiés par personne. C'est ce qu'on appelle un package halluciné.

Le problème ne s'arrête pas à l'erreur elle-même. Ces hallucinations ont tendance à se répéter : posez une question similaire à un assistant de code, et il y a de bonnes chances qu'il ressorte le même nom fictif. Cette répétabilité est justement ce qui rend l'hallucination exploitable. Un pirate n'a qu'à repérer ces noms récurrents, les enregistrer sur npm en y glissant un code malveillant, et attendre qu'un développeur exécute la commande suggérée par son assistant sans la vérifier. Le nom du jeu : transformer une erreur de machine en porte d'entrée sur votre poste de travail ou votre pipeline de build.

Comment un package piégé se retrouve dans votre projet

Le scénario tient en quelques étapes, et c'est justement sa banalité qui le rend dangereux. Un développeur demande à son assistant IA de corriger une erreur d'import ou d'ajouter une fonctionnalité. L'assistant répond avec une commande du type npm install nom-plausible. Le développeur, confiant, l'exécute directement dans son terminal. Si ce package existe réellement et qu'il a été enregistré par un attaquant, npm exécute au passage son script postinstall, un mécanisme légitime de l'écosystème qui permet à un package de lancer du code automatiquement après installation. C'est exactement ce mécanisme, normalement utile, qui sert de vecteur : vol de variables d'environnement, de tokens npm ou cloud, ou dépôt d'une porte dérobée dans le projet.

Le point commun avec le typosquatting classique est là : la faille ne vient pas d'une vulnérabilité technique dans npm, mais d'un excès de confiance au moment d'installer une dépendance. La différence, c'est que cette confiance n'est plus placée dans un collègue ou dans une recherche Google, mais dans un assistant IA qui ne vérifie pas lui-même l'existence du package qu'il suggère.

Ce que vos développeurs peuvent changer concrètement

Aucune de ces mesures ne demande un budget de sécurité conséquent. Elles relèvent de la discipline d'équipe, applicable dès aujourd'hui :

• Vérifiez avant d'installer. npm view nom-du-package affiche la date de publication, le nombre de versions et le dépôt source associé. Un package tout juste créé, sans historique ni dépôt public identifiable, est un signal d'alerte.
• Neutralisez les scripts d'installation par défaut. npm install --ignore-scripts empêche l'exécution automatique d'un script postinstall tant que vous n'avez pas audité le package.
• Verrouillez vos dépendances. En CI/CD, préférez toujours npm ci à npm install. La première n'installe que ce qui figure déjà dans package-lock.json, la seconde peut résoudre une nouvelle dépendance non revue.
• Passez par un registre interne. Un proxy npm type Verdaccio, qui n'autorise que les packages déjà validés par l'équipe, bloque de fait toute dépendance fantôme suggérée par une IA tant qu'un humain ne l'a pas approuvée.
• Traitez toute suggestion IA comme une pull request externe. Un nom de package proposé par un assistant n'est ni une preuve d'existence ni une preuve de fiabilité. Il mérite la même relecture qu'une contribution venue d'un inconnu.

Notre lecture chez CZSyn

Chez CZSyn, nous accompagnons des équipes qui ont intégré des assistants IA dans leur quotidien de développement sans forcément adapter leurs pratiques de revue de dépendances. Le vrai risque n'est pas l'intelligence artificielle en tant que telle : c'est l'automatisation de la confiance. Une commande qui sort d'une fenêtre de chat donne une impression d'autorité qu'elle n'a pas forcément gagnée. On l'exécute plus vite qu'on ne relirait un pull request d'un inconnu, alors que le niveau de vérification devrait être identique, voire supérieur.

Pour une PME française qui ne dispose pas d'une équipe sécurité dédiée, la parade la plus rentable reste organisationnelle avant d'être technique : un registre proxy qui filtre les nouvelles dépendances, une règle simple de relecture humaine systématique sur tout ajout de package, et l'habitude de ne jamais copier-coller une commande d'installation sans avoir vérifié que le package existe vraiment et depuis quand. Ce sont des réflexes à instaurer une fois, pas des outils coûteux à maintenir.

Sources primaires

• VentureBeat, « Forget typosquatting: Slopsquatting is the new software supply chain threat created by AI coding tools ».
• Documentation officielle npm, docs.npmjs.com.
• GitHub Advisory Database, github.com/advisories.