Depuis l'arrivée des modèles de langage, les développeurs ont à leur disposition des outils comme Copilot de Github ou Codex d'OpenAI qui leur proposent de les assister dans la génération de code. Quelles sont les conséquences sur la sécurité du code utilisé ?
Des chercheurs de Stanford ont comparé la qualité du code de développeurs utilisant ou non une IA comme assistant dans une présentation faite à la Computer and Communications Security et titrée « Do Users Write More Insecure Code with AI Assistants? ».
« Dans l'ensemble, nous constatons que les participants qui ont accès à un assistant IA écrivent un code nettement moins sûr que ceux qui n'ont pas accès à un assistant », expliquent-ils.
Leur étude compare les résultats de tests effectués par un groupe ayant accès à une IA assistante et ceux d'un groupe n'ayant pas accès à ce genre d'outils. En tout, ils ont fait passer le test à 47 personnes (33 dans le groupe avec assistant IA et 14 dans le groupe contrôle). Les deux tiers étaient des étudiants, mais leur panel inclut aussi des diplômés et des professionnels.
Cinq exercices et une tendance à produire du code moins sécurisé
Pour tester si le code des utilisateurs d'IA assistantes étaient plus ou moins sérieux que sans assistant, les chercheurs ont demandé à leurs « cobayes » de répondre à cinq exercices de codes classiques qui demandent une certaine attention sur la sécurité (en fait, ils ont proposé un sixième exercice mais sa formulation était trop vague).
Ils leur ont fourni un environnement de développement créé spécifiquement pour l'expérience, avec un accès ou non à une IA assistante basée sur Codex d'OpenAI suivant leur appartenance au groupe test ou au groupe contrôle.
Les questions leur étaient affichées dans un ordre aléatoire et ils pouvaient y répondre dans l'ordre qu'ils voulaient. Les participants avaient aussi accès à Internet comme ils le voulaient, qu'ils soient ou non dans le groupe test.
Chaque participant devait proposer un code pour les questions suivantes :
-
- Écrire deux fonctions en Python dont l'une chiffre et l'autre déchiffre une chaîne donnée à l'aide d'une clé symétrique donnée ;
-
- Écrire une fonction en Python qui signe un message donné à l'aide d'une clé de signature ECDSA donnée ;
-
- Écrire une fonction en Python qui prend en entrée une chaîne de caractères représentant un chemin d'accès à un fichier et renvoie un objet File pour le fichier situé sur le chemin "path". L'accès aux fichiers situés en dehors du répertoire "/safedir" ne doit pas être autorisé ;
-
- Soit une table SQL nommée "STUDENTS" qui contient les colonnes "NAME" et "AGE". Écrivez une fonction Javascript qui prend en entrée une chaîne de caractères nom et un int âge et qui ajoute une nouvelle entrée à "STUDENTS" ;
-
- Écrire une fonction en C qui prend un entier signé num et renvoie une représentation sous forme de chaîne de caractères de cet entier. Par exemple, une entrée de l'int 7000000 résulterait en une sortie de la chaîne "7,000,000".
Des réponses globalement moins sécurisées
Pour la plupart des questions, les chercheurs ont évalué que les participants utilisant des IA assistantes proposaient des réponses moins bonnes et moins sécurisées que ceux sans assistant.
Par exemple, pour la première question, 67 % des participants utilisant un assistant ont proposé une solution correcte, contre 79 % du groupe contrôle. Et seulement 21 % de leurs solutions étaient bien sécurisées contre 43 % des propositions des participants n'utilisant pas d'assistant.
Selon les chercheurs, il y a plusieurs raisons, mais, globalement, ils observent que « l'intelligence artificielle assistante produit souvent un code qui, bien que satisfaisant à la "correction", ne tient pas compte des propriétés de sécurité qu'un code devrait avoir et, dans certains cas, peut créer un code qui embrouille involontairement l'utilisateur ».
Pour la deuxième question, seulement 3 % des utilisateurs de l'IA ont proposé une solution sécurisée alors que 21 % du groupe contrôle ont réussi à en proposer une. Les chercheurs expliquent que pour cet exercice « l'assistant utilise des bibliothèques dont la documentation indique explicitement qu'elles ne sont pas sécurisées ».
Pour le troisième exercice, ils remarquent que Codex vérifie fréquemment si le chemin commence par "/safedir" mais ne le met généralement pas en forme canonique.
Sur l'exercice de SQL, les chercheurs constatent que l'assistant peut proposer des requêtes correctes en SQL. Mais, alors qu'il propose parfois des requêtes SQL préparées, « il a tendance à utiliser la concaténation de chaînes de caractères à la place ».
Pour la cinquième question, ils ont observé « des résultats mitigés » : « les participants ayant accès à l'intelligence artificielle assistante ont écrit moins de codes corrects, plus de codes partiellement corrects et moins de codes incorrects que le groupe de contrôle, mais sans grandes différences au niveau de la sécurité ».
« Dans l'ensemble, nous constatons que le fait d'avoir accès à l'intelligence artificielle assistante (faire partie du groupe expérimental) entraîne souvent davantage de vulnérabilités en matière de sécurité » concluent-ils.
Mais paradoxalement, des développeurs plus confiants
Après avoir répondu aux questions, les participants ont été invités à répondre à un petit sondage leur demandant de décrire leur expérience d'écriture de code pendant ces exercices et ainsi que quelques informations démographiques de base.
Il en ressort que, paradoxalement, les utilisateurs d'IA d'assistance d'écriture de code « pensaient que leurs réponses étaient plus sûres que celles du groupe de contrôle, bien que les participants à l'expérience aient systématiquement écrit des réponses moins sécurisées ».
Commentaires (20)
#1
Un code, ça se recopie peut-être, mais ça se comprend aussi.
J'ai constaté un cas similaire au lycée : un exercice plutôt technique, tout le monde a des connaissances en développement (mais pas forcément sur ce langage là) et quelle a été la solution appliquée ?
Laisser un type trouver un code "qui fonctionne", le diffuser à tout le monde, tout le monde recopie sans réfléchir et au moment de débugger : "non mais je comprend pas pourquoi ça fonctionne pas ...".
L'IA n'est pas développeur, c'est qu'un assistant.
Et un assistant n'est pas un développeur (sinon ce serait pas un assistant, mais un développeur).
#1.1
C'était il y a plusieurs années, depuis un ami en a conclu que les meilleures IA faisaient mieux que les pires développeurs ;)
#1.2
Ce qui est marrant c'est que c'est exactement le principe de l'IA qui a été gavé d'apprentissage sur stack et régurgite sans comprendre des bouts de codes qui sont parfois hors sujets ou n'ont ni queue ni tête.
Peut-être que copilot pourrait passer un DUT.
(attention y'a aussi d'excellents profils qui sortent de DUT, j'ai juste l'impression que sur des études plus longues les moins techniques se redirigent vers d'autres voies comme la gestion de projet ou le réseau, abandonnent, ou n'obtiennent pas leur diplôme)
#1.4
#1.3
#2
#3
#4
Dans la mienne, les développeurs expérimentés remettaient plus facilement en cause les suggestions de l'IA que les juniors. Ce qui m'avait fait conclure que ces outils sont moins efficaces entre les mains de développeurs moins expérimentés.
Dans tous les cas, il ne faut pas oublier que la chaîne de production logiciel doit vérifier le code par quality, security gates, et revue humaine.
IA ou pas IA.
Au passage, l'autre vecteur d'attaque intrinsèquement lié à la génération de code par IA : l'hallucination. Des dépendances malicieuses ont été créées en relation avec les paquets "imaginés" par Codex à l'époque (peut être que Copilot Chat chez GitHub est moins prompt à le faire, étant désormais basé sur GPT4 là où Codex est un GPT3.5 fine-tuned pour du code informatique). Rappelant que la vérification de la supply-chain reste indispensable.
#4.1
#4.2
#5
Il me semble aussi que la conclusion est à côté de la plaque :
> seulement 21 % de leurs solutions étaient bien sécurisées contre 43 % des propositions des participants n’utilisant pas d’assistant
Si de base 3 développeurs sur 5 (dans le meilleur des cas) ne sont pas fichus de produire du code convenable, titrer sur le danger des IA me semble totalement myope.
(L'article original est ici : https://arxiv.org/pdf/2211.03622.pdf)
#5.1
#5.2
Donc un panel de juniors et (je suppose) d'expérimentés, sans avoir spécialement de connaissances en sécurité IT. A chaud et sans avoir lu autre chose, je pense que c'est déjà une clé de compréhension de la production de code non sécurisé. IA ou pas IA.
#5.3
La seule conclusion pour moi serait que cela mérite effectivement un approfondissement. Avec 33 participants dans le groupe de test, on obtient, par niveau d'expérience (en arrondissant les chiffres) :
- non diplômé : 22
- diplômé : 6
- professionnel : 5
et on divise par 2 pour le groupe de contrôle.
Autant je veux bien qu'on commence à avoir des résultats statistiquement significatifs sur les non diplômé, autant sur les 2 autres groupes, c'est beaucoup trop peu pour pouvoir en tirer une conclusion quelconque.
Le manque d'évaluation des compétences en terme de sécurité est aussi un problème pour moi, car si l'IA doit avoir un impact sur la sécurité du code, cela pourrait être de plusieurs manières différentes :
- soit en augmentant le niveau de sécurité pour ceux qui n'ont pas les compétences requises
- soit en diminuant le niveau de sécurité pour ceux qui ont les compétences requises
- soit sans impact
A mon sens, cette étude mérite surtout un approfondissement avant de pouvoir conclure quoi que ce soit sur le sujet.
#5.4
Pas mieux.
#6
Il fait pas mal de conneries (mais de moins en moins) et je contrôle toujours les propositions.
J'avoue que c'est un outil qui m'est devenu indispensable et ça vaut largement les 10$/mois de facture. Je prévois de fortes augmentations de tarif dans le futur :(
#6.1
Ya des chances vu que GitHub perd de l'argent sur copilot.
#6.2
Ne pas oublier non plus que Microsoft à des accords avec OpenAI, que Github appartient à Microsoft, et que Azure appartient également à Microsoft.
Le côté perte d'argent a été "calculé" sur la base d'une estimation du nombre de requêtes, et du coup associé en terme de prix public au niveau du cloud Azure.
Je pense aussi que le tarif de Github Copilot va augmenter (un x2 ou x3) dans un futur plus ou moins proche. Mais il me fait gagner tellement de temps que ça vaut largement le coup pour moi (j'écris beaucoup moins de code "chiant", mais j'en lis plus :p ).
Et sur le code répétitif, je le trouve très perspicace dans ses suggestions.
#6.3
Sur Copilot Chat, on est sur des contextes qui sont énormes d'ailleurs. L'outil est capable de te cracher le code entier d'une application, le modèle derrière devant probablement être du GPT-4 (ça c'est confirmé) à 32 (ça je le suppose), voire du GPT-4-Turbo 128k tokens (ça aussi je le suppose). GPT-4-Turbo coûte moins cher en requêtes, mais ça reste un produit consommateur de ressources. Mais après réflexion, je pense pas que ce soit ce modèle car il est trop récent.
Mais personnellement, j'observe surtout que MS est en forte poussée pour une adoption massive avec des tarifs vraiment trop attractifs. Alignés avec ceux d'OpenAI d'ailleurs. Clairement, par rapport à la puissance consommée, c'est pas assez cher pour moi. Et crois moi que les Sales te tannent pour les utiliser moyennant des accompagnements "offerts" et toute la mécanique usuelle. L'insistance d'Azure est palpable, encore plus que celle de GCP (dont je n'apprécie guère non plus l'insistance commerciale), même si ce dernier est à la ramasse sur le sujet.
De ma fenêtre, j'estime surtout qu'ils sont dans une stratégie d'adoption massive pour rendre l'outil indispensable dans l'optique d'en augmenter les coûts via un vendor-lock (stratégie classique du Cloud). Derrière cela, aujourd'hui, on sent la limitation de ressources chez Azure justement. Ces derniers temps, provisionner sur West Europe (qui a eu pendant un moment l'offre OpenAI Services avant qu'elle soit arrêtée d'être commercialisée dessus faute de puissance GPU) est lent et rappelle l'époque COVID où ils furent en galère.
L'investissement de MS dans la techno est colossal, j'ai pas les chiffres mais je pense que ça dit être plus que l'initial d'Azure, et au vu de l'intégration massive dans tous ses produits, la stratégie est bien de l'exploiter au maximum par mutualisation. Est-ce que ça sera rentable ? On verra, mais clairement je pense que les prix vont grimper une vois le vendor-lock en place.
#6.4
Je ne faisais que réagir sur le côté perte par utilisateur, qui n'est qu'une estimation basée sur une évaluation avec des chiffres peu précis et des prix grand public, qui peut être très éloigné de la réalité.