Les dangers cachés du codage par l’IA

Bien que les avantages des assistants IA sur le lieu de travail restent discutables, c’est dans le domaine du développement logiciel qu’ils sont adoptés par le plus grand nombre. Ici, les LLM remplissent plusieurs fonctions : refactorisation, documentation, et même développement d’applications entières. Cependant, les problèmes habituels liés à la sécurité des informations dans le domaine du développement sont désormais aggravés par les vulnérabilités propres aux modèles d’IA. À cette intersection, de nouveaux bugs et problèmes apparaissent presque chaque semaine.

Code généré par l’IA vulnérable

Lorsqu’un LLM génère du code, celui-ci peut inclure des bugs ou des failles de sécurité. Après tout, ces modèles sont entraînés à partir de données accessibles au public sur Internet, y compris des milliers d’exemples de code de mauvaise qualité. Une récente étude de Veracode a révélé que les principaux modèles d’IA produisent désormais un code qui se compile avec succès dans 90 % des cas. Il y a moins de deux ans, ce chiffre était inférieur à 20 %. Cependant, la sécurité de ce code ne s’est pas améliorée : 45 % d’entre eux contiennent encore des vulnérabilités classiques figurant dans la liste OWASP Top 10, sans grand changement depuis deux ans. L’étude a porté sur plus d’une centaine de LLM populaires et de fragments de code en Java, Python, C# et JavaScript. Ainsi, que le LLM soit utilisé pour la « finalisation de code » dans Windsurf ou le « vibe coding » dans Loveable, l’application finale doit être soumise à des tests de vulnérabilité approfondis. Or, dans la pratique, cela arrive rarement : selon une étude de Wiz, 20 % des applications codées par vibe coding présentent de graves vulnérabilités ou des erreurs de configuration.

Pour illustrer ces failles, on cite souvent l’exemple de l’application de rencontre réservée aux femmes Tea, qui s’est retrouvée au centre d’une polémique après deux fuites de données majeures. Cependant, cette application est antérieure au vibe coding. C’est le tribunal qui déterminera si l’IA est responsable de l’erreur commise par Tea. Dans le cas de la start-up Enrichlead, cependant, l’IA était clairement responsable. Son fondateur s’est vanté sur les réseaux sociaux que 100 % du code de sa plateforme avait été écrit par l’IA Cursor, sans « aucun code écrit à la main ». Quelques jours seulement après son lancement, il s’est avéré que la plateforme présentait de nombreuses failles de sécurité de niveau débutant, permettant à n’importe qui d’accéder à des fonctionnalités payantes ou de modifier des données. Le projet a été abandonné après que le fondateur n’a pas réussi à amener le code à un niveau de sécurité acceptable à l’aide de Cursor. Cependant, il reste déterminé et a depuis lors lancé de nouveaux projets fondés sur le vibe coding.

Vulnérabilités courantes dans le code généré par l’IA

Bien que la programmation assistée par l’IA n’existe que depuis un an ou deux, il existe déjà suffisamment de données pour identifier ses erreurs les plus courantes. Voici les erreurs les plus fréquentes :

• Absence de validation des entrées, absence de nettoyage des données utilisateur des caractères indésirables, et autres erreurs élémentaires menant à des vulnérabilités classiques, comme les scripts intersites (XSS) et l’injection SQL.
• Les clés API et autres secrets sont codés en dur directement dans la page Web et sont visibles par les utilisateurs dans son code.
• Logique d’authentification entièrement implémentée côté client, directement dans le code du site exécuté dans le navigateur. Cette logique peut être facilement modifiée pour contourner toute vérification.
• Erreurs de journalisation : allant d’un filtrage insuffisant lors de l’écriture dans les journaux à une absence totale de journaux.
• Fonctions trop puissantes et dangereuses : les modèles d’IA sont optimisés pour produire un code qui résout une tâche de la manière la plus rapide possible. Mais le chemin le plus court est souvent incertain. Un exemple classique est l’utilisation de la fonction eval pour les opérations mathématiques sur les entrées utilisateur. Il en résulte la possibilité d’exécuter du code arbitraire dans l’application générée.
• Dépendances obsolètes ou inexistantes. Le code généré par l’IA fait souvent référence à d’anciennes versions de bibliothèques, effectue des appels API obsolètes ou non sécurisés, voire tente d’importer des bibliothèques fictives. Cette dernière opération est particulièrement dangereuse, car les pirates peuvent créer une bibliothèque malveillante avec un nom « plausible », et l’agent IA l’inclura dans un projet réel.

Dans le cadre d’une étude approfondie, les auteurs ont analysé le code généré par l’IA afin d’identifier les faiblesses répertoriées dans la liste MITRE CWE Top 25. Parmi les vulnérabilités les plus fréquentes figuraient : CWE-94 (injection de code), CWE-78 (injection de commande système), CWE-190 (débordement d’entier), CWE-306 (absence d’authentification), et CWE-434 (chargement de fichiers sans restriction).

Un exemple frappant de la faille CWE-94 est la récente compromission de la plateforme Nx, dont nous avons déjà parlé précédemment. Les pirates ont réussi à infecter un outil de développement populaire par un cheval de Troie en volant un jeton leur permettant de publier de nouvelles versions du produit. Le vol de jetons a exploité une vulnérabilité introduite par un simple fragment de code généré par l’IA.

Invites dangereuses

Le dicton bien connu des développeurs « done exactly according to the spec » (« fait exactement selon les spécifications ») s’applique également lors de l’utilisation d’un assistant IA. Si l’invite de création d’une fonction ou d’une application est vague et ne mentionne pas les aspects liés à la sécurité, le risque de générer un code vulnérable augmente considérablement. Une étude spécifique a révélé que même des remarques générales, comme « veillez à ce que le code respecte les meilleures pratiques en matière de sécurité », permettaient de réduire de moitié le taux de vulnérabilités.

Toutefois, l’approche la plus efficace consiste à utiliser des consignes de sécurité détaillées et adaptées à chaque langage, qui font référence aux listes d’erreurs MITRE ou OWASP. Une vaste collection de ces consignes de sécurité provenant de Wiz Research est disponible sur GitHub. Il est recommandé de les ajouter aux invites système des assistants IA via des fichiers tels que claude.md, .windsurfrules ou équivalents.

Dégradation de la sécurité lors des révisions

Lorsque le code généré par l’IA est révisé à plusieurs reprises à l’aide d’invites de suivi, sa sécurité se détériore. Une étude récente a demandé à GPT-4o de modifier un code existant jusqu’à 40 fois, pendant que les chercheurs analysaient chaque version à la recherche de vulnérabilités après chaque itération. Après seulement cinq itérations, le code contenait 37 % de vulnérabilités critiques en plus par rapport à la version initiale. L’étude a testé quatre stratégies d’invites, dont trois mettaient chacune l’accent sur un aspect différent : (i) les performances, (ii) la sécurité et (iii) les nouvelles fonctionnalités. La quatrième était rédigée avec des invites peu claires.

Lorsque les invites se sont concentrées sur l’ajout de nouvelles fonctionnalités, 158 vulnérabilités sont apparues, dont 29 critiques. Lorsque l’invite mettait l’accent sur la sécurité du codage, le nombre a considérablement diminué, mais comprenait tout de même 38 nouvelles vulnérabilités, dont sept critiques.

Il est intéressant de noter que les invites  » axées sur la sécurité  » ont entraîné le pourcentage d’erreurs le plus élevé dans les fonctions liées à la cryptographie.

Négligence du contexte industriel

Dans des secteurs tels que la finance, la santé et la logistique, il existe des exigences techniques, organisationnelles et juridiques qui doivent être prises en compte lors du développement d’applications. Les assistants IA ignorent ces contraintes. Ce problème est souvent appelé « manque de profondeur ». Par conséquent, les méthodes de stockage et de traitement des données personnelles, médicales et financières imposées par les réglementations locales ou sectorielles ne seront pas prises en compte dans le code généré par l’IA. Par exemple, un assistant pourrait écrire une fonction mathématiquement correcte pour calculer les intérêts sur les dépôts, mais ignorer les règles d’arrondi imposées par les régulateurs. Les réglementations relatives aux données de santé exigent souvent un enregistrement détaillé de chaque tentative d’accès, ce que l’IA ne peut pas mettre en œuvre automatiquement avec le niveau de détail requis.

Mauvaise configuration des applications

Les vulnérabilités ne se limitent pas au code généré dans le cadre du vibe coding lui-même. Les applications créées à l’aide du vibe coding sont souvent développées par des utilisateurs inexpérimentés, qui soit ne configurent pas du tout l’environnement d’exécution, soit le configurent en suivant les conseils de cette même IA. Il en résulte des erreurs de configuration dangereuses :

• Les bases de données requises par l’application sont créées avec des autorisations d’accès externes trop larges. Cette situation donne lieu à des fuites comme celles de Tea/Sapphos, où le pirate n’a même pas besoin d’utiliser l’application pour télécharger ou supprimer l’intégralité de la base de données.
• Les applications internes de l’entreprise restent accessibles au public sans authentification.
• Les applications se voient accorder des autorisations élevées pour accéder aux bases de données critiques. Si on y ajoute les vulnérabilités du code généré par l’IA, ce sont les injections SQL et les attaques similaires qui deviennent plus faciles.

Vulnérabilités des plateformes

La plupart des plateformes de vibe coding exécutent les applications générées à partir d’invites directement sur leurs propres serveurs. Cela lie les développeurs à la plateforme, notamment en les exposant à ses vulnérabilités et en les rendant dépendants de ses pratiques de sécurité. Par exemple, en juillet, une vulnérabilité a été découverte dans la plateforme Base44 qui a permis à des individus malintentionnés d’accéder à n’importe quelle application privée.

Menaces au stade du développement

La simple présence d’un assistant disposant de droits d’accès étendus sur l’ordinateur du développeur crée des risques. Voici quelques exemples :

La vulnérabilité CurXecute (CVE-2025-54135) permettait aux pirates d’ordonner à Cursor, un outil de développement IA très populaire, d’exécuter des commandes arbitraires sur la machine du développeur. Tout ce dont on avait besoin, c’était d’un serveur MCP (Model Context Protocol) actif connecté à Cursor, auquel une partie externe pouvait accéder. Il s’agit d’une situation typique : les serveurs MCP permettent aux agents d’IA d’accéder aux messages Slack, aux tickets Jira, etc. L’injection rapide peut être effectuée par l’un de ces canaux.

La vulnérabilité EscapeRoute (CVE-2025-53109) permettait la lecture et l’écriture de fichiers arbitraires sur le disque du développeur. La faille existait dans le serveur MCP très populaire d’Anthropic, qui permet aux agents IA d’écrire et de lire des fichiers dans le système. Les restrictions d’accès du serveur n’ont tout simplement pas fonctionné.

Un serveur MCP malveillant qui permettait aux agents IA d’envoyer et de recevoir des emails via Postmark transférait simultanément toute la correspondance vers une adresse cachée. Nous avions prédit l’émergence de tels serveurs MCP malveillants déjà en septembre.

Une vulnérabilité dans l’interface de ligne de commande Gemini permettait l’exécution arbitraire de commandes lorsqu’un développeur demandait simplement à l’assistant IA d’analyser le code d’un nouveau projet. L’injection malveillante a été déclenchée à partir d’un fichier readme.md.

L’extension Q Developer d’Amazon pour Visual Studio Code contenait brièvement des instructions pour effacer toutes les données de l’ordinateur d’un développeur. Un pirate a exploité une erreur des développeurs d’Amazon et a réussi à insérer cette invite malveillante dans le code public de l’assistant sans disposer de privilèges particuliers. Heureusement, une petite erreur de codage a empêché son exécution.

Une vulnérabilité dans l’agent Claude Code (CVE-2025-55284) permettait d’exfiltrer des données à partir de l’ordinateur d’un développeur via des requêtes DNS. L’injection rapide, qui reposait sur des utilitaires courants s’exécutant automatiquement sans confirmation, pouvait être intégrée dans n’importe quel code analysé par l’agent.

L’agent IA autonome Replit a supprimé les bases de données principales d’un projet qu’il développait, car il a décidé que la base de données devait être nettoyée. Cette opération a enfreint une instruction directe interdisant toute modification (gel du code). Derrière ce comportement inattendu de l’IA se cache une faille architecturale majeure : à l’époque, Replit n’avait pas séparé les bases de données de test et de production.

Une injection d’invite placée dans un commentaire du code source a incité l’environnement de développement Windsurf à stocker automatiquement des instructions malveillantes dans sa mémoire à long terme, lui permettant ainsi de voler des données du système pendant des mois.

Dans le cas de l’incident de compromission Nx, des outils en ligne de commande pour Claude, Gemini et Q ont été utilisés pour rechercher des mots de passe et des clés pouvant être volés à partir d’un système infecté.

Comment utiliser en toute sécurité les codes générés par l’IA

Le niveau de risque lié au code créé par l’IA peut être considérablement réduit, mais pas complètement, grâce à une combinaison de mesures organisationnelles et techniques :

• Mettre en place une révision automatique du code généré par l’IA au fur et à mesure de son écriture à l’aide d’outils SAST optimisés.
• Intégrer les exigences de sécurité dans les invites système de tous les environnements d’IA.
• Faire appel à des spécialistes expérimentés pour effectuer des revues de code détaillées, avec l’aide d’outils d’analyse de sécurité spécialisés basés sur l’IA afin d’accroître l’efficacité.
• Former les développeurs à rédiger des invites sécurisées et, plus généralement, leur proposer une formation approfondie sur l'utilisation sécurisée de l'IA.