⚠️ Sécurité dépendances IA : stop aux paquets non trouvés
Sécurité des dépendances IA : 1 paquet suggéré sur 5 peut être absent. Découvrez phantom-deps, évitez slopsquatting et vérifiez avant install.
Avant d'installer un paquet suggéré par une IA, vérifiez qu'il existe
Un assistant de programmation vous génère un script Python, un fichier requirements.txt et une liste de bibliothèques à installer. Tout semble cohérent. Vous lancez pip install -r requirements.txt et passez à la suite. Le souci, c'est qu'un nom de paquet proposé par une IA peut sonner juste... tout en n'ayant jamais existé.
Une étude présentée à USENIX Security 2025 a analysé 2,23 millions de références à des paquets générées par 16 grands modèles de langage. Résultat : 19,7 % pointaient vers des paquets inexistants. Ça ne veut pas dire que chaque projet créé avec une IA est automatiquement risqué. Par contre, ça montre qu'une vérification très simple manque souvent dans la chaîne classique : confirmer qu'une dépendance existe vraiment avant de l'installer.
C'est précisément l'objectif de phantom-deps, un scanner léger conçu pour contrôler des dépendances suggérées par une IA avant installation. Il repère les noms absents des registres PyPI et npm, ainsi que les paquets publiés très récemment. Voilà ce qu'il fait, comment l'intégrer à votre flux, et surtout ce qu'il ne faut pas lui demander.
Pourquoi un paquet inventé pose un risque réel
Les modèles de génération de code peuvent produire des exemples convaincants en quelques secondes. Ils peuvent aussi associer un nom de bibliothèque "plausible" à une fonction qui n'existe pas, ou adapter le nom d'un outil connu avec un suffixe crédible. À la lecture, datavalidator-pro ou fastjson-utils ne font pas forcément lever un drapeau rouge. Mais un nom de paquet n'est pas valide simplement parce qu'il a une belle forme.
Dans un projet "classique", une dépendance vient souvent d'une documentation, d'un dépôt déjà utilisé ou d'un choix entériné par l'équipe. Avec du code généré, la liste peut arriver directement dans un fichier prêt à installer. Et là, le geste est presque automatique : copier, installer, exécuter. C'est ce raccourci qui ouvre une brèche opérationnelle.
Le slopsquatting, ou l'exploitation d'une erreur plausible
Quand un modèle suggère un paquet qui n'existe pas, quelqu'un peut tenter d'enregistrer ce nom sur un registre public avant que des utilisateurs ne s'y fient. La prochaine personne qui suit la recommandation et installe le paquet récupère alors le code publié sous ce même nom. Cette approche s'appelle slopsquatting.
Le principe rappelle le typosquatting : dans les deux cas, l'attaquant parie sur une erreur de nom et sur le fait que le lecteur ne vérifiera pas assez tôt. La différence, c'est la source de l'erreur. Le typosquatting joue souvent sur des fautes de frappe ou une confusion avec un paquet populaire. Le slopsquatting, lui, exploite des noms inventés (ou halluciné) par un modèle génératif, puis repris par des développeurs.
Le fait qu'un paquet n'existe pas au moment où vous vérifiez ne prouve pas qu'une attaque est en cours. En revanche, c'est une indication utile : le registre ne contient pas ce que votre fichier vous demande d'installer. La décision logique devient alors simple : suspendre l'installation et vérifier le nom, la documentation et l'origine de la recommandation.
Pourquoi le contrôle doit arriver avant l'installation
Beaucoup d'outils de sécurité analysent un dépôt après coup, ou surveillent les registres à la recherche de contenus malveillants. C'est utile, mais ce n'est pas le même moment. Si le but est de vérifier une suggestion produite "à la volée", le contrôle le plus rentable intervient juste avant l'installation.
C'est aussi important en équipe, même petite. Une dépendance installée pendant le développement peut exécuter du code selon le mode d'installation et les outils en place. Elle peut aussi se retrouver dans un fichier de verrouillage, une image de conteneur ou un pipeline d'intégration continue. Vérifier en amont évite de transformer une hypothèse du modèle en dépendance acceptée par le projet.
Et pour éviter une mauvaise lecture : l'étude ne dit pas que 19,7 % des dépendances sont malveillantes. Elle parle de références pointant vers des paquets absents, pas forcément vers des paquets dangereux. Le vrai danger arrive quand quelqu'un enregistre ensuite un de ces noms, et qu'un utilisateur installe sans vérifier. Autrement dit : ce n'est pas "hallucination = attaque", c'est une chaîne de conditions.
Ce que vérifie phantom-deps
phantom-deps est un outil en ligne de commande qui inspecte un projet avant l'installation de ses dépendances. Son intérêt principal n'est pas une analyse "profonde", mais une chose très concrète : répondre à la question « ce nom existe-t-il sur le registre ? » au moment où la suggestion apparaît.
Il sait lire plusieurs sources courantes : requirements.txt, pyproject.toml, setup.cfg et package.json. Il peut aussi repérer des imports Python simples dans le projet. Ensuite, il vérifie les noms tiers sur les registres PyPI ou npm. Deux résultats dominent.
- PHANTOM : le nom n'existe pas sur le registre interrogé. C'est le cas le plus directement lié à une hallucination.
- NEW : le paquet existe, mais sa première publication date de moins de 30 jours. Dans ce cas, une vérification supplémentaire s'impose, car une publication récente est une période où des pratiques type typosquatting ou slopsquatting peuvent entrer en jeu.
Un résultat NEW n'est pas une accusation. Un paquet récent peut être parfaitement légitime. Le signal dit simplement : prenez le temps de vérifier l'éditeur, le dépôt, la documentation et pourquoi cette dépendance apparaît dans le projet.
Exemple de résultat
Une exécution peut ressembler à ceci :
PHANTOM - does not exist on the registry (1):
✗ datavalidator-pro [pypi, from requirements.txt]
NEW - published recently, high risk (1):
! fastjson-utils (6d old) [pypi, from imports]
1 known-good packages checked, 3 total.
Le premier nom n'est pas sur PyPI. Le second existe, mais a été publié il y a six jours. Dans les deux cas, le scanner ne tranche pas "malveillant ou pas". Il rend simplement visibles deux raisons de ne pas installer à l'aveugle.
L'outil gère aussi une correspondance approximative entre certains imports Python et leurs noms de distribution. Par exemple : bs4 correspond à beautifulsoup4, PIL à Pillow, et cv2 à opencv-python. Cette aide n'est pas une vérité universelle : si la correspondance tombe à côté, vous aurez peut-être une requête en plus, mais la vérification finale se fait toujours contre le registre réel.
Dernier détail pratique : en cas de problème réseau, le scanner signale qu'il n'a pas pu joindre le registre, plutôt que de conclure à tort que le paquet est absent. C'est important. « Impossible de vérifier » et « n'existe pas » ne sont pas le même résultat, et votre équipe devrait pouvoir gérer ces cas différemment.
Comment l'utiliser avant une installation
Le cas d'usage reste volontairement simple. Le projet est présenté comme un outil Python sans dépendances externes, basé sur la bibliothèque standard et sur des appels directs aux API JSON de PyPI et du registre npm. Les résultats des registres sont mis en cache localement. Il n'impose ni service permanent, ni compte, ni chaîne de traitement dédiée.
Pour installer et faire une vérification de base :
pip install phantom-deps
phantom-deps ./mon-projet-genere-par-ia
Le scanner examine les fichiers pris en charge et les imports Python qu'il sait détecter. S'il trouve un paquet absent ou récemment publié, il renvoie un code de sortie 1. Vous pouvez donc l'utiliser dans un script, un contrôle avant commit, ou une étape de CI. Par exemple :
phantom-deps . || echo "Dépendances non vérifiées : examen nécessaire avant installation"Cet exemple affiche un message, mais il ne bloque pas réellement l'étape suivante. Si vous voulez une barrière stricte, votre pipeline doit traiter le code de sortie comme un échec et arrêter la suite. Pour un contrôle plus exploratoire, vous pouvez conserver le résultat comme avertissement et demander une validation humaine. Le bon réglage dépend du coût d'un faux positif et du niveau de risque du projet.
Une procédure simple pour les suggestions de code
Pour éviter que l'outil devienne un rituel de plus, je recommande un flux en quatre étapes :
- Demandez au modèle les dépendances séparément du code. Une liste explicite se contrôle plus facilement qu'un paquet ajouté "au milieu" d'un exemple.
- Vérifiez les noms avant d'exécuter l'installation. Lancez le scanner sur le fichier ou le dossier qui contient les dépendances proposées.
- Traitez chaque alerte selon sa nature. Un nom absent doit être confirmé ou corrigé. Un paquet récent doit être examiné, pas automatiquement rejeté.
- N'installez que la version retenue par votre projet. Après validation, gardez des versions reproductibles selon les pratiques de votre équipe, puis faites les contrôles habituels.
Séparer la demande est souvent plus efficace que de demander à l'IA si ses propres dépendances sont "correctes". Le modèle peut expliquer son choix, mais son explication ne prouve pas que le paquet existe ni qu'il est maintenu. La vérification doit venir d'une source indépendante : ici, le registre officiel.
Dans une équipe produit, vous pouvez aussi brancher ce contrôle dans une commande de prévalidation documentée. Ça évite de dépendre de la mémoire de chacun et rend le résultat reproductible. Il n'est pas nécessaire d'imposer la même politique partout : un prototype local, un service exposé sur Internet et un logiciel distribué à des clients n'ont pas le même niveau d'exigence. Dans tous les cas, savoir qu'un nom n'existe pas avant d'installer, c'est un retour sur investissement très élevé.
Vérifier aussi l'outil que vous installez
phantom-deps s'installe depuis PyPI. Comme pour tout outil "dans la chaîne", autant le traiter avec la même prudence : regardez le projet, sa provenance, et privilégiez les instructions du dépôt officiel. L'outil est proposé sous licence MIT ; son code et sa page de paquet sont disponibles sur GitHub et PyPI.
Le fait qu'un outil soit léger ou open source ne garantit pas qu'il convient à votre environnement. Si vous l'intégrez durablement à une CI, vérifiez sa version, la façon dont il est distribué et les règles de mise à jour applicables chez vous. Un scanner de dépendances reste une dépendance.
Ce que le scanner ne remplace pas
phantom-deps répond à une question précise. Il vérifie l'existence d'un nom et signale les publications récentes. Il ne remplace pas un audit complet de la chaîne logicielle.
Il ne prouve pas qu'un paquet existant est sûr. Un paquet publié depuis plusieurs années peut contenir des vulnérabilités, être compromis ou simplement ne pas convenir à votre usage. À l'inverse, une publication récente peut très bien être due à un mainteneur légitime. Le seuil de 30 jours sert donc de repère opérationnel, pas de frontière "scientifique" entre paquets sûrs et paquets dangereux.
Concrètement, il ne remplace pas :
- un examen du code et de la provenance d'une dépendance importante ;
- la consultation des avis de sécurité et des versions vulnérables ;
- la gestion des versions verrouillées et des mises à jour ;
- les règles de validation de votre dépôt et de votre pipeline ;
- une analyse plus large : dépendances, licences, chaîne de publication.
Il faut aussi garder en tête ses limites de détection. La correspondance entre imports Python et distributions n'est qu'une aide. Certains projets ont des configurations particulières, des dépendances privées, ou des formats qui ne sont pas couverts par la liste supportée. Un scan "propre" veut dire que les noms reconnus ont été vérifiés dans les registres ciblés ; ça ne prouve pas que toutes les dépendances du projet ont été trouvées.
Enfin, tout dépend de l'accès réseau aux registres. Si PyPI ou npm est indisponible, le scanner indique un problème de vérification plutôt que de conclure à l'absence. Dans un environnement isolé, derrière un proxy, ou avec des restrictions réseau, il faut intégrer ce cas à la procédure. Le résultat ne doit pas être interprété comme une validation silencieuse.
Un outil utile quand son périmètre reste clair
La vraie valeur de ce type de scanner, c'est son faible coût et sa place naturelle dans le flux. Il n'a pas besoin de lancer une plateforme d'analyse complète pour répondre à une question simple. En revanche, lui donner le rôle de "certificat de sécurité" serait dangereux : ça crée une confiance automatique qui ne correspond pas à ce qu'il fait.
La règle pratique est donc :
- utilisez-le pour repérer les suggestions qui ne doivent pas passer directement de la réponse d'un modèle à une commande d'installation ;
- en présence de
PHANTOM, stoppez et vérifiez le nom ; - en présence de
NEW, vérifiez l'éditeur et la nécessité réelle de la dépendance ; - si le registre est inaccessible, suivez votre procédure interne ou reportez la décision ; ne transformez pas l'incertitude en feu vert.
Et oui, ce principe vaut aussi dans un contexte européen. Les règles de conformité et de sécurité ne sont pas satisfaites par un simple contrôle de présence. Mais une vérification avant installation peut compléter ce qui existe déjà, en rendant explicite un risque introduit par les outils génératifs. C'est une brique de maîtrise de la chaîne logicielle, sans se substituer à la gouvernance.
Conclusion : ajouter un contrôle proportionné
Les assistants de programmation accélèrent la production de code, mais leurs suggestions de dépendances ne devraient pas être traitées comme des faits vérifiés. L'étude présentée à USENIX Security 2025 rappelle que, dans les références observées, une part significative pointait vers des paquets absents. Vérifier leur existence avant installation reste donc une mesure simple, pas un extra superflu.
phantom-deps met ce contrôle en amont, avec un périmètre limité et facile à comprendre : détecter les noms introuvables et signaler les paquets très récents. Il ne certifie pas la sécurité d'une bibliothèque, et il ne remplace pas l'analyse de vulnérabilités. Mais utilisé pour ce qu'il fait réellement, il peut éviter qu'une suggestion "plausible" passe directement dans votre environnement.
Avant votre prochaine installation générée par une IA, lancez le scan, regardez les alertes et validez chaque dépendance avec une source fiable. Consultez le dépôt GitHub de phantom-deps et sa page PyPI pour vérifier le projet et ses instructions.