LLM : une approche (im)parfaitement humaine du codage sécurisé ?

Une version de cet article a été publiée dans Dark Reading. Il a été mis à jour et syndiqué ici.

‍

Dès les premiers échos de l'engouement pour les derniers outils d'IA révolutionnaires, les développeurs comme les curieux du code les ont utilisés pour générer du code en un clic. Les experts en sécurité ont rapidement souligné que, dans de nombreux cas, le code produit était de piètre qualité et vulnérable, et qu'entre les mains de personnes peu sensibilisées à la sécurité, il pourrait entraîner une avalanche d'applications et de développements web non sécurisés pour les consommateurs.

Et puis, il y a ceux qui possèdent suffisamment de connaissances en sécurité pour l'utiliser à des fins, disons, malveillantes. Pour chaque prouesse impressionnante de l'IA, il semble y avoir une contrepartie où la même technologie est utilisée à des fins néfastes. Hameçonnage, vidéos truquées (deepfakes), création de logiciels malveillants, piratage amateur… ces activités perturbatrices sont réalisables beaucoup plus rapidement, avec des barrières à l'entrée réduites.

Il existe certainement beaucoup de contenu racoleur vantant ces outils comme révolutionnaires, ou du moins supérieurs aux compétences humaines « moyennes ». S'il semble inévitable que l'IA de type LLM transforme notre approche du travail, et pas seulement dans le développement logiciel, nous devons prendre du recul et considérer les risques au-delà des gros titres.

En tant qu'assistant de codage, ses défauts sont peut-être son trait le plus « humain ».

Les mauvaises pratiques de codage dominent ses solutions privilégiées

ChatGPT ayant été entraîné sur des décennies de code et de bases de connaissances existantes, il n'est pas surprenant que, malgré ses merveilles et ses mystères, il souffre des mêmes pièges courants que les humains lorsqu'ils naviguent dans le code. Les mauvaises pratiques de codage sont la norme, et il faut toujours un pilote conscient des enjeux de sécurité pour générer des exemples de code sécurisés en posant les bonnes questions et en utilisant le bon « prompt engineering ».

Même dans ce cas, rien ne garantit que les extraits de code fournis soient précis et fonctionnels du point de vue de la sécurité ; la technologie est sujette aux hallucinations, allant jusqu'à inventer des bibliothèques inexistantes lorsqu'on lui demande d'effectuer certaines opérations JSON spécifiques, comme l'a découvert Mike Shema. Cela pourrait conduire à du « squatting par hallucination » de la part d'acteurs malveillants, qui seraient ravis de créer des logiciels malveillants déguisés en bibliothèque fabriquée, recommandée avec une totale confiance par ChatGPT.

En fin de compte, nous devons faire face à la réalité : nous n'avons généralement pas exigé des développeurs qu'ils soient suffisamment sensibilisés à la sécurité, et nous ne les avons pas non plus préparés adéquatement, en tant qu'industrie, à écrire du code sécurisé par défaut. Cela se reflète dans l'énorme quantité de données d'entraînement fournies à ChatGPT, et nous pouvons nous attendre à des résultats de sécurité tout aussi médiocres de la part de ses sorties, du moins au début. Les développeurs doivent être capables d'identifier les failles de sécurité et soit de les corriger eux-mêmes, soit de concevoir de meilleurs prompts pour obtenir un résultat plus robuste.

La première étude utilisateur à grande échelle examinant comment les utilisateurs interagissent avec un assistant de codage IA pour résoudre diverses fonctions liées à la sécurité - menée par des chercheurs de l'Université de Stanford - soutient cette idée, avec une observation concluant :

« Nous avons observé que les participants ayant accès à l'assistant IA étaient plus susceptibles d'introduire des vulnérabilités de sécurité pour la majorité des tâches de programmation, tout en étant plus enclins à qualifier leurs réponses non sécurisées de sécurisées par rapport à ceux de notre groupe témoin. »

Cela témoigne d'un niveau de confiance par défaut envers les outils de codage IA, supposant qu'ils produisent toujours un code intrinsèquement sécurisé, alors que ce n'est pas le cas.

Entre cela et les menaces inévitables liées à l'IA qui imprégneront notre avenir, les développeurs doivent plus que jamais affiner leurs compétences en sécurité et placer la barre plus haut en matière de qualité de code, quelle que soit son origine.

L'enfer des violations de données est pavé de bonnes intentions

Il n'est pas surprenant que les assistants de codage IA soient populaires, surtout lorsque les développeurs font face à des responsabilités croissantes, des délais serrés et que les ambitions d'innovation de leur entreprise reposent sur leurs épaules. Cependant, même avec les meilleures intentions, un manque de sensibilisation concrète à la sécurité lors de l'utilisation de l'IA pour coder mènera inévitablement à des problèmes de sécurité flagrants. Tous les développeurs utilisant des outils d'IA/ML généreront plus de code, et son niveau de risque dépendra de leur propre niveau de compétence. Les organisations doivent être parfaitement conscientes que des personnes non formées généreront certes du code plus rapidement, mais qu'elles augmenteront également la vitesse d'accumulation de la dette technique de sécurité.

Même notre test préliminaire (avril 2023) avec ChatGPT a révélé qu'il génère des erreurs très basiques pouvant avoir des conséquences dévastatrices. Lorsque nous lui avons demandé de créer une routine de connexion en PHP utilisant une base de données MySQL, le code fonctionnel a été généré rapidement. Cependant, il a opté par défaut pour le stockage des mots de passe en texte clair dans une base de données, le stockage des identifiants de connexion à la base de données dans le code, et l'utilisation d'un modèle de codage pouvant entraîner une injection SQL (bien qu'il ait effectué un certain niveau de filtrage sur les paramètres d'entrée et renvoyé des erreurs de base de données). Autant d'erreurs de débutant, quel que soit le critère :
‍

‍
Des prompts supplémentaires ont permis de corriger ces erreurs, mais il faut des connaissances approfondies en sécurité pour rectifier le tir. L'utilisation incontrôlée et généralisée de ces outils ne vaut pas mieux que de laisser des développeurs juniors travailler sur vos projets ; si ce code sert à construire une infrastructure sensible ou à traiter des données personnelles, nous sommes face à une bombe à retardement.

Bien sûr, tout comme les développeurs juniors améliorent indéniablement leurs compétences au fil du temps, nous nous attendons à ce que les capacités d'IA/ML s'améliorent. Dans un an, il ne fera peut-être plus d'erreurs de sécurité aussi évidentes et simples. Cependant, cela aura pour effet d'augmenter considérablement les compétences en sécurité nécessaires pour traquer les erreurs plus graves, cachées et non triviales qu'il risque toujours de produire.

Nous restons mal préparés à détecter et corriger les vulnérabilités de sécurité, et l'IA creuse l'écart

Bien que l'on parle de « shifting left » depuis de nombreuses années, la réalité est que la plupart des organisations souffrent d'un manque flagrant de connaissances pratiques en sécurité au sein de leurs équipes de développement. Nous devons redoubler d'efforts pour leur fournir les outils et la formation adaptés pour les accompagner.

En l'état actuel, nous ne sommes pas préparés aux failles de sécurité classiques, sans parler des nouveaux risques liés à l'IA, tels que l'injection de prompts ou le « hallucination squatting », qui constituent des vecteurs d'attaque inédits prêts à se propager à une vitesse fulgurante. Si les outils de codage par IA représentent l'avenir de l'arsenal des développeurs, il est urgent de leur apprendre à maîtriser ces outils de productivité en toute sécurité.

‍