Les hallucinations de l'IA conduisent à une nouvelle cybermenace : le Slopsquatting, les développeurs "Vibe coding" qui utilisent des LLM pour créer du code s'exposent à un nouveau type d'attaque

Les hallucinations de l'IA conduisent à une nouvelle cybermenace : le Slopsquatting, les développeurs "Vibe coding" qui utilisent des LLM pour créer du code s'exposent à un nouveau type d'attaque

Une nouvelle catégorie d'attaques contre la chaîne d'approvisionnement, appelée « slopsquatting », est née de l'utilisation accrue d'outils d'IA générative pour le codage et de la tendance du modèle à « halluciner » des noms de paquets inexistants. Le terme « slopsquatting » a été inventé par le chercheur en sécurité Seth Larson en référence au « typosquatting », une méthode d'attaque qui incite les développeurs à installer des paquets malveillants en utilisant des noms qui ressemblent beaucoup à des bibliothèques populaires.

L'hallucination est largement reconnue comme un inconvénient important pour les grands modèles de langage (LLM). De nombreux travaux ont tenté de réduire l'ampleur de l'hallucination. Jusqu'à présent, ces efforts ont surtout été empiriques, ce qui ne permet pas de répondre à la question fondamentale de savoir s'il est possible d'éliminer complètement l'hallucination. Selon une étude de février 2024, l'hallucination est inévitable. Ce serait une limitation innée des grands modèles de langage (LLM) de l'intelligence artificielle (IA).

Selon un nouveau rapport d'experts en cybersécurité, les développeurs qui s'appuient sur de grands modèles de langage (LLM) pour créer du code pourraient, sans le savoir, s'exposer à un nouveau type d'attaque de la chaîne d'approvisionnement. Un acteur de la menace demanderait à un LLM de créer du code. Le code qu'il renvoie peut contenir des logiciels open source qui n'existent pas, un problème courant pour l'IA.

Cette nouvelle approche est désignée sous le terme de "Slopsquatting", qui a été inventé par le développeur Seth Larson, de la Python Software Foundation (PSF). Il s'agit d'un jeu de mots sur le "typosquatting", une tactique populaire utilisée par les acteurs de la menace pour les campagnes d'hameçonnage, où ils enregistrent des versions légèrement mal orthographiées de domaines légitimes.

Grâce au "Slopsquatting", l'auteur de la menace pourrait alors publier un faux paquet dans un dépôt officiel avec les mêmes détails que le paquet halluciné et y insérer un code malveillant. Lorsqu'un autre utilisateur demande au même LLM de générer du code et qu'il renvoie la même réponse hallucinée, la victime est invitée à télécharger le paquet malveillant.


Ce phénomène est plus probable qu'il n'y paraît, selon une étude sur les hallucinations de paquets réalisée par des chercheurs de Virginia Tech et des universités de l'Oklahoma et du Texas. Ils ont testé 16 LLM de génération de code et les ont incités à générer 576 000 échantillons de code Python et JavaScript.

La recherche a révélé qu'en moyenne, un cinquième des paquets recommandés n'existait pas, ce qui représente 205 000 noms de paquets hallucinés uniques. Plus important encore, elle a révélé que 43 % des mêmes paquets hallucinés étaient suggérés à chaque fois lorsque les mêmes invites étaient relancées 10 fois chacune, et que 58 % d'entre eux étaient répétés plus d'une fois. Seuls 39 % ne sont jamais réapparus.

Les paquets hallucinés étaient également "sémantiquement convaincants", ce qui les rendait difficiles à repérer par les développeurs. En outre, ils étaient d'autant plus susceptibles d'être créés que la "température" du LLM était élevée - en d'autres termes, si le LLM avait été réglé pour créer davantage de réponses aléatoires. Cela représente un risque particulier pour ceux qui sont attachés à l'idée du « vibe coding », où les développeurs sont plus susceptibles de faire aveuglément confiance au contenu de l'IA.

Le meilleur moyen d'atténuer le "slopsquatting" consiste pour les développeurs à surveiller de manière proactive chaque dépendance et à utiliser des outils pour contrôler les dépendances avant de les ajouter aux projets, selon le rapport. Fait intéressant, les chercheurs affirment que les hallucinations sont persistantes. Cela confirme que les hallucinations des grands modèles de langage (LLM) sont là pour rester.

Une étude de septembre 2024 avait déjà révélé ces conclusions. L'étude affirmait que les hallucinations des grands modèles de langage (LLM) découlent de leurs structures mathématiques et logiques fondamentales. En augmentant la complexité et la capacité des modèles, il est possible de réduire la fréquence de ces hallucinations, mais il serait impossible de les éliminer complètement.

Pour plus d'information, voici le rapport de Socket concernant cette découverte :

La montée du Slopsquatting : Comment les hallucinations de l'IA alimentent une nouvelle catégorie d'attaques de la chaîne d'approvisionnement

Les grands modèles de langage (LLM) sont en train de devenir un élément essentiel des flux de développement modernes. Les outils d'assistance au code alimentés par l'IA, tels que Copilot, ChatGPT et Cursor, sont désormais utilisés pour aider à écrire toutes sortes de choses, des applications web aux scripts d'automatisation. Ils permettent de réaliser des gains de productivité qui changent la donne, mais introduisent également de nouveaux risques, dont certains sont entièrement nouveaux.

L'un de ces risques est le slopsquatting, un nouveau terme désignant un type d'attaque étonnamment efficace de la chaîne d'approvisionnement en logiciels qui apparaît lorsque les LLM « hallucinent » des noms de paquets qui n'existent pas en réalité. Si vous avez déjà vu une IA recommander un paquet et que vous vous êtes demandé si c'était bien réel, vous avez déjà rencontré les fondements du problème.

Et maintenant, les attaquants s'en rendent compte.

Qu'est-ce que le Slopsquatting ?

Le terme slopsquatting a été inventé par le développeur de PSF, Seth Larson, et popularisé dans un article récent par le créateur d'Ecosyste.ms, Andrew Nesbitt. Il s'agit de la pratique consistant à enregistrer un nom de paquet inexistant halluciné par un LLM, dans l'espoir que quelqu'un, guidé par un assistant IA, le copiera-collera et l'installera sans se rendre compte qu'il s'agit d'un faux.

Il s'agit d'une variante du typosquatting : au lieu de s'appuyer sur les erreurs des utilisateurs, le slopsquatting s'appuie sur les erreurs de l'IA.



La recherche : Les LLM sont en train d'halluciner des paquets à l'échelle

Un nouvel article universitaire intitulé We Have a Package for You ! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs offre la première analyse rigoureuse à grande échelle des hallucinations de paquets dans le code généré par les LLM. La recherche a été menée par une équipe de l'Université du Texas à San Antonio, Virginia Tech et l'Université de l'Oklahoma, et a été récemment mise à la disposition du public dans une prépublication.

Les chercheurs ont testé 16 grands modèles de génération de code, tant commerciaux (comme GPT-4 et GPT-3.5) qu'open source (comme CodeLlama, DeepSeek, WizardCoder et Mistral), générant un total de 576 000 échantillons de code Python et JavaScript.

Voici les principales conclusions :

• 19,7 % de tous les paquets recommandés n'existaient pas.
• Les modèles open source ont halluciné beaucoup plus souvent - 21,7 % en moyenne - que les modèles commerciaux (5,2 %).
• Les plus mauvais élèves (CodeLlama 7B et CodeLlama 34B) ont eu des hallucinations dans plus d'un tiers des résultats.
• GPT-4 Turbo a obtenu les meilleures performances avec un taux d'hallucination de seulement 3,59 %.
• Sur l'ensemble des modèles, les chercheurs ont observé plus de 205 000 noms de paquets hallucinés uniques.

Ces résultats indiquent l'existence d'un modèle systémique et reproductible, et non d'erreurs isolées.



Les hallucinations sont persistantes

Dans le cadre d'expériences complémentaires, les chercheurs ont réexécuté dix fois chacune des 500 invites qui avaient précédemment déclenché des hallucinations. En analysant la fréquence de réapparition des paquets hallucinés dans les générations répétées, ils ont constaté un clivage intéressant.

Lorsque la même invite déclenchant des hallucinations est relancée dix fois, 43 % des paquets hallucinés sont répétés à chaque fois, tandis que 39 % ne réapparaissent jamais. Ce contraste frappant suggère un modèle bimodal de comportement : les hallucinations sont soit très stables, soit totalement imprévisibles.

Dans l'ensemble, 58 % des paquets hallucinés ont été répétés plus d'une fois au cours des dix exécutions, ce qui indique que la majorité des hallucinations ne sont pas simplement du bruit aléatoire, mais des artefacts répétables de la façon dont les modèles réagissent à certaines invites. Cette répétabilité augmente leur valeur pour les attaquants, car il est plus facile d'identifier des cibles viables de slopsquatting en observant seulement un petit nombre de sorties de modèles.


Cette cohérence rend le slopsquatting plus viable qu'on ne pourrait le penser. Les attaquants n'ont pas besoin de gratter d'énormes journaux d'invite ou de forcer brutalement des noms potentiels. Ils peuvent simplement observer le comportement du LLM, identifier les noms communément hallucinés et les enregistrer.

La température et la verbosité affectent le risque

Les LLM sont plus enclins à l'hallucination lorsque les paramètres de température augmentent. La température fait référence au paramètre utilisé pour ajuster le caractère aléatoire des réponses générées.

Une température plus élevée signifie plus d'aléatoire, ce qui conduit à des résultats plus « créatifs », y compris des paquets fictifs. À des valeurs de température élevées, certains modèles ont commencé à générer plus de paquets hallucinés que de paquets valides.


Les chercheurs ont également constaté que les modèles verbeux (ceux qui ont tendance à recommander un plus grand nombre de paquets uniques) présentaient des taux d'hallucination plus élevés. En revanche, les modèles plus conservateurs qui réutilisent un sous-ensemble de paquets plus petit et plus fiable sont plus performants, tant en termes d'évitement des hallucinations que de qualité globale du code.

Les paquets hallucinés ont souvent l'air plausibles

Le fait que de nombreux noms de paquets hallucinés soient sémantiquement convaincants constitue une préoccupation majeure. En utilisant la distance de Levenshtein pour mesurer la similarité avec les paquets réels, l'étude a trouvé :

• Seulement 13 % des hallucinations étaient de simples fautes de frappe.
• 38 % des hallucinations présentaient une similarité modérée avec des paquets réels, ce qui suggère un chevauchement dans la structure des noms ou des schémas d'utilisation communs, bien que les noms exacts n'aient pas été divulgués.
• Près de la moitié présentaient des scores de dissimilarité élevés, ce qui indique qu'ils étaient entièrement fabriqués, tout en restant crédibles dans leur contexte.

Les noms hallucinés sont donc difficiles à repérer à l'œil nu par les développeurs, en particulier lorsqu'ils apparaissent dans des extraits de code par ailleurs corrects.


Confusion inter-langages et paquets supprimés

Les chercheurs ont également analysé si les paquets Python hallucinés correspondaient parfois à des paquets valides dans d'autres écosystèmes. Ils ont constaté que 8,7 % des paquets Python hallucinés étaient en fait des paquets npm (JavaScript) valides, ce qui suggère que les LLM confondent parfois les langages lorsqu'ils suggèrent des dépendances.

Ils ont examiné si les paquets hallucinés étaient auparavant réels mais avaient été supprimés de dépôts tels que PyPI. La réponse : pas vraiment. Seuls 0,17 % des noms hallucinés correspondent à des paquets supprimés de PyPI entre 2020 et 2022. La grande majorité d'entre eux étaient entièrement fictifs.

Les LLM peuvent parfois détecter leurs propres hallucinations

L'un des résultats les plus encourageants est que certains modèles, en particulier GPT-4 Turbo et DeepSeek, ont pu identifier correctement les noms de paquets hallucinés qu'ils venaient de générer, atteignant une précision de plus de 75 % dans les tests de détection internes.

Cela laisse entrevoir des stratégies d'atténuation possibles, telles que l'autoraffinement, où un modèle vérifie la plausibilité de ses propres résultats avant de les présenter à l'utilisateur.

Conception d'invite

Pour évaluer les hallucinations de paquets, les chercheurs ont constitué deux grands ensembles de données d'invites : l'un provenant des questions de Stack Overflow, et l'autre généré à partir des descriptions des paquets les plus téléchargés sur PyPI et npm. Ces invites ont été conçues pour refléter les demandes réalistes des développeurs sur un large éventail de tâches et de bibliothèques.

Les exemples d'invites de codage comprenaient des tâches courantes, telles que :


Ces invites ont été introduites dans 16 LLM différents afin d'analyser quand et comment les noms de paquets hallucinés apparaissaient.

Bien que les chercheurs aient identifié des milliers de noms de paquets hallucinés uniques, ils ont délibérément décidé de n'enregistrer aucun d'entre eux dans des dépôts publics. Une telle démarche, même sans code, aurait pu être considérée comme trompeuse ou perturbatrice pour des plateformes telles que PyPI. Au lieu de cela, ils se sont concentrés sur la simulation et l'analyse à grande échelle, prouvant ainsi le risque sans y contribuer.

Pourquoi il s'agit d'un risque grave pour la chaîne d'approvisionnement

Les attaques par confusion de paquets, telles que le typosquatting, la confusion de dépendances et maintenant le slopsquatting, restent l'un des moyens les plus efficaces de compromettre les écosystèmes open source. Les LLM ajoutent une nouvelle couche d'exposition : des paquets hallucinés peuvent être générés de manière cohérente et partagés à grande échelle par le biais d'auto-complétions, de tutoriels et d'extraits de code assistés par l'IA.

Cette menace s'étend. Si un seul paquet halluciné est largement recommandé par les outils d'IA et qu'un attaquant a enregistré ce nom, le potentiel de compromission à grande échelle est réel. Et étant donné que de nombreux développeurs font confiance aux résultats des outils d'IA sans validation rigoureuse, la fenêtre d'opportunité est grande ouverte.

L'essor du Vibe Coding rend la situation encore plus dangereuse

Le risque de slopsquatting est encore amplifié par la montée en puissance du « vibe coding » assisté par l'IA. Inventé par Andrej Karpathy, ce terme décrit un changement dans la manière dont les logiciels sont écrits : au lieu de rédiger le code ligne par ligne, les développeurs décrivent ce qu'ils veulent, et un LLM génère la mise en œuvre.

[TWITTER]<blockquote class="twitter-tweet"><p lang="en" dir="ltr">There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…</p>— Andrej Karpathy (@karpathy) <a href="https://twitter.com/karpathy/status/1886192184808149383?ref_src=twsrc%5Etfw">February 2, 2025</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>[/TWITTER]

Dans ce flux de travail, le rôle du développeur passe de celui d'auteur du code à celui de contrôleur, guidant, testant et affinant ce que l'IA produit. Des outils comme Composer de Cursor avec Sonnet sont à la pointe de cette tendance, transformant la génération de code en un processus de conception conversationnel.

Mais dans cet environnement, le risque de faire aveuglément confiance aux dépendances générées par l'IA augmente considérablement. Les développeurs qui s'appuient sur le vibe coding peuvent ne jamais taper ou rechercher manuellement le nom d'un paquetage. Si l'IA inclut un paquet halluciné qui semble plausible, la voie de la moindre résistance est souvent de l'installer et de passer à autre chose.

Lorsque les LLM hallucinent des noms de paquets, et qu'ils le font régulièrement, comme le montre la recherche, ils deviennent un maillon invisible de la chaîne d'approvisionnement en logiciels. Et dans les flux de vibe coding, ces liens sont rarement revérifiés.

Comment rester en sécurité

Voici les recommandations de Socket :


Source : Socket

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Les outils d'IA de codage inventent des noms de paquets inexistants qui menacent la chaîne d'approvisionnement en logiciels : Les attaquants publient des paquets malveillants avec ces noms sur npm ou PyPI

« L'IA Cursor m'a dit que je devais apprendre à coder au lieu de lui demander de générer du code », rapporte un programmeur. Quand l'IA remet elle-même en question la culture du « vibe coding »

Vulnérabilité dans GitHub Copilot et Cursor : comment les pirates peuvent compromettre le code généré par l'IA avec des portes dérobées et des vulnérabilités en injectant des instructions malveillantes cachées