35 CVE en mars : le vibe coding face au mur de la sécurité

En trois mois, le nombre de vulnérabilités officiellement attribuées à du code généré par IA a été multiplié par six. L’étude vient de Georgia Tech. L’alerte vient du NCSC britannique, en keynote à la RSA Conference le 24 mars. Les deux convergent vers le même constat : le vibe coding produit du code qui fonctionne, mais qui n’est pas sûr.

Si vous utilisez l’IA pour développer vos outils internes, votre site ou votre MVP, ces chiffres vous concernent directement.

Les chiffres Georgia Tech : 35 CVE, une multiplication par six

Le projet “Vibe Security Radar”, lancé en mai 2025 par le Systems Software & Security Lab de Georgia Tech, surveille une cinquantaine d’outils de codage assisté par IA. Son fondateur, Hanqing Zhao, a publié les résultats de mars 2026.

Les faits bruts :

• Janvier 2026 : 6 CVE attribuées à du code généré par IA
• Février 2026 : 15 CVE
• Mars 2026 : 35 CVE
• Total depuis mai 2025 : 74 CVE confirmées sur 43 849 advisories analysées

Sur les 35 CVE de mars, 27 proviennent de Claude Code, 4 de GitHub Copilot, 2 de Devin. Les outils les plus utilisés produisent mécaniquement le plus de vulnérabilités.

Selon Infosecurity Magazine, Zhao estime que le chiffre réel est “cinq à dix fois plus élevé” que ce que le radar détecte, soit 400 à 700 cas dans l’écosystème open source. La raison : de nombreux développeurs suppriment les signatures IA de leurs commits avant de les publier.

Les vulnérabilités les plus fréquentes

Une étude complémentaire de DryRun Security a testé trois agents IA (Claude Code, OpenAI Codex, Google Gemini) sur 30 pull requests. Résultat : 87 % contenaient au moins une faille de sécurité, pour un total de 143 problèmes identifiés.

Les types de vulnérabilités qui reviennent systématiquement :

• Contrôle d’accès défaillant : des endpoints sensibles sans authentification, présents dans tous les agents testés
• Secrets codés en dur : des clés JWT ou des tokens API inscrits directement dans le code source
• Validation côté client uniquement : l’IA génère des vérifications dans le navigateur mais oublie le serveur
• OAuth mal implémenté : paramètres de sécurité manquants, comptes liés sans vérification
• Rate limiting absent : le middleware est défini mais jamais connecté aux routes

James Wickett, CEO de DryRun Security, résume : “Les agents IA produisent du logiciel fonctionnel à une vitesse incroyable, mais la sécurité ne fait pas partie de leur réflexion par défaut.”

Ce constat rejoint les 30 CVE en 60 jours déjà documentées sur le protocole MCP : les outils IA génèrent du code qui passe les tests fonctionnels mais échoue aux audits de sécurité.

Le NCSC UK sonne l’alarme : six commandements pour le vibe coding

Le 24 mars, Richard Horne, directeur du National Cyber Security Centre britannique, a consacré sa keynote à la RSA Conference au vibe coding. Son message, publié sur le site du NCSC : l’opportunité est réelle, mais les garde-fous sont absents.

Horne a présenté six commandements pour sécuriser le développement assisté par IA :

1. Secure by default : les modèles IA doivent générer du code durci dès la première sortie
2. Trust but verify : exiger une traçabilité vérifiable de l’origine des modèles
3. Revue de code par IA : utiliser l’IA pour auditer le code IA et humain
4. Garde-fous déterministes : imposer des règles strictes limitant les capacités du code généré
5. Plateformes d’hébergement sécurisées : des environnements sandboxés protégeant contre le code compromis
6. Hygiène de sécurité automatisée : documentation, tests, fuzzing et threat modeling pilotés par IA

Le point clé : le NCSC ne demande pas d’arrêter le vibe coding. Il demande aux éditeurs d’outils IA d’intégrer la sécurité dans leurs modèles, pas de la déléguer à l’utilisateur final.

Ce que cela change pour votre PME

Si vous développez avec l’IA – que ce soit pour un prototype, un outil interne ou une application client – ces alertes appellent des actions concrètes.

Le code IA n’est pas un livrable. C’est une première ébauche. Comme l’a montré le parcours réel d’un solopreneur passant du prototype à la production, le vibe coding accélère le démarrage mais ne remplace pas la validation professionnelle.

La responsabilité reste la vôtre. L’AI Act européen entre en vigueur en août 2026. Le code déployé en production est sous la responsabilité de celui qui le met en ligne, pas de l’outil qui l’a généré. Une CVE dans votre application SaaS, c’est votre problème juridique et commercial.

Le ratio coût/risque a changé. Avec 87 % des pull requests IA contenant des failles, ne pas auditer revient à jouer à la roulette. Le coût d’un audit de sécurité est une fraction du coût d’une fuite de données ou d’une violation de conformité.

Cinq actions concrètes avant votre prochain déploiement

1. Passez chaque sortie IA dans un linter de sécurité. Des outils comme Semgrep, Bandit (Python) ou Brakeman (Ruby) détectent les failles courantes en quelques secondes. Intégrez-les dans votre pipeline CI/CD.

2. Interdisez les secrets dans le code. Configurez un outil de détection de secrets (gitleaks, truffleHog) en pre-commit hook. Les clés API et tokens codés en dur sont la première vulnérabilité que l’IA introduit.

3. Validez côté serveur, toujours. Si l’IA génère une validation de formulaire, vérifiez qu’elle existe aussi côté back-end. La validation côté client seule est une non-protection.

4. Faites relire le code critique par un humain. L’IA est un excellent assistant de rédaction, pas un architecte sécurité. Les garde-fous de l’agentic engineering montrent que même les pipelines automatisés les plus avancés conservent une boucle de validation humaine.

5. Documentez l’origine du code. Notez quels fichiers ont été générés par IA. En cas d’incident, cette traçabilité accélère l’audit et limite l’exposition.

Un signal d’alarme, pas un arrêt de mort

Le vibe coding n’est pas condamné par ces chiffres. Il est confronté à sa première crise de maturité. Georgia Tech documente le problème. Le NCSC propose un cadre. Les outils de sécurité automatisés progressent.

Pour les PME qui utilisent l’IA dans leur développement, le message est clair : continuez, mais ne déployez jamais du code IA sans l’avoir passé au crible. Le coût d’un linter est nul. Le coût d’une CVE en production ne l’est pas.