Ces dernières années, la sécurité des applications avait une frontière bien définie : le référentiel et le pipelineC'est là que se trouvaient les commandes, que les analyses étaient effectuées et que les équipes décidaient du déploiement en production. Tout reposait sur une seule hypothèse : un développeur choisissait explicitement le code et les dépendances à intégrer au système.
Cette hypothèse n'est plus valable. De plus en plus de code est aujourd'hui écrit, suggéré ou installé par un agent d'IA, souvent sans que personne ne vérifie le nom du code utilisé. Lorsque lecisL'attaque se déplace au fur et à mesure que le code est intégré. Elle se place dès le début du processus : au moment de la création du code, au sein même de l'assistant et dans les fichiers qui le configurent.
Voici votre surface d'attaque IA : chaque modèle, agent, serveur MCP, compétence et dépendance suggérée par l'IA peut désormais introduire un risque avant même qu'un humain ne l'ait examinée. L'IA à laquelle vos développeurs font confiance en fait maintenant partie. Il ne s'agit pas d'un risque futur, mais d'un changement déjà effectif, dont voici les conséquences concrètes.
Une vague d'attaques, et non un incident isolé
Aucun des exercices suivants n'est un exercice de laboratoire.cisQu’il s’agisse d’un cas réel ou hypothétique, ce sont des incidents publics et documentés, presque tous survenus au cours de l’année écoulée, et chacun d’eux nous rapproche un peu plus de l’agent d’IA lui-même :
- Août 2025, s1ngularité : Des attaquants ont volé un jeton de publication de Nx, l'un des systèmes de construction les plus utilisés, et ont diffusé des versions malveillantes sur npm, en utilisant des outils d'IA pour rechercher des secrets sur les machines des développeurs.
- Septembre 2025, craie/débogage : L'une des plus importantes compromissions de npm en termes d'ampleur : 18 paquets totalisant plus de deux milliards de téléchargements hebdomadaires ont été pris en main grâce au piratage du compte d'un seul mainteneur.
- Septembre 2025, Shai-Hulud : Il s'agit de l'un des premiers vers informatiques documentés capables de se propager automatiquement via npm. Sa deuxième vague, en novembre, était plus agressive et liée à des secrets exposés dans plus de 25 000 dépôts.
- Octobre 2025, importations inutilisées : dans le cadre de la campagne PhantomRaven, où une hallucination d'IA a introduit un véritable logiciel malveillant dans npm via une technique de slopsquatting.
- Cette année, ClawHub : un registre de compétences en IA empoisonné où cinq des sept compétences les plus téléchargées étaient des logiciels malveillants.
L'industrie parvient à la même conclusion. Le Top 10 OWASP pour les applications LLM place l'injection rapide en tête. Le Top 10 OWASP MCP (actuellement en version bêta) cible le protocole utilisé par les agents pour communiquer avec les outils. Le Top 10 OWASP des compétences d'agent, un nouveau projet en phase d'incubation, désigne les compétences malveillantes comme son principal risque. OWASP procède généralement avec prudence ; l'ouverture simultanée de trois fronts, dont un en urgence, témoigne de la rapidité de l'évolution de la situation.
Ces trois points convergent vers la même idée : les instructions, les outils et les configurations d’un modèle font désormais partie de la surface d’attaque de l’IA et se trouvent généralement dans votre propre dépôt. Ce qui soulève la première question qu’il convient de poser à vos équipes : qui examine les fichiers de règles, les compétences et les configurations MCP présents dans votre dépôt ?
Vecteur 1 : la compétence empoisonnée
Une compétence est un fichier d'instructions et de capacités qui enseigne à un agent d'IA comment effectuer une tâche. Ce n'est pas la seule façon de façonner le comportement d'un agent (fichiers de règles, hooks(et les configurations MCP font de même), mais elles partagent toutes une propriété : elles voyagent à l'intérieur du dépôt, avec le code.
Les recherches menées cette année ont passé en revue 4 000 de ces compétences :
- 36 % présentaient au moins une faille de sécurité.
- 13.4 % étaient critiques.
- Près de 100 d'entre eux contenaient directement des charges utiles malveillantes.
Le changement fondamental : l’attaquant ne cible plus votre code. Il cible l’agent qui l’écrit, en y insérant des instructions cachées (parfois à l’aide de caractères invisibles) que le modèle lit et interprète comme opérationnelles. Un examinateur humain valide ensuite ces instructions. pull request En toute bonne foi, car, à leurs yeux, le fichier semble correct. Le modèle interprète des instructions que le réviseur n'a jamais vues.
Ce n'est pas une simple hypothèse. La vulnérabilité CVE-2025-59536 (CVSS 8.7) permettait de lancer Claude Code depuis un dépôt non fiable, où une configuration malveillante pouvait exécuter des commandes avant même que l'utilisateur n'ait validé la boîte de dialogue de confiance. Une autre vulnérabilité, CVE-2026-21852, permettait l'exfiltration d'une clé API via la configuration du projet, sans aucune intervention de l'utilisateur.
H2 : Vecteur 2 : squatting
Le terme combine « slop » (les données inutilisables générées parfois par une IA) et l'attaque classique de typosquatting. Le typosquatting repose sur l'erreur humaine : un attaquant enregistre un nom de paquet proche d'un nom populaire et attend une faute de frappe. C'est aléatoire.
Squatting n'attend pas qu'une erreur soit commise. Dans l'étude mentionnée lors de cette session, 19.7 % des références de paquets générées par les modèles d'IA pointaient vers des paquets inexistants. Les modèles ont tendance à répéter les mêmes noms de manière hallucinatoire ; un attaquant observe donc les noms inventés par l’IA, les enregistre avec du code malveillant et attend la prochaine installation suggérée par l’IA pour l’intégrer à votre application.
L'échelle n'est pas petite : Plus de 450 000 nouveaux paquets malveillants ont été identifiés en 2025. Deux exemples le rendent concret :
- Un chercheur a placé un paquet test inoffensif appelé huggingface-cli pour le prouver. Il a été enregistré Plus de 30 000 téléchargements en trois mois.
- importations inutiliséesL'incident mentionné dans la chronologie ci-dessus était un logiciel malveillant confirmé, actif dans un registre public, utilisant précisément cette technique. Il ne s'agissait pas d'un test.
La question n'est pas de savoir si cela peut arriver à votre équipe, mais plutôt combien de packages suggérés par l'IA sont intégrés à votre code aujourd'hui sans que personne ne les examine.
La réponse: standardLes gens rattrapent leur retard
Deux forces agissent en parallèle. Tandis que les attaques s'accélèrent, standardLes corps réagissent :
- Norme NIST SP 800-218A étend le cadre de développement logiciel sécurisé avec des pratiques spécifiques aux modèles d'IA, notamment la preuve d'intégrité et de provenance.
- In 2026 mai, CISA et ses partenaires internationaux du G7 ont publié des directives sur une nomenclature logicielle pour l'IA, définissant ce qui doit figurer dans cet inventaire : modèles, ensembles de données, composants, fournisseurs et dépendances.
La direction est claire : SBOM se développe en une nomenclature IA. On ne peut certifier ou attester ce qu'on ne peut inventorier. Et aujourd'hui, la plupart des organisations ne peuvent pas :
- 43 % ils ne peuvent pas auditer ni inventorier les outils d'IA qu'ils utilisent déjà.
- 79 % n'ont aucune visibilité sur les agents d'IA et les systèmes MCP exécutés dans leur propre environnement.
Dans les environnements réglementés, cet inventaire passe du statut de bonne pratique à celui d'exigence contractuelle ou d'obligation de conformité. Mais un inventaire ne fait que recenser les biens disponibles ; à lui seul, il ne permet pas de se prémunir contre une attaque.
L'écart : une solution EDR pour la sécurité des applications
SAST et SCA Les outils sont conçus pour analyser le code et les dépendances, et non le comportement d'un agent ou sa configuration. EDR Ces outils permettent de visualiser les processus et les connexions réseau, mais ils ne disposent généralement pas du contexte de sécurité applicatif nécessaire pour interpréter une dépendance ou la configuration d'un agent. Un fossé existe entre ces deux catégories d'outils : c'est précisément là que le code est créé et là que réside la surface d'attaque de l'IA.
Cette lacune présente trois angles morts :
- Actifs d'IA. Les modèles, les agents et les serveurs MCP n'apparaissent pas sur votre SASTest ou SCALe radar de [nom du radar]. On ne peut pas inventorier ce qu'on ne voit pas.
- Fichiers de configuration. Les compétences, les règles et les configurations MCP façonnent le comportement des agents, mais sont généralement examinées comme s'il s'agissait de simples textes inoffensifs.
- Installation du paquet. A Une dépendance malveillante peut s'exécuter avant même d'être identifiée comme telle., puis exfiltrer des secrets et des jetons sans que personne ne l'approuve.
Comment Xygeni le ferme
Ce qu'un EDR fait pour les terminaux, Xygéni Shield joue un rôle essentiel dans le cycle de vie du développement assisté par l'IA : il protège l'environnement de création du code tout en comprenant le contexte de sécurité de l'application.
- Visibilité où SAST et SCA n'atteins pas. Xygeni signale les fichiers de compétences et de règles malveillants, analyse les configurations MCP et crée un environnement prêt pour l'audit. Nomenclature AI-BOM, correspondant aux 10 meilleurs classements OWASP LLM, MCP et Agentic Skills.
- Des renseignements, et pas seulement des signatures. MEW (Malware Early Warning) analyse le comportement et les risques d'un logiciel malveillant afin de le bloquer avant même la publication d'une CVE, d'un avis de sécurité ou d'une signature publique. Une veille réseau actualisée permet de couper les connexions aux infrastructures malveillantes connues.
- Un seul point de contrôle, du code au point de terminaison. Un agent unique, déployé sans réarchitecture de l'environnement, avec la souveraineté des données européennes et les preuves de conformité intégrées.
Lors d'une démonstration en direct, cette application de politique de sécurité a bloqué la tentative d'un agent d'IA d'installer un logiciel malveillant via trois méthodes d'installation différentes (environnement virtuel, gestionnaire de paquets et téléchargement direct), avant même la fin de l'installation. Toutes les opérations ont été consignées en temps réel et exportées vers un SOC. La mise en place d'un premier projet prend généralement une heure ; l'extension de la protection à l'ensemble d'une organisation nécessite généralement une à deux semaines, selon sa structure.
QFP
Quelle est la surface d'attaque de l'IA en un paragraphe ?
La surface d'attaque de l'IA désigne l'ensemble des modèles, agents, serveurs MCP, compétences, fichiers de règles et dépendances suggérées par l'IA par lesquels un risque peut s'introduire dans une application, souvent avant même qu'elle ne soit examinée par un humain. Elle s'étend au-delà du code et des dépendances traditionnels pour inclure les fichiers de configuration et les instructions qui déterminent le comportement d'un agent d'IA.
Comment savoir si un nom de paquet suggéré par mon assistant IA est une hallucination ou s'il est simplement légitime mais inconnu ?
Avant l'installation, vérifiez le registre et analysez le contenu et la finalité du paquet plutôt que de vous fier uniquement à son nom. Xygeni automatise cette validation en temps réel lors de la génération du code, ce qui permet d'approuver ou de bloquer l'installation avant son exécution, même si vous ne connaissez pas le paquet.
Le slopsquatting affecte-t-il tous les modèles d'IA de la même manière ?
L'étude à l'origine du chiffre de 19.7 % a porté sur plusieurs modèles et a révélé que le problème était largement répandu, avec seulement de faibles variations entre eux. Il s'agit d'une tendance générale dans le développement assisté par l'IA, et non d'un défaut propre à un assistant en particulier.
Peut-on vérifier a posteriori si nous avons déjà installé un paquetage hallucinatoire ou malveillant ?
Oui. La plateforme Xygeni donne accès à une base de données mise à jour régulièrement recensant les packages malveillants détectés, consultable par rapport à votre inventaire de composants existant. Vous pouvez ainsi confirmer en quelques clics si un élément déjà installé constitue une menace connue.
Combien de temps faut-il pour la mise en œuvre dans une organisation de taille moyenne comportant plusieurs équipes ?
L'intégration d'un premier projet prend généralement environ une heure. Le déploiement à l'échelle d'une organisation entière prend généralement une à deux semaines, selon la structure de l'équipe et ses méthodes de travail.
Cartographiez gratuitement votre surface d'attaque en IA
Cartographiez gratuitement l'empreinte IA de votre application : créez un compte et Effectuez une première analyse en quelques minutesCommencez par une seule application, voyez quelle IA elle contient et identifiez la partie de votre surface d'attaque d'IA qui est dangereuse.
Certaines des fonctionnalités mentionnées ci-dessus sont mises en œuvre par le biais du Bouclier Xygeni et du ASPMModules de sécurité IA ; la disponibilité peut varier selon le forfait. Voir xygeni.io pour obtenir les détails actuels du produit.
