WildCode Revisited: A Comprehensive Empirical Study on the Security of LLM-Generated Code
Cette étude valide empiriquement que le code réel généré par ChatGPT manque fréquemment de sécurité, confirmant les conclusions antérieures d'expériences synthétiques tout en révélant que les utilisateurs demandent rarement des précisions sur les préoccupations de sécurité lorsqu'ils sollicitent du code.
Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous avez un assistant très talentueux, incroyablement rapide, mais quelque peu naïf, capable de rédiger du code informatique pour vous. Vous lui demandez une recette, et il prépare un repas en quelques secondes. Mais attention : il a appris à cuisiner en lisant des millions de livres de cuisine, mais il n'a jamais mis les pieds dans une cuisine et ne comprend pas vraiment pourquoi certains ingrédients pourraient être dangereux s'ils sont mal mélangés.
Ce document, « WildCode Revisited », est comme une inspection sanitaire massive et réelle de la nourriture que cet assistant sert. Au lieu de demander à l'assistant de cuisiner un repas de test spécifique dans un laboratoire (ce que faisaient la plupart des études précédentes), les chercheurs sont allés dans le « monde réel ». Ils ont examiné plus de 82 000 conversations réelles où des gens ordinaires ont demandé à cette IA (ChatGPT) d'écrire du code pour eux.
Voici ce qu'ils ont trouvé, décomposé en analogies simples :
1. La cuisine « sauvage » vs La cuisine de test
La plupart des études précédentes étaient comme une émission de cuisine où le chef est invité à « Faire une lasagne parfaite ». Le chef sait que c'est un test, alors il fait de son mieux.
Cette étude a examiné le jeu de données WildChat, qui est comme un restaurant ouvert 24h/24 où les clients commandent ce qu'ils veulent, dans la langue qu'ils parlent. Les chercheurs ont découvert que lorsque les gens demandent simplement du code sans spécifier de consignes de sécurité, l'IA sert souvent des plats pleins de trous. C'est comme si l'assistant oubliait de verrouiller la porte arrière, laissant la maison grande ouverte aux cambrioleurs (hackers).
2. La « fuite » de sécurité
Les chercheurs ont agi comme des inspecteurs de sécurité, scannant le code à la recherche d'erreurs courantes. Ils ont découvert que l'IA sert fréquemment :
- Des verrous faibles : Utiliser de vieux verrous faciles à crocheter (chiffrement faible) au lieu de modèles modernes et incassables.
- Des fenêtres ouvertes : Laisser les fenêtres ouvertes pour que des inconnus puissent entrer (vulnérabilités d'injection SQL).
- Des ingrédients factices : L'IA invente parfois des « ingrédients » (bibliothèques logicielles) qui n'existent pas réellement. Si vous essayez de les utiliser, votre programme plante. Pire encore, un acteur malveillant pourrait créer un ingrédient factice portant le même nom et y glisser un virus.
- Du verre fragile : Le code est souvent fait d'un verre qui se brise si on le regarde d'une certaine manière (problèmes de sécurité de la mémoire), surtout dans des langages comme le C/C++.
La grande surprise : Même si le code semble fonctionner (il s'exécute), il est souvent rempli de pièges de sécurité. L'IA est excellente pour faire en sorte que les choses fonctionnent, mais elle est médiocre pour faire en sorte qu'elles soient sûres.
3. Les clients ne demandent pas la sécurité
Les chercheurs ont également examiné ce que les clients (les utilisateurs) demandaient.
- Le groupe « Réparez-le, c'est tout » : La plupart des gens voulaient simplement que le code fonctionne ou voulaient corriger un bug. Ils étaient comme des clients disant : « Faites-moi un sandwich », sans se soucier de savoir si le pain contient de la moisissure.
- Le silence sur la sécurité : Très peu de personnes ont demandé : « Est-ce que ce code est sûr ? » ou « Y a-t-il une porte dérobée ? ». C'est comme si les clients commandaient de la nourriture sans jamais demander : « Est-ce frais ? » ou « Y a-t-il un inspecteur sanitaire ici ? ».
- Le bug de la « Sécurité » : Même lorsque les utilisateurs demandaient du code sécurisé, l'IA n'écoutait pas toujours, et les utilisateurs ne vérifiaient pas toujours si l'IA avait réellement rendu le code sécurisé.
4. Pouvons-nous mieux entraîner l'assistant ? (L'expérience du « Prompt »)
Les chercheurs ont essayé quelques astuces pour voir s'ils pouvaient amener l'IA à cuisiner des repas plus sûrs. Ils ont testé :
- Le jeu de rôle : Dire à l'IA : « Agis comme un expert en sécurité. » (Résultat : Pas très efficace. L'IA faisait semblant d'être un expert mais continuait de commettre des erreurs.)
- Les étiquettes d'avertissement : Dire à l'IA : « Ce code présente des problèmes de sécurité. » (Résultat : Un peu mieux, mais ce n'est pas un miracle.)
- La « fiche de triche » : Donner à l'IA une liste d'erreurs spécifiques trouvées par un scanner de sécurité et dire : « Corrige ces erreurs. » (Résultat : C'est ce qui a le mieux fonctionné. Lorsque l'IA se voyait montrer exactement ce qui n'allait pas, elle corrigeait le code bien mieux.)
5. Le jeu du « Refus »
Parfois, l'IA refuse d'écrire du code si elle pense que la demande est dangereuse (comme écrire un virus). Les chercheurs ont découvert que les utilisateurs pouvaient parfois piéger l'IA pour qu'elle écrive du code dangereux en posant la même question d'une manière légèrement différente. C'est comme un enfant qui demande : « Puis-je avoir un biscuit ? » et reçoit un « Non », puis demande : « Puis-je avoir un biscuit si j'ai faim ? » et reçoit un « Oui ». Les filtres de sécurité de l'IA ne sont pas aussi robustes qu'on l'espérerait.
Le mot de la fin
Cette étude est un rappel à la réalité. Elle montre que, bien que l'IA soit incroyable pour générer du code rapidement, elle n'est actuellement pas un substitut sûr à un expert humain en sécurité.
- Le Code : Contient souvent des pièges cachés et des points faibles.
- Les Utilisateurs : Demandent rarement des comptes sur la sécurité, supposant que l'IA sait ce qu'elle fait.
- La Solution : Nous ne pouvons pas simplement dire à l'IA « sois prudente ». Nous devons lui donner des retours spécifiques sur ce qui ne va pas (comme un scanner de sécurité) pour l'aider à colmater les brèches.
L'étude conclut que nous sommes pressés d'utiliser ces outils, mais que nous le faisons sans vérifier les verrous des portes. Nous devons être beaucoup plus prudents et proactifs concernant la sécurité avant de laisser l'IA écrire le code qui fait fonctionner notre monde.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.