Comment les hallucinations de l’IA créent de nouvelles menaces pour les logiciels

Le « slopsquatting » est une nouvelle forme d’attaque visant la chaîne d’approvisionnement

L’IA transforme le développement logiciel à un rythme effréné. Les développeurs peuvent désormais générer du code, résoudre des problèmes et créer des applications bien plus rapidement qu’auparavant. C’est un véritable avantage. Mais chaque nouvelle fonctionnalité crée une nouvelle surface d’attaque. Le « slopsquatting » en est l’un des exemples les plus récents.

Le « slopsquatting » se produit lorsqu’un assistant de programmation basé sur l’IA recommande un paquet logiciel qui n’existe pas réellement. Les grands modèles linguistiques génèrent parfois des noms de paquets qui semblent légitimes, car ils prédisent la réponse la plus probable au lieu de vérifier si le paquet existe réellement. Si un pirate constate qu’un nom de paquet fictif particulier apparaît à plusieurs reprises, il peut enregistrer ce nom dans un référentiel public de paquets et y télécharger du code malveillant.

La suite est simple. Un développeur accepte la recommandation de l’IA sans vérifier la dépendance, installe le paquet et introduit, à son insu, un logiciel malveillant dans l’application. La compromission commence dès la phase de développement du logiciel, et non après son déploiement. Il s’agit donc d’un problème lié à la chaîne d’approvisionnement logicielle.

Cette technique diffère du « typosquatting » traditionnel. Le typosquatting repose sur les erreurs d’orthographe commises par les développeurs lors de l’installation de paquets légitimes. Les registres de paquets ont passé des années à mettre en place des défenses contre ce type d’attaque. Le « slopsquatting » contourne bon nombre de ces protections, car les noms de paquets sont entièrement nouveaux et ne constituent pas des versions mal orthographiées de bibliothèques existantes. Les systèmes de détection actuels n’ont pas été conçus pour faire face à des « hallucinations » de paquets générés par l’IA à grande échelle.

Pour les dirigeants, cela modifie la manière dont l’adoption de l’IA doit être encadrée. Les gains de productivité apportés par les assistants de codage basés sur l’IA sont bien réels, mais ils ne doivent pas être considérés comme un substitut aux contrôles de sécurité logicielle déjà en place. Les organisations ont besoin de processus permettant de vérifier les dépendances générées par l’IA avant qu’elles ne soient intégrées aux systèmes de production. L’IA doit permettre d’accélérer le développement, tandis que les systèmes de sécurité continuent de valider tout ce qui entre dans la chaîne d’approvisionnement logicielle.

Les hallucinations de l’IA ont évolué

La plupart des débats concernant les hallucinations de l’IA se concentrent sur les réponses erronées. Dans le développement logiciel, les conséquences sont plus graves. Un nom de paquet issu d’une hallucination n’est pas seulement une information inexacte. Il peut devenir un point d’entrée pour du code malveillant.

Les grands modèles linguistiques génèrent des réponses en se basant sur des probabilités. Ils ne vérifient pas si chaque recommandation figure bien dans un référentiel logiciel officiel. À mesure que les assistants de codage basés sur l’IA gagnent en efficacité, les développeurs accordent naturellement davantage de confiance à leurs suggestions. Cette confiance offre une opportunité aux attaquants. Si des cybercriminels connaissent les noms de paquets fictifs qu’un modèle génère couramment, ils peuvent créer ces paquets avant que les développeurs ne se rendent compte qu’ils n’ont jamais été légitimes.

La difficulté réside dans le fait que ces « hallucinations » sont souvent cohérentes. Elles ne sont pas totalement aléatoires. Les modèles peuvent recommander à plusieurs reprises la même dépendance inexistante à différents utilisateurs et pour différents projets. Cette cohérence offre aux attaquants une cible prévisible, au lieu de les obliger à deviner ce que les développeurs pourraient installer.

Ce risque va au-delà des modèles actuels. Des chercheurs ont démontré que des techniques adversaires, notamment la manipulation au niveau des tokens et l’empoisonnement des résultats de recherche, peuvent accroître la probabilité d’hallucinations spécifiques. En d’autres termes, des attaquants pourraient à terme influencer les systèmes d’IA afin qu’ils recommandent précisément les paquets malveillants qu’ils souhaitent voir les développeurs installer. L’IA passe ainsi du statut de source passive d’erreurs à celui d’une technologie que des acteurs malveillants sophistiqués peuvent manipuler activement.

Les recherches montrent qu’il ne s’agit pas d’un phénomène rare. Une étude a révélé que les taux d’hallucination variaient entre 50 % et 82 %, selon le modèle linguistique et la méthode de formulation des invites. Même GPT-4o, le modèle le plus performant de cette étude, a atteint un taux d’hallucination minimal de 23 % malgré les techniques d’atténuation basées sur les invites.

Pour les dirigeants d’entreprise, la conclusion est claire. Le code généré par l’IA doit être soumis aux mêmes règles de gouvernance que le code écrit par des humains. Chaque dépendance doit être validée par rapport à des référentiels fiables, des contrôles de sécurité automatisés doivent faire partie intégrante du pipeline de développement, et les résultats fournis par l’IA doivent être considérés comme des recommandations plutôt que comme des faits avérés. Les organisations qui associent la productivité offerte par l’IA à une gouvernance logicielle rigoureuse se trouveront dans une position bien plus solide que celles qui s’appuient uniquement sur l’IA.

Le « slopsquatting » peut entraîner des violations prolongées et difficiles à détecter

L’une des principales préoccupations liées au « slopsquatting » ne réside pas dans la manière dont les logiciels malveillants pénètrent dans un système, mais dans la durée pendant laquelle ils peuvent y rester sans être détectés.

Lorsqu’un développeur installe un paquet malveillant qui semble légitime, celui-ci peut s’intégrer à la chaîne de dépendances normale de l’application. À partir de ce moment, le code malveillant peut continuer à fonctionner dans les environnements de développement, de test et de production. Les logiciels modernes dépendant souvent de centaines, voire de milliers de paquets tiers, il peut s’avérer difficile d’identifier une seule dépendance malveillante, surtout si celle-ci agit de manière discrète.

Cela pose un défi aux organisations qui se concentrent principalement sur la prévention des attaques au niveau du périmètre réseau. Les attaques par la chaîne d’approvisionnement commencent bien plus tôt dans le cycle de vie des logiciels. Si un code malveillant est introduit pendant la phase de développement, il peut passer inaperçu lors des processus de déploiement standard et s’intégrer dans des applications stratégiques pour l’entreprise avant même que les équipes de sécurité ne détectent quoi que ce soit d’anormal.

L’écosystème logiciel dans son ensemble montre déjà des signes d’une pression croissante. Selon une étude récente, une équipe a analysé 31 267 vulnérabilités réparties sur 14 675 progiciels couvrant 10 langages de programmation. Elle a constaté que le nombre de vulnérabilités signalées augmente de 98 % par an, tandis que le nombre de progiciels open source progresse de 25 % chaque année. Cette même étude a également révélé que la durée de vie moyenne des vulnérabilités a augmenté de 85 %, ce qui suggère que l’identification et la résolution des problèmes de sécurité prennent davantage de temps.

Pour les dirigeants, ces chiffres mettent en évidence un problème opérationnel plutôt que simplement technique. À mesure que les entreprises recourent de plus en plus aux logiciels libres et au développement assisté par l’IA, les équipes de sécurité doivent gérer un nombre croissant de dépendances sans bénéficier d’une visibilité proportionnellement accrue. Cela peut se traduire par un risque métier accru, des cycles de correction plus longs et des coûts plus élevés lorsque les vulnérabilités ne sont pas détectées.

La réponse concrète consiste à améliorer la visibilité sur l’ensemble de la chaîne d’approvisionnement logicielle. La surveillance continue, la gestion de la nomenclature logicielle (SBOM), l’analyse des dépendances et les audits de sécurité réguliers devraient devenir des pratiques courantes. Les organisations qui savent exactement quels composants elles utilisent sont bien mieux à même d’identifier les paquets compromis et d’y remédier avant qu’ils n’affectent leurs clients ou leurs opérations critiques.

Les recommandations de forfaits générées par l’IA semblent souvent crédibles

Le succès du « slopsquatting » repose sur la crédibilité. Les noms de paquets générés par l’IA semblent souvent suffisamment réalistes pour que les développeurs les prennent pour des noms authentiques. Ils peuvent ressembler étroitement à des bibliothèques existantes, ne présenter qu’une légère différence, ou simplement donner l’impression d’être un paquet qui devrait déjà exister.

Le défi est d’autant plus grand que l’IA présente ces recommandations avec assurance et au sein d’un code par ailleurs correct. Les développeurs s’attachent naturellement à vérifier si le code résout le problème de programmation, et non si chaque dépendance a été vérifiée individuellement. Face aux échéances des projets et à la pression croissante pour livrer rapidement des logiciels, il devient facile d’accepter une recommandation de l’IA sans validation supplémentaire.

Cela pose un problème tant d’ordre humain que technique. Plus l’IA gagne en fiabilité dans de nombreuses situations, plus les utilisateurs sont susceptibles de lui faire confiance dans des situations où elle se trompe. Des résultats de grande qualité dans un domaine donné peuvent, sans le vouloir, renforcer la confiance accordée à des recommandations qui devraient pourtant encore être vérifiées.

Pour les dirigeants d’entreprise, il s’agit d’un enjeu important en matière de gouvernance. Les politiques de sécurité doivent évoluer parallèlement à l’adoption de l’IA. On ne saurait attendre des équipes de développement qu’elles vérifient manuellement chaque recommandation en s’appuyant uniquement sur leurs propres efforts. Les organisations devraient plutôt intégrer la vérification au processus de développement grâce à des contrôles automatisés permettant de s’assurer que les noms des paquets existent bien dans des référentiels fiables avant le déploiement du logiciel.

La direction joue également un rôle dans la définition de la culture d’entreprise. L’IA doit être considérée comme un outil de productivité. Les équipes doivent être encouragées à valider les recommandations générées par l’IA sans freiner l’innovation. Lorsque la vérification s’intègre au flux de travail standard plutôt que de constituer une étape facultative supplémentaire, les organisations peuvent tirer parti du développement assisté par l’IA tout en réduisant considérablement le risque d’introduire des paquets malveillants dans leurs logiciels.

Les hallucinations générées par les modèles LLM sont courantes et peuvent être manipulées à l’aide de techniques adversariales

Les hallucinations ne constituent pas un défaut ponctuel des grands modèles linguistiques. Elles découlent de la manière dont ces systèmes génèrent leurs réponses. Un grand modèle linguistique prédit la séquence de mots la plus probable en se basant sur les schémas observés dans ses données d’entraînement. Il ne vérifie pas de manière indépendante si un logiciel existe réellement avant de le recommander.

Cela est important car les pirates n’ont pas besoin d’exploiter une vulnérabilité logicielle au sens traditionnel du terme. Ils peuvent au contraire tirer parti d’un comportement prévisible inhérent à l’IA elle-même. Si un modèle génère de manière répétée le même nom de paquet fictif, un pirate peut enregistrer ce paquet et attendre que les développeurs l’installent. À mesure que le codage assisté par l’IA se généralise, le nombre potentiel de projets concernés augmente.

Ce risque pourrait s’aggraver à mesure que les techniques adversaires gagnent en sophistication. La manipulation au niveau des tokens et l’empoisonnement de la recherche sont des exemples de méthodes susceptibles d’influencer les résultats d’un modèle. La manipulation au niveau des tokens vise à modifier la manière dont le modèle prédit des mots spécifiques ou des noms de paquets, tandis que l’empoisonnement de la recherche cible les sources d’informations externes auxquelles certains systèmes d’IA ont recours pour générer des réponses. En cas de succès, ces techniques pourraient accroître le risque que les développeurs reçoivent des recommandations contrôlées par des attaquants.

Les hallucinations restent très répandues. Une étude a révélé que les taux d’hallucinations variaient entre 50 % et 82 %, selon le modèle linguistique et la méthode de formulation des invites. Même GPT-4o, le modèle le plus performant de cette étude, a affiché un taux d’hallucinations minimal de 23 % malgré les techniques d’atténuation basées sur les invites. Ces résultats suggèrent qu’une simple amélioration des invites ne suffira probablement pas à éliminer le problème.

Pour les dirigeants, cela confirme un principe important : la sécurité de l’IA et la cybersécurité sont de plus en plus étroitement liées. Les organisations ne doivent pas partir du principe que l’amélioration de la qualité des modèles rendra superflus les contrôles de sécurité. Les systèmes de vérification, les pratiques de développement logiciel sécurisées et la surveillance continue doivent rester des exigences fondamentales, quelle que soit la plateforme d’IA adoptée. À mesure que les capacités de l’IA s’améliorent, les pirates sont également susceptibles d’adapter leurs méthodes, ce qui fait de la gouvernance continue un élément essentiel de la stratégie d’IA de l’entreprise.

Tous les modèles linguistiques ne sont pas également susceptibles de générer des hallucinations pouvant faire l’objet d’une exploitation malveillante

Le risque de « slopsquatting » dépend en partie du modèle d’IA utilisé. Selon cette nouvelle étude, les modèles propriétaires génèrent actuellement moins de noms de paquets « hallucinés » que de nombreuses alternatives open source. Cela réduit la probabilité de recommander une dépendance inexistante, mais n’élimine pas pour autant le risque sous-jacent.

Cette étude a évalué 30 systèmes d’IA différents, générant environ 576 000 exemples de code faisant référence à 2,23 millions de bibliothèques logicielles. Au total, 19,7 % de ces références à des bibliothèques étaient des hallucinations. GPT-4.0 Turbo a enregistré un taux d’hallucinations de 3,59 %, tandis que DeepSeek 1B, identifié comme le modèle open source le plus performant parmi ceux testés, a affiché un taux d’hallucinations de 13,63 %. Sur la base de ces résultats, les chercheurs ont conclu que les organisations s’appuyant sur des modèles de codage open source pourraient être exposées à un risque d’attaques de type « slopsquatting » environ quatre fois plus élevé.

Ces conclusions sont utiles pour la planification stratégique, mais elles ne doivent pas être interprétées comme un classement définitif en matière de sécurité de l’IA. Les modèles linguistiques continuent d’évoluer grâce à de nouvelles méthodes d’entraînement, à des mises à jour logicielles et à des architectures en constante évolution. Les performances mesurées aujourd’hui ne refléteront peut-être pas celles d’ici six mois. De même, les pirates continueront d’étudier aussi bien les systèmes propriétaires que les systèmes open source afin d’identifier de nouvelles failles.

Pour les dirigeants d’entreprise, le choix entre une IA propriétaire et une IA open source ne doit pas se limiter aux taux d’hallucination. Le coût, la flexibilité, les exigences réglementaires, la confidentialité des données, l’intégration aux systèmes existants et la stratégie à long terme des fournisseurs sont autant de facteurs qui influencent cette décision. La sécurité est un aspect important à prendre en compte, mais elle ne constitue qu’un élément d’une stratégie technologique d’entreprise plus large.

L’approche la plus pérenne consiste à partir du principe que tout assistant de codage basé sur l’IA est susceptible de commettre des erreurs. Les contrôles de sécurité doivent donc être conçus pour valider les résultats plutôt que de se fier au modèle lui-même. Les organisations qui intègrent directement la vérification dans leur cycle de vie de développement logiciel seront mieux à même de tirer parti de l’IA, quel que soit le modèle qu’elles choisissent aujourd’hui ou à l’avenir.

Le recours croissant au codage assisté par l’IA élargit la surface d’attaque pour le « slopsquatting »

Le développement logiciel assisté par l’IA s’intègre rapidement dans le quotidien des ingénieurs. Les développeurs utilisent des assistants de codage pour générer des fonctions, expliquer le code, identifier des bogues et recommander des dépendances logicielles. Cela accélère le développement, mais augmente également le nombre de recommandations générées par l’IA qui sont intégrées dans les environnements de production.

Les développeurs estiment que plus de 40 % du code qu’ils valident intègre déjà une assistance par IA, et nombreux sont ceux qui s’attendent à ce que ce pourcentage continue d’augmenter au cours des prochaines années. L’étude indique également que 72 % des développeurs ayant testé des outils d’IA les utilisent désormais quotidiennement. Ces chiffres montrent que le développement assisté par l’IA est en train de devenir un modèle opérationnel standard plutôt qu’une fonctionnalité expérimentale.

À mesure que son adoption se généralise, les organisations doivent s’attendre à ce que le volume des dépendances générées par l’IA augmente également. Toute dépendance intégrée à une application représente un risque potentiel si elle n’est pas correctement vérifiée. Le problème n’est pas que le code généré par l’IA soit intrinsèquement peu sûr. Le problème réside dans le fait qu’une mise à disposition plus rapide des logiciels peut, involontairement, réduire le niveau de contrôle appliqué aux bibliothèques tierces si la gouvernance n’évolue pas au même rythme que les pratiques de développement.

Les dirigeants devraient considérer cela comme un défi lié à la mise à l’échelle de l’activité. Les gains de productivité sont précieux, mais ils nécessitent également des investissements dans des processus capables de s’adapter à cette évolution. On ne devrait pas attendre des équipes de développement qu’elles vérifient manuellement chaque recommandation issue de l’IA à mesure que son adoption se généralise. Les entreprises devraient plutôt renforcer la validation automatisée des dépendances, l’analyse de la composition logicielle et les tests de sécurité en continu, afin que la sécurité suive le rythme du développement.

Les organisations qui parviennent à allier une productivité optimisée par l’IA à une gouvernance rigoureuse seront mieux à même d’innover sans s’exposer à des risques opérationnels inutiles. L’IA peut accélérer la mise à disposition des logiciels, mais le succès à long terme repose sur la nécessité de veiller à ce que cette rapidité ne se fasse pas au détriment de l’intégrité des logiciels.

Les organisations peuvent réduire le risque de « slopsquatting » grâce à une validation plus rigoureuse des paquets et à une surveillance continue de la sécurité

Le « slopsquatting » constitue un risque maîtrisable lorsque les organisations considèrent le code généré par l’IA comme une donnée d’entrée nécessitant une vérification plutôt qu’une acceptation automatique. L’objectif n’est pas de ralentir le développement, mais de s’assurer que les dépendances logicielles sont validées avant d’être intégrées aux systèmes de production.

L’une des mesures les plus efficaces consiste à vérifier automatiquement, avant l’installation, les noms des paquets par rapport à des référentiels publics ou privés de confiance. Ce contrôle simple permet d’empêcher les développeurs d’installer des paquets qui n’existent pas dans les référentiels approuvés ou qui ont été enregistrés par des pirates afin d’exploiter les « hallucinations » de l’IA. L’intégration directe de ces vérifications dans les pipelines de développement réduit le recours à la vérification manuelle tout en améliorant la cohérence entre les équipes d’ingénierie.

La surveillance continue revêt une importance tout aussi grande une fois le logiciel déployé. Les équipes de sécurité doivent rester vigilantes face aux installations inattendues de paquets, aux mises à jour inhabituelles des dépendances et aux comportements anormaux des logiciels, susceptibles d’indiquer qu’un composant a été compromis. Associées aux informations actuelles sur les menaces relatives aux campagnes de « slopsquatting » connues, ces capacités renforcent la capacité d’une organisation à identifier et à contenir les menaces avant qu’elles ne se propagent à plusieurs systèmes.

Pour les dirigeants, il s’agit en fin de compte d’une question de gouvernance plutôt que d’un simple détail technique de mise en œuvre. L’adoption de l’IA doit s’accompagner de politiques de développement logiciel actualisées, de pratiques de gestion des dépendances renforcées et d’une responsabilité clairement définie en matière de validation des composants tiers. Ces mesures permettent de garantir que l’IA contribue à accélérer l’innovation sans compromettre le niveau de sécurité de l’organisation.

La leçon à en tirer va bien au-delà du « slopsquatting ». À mesure que l’IA s’intègre dans le développement des logiciels d’entreprise, les organisations auront besoin de cadres de sécurité capables d’évoluer aussi rapidement que la technologie elle-même. Les entreprises qui investissent dès maintenant dans la validation automatisée, la surveillance continue et les pratiques de développement sécurisées seront mieux préparées à adopter en toute confiance les futures capacités de l’IA, tout en préservant la résilience de leurs chaînes d’approvisionnement logicielles.

Dernières réflexions

Le développement logiciel assisté par l’IA n’est plus une tendance émergente. Il fait désormais partie intégrante de la manière dont les organisations modernes conçoivent leurs produits, fournissent leurs services et se positionnent face à la concurrence. Les gains de productivité sont considérables, mais chaque amélioration des capacités modifie le paysage de la sécurité. Le « slopsquatting » illustre parfaitement la façon dont les attaquants s’adaptent aussi rapidement que la technologie elle-même.

Pour les dirigeants d’entreprise, la priorité ne doit pas être de ralentir l’adoption de l’IA, mais bien de l’adopter de manière responsable. Les organisations qui considèrent par défaut que le code généré par l’IA est fiable s’exposent à des risques inutiles. En revanche, celles qui associent l’IA à une gouvernance rigoureuse, à une validation automatisée et à une surveillance continue seront en mesure d’avancer rapidement sans compromettre l’intégrité de leurs logiciels.

C’est également l’occasion de repenser plus largement la sécurité de la chaîne d’approvisionnement logicielle. La gestion des dépendances, la validation du code et les pratiques de développement sécurisées devraient devenir des capacités stratégiques plutôt que de simples fonctions techniques isolées. À mesure que l’IA s’intègre à l’ensemble du cycle de vie du développement logiciel, ces capacités auront une influence directe sur la résilience opérationnelle, la confiance des clients et les performances commerciales à long terme.

Les organisations qui tireront le plus grand avantage concurrentiel de l’IA ne seront pas nécessairement celles qui produisent du code le plus rapidement. Ce seront celles qui développent des logiciels sécurisés et fiables à grande échelle, tout en garantissant la fiabilité de chaque composant mis en production. Dans les années à venir, cet équilibre entre rapidité et confiance deviendra une caractéristique déterminante du leadership technologique.