Le slopsquatting transforme les paquets hallucinés par l'IA en attaques de la chaîne d'approvisionnement

Le slopsquatting se produit lorsqu’un attaquant enregistre un nom de paquet inventé par un outil de codage IA, puis y place un malware. Le développeur demande du code à un assistant, l’assistant recommande une bibliothèque qui n’existe pas, et le développeur lance la commande d’installation. Si l’attaquant a obtenu ce nom en premier, son code est maintenant sur la machine du développeur.

Le nom combine « slop », l’argot pour une sortie IA de mauvaise qualité, avec « squatting », l’ancienne habitude de revendiquer des noms que vous ne possédez pas. Les équipes de sécurité reconnaîtront le schéma du typosquatting, où les attaquants enregistrent des fautes d’orthographe de paquets populaires. Le slopsquatting utilise des noms qui n’ont jamais existé jusqu’à ce qu’un modèle les invente. Les deux sont des attaques sur la chaîne d’approvisionnement logicielle et introduisent du code malveillant dans une build.

Les modèles d’IA inventent des noms de paquets, et les noms se répètent

Des chercheurs de la University of Texas at San Antonio, de la University of Oklahoma et de Virginia Tech ont généré 576 000 exemples de code Python et JavaScript à travers 16 modèles de langage, et 19,7 % des packages recommandés par ces exemples n’existaient pas. Les modèles commerciaux présentaient en moyenne au moins 5,2 % de packages halluciné et les modèles open source 21,7 %. Dans tous les modèles, l’étude a enregistré 205 474 noms uniques inventés.L’étude a été présentée à USENIX Security 2025. Elle a testé des modèles disponibles début 2024, et les auteurs notent que les modèles plus récents pourraient se comporter différemment.

Les mêmes faux noms réapparaissent. Lorsque les chercheurs ont relancé 500 invites ayant produit une hallucination, 43 % des packages inventés sont apparus lors des 10 exécutions répétées, et 58 % sont apparus plus d’une fois. Cela donne à un attaquant une liste courte et prévisible de noms à enregistrer.

Peu de noms inventés ressemblent à des noms réels. Parmi les hallucinations Python, seulement 13,4 % étaient à un ou deux caractères d’un vrai paquet, et 48,6 % étaient très différents de tout nom réel.

Vérifier un nom suggéré par rapport à une liste de packages connus ne résout pas le problème. Un attaquant peut déjà avoir publié un malware sous ce nom, donc le package semblera exister.

Les attaquants enregistrent les noms et attendent

Un attaquant soumet des modèles populaires à des questions courantes de codage et note chaque nom de paquet qui n’existe pas. Ils enregistrent ces noms sur des registres publics tels que npm ou PyPI, puis publient un paquet qui fait à peu près ce qu’un développeur attendrait, avec une charge utile cachée ajoutée.

Finalement, un développeur reçoit la même recommandation et colle la commande d’installation. Installer un paquet open source Python ou JavaScript peut permettre à son auteur d’exécuter du code arbitraire sur la machine, donc la charge utile peut se déclencher pendant l’installation, avant que quiconque ne lise une ligne du code du paquet.

Un ordinateur portable de développeur contient des clés cloud, des jetons API, des clés SSH, du code source et un accès VPN. En compromettant l’un d’eux, l’attaquant obtient un point d’appui dans la chaîne de build, avec un accès à la production.

Le codage Vibe supprime le dernier point de contrôle

Le coding Vibe signifie accepter du code généré par l’IA avec peu de relecture, et la relecture est l’étape qui pourrait détecter un mauvais nom de paquet. L’attaque dépend d’un utilisateur qui installe des paquets recommandés sans vérification suffisante, faisant confiance au modèle pour ne nommer que des paquets réels. Personne ne lit la liste des dépendances, donc une bibliothèque inconnue est installée sans un second examen. Les personnes créant des outils internes avec un assistant peuvent ne pas savoir à quoi ressemble une bibliothèque légitime, elles sont donc encore moins susceptibles de le remarquer. Les relectures qui ne lisent que le code généré ne voient jamais la dépendance, un point aveugle dans la sécurité du code IA.

Les points de terminaison des développeurs ont besoin de leurs propres limites

Les contrôles de pipeline réduisent l’entrée de mauvais packages. Ils ne peuvent pas promettre zéro, et un package qui passe s’exécute sur l’endpoint d’un développeur.

Netwrix PolicyPak applique des contrôles endpoint via Group Policy, MDM ou son service cloud. PolicyPak supprime les droits d’administrateur local et utilise des règles d’élévation sécurisées, permettant aux développeurs d’avoir uniquement l’accès nécessaire aux tâches approuvées. Sa liste blanche, basée sur la propriété des fichiers, bloque les applications et scripts non fiables, limitant ce qu’un paquet malveillant peut faire une fois sur une machine.