TL; DR
Presque toutes les équipes d'ingénierie utilisent des assistants de programmation IA. Presque aucune n'est capable de recenser les IA qu'elle utilise réellement. Gartner a défini la gestion de la posture de sécurité de l'IA comme une catégorie de son cycle de hype 2025 pour la sécurité des données, car le fossé est réel : les modèles, les agents, les serveurs MCP et les ensembles de données sont des actifs d'IA dans la surface d'attaque, et la plupart des organisations n'ont aucun moyen structuré de les visualiser.
Découvrir sans remédier n'est qu'une découverte. dashboard. Environ 40 % du code généré par l'IA contient des failles de sécurité. Les assistants IA reproduisent des schémas non sécurisés à un volume qu'aucune vérification manuelle n'est conçue pour gérer. Connaître les ressources IA existantes ne résout que la moitié du problème ; l'autre moitié consiste à évaluer les risques et à corriger le code avant sa mise en production, dans le même flux de travail que celui utilisé pour son écriture.
La surface d'attaque est plus vaste que le code lui-même. Des attaques documentées ciblent déjà les ressources entourant le code : du code Unicode caché dans des fichiers de règles qui amène les assistants à émettre des sorties compromises, l’empoisonnement de l’outil MCP et l’exécution complète de code à distance via un pont MCP largement utilisé (plus de 437 000 téléchargements), et le slopsquatting — l’enregistrement des noms de paquets que les modèles d’IA sont statistiquement susceptibles d’interpréter de manière erronée. SAST et SCA Je ne vois rien de tout cela.
La solution consiste en une seule boucle, et non en trois outils à points : IA-SPM constitue l'inventaire et la nomenclature IA ; Sécurité de l'IA évalue le risque par rapport au Top 10 de l'OWASP pour les demandes de LLM ; DevAI Il corrige les vulnérabilités du code au sein de l'IDE au fur et à mesure de son écriture, qu'il soit généré par l'IA ou écrit par l'homme, et intercepte les actions que d'autres agents s'apprêtent à effectuer avant qu'ils ne les réalisent. Cela s'applique aux résultats des propres scanners de Xygeni et à tout ce qui a déjà été ingéré par les outils en place. — aucune opération de remplacement nécessaire.
Presque toutes les équipes d'ingénierie ont adopté des assistants de programmation IA. Pourtant, rares sont celles qui peuvent répondre à une question simple : quels modèles d'IA, agents et serveurs MCP utilisons-nous réellement, et quels risques chacun comporte-t-il ? Ce manque a désormais un nom : Gartner a formellement défini la gestion de la posture de sécurité de l'IA. (IA-SPM) en tant que catégorie dans son Cycle de vie des tendances en matière de sécurité des données à l'horizon 2025 — de la même lignée que celle qui a donné naissance aux normes CSPM et DSPM. Cette catégorie existe car les chiffres sont concrets : environ 40 % du code généré par l’IA contient des failles de sécurité, l’IA fait désormais partie de la surface d’attaque et n’est plus seulement un outil utilisé par les développeurs, et la plupart des organisations ne disposent d’aucun inventaire structuré des ressources d’IA qu’elles exploitent.
C'est également le sujet que nous aborderons sur le terrain à OWASP AppSec Days Portugal 2026, les 23 et 24 septembre à Porto, où Xygeni est un sponsor OrNous y reviendrons à la fin, mais si vous souhaitez passer directement à la suite, obtenez votre billet ici.
Le problème : le code généré par l’IA comporte son propre profil de risque
Environ 40 % du code généré par l'IA contient des failles de sécurité. Des recherches indépendantes sur les assistants de programmation IA ont révélé des taux d'échec constamment élevés face aux tests de sécurité. OWASP Top 10Certaines catégories de failles, comme les attaques XSS (Cross-Site Scripting), apparaissent dans la grande majorité des exemples générés. Les assistants IA ne se contentent pas d'écrire du code plus rapidement ; ils reproduisent également plus rapidement les schémas non sécurisés, les dépendances non sécurisées et les configurations non sécurisées, et ce, à un volume qu'aucun processus de vérification manuelle n'est conçu pour gérer.
La surface d'attaque ne se limite pas au code écrit par un assistant. Elle s'étend aux ressources d'IA que vos équipes utilisent déjà et dont elles font rarement l'inventaire : modèles, jeux de données, agents et serveurs MCP. Chacune d'entre elles a déjà donné lieu à des attaques réelles et documentées.
- Porte dérobée du fichier de règles : Des attaquants dissimulent des instructions à l'aide de caractères Unicode invisibles dans des fichiers de règles et de configuration lus par des outils comme GitHub Copilot et Cursor, ce qui amène l'assistant à exécuter du code malveillant sans jamais le signaler. Répertorié comme un Étude de cas MITRE ATLAS.
- Empoisonnement de l'outil MCP et exécution de code à distance : Une vulnérabilité critique dans un pont MCP largement utilisé, téléchargé plus de 437 000 fois, permettait l'exécution complète de code à distance dès qu'un client se connectait à un serveur MCP non fiable.
- Squatting: Une recherche universitaire à grande échelle a généré plus de deux millions d'échantillons de code dans seize LLM et a révélé que près d'un package recommandé sur cinq n'existait pas du tout, des noms que les attaquants peuvent enregistrer et utiliser à l'avance comme armes.
Rien de tout cela n'apparaît dans un ouvrage traditionnel SAST or SCA Ces outils analysent le code. Ils ne comprennent pas ce qu'est un modèle, ce que fait un serveur MCP, ni si le fichier de configuration d'un agent a été altéré.
La plupart des équipes résolvent la moitié du problème.
La réaction instinctive consiste à ajouter des outils ponctuels : un pour l’analyse des modèles, un autre pour les pare-feu d’exécution, un troisième pour… assistants IDEC'est la même erreur qu'a commise AppSec avec SAST, SCAet le scan des secrets il y a quinze ans, et cela produit le même résultat : une visibilité fragmentée, un bruit d’alertes et aucun endroit unique pour répondre à la question « quelle IA utilisons-nous réellement et est-elle sûre ? »
La découverte sans correction ne fait que localiser le problème. Corriger sans découvrir signifie corriger du code alors que des serveurs MCP fantômes et des agents non approuvés fonctionnent sans surveillance à proximité. La sécurité de l'IA doit couvrir les deux, sur la même plateforme, sinon il ne s'agit pas de gestion de la posture. dashboard.
La meilleure solution : une gestion de la posture de sécurité par IA qui découvre, détecte et corrige les problèmes.
Xygéni Sécurité de l'IA boucle la boucle pour l'ensemble de l'ère de l'IA SDLC, du modèle et du serveur MCP jusqu'au point de terminaison du développeur.
- Découvrir. AI-SPM établit un inventaire en temps réel de toutes les ressources d'IA de l'organisation : modèles, jeux de données, agents, serveurs MCP. Il prouve cet inventaire grâce à un Nomenclature IA, la base de preuves que les auditeurs et les organismes de réglementation demandent de plus en plus, qu'il s'agisse de documentation technique pour les systèmes à haut risque en vertu de la loi européenne sur l'IA ou des inventaires d'actifs requis par des cadres comme l'ENS espagnol.
- Détecter. AI Security évalue chaque actif en fonction du risque réel : injection rapide, configurations MCP non sécurisées, exposition des données, conformément aux normes en vigueur. Top 10 de l'OWASP pour les candidatures au LLMLes résultats sont classés par ordre de priorité, et non pas mis en file d'attente.
- Corrigez, au point où le code est écrit. C'est là que l'IA générée code security Le problème est effectivement résolu. Xygeni DevAI Il s'exécute en continu au sein de l'IDE, effectuant une analyse incrémentale à mesure que les développeurs travaillent avec du code écrit par des humains et du code généré par l'IA. Il réalise une détection de vulnérabilités par IA autonome et cartographie les Chemins d'attaque pilotés par l'IA pour montrer comment une faille pourrait être exploitée, et fournit des correctifs sécurisés générés par l'IA qui sont validés en termes d'exploitabilité et de risque de rupture de compatibilité avant même qu'un développeur ne les applique. Guardrails Les modifications sont validées par rapport à la politique de sécurité et de conformité avant d'atteindre l'intégration continue, et un agent DevAI dédié intercepte ce que les autres agents sont sur le point de faire : validation des fichiers de compétences et de règles, contrôle de chaque package qu'un agent tente d'installer à la recherche de logiciels malveillants et de schémas de slopsquatting, et surveillance du comportement de l'outil MCP pour détecter toute tentative d'empoisonnement, le tout avant l'exécution.
- Imposer. Shield étend cette même politique au point de terminaison du développeur, bloquant toute activité d'IA non sécurisée avant son exécution.
Et parce que Triage de l'IALes explications et les mesures correctives s'appliquent non seulement aux conclusions de Xygeni, mais aussi à tout ce qui provient des outils déjà en place ; les équipes en bénéficient sans avoir à supprimer ce dans quoi elles ont déjà investi.
Venez rencontrer Xygeni à l'événement OWASP AppSec Days Portugal 2026
Nous portons cette conversation à Porto. Xygéni est sponsor Gold à OWASP AppSec Days Portugal 2026, En cours d'exécution Septembre 23-24 à la Fundação António Cupertino de Miranda.
Nous serons présents à l'événement pour présenter concrètement la gestion de la posture de sécurité de l'IA : comment les équipes découvrent des ressources d'IA dont elles ignoraient l'existence, et comment l'IA génère des informations. code security s'intègre à un programme AppSec existant au lieu d'être simplement ajouté à côté, et décrit à quoi ressemble réellement la vague actuelle de menaces MCP et d'agents dans la réalité.
Si vous participez, Venez rencontrer l'équipe Xygeni au stand 12. Si la sécurité de l'IA figure parmi vos priorités et que vous ne pouvez pas vous rendre à Porto, nous serons ravis de vous en parler directement. Aux mêmes dates, nous serons également présents à Journée OWASP allemande 2026 à Karlsruhe, en parlant de la sécurité de l'IA et Shieldsa couche d'application en particulier.
Réservez une réunion avec nous !
QFP
- Qu’est-ce que la gestion de la posture de sécurité par IA (AI-SPM) ?
L'AI-SPM est la discipline qui consiste à découvrir, inventorier et évaluer en continu les risques liés à chaque ressource d'IA utilisée par une organisation (modèles, jeux de données, agents et serveurs MCP), à l'instar du CSPM pour le cloud et du DSPM pour les données. Gartner l'a définie comme une catégorie de son cycle de vie des technologies émergentes en matière de sécurité des données pour 2025. La solution AI-SPM de Xygeni permet de constituer cet inventaire et de l'étayer par une nomenclature d'IA (AI-BOM), fournissant ainsi aux équipes de sécurité et de conformité les éléments justificatifs à présenter à un auditeur.
- Qu'est-ce qui rend l'IA générée code security différent du traditionnel SAST or SCA?
L'analyse statique traditionnelle et l'analyse des dépendances ont été conçues pour comprendre le code et les paquets, et non les risques spécifiques à l'IA. Elles ne détectent pas les injections de prompts, les règles ou fichiers de compétences malveillants, l'empoisonnement des outils MCP, ni les noms de paquets slopsquattés qu'un assistant IA pourrait installer. code security doit s'intégrer au même flux de travail que celui utilisé par les développeurs, en analysant simultanément le code écrit par l'homme et le code généré par l'IA, ce que fait Xygeni DevAI au sein de l'IDE.
- Pourquoi environ 40 % du code généré par l'IA contient-il des vulnérabilités ?
Les assistants de programmation IA apprennent et reproduisent les schémas de leurs données d'entraînement, y compris les données non sécurisées, et génèrent du code bien plus rapidement que ne peut le faire une analyse manuelle. Des études indépendantes ont systématiquement mis en évidence des taux élevés de vulnérabilités du Top 10 de l'OWASP dans les échantillons générés par l'IA, certaines catégories de failles, comme les attaques XSS (Cross-Site Scripting), apparaissant dans la grande majorité des tests.
- L'AI-SPM remplace-t-il nos outils AppSec existants ?
Non, et il ne devrait pas essayer. La solution d'analyse, d'explication et de remédiation par IA de Xygeni s'applique aux résultats des scanners Xygeni et à ceux provenant d'outils tiers déjà en place. Les équipes bénéficient ainsi d'une couverture unifiée des risques liés à l'IA sans avoir à remplacer intégralement leurs investissements existants.
- Où puis-je voir cela en action ?
Xygeni est sponsor Gold de l'OWASP AppSec Days Portugal 2026., les 23 et 24 septembre à Porto, et l'équipe sera sur place à Stand 12 conversation via AI-SPM, généré par l'IA code securityet la vague actuelle de menaces MCP et d'agents malveillants. Achetez votre billet ou contactez-nous directement si vous ne pouvez pas vous rendre à Porto.
La même semaine, nous sommes également à Journée OWASP allemande 2026 à Karlsruhe, axé sur la sécurité de l'IA et Shieldcouche d'application de la loi.
