Les soumissions de vulnérabilités logicielles générées par des modèles d'IA ont inauguré une « nouvelle ère de rapports de sécurité bâclés pour l'open source » - et les développeurs qui maintiennent ces projets souhaiteraient que les chasseurs de bogues s'appuient moins sur les résultats produits par les assistants d'apprentissage automatique.Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blog la semaine dernière, exhortant les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. « Récemment, j'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par LLM dans les projets open source », écrit-il, rappelant les résultats similaires obtenus par le projet Curl en janvier. « Ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés ».
Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.
Une montée en flèche des rapports automatisés
Les mainteneurs jouent un rôle essentiel dans l'univers de l'open source. Ces bénévoles consacrent leur temps et leur expertise à maintenir des projets utilisés par des millions de personnes à travers le monde. Pourtant, ces derniers mois, un phénomène inquiétant perturbe leur travail : une multiplication des rapports de bogues de mauvaise qualité générés par des intelligences artificielles (IA).
Avec l’essor des outils d'IA comme ChatGPT, Bard ou Copilot, il est devenu plus facile que jamais pour les utilisateurs de générer des rapports de bogues. Ces outils, bien qu’impressionnants, génèrent parfois des rapports qui manquent de pertinence, sont mal formulés ou complètement hors sujet. Résultat : les mainteneurs se retrouvent à gérer une quantité croissante de « bruit », au détriment des problèmes légitimes.
Les mainteneurs rapportent une tendance claire : des rapports contenant des descriptions vagues, des solutions proposées incorrectes, ou des erreurs inexistantes. Dans certains cas, des IA « inventent » des problèmes à partir d’une compréhension superficielle du code. Ces rapports peuvent sembler crédibles, mais nécessitent souvent un temps considérable pour être vérifiés et écartés.
Une pression accrue sur les mainteneurs
Ce phénomène exacerbe une charge de travail déjà lourde. Beaucoup de mainteneurs sont des bénévoles qui jonglent entre leur travail, leur vie personnelle, et leurs responsabilités dans des projets open source. Traiter des rapports inutiles prend du temps, fatigue émotionnellement et peut entraîner un épuisement professionnel.
En outre, ces rapports nuisent aux discussions communautaires. Lorsque les canaux de communication sont saturés de contenu généré par l’IA, il devient plus difficile pour les utilisateurs humains de se faire entendre.
Pour Seth Larson, cette tendance est très préoccupante
Envoyé par Seth Larson
Je fais partie de l'équipe de triage des rapports de sécurité pour CPython, pip, urllib3, Requests et une poignée d'autres projets open source. J'occupe également une position de confiance qui me permet d'être « étiqueté » dans d'autres projets open source pour aider les autres lorsqu'ils ont besoin d'aide en matière de sécurité.
Récemment, j'ai remarqué une augmentation des rapports de sécurité de très mauvaise qualité, spammés et hallucinés par le LLM dans les projets open source. Le problème est qu'à l'ère des LLM, ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés. D'autres projets tels que curl ont fait état de résultats similaires.
Certains rapporteurs utiliseront divers outils d'analyse de sécurité et ouvriront des rapports de vulnérabilité sur la base des résultats obtenus, apparemment sans le moindre esprit critique. Par exemple, urllib3 a récemment reçu un rapport parce qu'un outil détectait notre utilisation de SSLv2 comme non sécurisée alors que notre usage est de désactiver explicitement SSLv2.
Il est difficile de s'attaquer à ce problème car il est réparti sur des milliers de projets open source et, en raison de la nature sensible de la sécurité des rapports, les mainteneurs open source sont découragés de partager leurs expériences ou de demander de l'aide. Le partage d'expériences demande du temps et des...
Récemment, j'ai remarqué une augmentation des rapports de sécurité de très mauvaise qualité, spammés et hallucinés par le LLM dans les projets open source. Le problème est qu'à l'ère des LLM, ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés. D'autres projets tels que curl ont fait état de résultats similaires.
Certains rapporteurs utiliseront divers outils d'analyse de sécurité et ouvriront des rapports de vulnérabilité sur la base des résultats obtenus, apparemment sans le moindre esprit critique. Par exemple, urllib3 a récemment reçu un rapport parce qu'un outil détectait notre utilisation de SSLv2 comme non sécurisée alors que notre usage est de désactiver explicitement SSLv2.
Il est difficile de s'attaquer à ce problème car il est réparti sur des milliers de projets open source et, en raison de la nature sensible de la sécurité des rapports, les mainteneurs open source sont découragés de partager leurs expériences ou de demander de l'aide. Le partage d'expériences demande du temps et des...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Quelle lecture faites-vous de la situation ? Trouvez-vous l'analyse de Seth Larson crédible ou pertinente ? Dans quelle mesure ?