Souvent critiquée pour sa sécurité, l’IA peut aussi servir à renforcer la protection des applications. C’est le cas de l’outil mis au point par plusieurs chercheurs universitaires capable de détecter et de corriger du code vulnérable dans les référentiels de logiciel open source. Ainsi, il a recherché dans GitHub une vulnérabilité particulière de traversée de répertoire présente depuis 2010 dans les projets Node.js. Il a réussi à identifier 1756 projets vulnérables, dont certains sont qualifiés de « très influents ». et 63 d’entre eux ont été jusqu’à présent corrigés. La solution propose aux plateformes de genAI telles que ChatGPT de créer et de distribuer automatiquement des correctifs dans les référentiels de code, augmentant ainsi considérablement la sécurité des applications open source.
Mais la recherche, décrite dans un article récemment publié, met également en évidence une sérieuse limitation dans l'utilisation de l'IA, qui devra être corrigée pour rendre la solution efficace. En effet, si l'application automatisée de correctifs par un grand modèle de langage (LLM) améliore considérablement la mise à l’échelle, le correctif peut aussi introduire d'autres bogues. En particulier quand la vulnérabilité existe depuis longtemps, le LLM peut être contaminé et générer du code vulnérable. Les chercheurs pensent donc qu’il faudra éradiquer les modèles de code vulnérables populaires non seulement des projets open source et des ressources des développeurs, mais aussi des LLM, « une tâche qui peut s'avérer très difficile ».
Du mauvais code implanté depuis des années par les pirates
Cela fait des années que les acteurs de la menace introduisent des vulnérabilités dans les référentiels open source, dans l'espoir que, avant la découverte de ces bogues, ils puissent les exploiter pour infiltrer les entreprises qui adoptent des applications open source. Sauf que les développeurs copient et collent sans le savoir du code faillible provenant de plateformes de partage de code comme Stack Overflow, et ce code se retrouve ensuite dans les projets GitHub. Les chercheurs font remarquer que les attaquants n'ont besoin de connaître qu'un seul modèle de code vulnérable pour pouvoir attaquer avec succès de nombreux projets et leurs dépendances en aval. La solution créée par les chercheurs donne la possibilité de découvrir et d'éliminer à grande échelle les failles dans les logiciels open source, et non pas dans un seul projet à la fois comme c'est le cas actuellement.
Cependant, l'outil n'est pas capable de tout scanner et de tout corriger en un passage, car les développeurs créent souvent des référentiels sans contribuer aux projets d'origine. Par conséquent, pour qu'une vulnérabilité soit réellement effacée, tous les référentiels contenant un morceau de code vulnérable devraient être analysés et corrigés. De plus, le modèle de code vulnérable étudié dans le cadre de cette recherche utilise directement le nom du chemin dans l'URL, sans formatage particulier, ce qui facilite la découverte de la faille. C'est sur ce modèle que l'outil se concentre, et les autres emplacements du mauvais code ne sont pas détectés. Les chercheurs présenteront l'outil en août lors d'une conférence sur la sécurité au Vietnam. Ils prévoient de l'améliorer et d'étendre sa portée, notamment en intégrant d'autres modèles de codes vulnérables et en améliorant la génération de correctifs.
Scepticisme des experts
Cependant, Robert Beggs, directeur de la société canadienne de réponse aux incidents DigitalDefence, est sceptique quant à la valeur de l'outil dans son état actuel. « L'idée d'une solution automatisée pour rechercher et corriger les codes malveillants existe depuis un certain temps », souligne-t-il, et il reconnaît aux auteurs le mérite d'avoir tenté de résoudre un grand nombre des problèmes éventuels déjà soulevés. « Cependant, la recherche n'aborde toujours pas certaines questions : savoir par exemple qui est responsable si un correctif défectueux endommage un projet public, ou encore savoir si un gestionnaire de référentiel peut reconnaître qu'un outil d'IA essaye d'insérer une vulnérabilité potentielle dans une application », a-t-il ajouté,
On ne sait pas non plus dans quelle mesure, le cas échéant, l'outil effectuera des tests post-remédiation pour s'assurer que le correctif ne cause pas d'autres dommages. Le document indique qu'en fin de compte, la responsabilité du correctif incombe aux responsables du projet. La partie IA de l'outil crée un correctif, calcule un score CVSS et soumet un rapport aux responsables du projet. « Les chercheurs ont mis au point un excellent processus et je leur reconnais tout le mérite d'avoir développé un outil doté de nombreuses capacités. Cependant, en ce qui me concerne, je ne toucherais pas à cet outil parce qu'il traite de la modification du code source », a déclaré M. Beggs. Et il ajoute : « Je ne pense pas que l'intelligence artificielle ait atteint le niveau nécessaire pour lui permettre de gérer le code source d'un grand nombre d'applications. » Ce dernier admet cependant que les articles universitaires ne sont généralement qu'une première approche.
Les développeurs de logiciels libres, en partie à l’origine du problème
En cours de route, les chercheurs ont également découvert un fait troublant : les développeurs d'applications de logiciels open source ignorent parfois les avertissements sur le manque de fiabilité de certains extraits de code. Le code vulnérable que les chercheurs voulaient corriger dans le plus grand nombre possible de projets GitHub remonte à 2010 et se trouve dans GitHub Gist, un service de partage d'extraits de code. Le code crée un serveur de fichiers HTTP statique pour les applications web Node.js. « Malgré sa simplicité et sa popularité, de nombreux développeurs semblent ignorer que ce modèle de code est vulnérable à l'attaque par traversée de chemin », ont écrit les chercheurs. Même ceux qui ont reconnu le problème se sont heurtés au désaccord d'autres développeurs, qui ont à plusieurs reprises réfuté l'idée de la malignité du code. En 2012, un développeur a déclaré que le code était vulnérable. Deux ans plus tard, un autre développeur a soulevé la même préoccupation concernant la vulnérabilité, mais un autre a affirmé par la suite que le code était sûr, après l'avoir testé. L’affaire s’est répétée en 2018.
Les chercheurs rappellent que la même chose s'est produite en 2016 et dans une question à propos de Stack Overflow qui a totalisé plus de 88 000 vues, un développeur a mis en garde contre une possible vulnérabilité du code. Cependant, il n'a pas été en mesure de vérifier le problème, de sorte que le code a de nouveau été considéré comme sûr. Les chercheurs pensent que le malentendu sur la gravité de la vulnérabilité est dû au fait que, lorsque les développeurs testent le code, ils utilisent généralement un navigateur web ou la commande curl de Linux qui masqueraient tous deux le problème. « Les attaquants ne sont pas obligés d'utiliser des clients standard », ont déclaré les chercheurs. Plus inquiétant, ils ajoutent : « nous avons également trouvé plusieurs cours de Node.js qui utilisaient cet extrait de code vulnérable à des fins d'enseignement ».