Quand l’assistant invente une librairie, un pirate l’attend
Votre assistant de code propose un paquet au nom crédible. Il n’existe pas. Quelqu’un l’a pourtant déjà publié, avec un cadeau empoisonné à l’intérieur.
La réponse en bref
Le slopsquatting est une attaque de la chaîne d’approvisionnement logicielle. Un modèle de langage invente un nom de paquet, un attaquant enregistre ce nom sur un registre public, puis un développeur l’installe sans vérifier. La parade tient en une discipline simple, aucune dépendance n’entre dans le projet sans revue humaine et sans contrôle automatique.
- Le slopsquatting, de quoi parle-t-on
- Le mécanisme d’une attaque
- Une menace mesurée
- Pourquoi les projets vibe codés sont exposés
- Les défenses qui fonctionnent
- Un contrôle intégré à la chaîne de livraison
- Avantages et limites de la revue
- Nos services pour sécuriser vos dépendances
- Questions fréquentes sur le slopsquatting
Chez Snack Groupe, nous reprenons souvent des projets construits avec un assistant de code. Le code tourne, la démonstration convainc, mais la liste des dépendances n’a jamais été relue. C’est là que la faille se loge. Pour situer notre travail technique, vous pouvez découvrir Snack Développement.
Le slopsquatting, de quoi parle-t-on
Le terme a été proposé par Seth Larson, développeur chargé de la sécurité à la Python Software Foundation. Il assemble deux mots anglais. Le premier désigne le contenu bâclé produit en masse par l’IA. Le second évoque l’usurpation de nom, cette vieille ruse qui consiste à enregistrer un nom proche d’un paquet connu.
La différence tient dans l’origine de l’erreur. Ici, ce n’est plus une faute de frappe humaine qui ouvre la porte. C’est l’hallucination d’un modèle, qui invente avec aplomb une librairie plausible.
Le mécanisme d’une attaque
L’attaque ne demande aucune intrusion. Elle exploite la confiance que l’on accorde à une suggestion. Le schéma suit toujours le même chemin.
Le piège fonctionne parce que l’installation se fait en une ligne. Personne ne vérifie qu’un paquet au nom évident existe depuis longtemps, ni qui le maintient.
Une menace mesurée
Le risque n’est pas théorique. Une étude universitaire relayée par BankInfoSecurity et Snyk a analysé 576 000 échantillons de code générés par des modèles. Environ un paquet suggéré sur cinq n’existait pas.
Le chiffre le plus inquiétant est ailleurs. Une grande part des noms inventés revenait à l’identique quand on reposait la même question. Un attaquant peut donc prévoir ces noms et les réserver. Le taux varie toutefois beaucoup selon le modèle, de moins de 5 % à plus de 25 %.
Pourquoi les projets vibe codés sont exposés
Le vibe coding accélère tout, y compris l’erreur. On accepte une suggestion parce qu’elle fonctionne, sans relire chaque import. Ce réflexe s’ajoute aux autres risques que nous détaillons dans les failles cachées d’un site codé par IA.
Le problème grandit avec le projet. Plus les dépendances s’empilent, plus une seule mauvaise entrée suffit à compromettre l’ensemble. C’est aussi l’une des raisons qui expliquent pourquoi les sites IA tiennent rarement en production.
Les défenses qui fonctionnent
Bonne nouvelle, la parade ne demande pas d’outil exotique. Elle repose sur quelques habitudes tenues avec constance.
Ces gestes rejoignent un plan plus large, détaillé dans notre méthode pour sécuriser un site construit par IA.
Un contrôle intégré à la chaîne de livraison
La revue humaine reste indispensable, mais elle fatigue. Le bon réflexe consiste à confier une partie du contrôle à la chaîne d’intégration continue, la CI/CD. Chaque nouvelle dépendance y déclenche une vérification avant toute mise en ligne.
Ce contrôle ne remplace pas les autres garde-fous de la plateforme. Une base mal protégée reste un risque à part entière, comme le montre l’erreur de Row Level Security sur Supabase.
Avantages et limites de la revue
Ce que la revue protège
- Elle bloque les paquets inventés avant leur installation.
- Elle fige des versions connues et vérifiées.
- Elle laisse une trace de chaque ajout.
Ce qu’elle ne couvre pas seule
- Un paquet légitime compromis plus tard.
- Une faille dans votre propre code.
- Une équipe pressée qui contourne la règle.
Nos services pour sécuriser vos dépendances
Audit des dépendances
Nous vérifions l’existence, l’origine et la maintenance de chaque paquet installé.
Garde-fous automatiques
Nous posons des contrôles dans votre chaîne de livraison pour bloquer l’inconnu.
Reprise de projet IA
Nous relisons un projet généré par IA et le remettons d’aplomb.
Pour démarrer dès cette semaine, trois gestes suffisent.
- Listez toutes les dépendances de vos projets générés par IA.
- Vérifiez sur le registre la date de création et le mainteneur de chacune.
- Activez un contrôle automatique sur chaque nouvel ajout.
Les discussions entre développeurs sur Reddit confirment que ce risque reste mal connu des équipes pressées.
Questions fréquentes sur le slopsquatting
Quelle différence avec l’usurpation par faute de frappe ?
L’usurpation classique parie sur une faute de frappe humaine. Le slopsquatting parie sur l’erreur d’un modèle, qui invente un nom plausible. Le résultat est le même, un paquet malveillant installé par confiance.
Tous les assistants de code sont-ils concernés ?
Oui, mais à des degrés divers. Le taux de paquets inventés varie fortement d’un modèle à l’autre. Aucun n’est à l’abri, d’où l’intérêt d’un contrôle systématique.
Comment savoir si un paquet est légitime ?
Regardez sa date de création, son nombre de versions, son mainteneur et son dépôt de code. Un paquet récent, sans historique et au nom très générique mérite une méfiance immédiate.
Un fichier de verrouillage des versions suffit-il ?
Il aide beaucoup, car il fige des versions précises. Mais il ne vérifie pas qu’un paquet est sain au moment où vous l’ajoutez. Il complète la revue, il ne la remplace pas.
Snack Groupe propose-t-il un accompagnement post-projet ?
Oui. Après l’audit, nous assurons la veille sur vos dépendances, les mises à jour de sécurité et le suivi des alertes au fil des versions.
Une start-up du secteur des services nous avait confié une application générée en quelques semaines. La relecture des dépendances a révélé un paquet au nom générique, publié depuis peu, sans historique. Il a été retiré avant la mise en production.
Parcours-type, secteur des services
