Le codage Vibe est-il vraiment sûr ? Cet article de l'université Carnegie Mellon étudie principalement l'« Évaluation comparative des vulnérabilités du code généré par des agents à partir de tâches réelles ». Si les agents d'IA sont de plus en plus performants en termes de « fonctionnalités » du code généré, leur « sécurité » reste alarmante. Même dans un code parfaitement fonctionnel, plus de 80 % présente de graves failles de sécurité. Contexte : Qu'est-ce que le « Vibe Coding » ? Pourquoi est-il dangereux ? Le « Vibe Coding » est un paradigme de programmation émergent : au lieu d'écrire du code ligne par ligne, les programmeurs utilisent le langage naturel pour donner des instructions vagues ou de haut niveau, qui sont ensuite utilisées par un agent LLM pour réaliser automatiquement des tâches de codage complexes. Situation actuelle : Cette méthode améliore considérablement l'efficacité, et 75 % des personnes interrogées l'utilisent. Risque potentiel : les utilisateurs se contentent souvent de vérifier si le code « fonctionne » (fonctionnalités), sans se soucier de sa sécurité. L’article souligne que cette confiance aveugle introduit des risques de sécurité importants dans l’environnement de production. Méthodologie de recherche : Benchmark SUSVIBES Pour vérifier la sécurité, l’équipe a créé une nouvelle suite de benchmarks appelée SUSVIBES. Source réelle : contrairement aux tests précédents qui ne testaient que des fichiers/fonctions simples, SUSVIBES a déniché 200 exigences fonctionnelles complexes dans des projets open-source réels (GitHub) qui avaient historiquement connu des vulnérabilités de sécurité. Processus de test : • Trouvez une vulnérabilité qui a été corrigée (par exemple, une version qui a corrigé l'injection SQL). • Rétablir le code à son état précédent avant la correction et faire en sorte que l'agent IA réimplémente la fonctionnalité. • Double vérification : Exécuter à la fois des « tests fonctionnels » (pour vérifier si la fonction est implémentée) et des « tests de sécurité » (pour vérifier si la vulnérabilité d'origine est reproduite). Constat principal : Le phénomène inquiétant des « scores élevés, faibles capacités » L'équipe a testé les frameworks d'agents les plus avancés (SWE-Agent, OpenHands) et les modèles les plus performants (Claude 4 Sonnet, Gemini 2.5 Pro, Kimi K2). Les résultats sont extrêmement alarmants : Puissant mais extrêmement vulnérable : La combinaison la plus performante (SWE-Agent + Claude 4 Sonnet) a résolu 61 % des tâches (fonctionnement correct). Cependant, parmi ces codes fonctionnant correctement, seuls 10,5 % sont sûrs. Autrement dit, plus de 80 % du « bon code » contient en réalité de graves vulnérabilités (telles que des conditions de concurrence, une élévation de privilèges, des attaques par injection, etc.). Différences entre les modèles : • Claude 4 Sonnet : Le plus puissant, mais aussi celui qui engendre le plus de vulnérabilités. • Gemini 2.5 Pro : Bien que le taux de réussite des fonctions soit faible (19,5 %), il est relativement sûr parmi les problèmes qu'il peut résoudre (considéré comme le modèle relativement « sûr »). • Kimi K2 : Niveau intermédiaire. Le message de sécurité est invalide. Les chercheurs ont essayé de dire à l'IA : « Veuillez faire attention » et « Veuillez vérifier les vulnérabilités CWE ». • Résultat : Non seulement la sécurité n'a pas été améliorée de manière significative, mais l'IA est devenue trop sensible et même les fonctions normales ne pouvaient plus être écrites correctement (le taux de réussite des fonctions a chuté d'environ 6 %). Étude de cas : Comment la vulnérabilité est-elle apparue ? L'article fournit un exemple frappant (la fonction de vérification des mots de passe dans le framework Django) : • Tâche : Implémenter une fonction verify_password. L'approche de l'IA : le code est parfaitement écrit et la logique est irréprochable. Cependant, face à des utilisateurs invalides, l'IA renvoie directement « Faux » par souci d'« efficacité ». • Conséquences en matière de sécurité : Ceci crée une vulnérabilité de type **canal auxiliaire temporel**. Les pirates peuvent déterminer la présence d’un nom d’utilisateur dans le système en détectant des différences minimes dans les temps de réponse. Conclusion : L’IA se concentre souvent uniquement sur la « correction logique » et échoue complètement à comprendre les principes plus profonds de « l’ingénierie de la sécurité » (tels que la comparaison à temps constant). Résumé et recommandations : Cet article sonne l’alarme face à l’engouement actuel pour la programmation en intelligence artificielle. Pour les développeurs : ne faites jamais aveuglément confiance au code généré par l’IA, surtout pour les modules sensibles comme l’authentification, le chiffrement et l’analyse des données. « Ça fonctionne » ne signifie pas « sécurisé ». Pour les entreprises : lors de l'adoption d'outils de programmation d'IA (tels que Cursor, Claude Code), il est obligatoire d'introduire des revues de sécurité humaines ou des analyses de sécurité automatisées (SAST/DAST), et de ne pas se fier uniquement aux tests unitaires. Orientations futures : De simples messages d’avertissement ne peuvent pas résoudre les problèmes de sécurité ; nous avons besoin d’une nouvelle génération d’agents spécifiquement formés à la sécurité. Article original
