Suggestions de code par IA : le risque caché des faux paquets logiciels

Un assistant de code peut proposer en quelques secondes une fonction, une commande d’installation ou la liste des bibliothèques nécessaires à un projet. Cette apparente fluidité masque un danger très concret : lorsqu’un modèle invente le nom d’un paquet logiciel, un attaquant peut enregistrer ce nom dans un dépôt public et attendre qu’un développeur l’installe. La faille ne se trouve alors pas forcément dans le code écrit par l’IA, mais dans la dépendance que celle-ci a convaincu son utilisateur d’ajouter.

Ce risque concerne la chaîne d’approvisionnement logicielle, c’est-à-dire l’ensemble des composants, services et outils utilisés pour fabriquer puis distribuer un logiciel. Les applications modernes reposent souvent sur de nombreuses dépendances externes. Un seul paquet malveillant, importé sans contrôle, peut donc compromettre un projet, ses données ou les systèmes sur lesquels il sera déployé.

Quand l’IA invente une dépendance qui n’existe pas

Les grands modèles de langage produisent du texte plausible à partir de régularités apprises dans leurs données. Ils ne consultent pas automatiquement, à chaque réponse, l’état réel et à jour des registres de paquets tels que PyPI pour Python ou npm pour l’écosystème JavaScript. Ils peuvent ainsi recommander une bibliothèque dont le nom semble crédible, dont l’usage paraît cohérent avec la demande, mais qui n’a jamais existé.

Ce comportement est une hallucination. Dans le cadre du développement, elle peut prendre plusieurs formes : un nom de paquet fictif, une fonction inexistante, une version erronée ou une commande d’installation qui ne correspond à aucun projet publié. Le problème devient particulièrement sérieux lorsqu’un nom inexistant se transforme, après sa suggestion par une IA, en paquet réellement téléchargeable parce qu’un acteur malveillant l’a enregistré.

Une étude récente consacrée aux hallucinations de paquets mesure l’ampleur du phénomène. Environ 5,2 % des suggestions produites par des modèles commerciaux ne correspondaient à aucun paquet réel. Pour les modèles open source, la proportion atteignait 21,7 %. Ces chiffres ne signifient pas qu’un cinquième des logiciels créés avec ces modèles sont dangereux. Ils indiquent en revanche qu’une recommandation de dépendance ne doit jamais être considérée comme une information vérifiée.

Le slopsquatting, une attaque fondée sur les erreurs plausibles de l’IA

Des spécialistes de la sécurité ont donné un nom à cette technique : le slopsquatting. Le terme désigne l’enregistrement, par des personnes malveillantes, de noms de paquets que des outils d’IA sont susceptibles d’inventer et de recommander. Il s’inspire du typosquatting, une pratique plus ancienne consistant à déposer des noms très proches de services ou de bibliothèques connus afin d’exploiter une faute de frappe.

La différence est importante. Dans le typosquatting, l’attaquant anticipe une erreur humaine de saisie. Dans le slopsquatting, il exploite une erreur produite par un modèle, puis reprise par un humain qui fait confiance à son assistant. Le paquet malveillant peut être publié sous un nom totalement fictif, mais suffisamment naturel pour sembler correspondre à une vraie bibliothèque.

Le scénario d’attaque est simple :

• un développeur demande à une IA comment accomplir une tâche précise ;
• l’outil suggère l’installation d’un paquet inexistant ;
• un attaquant publie un paquet sous ce même nom dans un registre ;
• une réponse ultérieure de l’IA recommande ce nom, désormais disponible ;
• le développeur l’installe, ce qui peut déclencher l’exécution de code malveillant.

L’étude de la société de sécurité Socket montre que ces hallucinations ne sont pas toujours aléatoires. Lorsqu’un même prompt déclencheur est relancé environ dix fois, près de 43 % des noms de paquets hallucinéss réapparaissent systématiquement. Cette répétition rend certains noms prévisibles. Pour un attaquant, elle fournit une liste de candidats possibles à enregistrer dans l’espoir d’être proposé plus tard par un assistant de programmation.

Pourquoi un paquet malveillant peut paraître crédible

Un développeur pressé ne juge pas uniquement un paquet à son nom. Il peut aussi se laisser rassurer par une page de présentation soignée, une documentation qui paraît complète ou un dépôt de code qui imite les codes d’un projet légitime. Les paquets imposteurs peuvent afficher des README réalistes, renvoyer vers de faux dépôts GitHub ou s’appuyer sur des contenus douteux censés attester de leur existence.

Cette mise en scène est particulièrement efficace lorsque l’IA a déjà fourni le nom du paquet. La suggestion donne une impression de validation technique : si l’assistant l’a recommandé dans un exemple de code fonctionnel, il est tentant de supposer que la dépendance est connue et éprouvée. Or un modèle de langage ne fournit pas, par nature, une garantie sur la provenance, la maintenance ou l’innocuité d’un composant.

Un incident rapporté en janvier 2025 illustre ce mécanisme : l’outil d’IA de Google a suggéré un paquet malveillant imitant un paquet légitime. Le cas rappelle qu’une réponse convaincante peut relayer involontairement un élément hostile, y compris lorsqu’elle est produite par un service largement utilisé.

Le « vibe coding » augmente le risque de copier sans contrôler

Feross Aboukhadijeh, PDG de Socket, évoque la montée du « vibe coding ». L’expression décrit une manière de programmer où l’utilisateur dialogue avec un outil d’IA, reçoit du code et des commandes, puis les copie rapidement dans son environnement sans en vérifier tous les détails. Cette pratique peut être utile pour prototyper ou découvrir une technologie, mais elle réduit la distance critique entre une suggestion et son exécution.

Le danger n’est pas que tous les développeurs utilisant l’IA cessent de contrôler leur travail. Il tient au fait que les outils abaissent fortement le coût de la production de code et de commandes. Une dépendance peut être ajoutée en une ligne, parfois au milieu de dizaines d’autres recommandations. Dans ce contexte, une erreur de nom ou une bibliothèque inconnue passe plus facilement inaperçue.

La chaîne logicielle est particulièrement exposée parce que les gestionnaires de paquets automatisent l’installation. Selon le langage et l’outil employés, une dépendance peut télécharger d’autres composants, lancer des scripts d’installation ou modifier l’environnement de développement. Si le paquet contient une porte dérobée, un mécanisme de vol de données ou un autre logiciel malveillant, les conséquences peuvent dépasser largement le poste du développeur initial.

Comment vérifier un paquet avant de l’installer

Le premier réflexe consiste à ne pas exécuter directement la commande proposée par un assistant. Avant d’ajouter une dépendance, il faut vérifier son existence dans le registre officiel correspondant, puis s’assurer que le paquet consulté est bien celui que l’on cherchait. Une simple recherche permet souvent de détecter un nom absent, trop récent ou suspect.

Plusieurs contrôles, simples mais complémentaires, limitent fortement les risques :

• comparer le nom suggéré avec la documentation officielle du langage, du framework ou du projet utilisé ;
• examiner l’éditeur ou l’organisation qui publie le paquet, son historique et sa cohérence avec le projet annoncé ;
• vérifier l’activité de maintenance, les versions publiées et la documentation disponible ;
• inspecter le code et les scripts d’installation lorsqu’il s’agit d’une dépendance nouvelle ou sensible ;
• épingler les versions validées dans les fichiers de dépendances afin d’éviter des changements inattendus ;
• soumettre les nouvelles bibliothèques à une revue de code et à des outils d’analyse des dépendances.

Ces mesures ne transforment pas un registre public en espace sans risque. Elles réduisent toutefois la probabilité qu’un projet adopte un paquet uniquement parce que son nom a été rendu crédible par une réponse générée automatiquement. Les signaux visuels, comme un README bien rédigé, ne suffisent pas à établir la confiance.

Le rôle des équipes et des plateformes de paquets

La protection ne peut pas reposer uniquement sur l’attention d’une personne. Dans les organisations, les équipes de développement et de sécurité peuvent définir une liste contrôlée de dépendances autorisées, ou créer un sous-ensemble interne de paquets approuvés à partir de registres comme PyPI. L’objectif est de limiter les installations directes depuis l’espace public pour les projets sensibles.

Les outils d’analyse de composition logicielle peuvent aussi inventorier les dépendances d’un projet et signaler les composants connus pour présenter un risque. Ils sont utiles pour détecter des vulnérabilités ou des incohérences, mais ne remplacent pas la validation de l’identité d’un nouveau paquet. Dans le cas du slopsquatting, le problème naît justement lorsqu’une bibliothèque inconnue semble correspondre à un besoin parfaitement légitime.

La Python Software Foundation travaille de son côté à réduire les risques liés aux logiciels malveillants sur PyPI, notamment à travers des mécanismes de signalement et des améliorations de la détection. Ces initiatives sont nécessaires, mais elles interviennent dans un écosystème ouvert où de nouveaux noms peuvent être publiés rapidement. Seth Michael Larson, développeur en résidence à la Python Software Foundation, souligne qu’il manque encore une quantification des tentatives d’installation provoquées par ces hallucinations.

Cette absence de mesure rend la transparence des fournisseurs d’IA particulièrement importante. Des données plus précises sur les noms de paquets générés, leur récurrence et les corrections appliquées aideraient les responsables de sécurité à évaluer l’exposition réelle de leurs équipes.

Ce qu’il faut surveiller

Le slopsquatting révèle une évolution de la sécurité logicielle : les attaquants n’ont pas besoin de compromettre directement une bibliothèque populaire s’ils peuvent placer une dépendance piégée sur le chemin d’un développeur guidé par l’IA. L’automatisation de la programmation accélère aussi l’automatisation de la tromperie, surtout lorsque les réponses des modèles présentent des régularités exploitables.

À mesure que les assistants de code deviennent des outils quotidiens, la question ne sera donc pas seulement de savoir s’ils écrivent du code correct. Il faudra aussi déterminer s’ils savent distinguer une dépendance réelle d’un nom plausible, signaler clairement leur degré d’incertitude et orienter les utilisateurs vers des sources vérifiables.

D’ici là, la règle reste simple : tout paquet suggéré par une IA doit être vérifié avant son installation. Ce réflexe n’annule pas les gains de productivité des assistants, mais il évite de confondre une réponse fluide avec une garantie de confiance.