La communication intense autour de l’intelligence artificielle générative (IAGén) et l’augmentation de son utilisation – au moins en phase de test – que cela soit par peur de rater quelque chose ou pour apporter une réelle valeur ajoutée, conduit à se poser la question de son utilité dans beaucoup de domaines, et, pourquoi pas, afin d’améliorer la sécurité du code. En particulier, l’IAGén permet-elle d’écrire du code informatique plus sécurisé ? Peut-elle aider à détecter des vulnérabilités dans du code existant ?
Dans cette première partie nous apporterons des éléments de réponse à la première question. Nous traiterons la seconde question dans un autre article.
Aspects humains
Commençons par considérer l’aspect humain du recours à l’utilisation de l’IAGén. Dans une analyse détaillée, dont je recommande vivement la lecture, Simkute expliquent les raisons pouvant conduire à une perte de productivité des programmeurs ayant recours à l’IAGén. Les chercheurs citent notamment : un glissement du rôle des programmeurs de la production à l’évaluation, une restructuration inutile des flux de travail, des interruptions, et une tendance de l’IAGén à rendre les tâches faciles plus faciles et les tâches difficiles plus difficiles. On s’étonne alors moins des résultats d’une étude de Perry, de l’université de Stanford. Ceux-ci montrent que les participants ayant accès à un assistant basé sur un modèle d’IA écrivent un code significativement moins sécurisé que ceux sans accès. Pire, les participants avec un accès à l’assistant étaient plus enclins à croire qu’ils écrivaient du code sécurisé, que ceux sans l’assistant. Cette observation de Perry et al. est corroborée par le travail de Klemmer: l’équipe de chercheurs a interrogé des programmeurs professionnels, et bien que ces derniers se méfient des suggestions des assistants d’IA, il apparait qu’ils surestiment aussi leur propre capacité à examiner les suggestions de ces assistants. L’adoption d’assistants impose donc la mise en place de pratiques de revue de code et d’analyse statique systématiques.
Fiabilité des propositions
Considérant maintenant la qualité des suggestions de l’IAGén, bien que celle-ci produise en général du code fonctionnellement correct, elle introduit également des problèmes de sécurité. Khoury ont montré à travers plusieurs exemples que ChatGPT 3.5 génère souvent du code qui présente des problèmes de sécurité : seuls 5 des 21 cas d’utilisation que les auteurs ont étudiés étaient initialement sécurisés. ChatGPT 3.5 n’a été en mesure de produire du code sécurisé que dans 7 autres cas, et ce, seulement après que les auteurs lui ont explicitement demandé de corriger le code.
Plus récemment, Sivana concluaient leurs expérimentations en soulignant que ChatGPT, en tant que plateforme, générait plus de vulnérabilités de type CWE que le site StackOverflow. Indépendamment, Fu ont montré à travers plusieurs centaines d’échantillons de codes générés par Co-Pilot et trouvés sur GitHub, qu’environ un tiers contient des vulnérabilités communes répertoriées par l’organisme MITRE (certaines faisant partie des 25 plus importantes). Les auteurs recommandent donc aux programmeurs de suivre les meilleures pratiques d’utilisation des outils de génération de code et de toujours vérifier les suggestions de code générées. Des résultats similaires avaient déjà été trouvés par Pearce deux ans plus tôt.
On pourrait multiplier les références à des résultats similaires. C’est ce qu’ont fait Basic et Giaretta dans une étude systématique extensive de la littérature académique sur les IAGén et la sécurité du code informatique. Les modèles concernés sont divers et incluent notamment ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet et Gemini Pro. Les auteurs confirment que plusieurs vulnérabilités clés, telles que les injections SQL et les dépassements de mémoire tampon, peuvent être trouvées dans le code généré par les IAGén. Ils signalent aussi que les risques d’empoisonnement des données d’entraînement peuvent non seulement conduire à une génération de code non sécurisé, mais aussi compromettre la détection des vulnérabilités.
Empoisonnement de l’IA
L’empoisonnement d’un modèle génératif de complétion de code consiste à compromettre l’intégrité de ce modèle en intégrant des échantillons de code malicieux dans les données d’entrainement du modèle. Les attaques par porte dérobée, quant à elles, tentent de dissimuler des déclencheurs à l’intérieur du réseau neuronal profond du modèle pendant la phase d’apprentissage, provoquant la génération de résultats choisis par l’adversaire.
Malgré des progrès importants des modèles de complétion de code, ceux-ci restent vulnérables à ce type d’attaques comme l’ont montré Yan avec CodeBreaker. Pour leur attaque, il n’est pas nécessaire de compromettre un modèle massif pré-entrainé comme BERT ou GPT. En effet ces modèles sont souvent utilisés comme fondation que les victimes règlent finement pour des tâches particulières en utilisant des données spécifiques souvent disponibles publiquement. Il suffit donc alors à l’adversaire de compromettre ces données de réglage fin, ou de téléverser son propre ensemble de données polluées générées avec CodeBreaker. Le code empoisonné généré après l’utilisation de CodeBreaker n’est pas détectable avec des outils de détection de vulnérabilités basés sur des analyses statiques traditionnelles ou des IAGén.
Même si ce type d’attaques est peu probable il pose la question de la provenance de l’outil d’IAGén utilisé et s’inscrit dans la problématique inhérente à l’IAGén actuelle d’obtenir des modèles à la fois sécurisés et exactes.
Importance de la requête
Tout n’est pas si noir cependant et il faut souligner l’importance du choix des incitations (« prompt » en anglais) données à l’IAGén afin d’éviter la génération de code avec des faiblesses potentielles. Götz montrent qu’alors que 65% du code initialement généré par divers outils d’IAGén est considéré comme non sécurisé par un ingénieur qualifié, ces mêmes outils génèrent du code sécurisé lorsqu’ils sont guidés manuellement. Les auteurs concluent qu’une expertise technique, en particulier dans le domaine de la sécurité est requise pour générer du code sécurisé en utilisant des assistants de codage.
Afin d’obtenir les meilleurs résultats possibles il faut donc que la requête envoyée à l’IAGén soit à la fois précise et clairement interprétable par le modèle. Autrement-dit, le programmeur a tout intérêt à se plier aux exigences de la machine et fournir avec le plus de détails possibles, non seulement la tâche que le modèle doit exécuter, mais aussi le contexte qui décrit cette tâche, ainsi que les données d’entrée et les données de sortie attendues. Cela peut se faire en seule fois ou sous forme de chaîne de pensée suivant un raisonnement particulier.
Il n’existe cependant pas de méthode idéale, mais Bruni donnent plusieurs exemples simples d’amélioration des incitations. Selon leurs expérimentations la méthode la plus efficace est, après une première requête, de demander à l’IAGén de revoir le code qu’elle a déjà suggéré pour des vulnérabilités potentielles, et enfin de proposer des corrections. Par exemple :
- Requête 1 : Génère du code Java pour …
- Requête 2 : Examine le code suivant et trouve les problèmes de sécurité :
<réponse fournie à la requête 1> - Requête 3 : À partir des problèmes suivants :
<problèmes signalés par la requête 2>, améliore le code suivant :<réponse fournie à la requête 1>
Cette façon de faire suppose bien évidemment que l’IAGén est capable de détecter des vulnérabilités, mais comme nous le verrons dans l’article suivant ce n’est pas encore le cas aujourd’hui.
Outils spécialisés
Nous pouvons néanmoins nous attendre à l’arrivée de nouveaux outils qui pourraient permettre aux programmeurs d’éviter les écueils de sécurité créés par l’IAGén.
Par exemple l’outil SafeCoder d’ETH Zurich propose un cadre permettant d’améliorer la sécurité du code généré par une IAGén sans sacrifier la fonctionnalité de ce code. L’outil combine le réglage standard des instructions avec un réglage fin – spécifique à la sécurité, en utilisant des exemples de code sûrs et non-sûrs. Pour créer un ensemble de données de qualité, les auteurs ont mis en place un processus automatisé qui extrait les corrections de vulnérabilités vérifiées à partir des modifications de code enregistrées sur GitHub à l’aide d’un filtrage heuristique et d’une analyse statique basée sur l’outil CodeQL. Les résultats montrent que SafeCoder améliore la sécurité du code d’environ 30 % tout en conservant son utilité dans des étalons tels que HumanEval et MMLU. Les auteurs admettent cependant que l’outil n’améliore pas la sécurité de code contenant des vulnérabilités pour lesquelles il n’a pas été entrainé.
En attendant, une façon de procéder pourrait être de combiner un outil d’analyse statique « classique » avec une IAGén en demandant d’abord à l’IAGén de générer le code souhaité, puis en utilisant l’outil d’analyse statique pour analyser ce code. En cas de problème identifié par l’outil, si la correction n’est pas évidente, on peut demander à l’IAGén de modifier celui-ci en indiquant à celle-ci l’erreur précédemment identifiée. On peut recommencer la boucle jusqu’à ce qu’aucun problème ne soit identifié par l’outil d’analyse. Bien évidemment cette procédure fastidieuse pourrait être automatisée dans un cycle de développement logiciel habituel..
Conclusion
La première partie de cet article était dédiée à l’impact de l’IAGén sur la qualité du code en termes de sécurité. En l’état actuel des choses, force est de constater que malgré la capacité étonnante des outils d’IAGén à générer du code informatique, ce code peut souvent présenter des problèmes de sécurité – et ce quelque-soit le modèle choisi. Il convient donc d’être très vigilent avant d’utiliser du code généré par des outils d’IAGén. De plus, même si les IAGén peuvent faciliter certaines tâches de programmation, il n’en reste pas moins qu’elles ne portent pas la responsabilité des conséquences potentiellement négatives de leur « travail », responsabilité qui échoit au programmeur et à son employeur.
Les compétences et connaissances en matière de sécurité des programmeurs – dont la tâche évoluera progressivement de créateur de code à contrôleur de code – restent un atout essentiel. L’arrivée de l’IAGén dans le cycle de développement est peut-être une bonne occasion de renforcer la collaboration entre les équipes de sécurité et de développement en établissant (ou renforçant) des groupes de travail dans lesquels sont alignés des objectifs communs afin d’améliorer la sécurité.
Dans la seconde partie nous nous focaliserons sur l’utilisation de l’IAGén pour la détection de vulnérabilités dans le code.
Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals. Cela t’intéresse de travailler chez Smals? Jette un coup d’œil à leurs offres d’emploi actuelles.