Les LLM génèrent du code C/C++ vulnérable. Voilà le scoop d’une étude récente qui renverse toutes les certitudes des développeurs sur les assistants IA. On a tous acheté le buzz : un prompt, et bim, des snippets propres et fonctionnels, prêts pour la prod. Des outils comme GPT-4o, Claude, voire les champions open source comme Llama, sont partout dans les revues de code, le prototypage, la génération de boilerplate. Mais cette analyse, qui brandit le solveur SMT Z3 comme un scalpel chirurgical, révèle la gangrène en dessous.
Les attentes ? Au zénith. Les LLM cartonnent aux benchmarks, pondent du Python élégant, déboguent en live. Le C/C++, ce monstre bas niveau où un pointeur égaré peut cramer votre serveur, tout le monde pensait qu’ils avaient monté en gamme. Faux. Taux de vulnérabilités à 55,8 % sur 3 500 échantillons. GPT-4o en tête à 62,4 %. Et le clou : les outils du secteur en loupent 97,8 %.
Voici la citation qui tape comme un buffer overflow :
Les grands modèles de langage (LLM) montrent une propension systémique à générer du code C/C++ syntaxiquement valide mais fondamentalement insecure. Une analyse rigoureuse par vérification formelle via le solveur SMT Z3 expose un mode de défaillance critique : 55,8 % du code C/C++ issu des LLM abrite des vulnérabilités de sécurité vérifiables.
C’est brutal.
Pourquoi les LLM butent-ils sur la sécurité C/C++ ?
Ne cherchez pas la paresse chez les modèles. Plongez dans l’architecture : c’est les données d’entraînement, empoisonnées dès le départ. Milliards de lignes raclées sur GitHub, Stack Overflow, et compagnie. Du code réel ? Rempli de buffer overflows, variables non initialisées, conditions de course. Les LLM apprennent les patterns, pas les invariants. Ils copient la syntaxe, le flux, mais zappent le pourquoi : ce décalage d’un dans strcpy, ce n’est pas du style, c’est une porte ouverte aux attaquants.
L’auto-vérification ? Succès à 78,7 % pour repérer les bugs. Impressionnant, hein ? Erreur. Détecter reste superficiel — « hé, cette boucle risque de déborder ». Corriger ? Bof. La génération reste bancale car l’objectif prioritaire chasse la fluidité, pas les preuves de sécurité. C’est comme former un chef sur des recettes fast-food et lui demander des étoiles Michelin en sécu.
Et les analyseurs statiques ? CodeQL, Semgrep, Cppcheck : ils chassent les patterns connus. Les LLM inventent des variantes inédites de catastrophes, des ruptures d’invariants subtiles que Z3 attrape en modélisant symboliquement tous les chemins. Six mois à éplucher 3 500 artefacts issus de prompts du style « implémentez une copie de chaîne sécurisée » ou « parsez une entrée non fiable ». Boum — 1 055 exploits constatés.
Comment le solveur Z3 a-t-il fait sauter le couvercle ?
La vérification formelle, ce n’est pas le grep de papa. Z3 traduit le C/C++ en contraintes logiques, pose la question : « L’indice peut-il virer négatif ? Débordement par ici ? » Le solveur épuise les chemins, crache des témoins — des entrées précises qui font tout péter. Buffer overflow ? Voici la séquence d’octets qui détourne le flux de contrôle.
Les outils traditionnels ? Heuristiques, règles. Ils ratent les dérapages systémiques, comme oublier les checks null dans du code architecturalement clean mais mortel. Les LLM excellent en syntaxe, flanchent en sémantique.
Mon avis — l’angle unique que le papier ne donne pas : ça rappelle les guerres des compilateurs C des années 80. À l’époque, pas de vérif de bornes native ; le ver Morris a surfé sur des buffer overflows jusqu’à ARPANET. Les LLM ? Éleveurs de vers modernes, formés sur les exploits d’hier, aveugles aux défenses de demain. L’histoire ne se répète pas, mais elle rime — en silicium.
Cela enterre-t-il la génération de code LLM pour les vrais projets ?
Réponse courte : pas encore, mais presque. Les pipelines intégrant des outils style Copilot ? Vous jouez au casino pour les apps fina
