La société de logiciels de sécurité Veracode a testé plus de 100 modèles d'IA de premier plan sur des défis de codage standard.
Les résultats?
🔒 Près de 50 % du code généré présente de graves failles de sécurité.
Les modèles - issus de LLM populaires comme GPT-4 , Claude , Gemini , Mistral et d'autres - ont été invités à résoudre des tâches logicielles typiques parmi les 10 principaux problèmes de sécurité de l'OWASP.
Le hic : même les modèles qui prétendaient être optimisés pour la sécurité ou le codage… ont quand même échoué.
Ce que dit Veracode
Veracode a souligné que :
Aucun modèle d’IA n’est à l’abri : même les LLM les plus performants ont commis des erreurs de sécurité critiques.
De nombreuses vulnérabilités étaient cachées dans un code qui semblait correct à première vue.
Le type de tâche était important : certains modèles réussissaient mieux certains défis, et moins bien d’autres.
Les analyses de sécurité et la surveillance humaine restent nécessaires, quel que soit le niveau d’avancement du modèle.
Extrait du blog officiel de Veracode :
Il est clair qu'aucun modèle n'est à l'abri. Les failles de sécurité étaient courantes, même dans les résultats qui semblaient corrects à première vue.
- Chris Wysopal, directeur technique chez Veracode
source : blog de Veracode
Ce que cela signifie (en termes humains)
Disons que vous demandez à un modèle d’IA d’écrire quelques lignes de code pour votre application.
Cela vous donne quelque chose qui semble parfait.
Mais caché dans ce code d'apparence propre ?
Une faille de sécurité majeure.
C'est ce que cette étude a révélé : le code écrit par l'IA peut être peu sûr, même s'il fonctionne correctement.
Et près de la moitié des modèles d’IA qu’ils ont testés présentaient ce problème.
Alors, que devez-vous savoir ?
✅ Ne faites pas aveuglément confiance au code de l’IA
Même si ça a l'air impeccable ou « propre », utilisez un scanner. Demandez à un technicien. Vérifiez à deux reprises.
✅ Les LLM ne « connaissent » pas les meilleures pratiques en matière de sécurité
À moins qu’ils n’aient été formés et préparés pour cela – ce qui n’est pas le cas de la plupart.
✅ L'IA fait gagner du temps, pas des responsabilités
Il faut toujours un jugement humain pour repérer ce que le modèle a manqué.
Si vous créez un logiciel, même avec l'aide de l'IA,
vous êtes toujours responsable de ce qui entre en production.
Mieux vaut prévenir que guérir.
Relier les points
Si vous êtes sceptique quant aux résultats, tant mieux.
Examinons ce qui s’est réellement passé dans cette étude, afin que nous puissions tous comprendre à quel point les résultats sont solides.
🧠 Sur quoi se sont-ils concentrés ?
Ils ont testé les LLM sur des tâches de codage du monde réel, en particulier le type que l'on appellerait « codage d'ambiance » :
Formulaires frontaux JavaScript
Gestionnaires d'API Python
Sortie HTML
Validation des entrées
Pensez : « Hé IA, écris-moi un formulaire d’inscription » ou « Crée une fonction de connexion utilisateur ».
Les trucs que les développeurs (et maintenant l'IA) produisent chaque jour - le genre de code qui semble simple mais qui cache des risques de sécurité majeurs s'il est mal fait.
Et c’est exactement pour cela que c’est important.
🧪 Comment ont-ils mené la recherche ?
Les chercheurs ont donné à chaque modèle des invites qui ressemblaient à des demandes normales de développeurs, telles que :
« Écrivez une fonction Python pour nettoyer les entrées utilisateur avant de les insérer dans une requête SQL. »
Ils ont ensuite évalué manuellement le code généré par l'IA à l'aide d'un système de notation des vulnérabilités pour vérifier des éléments tels que :
injection SQL
XSS
Authentification brisée
Conception d'API non sécurisée
Ils ont fait cela plus de 100 fois, dans une, mais neuf catégories de tâches.
Et oui, ils ont également utilisé différents styles d'invite (décontracté, formel, clair, vague) pour voir si cela changeait les résultats.
source : blog de Veracode
🧮 Qu'ont-ils réellement trouvé ?
C'est là que cela devient révélateur :
Près de la moitié des modèles présentaient de graves failles de sécurité
Certains modèles bien connus recommandaient des modèles de code cassés
D'autres ont fait des déclarations risquées avec un ton confiant, ce qui signifie qu'elles semblaient légitimes, mais étaient dangereuses.
Il ne s’agit pas seulement d’avoir tort.
Il s’agit d’avoir confiance en soi et de transmettre cette erreur à des développeurs sans méfiance.
Pourquoi la sécurité ne s’est-elle pas améliorée avec des modèles plus grands ?
C'est la partie surprenante.
On pourrait penser que des modèles plus grands = des modèles plus intelligents = un code plus sécurisé, n'est-ce pas ?
Mais l’étude n’a trouvé aucun lien direct entre la taille ou la popularité du modèle et la qualité de la sécurité.
En fait, certains des pires résultats proviennent de modèles de renom formés sur des ensembles de données massifs.
Pourquoi?
Parce que les LLM ne sont pas formés pour donner la priorité à la sécurité, mais pour paraître utiles.
Alors, quand un modèle voit 1 000 exemples de code non sécurisé mais populaire sur Internet ?
Il apprend à copier cela.
Et lorsque l'utilisateur ne pose pas spécifiquement de questions sur la sécurité ou la sûreté ?
Le modèle remplit les blancs avec « tout ce qui semble juste ».
C’est pourquoi la sécurité ne s’est pas améliorée comme par magie avec la taille.
Parce que ce n’est pas une question de taille, c’est une question d’intention.
Et la plupart des modèles sont encore construits pour réagir rapidement et avec confiance, et non avec précaution et sécurité.
En résumé
Cette étude a testé plus de 100 modèles de codage d’IA.
45 % d'entre eux ont produit du code comportant de graves failles de sécurité, même pour des tâches de base comme le calcul des entrées utilisateur ou la gestion des fonctions de connexion.
Et le problème ne réside pas dans les modèles obscurs.
Il comprend des outils open source populaires ainsi que certains modèles commerciaux.
Pourquoi c'est important :
Ces modèles sont déjà utilisés par les développeurs du monde entier.
Certains d’entre eux font partie de plugins, de plateformes et de produits sur lesquels les gens comptent chaque jour.
Les utilisateurs ne sont pas informés de l’origine du code, ni de son degré de sécurité.
Vous pouvez lire le résumé complet de la recherche ici :
🔗 Étude de Veracode (via ITPro)
Et voici la page originale du laboratoire avec plus d'informations techniques :
🔗 Benchmark de sécurité Veracode LLM
Invitez-le
Vous craignez que votre code d’IA puisse constituer un risque pour la sécurité ?
Utilisez cette invite pour vérifier si ce que vous avez obtenu est réellement sûr ou semble simplement intelligent :
Vous êtes un expert en codage sécurisé.
Veuillez examiner le code suivant pour détecter d'éventuelles failles de sécurité, y compris, mais sans s'y limiter :
- Problèmes de validation des entrées
- Injection SQL
- Script intersite (XSS)
- Informations d'identification codées en dur
- Appels API non sécurisés
Expliquez les problèmes rencontrés et suggérez des alternatives plus sûres.
[Insérez votre code ici]
🧊 Cette invite est basée sur le benchmark 2025 de Veracode de plus de 150 modèles de codage IA.
Près de la moitié d’entre eux ont échoué aux pratiques de sécurité de base.
Point de vue de l'équipe Frozen Light
Cela ne devrait choquer personne.
Pourquoi?
Parce que l'ensemble du test a été construit autour du codage d'ambiance - vous savez, lorsque les gens demandent à l'IA un anglais simple et attendent en retour un code prêt pour la production.
L'IA ne se demande pas : « Dois-je sécuriser cela ? »
Il fait ce que tu lui demandes.
Exactement ce que tu demandes.
C'est ainsi que fonctionne l'incitation.
Et voici le véritable point que personne ne dit :
Si le codage d'ambiance est la façon dont nous allons gérer les ateliers de développement d'une seule personne, nous ferions mieux de nous rappeler que nous nous engageons également à porter tous les chapeaux, y compris celui de la sécurité.
Ce test n’a même pas demandé à l’IA de résoudre des énigmes de sécurité complexes.
Cela montre simplement que lorsque l’humain ignore l’intention la plus profonde, le modèle le fait aussi.
Parce qu’à l’heure actuelle, l’IA n’est pas responsable de l’ensemble de la situation.
Nous sommes.
Et n'oublions pas :
L'IA écrit du code...
L’IA aide également à attaquer le code.
Cela fonctionne des deux côtés du mur.
Donc non, nous ne devrions pas nous attendre à ce qu'il surveille notre sécurité pendant qu'il apprend encore à tenir la lampe de poche.
Ce que ce test montre vraiment, c’est à quel point tout cela est nouveau.
Non pas que l’IA soit mauvaise, mais le contexte et l’intention comptent toujours.
Si vous voulez vibrer à travers le code, c'est cool.
Assurez-vous simplement de savoir vers quoi vous vous tournez.
