Après, le typosquatting et à l'heure où l'IA générative est utilisée par de nombreux développeurs pour les assister dans leur création, parlons du « slopsquatting ».

Comme nous l'expliquions, le terme « slop » est depuis quelque temps utilisé pour désigner les contenus bas de gamme générés par des IA et qui inondent de plus en plus le web. Ici, le slop concerne la génération de code.

En effet, depuis l'arrivée des IA génératives utilisées comme assistante d'outils d'édition de code, on s'est rapidement aperçu qu'elles pouvaient inciter les développeurs à introduire des failles de sécurité dans leurs codes. Des chercheurs ont déjà montré que les développeurs utilisant des IA assistantes proposent des réponses moins bonnes et moins sécurisées que ceux sans assistant.

• Les IA assistantes comme Codex ou Copilot poussent-elles à introduire plus de failles de sécurité ?

L'autre vecteur d'attaque intrinsèquement lié à la génération de code

Mais, comme l'affirmait déjà à l'époque le lecteur de Next, SebGF, « l'autre vecteur d'attaque intrinsèquement lié à la génération de code par IA [est] l'hallucination ».

Parfois, un grand modèle de langage (LLM) utilisé dans des IA génératives comme Codex ou Copilot peut générer le nom d'un paquet qui n'existe pas et suggérer son utilisation dans un code, alors qu'évidemment ce n'est pas une bonne solution. C'est le développeur Seth Larson, qui travaille pour la Fondation Python Software, qui a inventé le terme de « slopsquatting » à utiliser « quand un LLM hallucine un nom de paquet inexistant, et qu'un mauvais acteur l'enregistre malicieusement. Le frère IA du typosquatting ».

Des paquets vraiment hallucinés

Des chercheurs (notamment de l'Université du Texas), ont analysé le phénomène dans un article mis en ligne sur la plateforme de prépublication arXiv.

Ils confirment dans leur article que l'hallucination de nom de paquet n'est pas un problème marginal. Ils ont testé 16 modèles de langage en générant 576 000 exemples de code produit dans deux langages informatiques (python et JavaScript). Tous ont généré des noms de paquets qui n'existaient pas. Mais avec une différence importante : les modèles d'OpenAI semblent générer beaucoup moins d'hallucinations de noms de paquets, GPT-4 Turbo étant le modèle qui en génère le moins avec 3,6 % de noms de paquets « hallucinés ». Un CodeLlama 34B Python, pourtant spécialisé, génère des faux noms de paquets dans 22 % des cas environ :

Les chercheurs expliquent dans un schéma comment des utilisateurs malveillants peuvent mettre en place l'attaque en exploitant les hallucinations des modèles de langage :

L'idée est d'abord de trouver un nom de paquet halluciné par un modèle de langage via une demande de génération de code. L'utilisateur malveillant vérifie que le paquet n'existe pas dans les dépôts connus, puis en publie un, évidemment en incluant une partie susceptible de nuire à l'utilisateur ou d'exploiter son ordinateur à des fins douteuses. Ce nouveau paquet peut ainsi être inclus dans le code d'un développeur lambda qui aura demandé à son assistant préféré de lui générer du code.

Une hallucination répétée tout le temps ou pas du tout

Pour cela, me direz-vous, il faut que le nom de paquet halluciné soit le même. Or les chercheurs constatent que certains noms de paquets hallucinés reviennent.

En testant 500 prompts de génération de code 10 fois chacun, ils ont pu voir que la plupart des noms hallucinés, soit n'étaient plus jamais hallucinés, soit l'étaient tout le temps :

On peut voir ici que si DeepSeek hallucine plus de noms de paquets que les modèles d'OpenAI, le modèle chinois a tendance à moins répéter ces noms.

Un paramètre des modèles semble en lien avec ce phénomène : la température du modèle. Plus la température est faible, plus le résultat généré est prédictible, attendu. Mais les chercheurs constatent que plus on l'augmente et plus la génération de noms de paquets inexistants arrive :

Une vérification de la supply-chain reste indispensable

Dans l'article, les chercheurs montrent aussi que les noms de paquets « hallucinés » peuvent se confondre dans un code relu rapidement car leurs noms sont assez proches de noms de paquets existants :

« Nous n'en sommes qu'au tout début de l'étude de ce problème au niveau de l'écosystème », affirme Seth Larson auprès de The Register. Notamment, il explique qu' « il est difficile, voire impossible, de quantifier le nombre de tentatives d'installation dues aux hallucinations de LLM sans une plus grande transparence de la part des fournisseurs de LLM. Les utilisateurs de code, de paquets et d'informations générés par LLM devraient vérifier les résultats de LLM par rapport à la réalité avant de mettre ces informations en service, sinon il peut y avoir des conséquences dans le monde réel ».

C'est d'ailleurs ce que disait aussi SebGF, « rappelant que la vérification de la supply-chain reste indispensable ».