Discussion :

[Stéphane le calme]

L'open source est-il en danger ? Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA,
« ces systèmes ne sont pas encore capables de comprendre le code », estime un développeur

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

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 efforts, ce qui est une denrée rare chez les mainteneurs.

Et d'estimer que répondre aux rapports de sécurité coûte cher :

« Si cela arrive à une poignée de projets pour lesquels j'ai de la visibilité, alors je soupçonne que cela arrive à grande échelle aux projets open source. Cette tendance est très préoccupante.

« La sécurité est déjà un sujet qui n'est pas aligné avec la raison pour laquelle de nombreux mainteneurs donnent de leur temps aux logiciels open source, considérant plutôt la sécurité comme importante pour aider à protéger leurs utilisateurs. En tant que rapporteurs, il est essentiel de respecter ce temps souvent bénévole.

« Les rapports de sécurité qui font perdre du temps aux mainteneurs sont source de confusion, de stress, de frustration et, pour couronner le tout, d'un sentiment d'isolement dû à la nature secrète des rapports de sécurité. Tous ces sentiments peuvent contribuer à l'épuisement des contributeurs aux projets open source, qui jouissent probablement d'une grande confiance.

« À bien des égards, ces rapports de mauvaise qualité devraient être traités comme s'ils étaient malveillants. Même si ce n'est pas leur intention, le résultat est que les mainteneurs sont épuisés et plus réticents au travail de sécurité légitime ».

L'illustration de la persistance de ces préoccupations avec un rapport de bogue du projet Curl

Comme pour souligner la persistance de ces préoccupations, un rapport de bogue du projet Curl publié le 8 décembre montre que près d'un an après que le responsable Daniel Stenberg a soulevé le problème, il est toujours confronté à la « lenteur de l'IA » - et perd son temps à discuter avec un auteur de bogue qui pourrait être partiellement ou entièrement automatisé.

En réponse au rapport de bogue, Stenberg a écrit :

« Nous recevons régulièrement et en grand nombre des erreurs d'IA de ce type. Vous contribuez à [la] charge inutile des mainteneurs de Curl et je refuse de prendre cela à la légère et je suis déterminé à agir rapidement contre cela. Maintenant et à l'avenir.

« Vous avez soumis ce qui semble être un "rapport" d'IA évident où vous dites qu'il y a un problème de sécurité, probablement parce qu'une IA vous a trompé en vous faisant croire cela. Vous nous faites ensuite perdre notre temps en ne nous disant pas qu'une IA a fait cela pour vous et vous poursuivez la discussion avec des réponses encore plus merdiques - apparemment générées elles aussi par une IA

« Il est tout à fait possible d'utiliser l'IA pour apprendre des choses et résoudre des problèmes potentiels, mais lorsque vous supposez aveuglément qu'un outil stupide est automatiquement juste parce qu'il semble plausible, vous nous rendez à tous (le projet curl, le monde, la communauté open source) un très mauvais service. Vous auriez dû étudier l'affirmation et la vérifier avant de la rapporter. Vous auriez dû nous dire qu'une IA vous l'avait signalée. Vous auriez dû fournir l'emplacement exact du code source ou les étapes de la reproduction lorsqu'on vous l'a demandé - parce que lorsque vous ne l'avez pas fait, vous avez prouvé que votre "rapport" n'avait aucune valeur particulière ».

« Ces systèmes ne sont pas encore capables de comprendre le code »

Les contenus en ligne polluants et de mauvaise qualité existaient bien avant les chatbots, mais les modèles d'IA générative ont facilité leur production. Il en résulte une pollution du journalisme, de la recherche sur le web et, bien sûr, des médias sociaux.

Pour les projets open source, les rapports de bogues assistés par l'IA sont particulièrement pernicieux car ils nécessitent l'examen et l'évaluation d'ingénieurs en sécurité - souvent bénévoles - qui sont déjà pressés par le temps.

« Ce qui arrive à Python ou à Pip est susceptible d'arriver à d'autres projets ou plus fréquemment », a averti Larson. « Je suis surtout préoccupé par les mainteneurs qui gèrent cela de manière isolée. S'ils ne savent pas que les rapports générés par l'IA sont monnaie courante, ils pourraient ne pas être en mesure de reconnaître ce qui se passe avant de perdre des tonnes de temps sur un faux rapport. Perdre un temps précieux de bénévolat à faire quelque chose que vous n'aimez pas et en fin de compte pour rien est le moyen le plus sûr d'épuiser les mainteneurs ou de les éloigner du travail de sécurité ».

Selon Larson, la communauté des logiciels libres doit prendre de l'avance sur cette tendance afin d'atténuer les dommages potentiels.

« J'hésite à dire que le problème sera résolu par plus de technologie », a-t-il déclaré. « Je pense que la sécurité des logiciels libres a besoin de changements fondamentaux. Nous ne pouvons pas continuer à confier le travail à un petit nombre de mainteneurs, et nous avons besoin d'une normalisation et d'une visibilité accrues de ces types de contributions à l'open source ».

« Nous devrions répondre à la question suivante : "Comment impliquer davantage de personnes de confiance dans l'open source ?" Le financement du personnel est une réponse - comme ma propre subvention par Alpha-Omega - et l'implication par le don de temps de travail en est une autre ».

Alors que la communauté du logiciel libre réfléchit à la manière de réagir, Larson demande aux personnes qui soumettent des rapports de bogues de ne pas le faire s'ils n'ont pas été vérifiés par un être humain - et de ne pas utiliser l'IA, car « ces systèmes ne sont pas encore capables de comprendre le code ». Il invite également les plateformes qui acceptent les rapports de vulnérabilité au nom des mainteneurs à prendre des mesures pour limiter la création automatisée ou abusive de rapports de sécurité.

Sources : Seth Larson, rapport de bogue,

Et vous ?

Quelle lecture faites-vous de la situation ? Trouvez-vous l'analyse de Seth Larson crédible ou pertinente ? Dans quelle mesure ?

Quelles implications imaginez-vous si la situation perdure et s'aggrave ?

Quelles solutions pourraient être mises en place pour mieux soutenir les mainteneurs face à cette surcharge ?

Les utilisateurs d’IA sont-ils suffisamment formés à soumettre des rapports de qualité ? Qui devrait se charger de cette éducation ?

Les IA pourraient-elles, au contraire, être utilisées pour filtrer les rapports de mauvaise qualité ? Si oui, comment éviter les biais dans leur utilisation ?

Le phénomène des rapports générés par IA remet-il en question la viabilité du modèle open source tel qu’il existe aujourd’hui ?

[popo]

Quelle lecture faites-vous de la situation ? Trouvez-vous l'analyse de Seth Larson crédible ou pertinente ? Dans quelle mesure ?

J'approuve totalement cette analogie.
J'ai moi même pu constater le problème de ces rapports de bogues générés par des IA.
Tu prend du temps pour analyser, et lorsque tu demandes un complément d'informations pour reproduire, la personne botte en touche ou bien te fourni une informations qui ne permet pas de reproduire.
J'ai personnellement blacklisté plusieurs personnes, dont j'ignore désormais les rapports.

Quelles implications imaginez-vous si la situation perdure et s'aggrave ?

J'imagine qu'à force, la plupart des mainteneurs finiront pas ignorer les rapports "rédigés" par certaines personnes, comme je le fait déjà.
C'est dommage car, si dans le lot, il y en a un qui est légitime, il risque de ne pas être corrigé.

Ou alors, les mainteneurs finiront pas abandonner.
Ce qui serait beaucoup plus grave.
Je pense que Seth Larson a raison de considérer ces rapports comme malveillant.
Car si les mainteneurs abandonnent, cela fera l'affaire des personnes malveillantes qui se servent des failles non corrigées.
Il est n'est donc pas impossible que ces rapports soit "rédigés" par des personnes malveillantes tentant de saper le moral des mainteneurs.

Quelles solutions pourraient être mises en place pour mieux soutenir les mainteneurs face à cette surcharge ?

Cette solution n'est clairement pas viable à long terme.
Mais, personnellement j'établirais une norme permettant d'analyser de manière automatique la partie du rapport qui traite de la manière de reproduire, et j'ignorerais de manière systématique tout rapport qui en serait dépourvu.

Les utilisateurs d’IA sont-ils suffisamment formés à soumettre des rapports de qualité ? Qui devrait se charger de cette éducation ?

Je pense que ceux qui soumettent des rapports de qualité généré par une IA, savent très bien ce qu'ils font.
Je suis d'avis que le "Même si ce n'est pas leur intention" de Seth Larson est plutôt naïf, et que c'est justement l'objectif de personnes malveillantes de faire crouler les mainteneurs sous une montagne de faux rapport, dans l'objectif de les décourager ou de les mettre sous une pression telle, qu'il feront plus d'erreurs.

Les IA pourraient-elles, au contraire, être utilisées pour filtrer les rapports de mauvaise qualité ? Si oui, comment éviter les biais dans leur utilisation ?

Pour cela, il faudrait une IA capable de détecter les fausses informations dans ces rapports.
Mais puisque ces rapports sont sensés être une source fiable, sur quoi va-t-elle se baser pour distinguer le vrai du faux ?
Donc, en l'état actuel, avec la manière dont fonctionnent les IA, je ne pense pas que cela soit réalisable.

Le phénomène des rapports générés par IA remet-il en question la viabilité du modèle open source tel qu’il existe aujourd’hui ?

A plus ou moins long terme, à forcer d'épuiser les mainteneurs, je suis d'avis qu'il arrivera un moment où, pour se fier à une librairie open source, il faudra passer énormément de temps à analyser son code et à effectuer des tests pour en garantir la sécurité à un instant T. Et, comme en règle générale, on utilise des librairies pour gagner du temps ou parce qu'on n'est pas à l'aise sur le sujet traité par la librairie, cela va vite devenir contreproductif.
Je suis d'avis que cela pourrait probablement conduire (faute de confiance) à l'arrêt du modèle open tel qu'on le connait.

[Zefling]

En tout cas, ils s'intéressent pas aux petits projets.
Et j'ai viré toud les fichiers comme « package-lock.json » de mes projets pour ne plus être spam par les bots qui me disent : il faut mettre à jour ce package.

[nilsb111]

Effectivement, je n'y avais pas pensé, merci pour cet article très intéressant !
J'ai eu une idée de demi-solution, pas très satisfaisante mais potentiellement mieux que rien:
Faire payer chaque report une petite somme (~10€ ?) et rembourser les reports légitimes ou les reports qui n'ont visiblement pas été fait à l'IA et source d'une vrai erreur humaine.
Ça dissuaderait ceux qui voudraient spammer avec des reports...

[Mathis Lucas]

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de projets libres et open source sont submergés par des rapports de bogues inutiles rédigés par l'IA. S'ils semblent convaincants en apparence, ces rapports sont souvent basés sur les hallucinations de l'IA et nécessitent un temps considérable pour être vérifiés, ce qui détourne les ressources limitées des développeurs bénévoles. Cette situation peut entraîner une perte de temps, de l'épuisement et une diminution de la motivation des contributeurs bénévoles. Daniel Stenberg, créateur du projet cURL, a surnommé ces rapports de faible qualité « AI slop ». Dans un récent billet, il a formellement interdit les rapports de bogues générés par l'IA.

CURL est un outil et une bibliothèque de ligne de commande essentiels pour interagir avec les ressources Internet. Le projet open source reçoit des rapports de bogues et des problèmes de sécurité par le biais de nombreux canaux, notamment HackerOne, un service de signalement qui aide les entreprises à gérer les rapports de vulnérabilité et les primes aux bogues. Mais les pratiques ont évolué au cours de ces dernières années.

HackerOne s'est passionné pour les outils d'IA. « Une plateforme, une force double : l'esprit humain + la puissance de l'IA », peut-on lire sur sa page d'accueil. Ainsi, les utilisateurs s'appuient de plus en plus sur les outils d'IA de la plateforme pour générer des rapports de bogue et de sécurité.

Un afflux de rapports de bogues de mauve qualité générés par IA

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre dernier. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Récemment, c'est le créateur du projet cURL qui a exprimé son ras-le-bol :

Voilà, c'est fait. J'en ai assez. Je mets un terme à cette folie.

1. Tous les rapporteurs qui soumettent des rapports de sécurité sur le hashtag#Hackerone pour le hashtag#curl doivent désormais répondre à cette question : « avez-vous utilisé une IA pour trouver le problème ou générer cette soumission ? »

(Et s'ils le sélectionnent, ils peuvent s'attendre à un flot de questions de suivi prouvant l'existence d'une intelligence réelle.)

2. Nous bannissons INSTANTANÉMENT tous les rapporteurs qui soumettent des rapports que nous considérons comme un déchet généré par l'IA. Un seuil a été atteint. Nous sommes effectivement victimes d'un DDoS. Si nous le pouvions, nous les ferions payer pour cette perte de temps.

Nous n'avons toujours pas vu un seul rapport de sécurité valide réalisé avec l'aide de l'IA.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Ce phénomène souligne un problème plus général : les projets open source fonctionnent grâce à quelques bénévoles. L’utilisation abusive de l'IA peut nuire à l’écosystème, en gaspillant l'énergie précieuse des personnes qui le maintiennent. L'hallucination des modèles est un problème majeur de l'IA générative auquel les chercheurs n'ont pas encore trouvé de solution. Selon une étude de 2024, l'hallucination est un problème insoluble.

Récemment, quatre rapports de vulnérabilité malavisés, générés par l'IA, ont été publiés, apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Des signalements de fausses failles de sécurité dans les logiciels

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. Seth Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

« À bien des égards, ces rapports de mauvaise qualité devraient être traités comme s'ils étaient malveillants. Même si ce n'est pas leur intention, le résultat est que les mainteneurs sont épuisés et plus réticents au travail de sécurité légitime », a écrit Seth Larson dans son billet de blogue l'année dernière.

À titre d'exemple, Daniel Stenberg a évoqué un rapport de bogue datant du 4 mai 2025. Il suggérait un « nouvel exploit exploitant les cycles de dépendance de flux dans la pile de protocoles HTTP/3 ». La mauvaise gestion des dépendances de flux, lorsqu'un aspect d'un programme attend la sortie d'un autre aspect, peut conduire à l'injection de données malveillantes, à des conditions de course et à des plantages, ainsi qu'à d'autres problèmes.

Le rapport en question suggère que cela pourrait rendre cURL, qui est compatible avec HTTP/3, vulnérable à des exploits pouvant permettre l'exécution de code à distance. Mais comme le souligne le personnel de cURL, le correctif « configuration de serveur malveillant » soumis ne s'appliquait pas aux dernières versions d'un outil Python en question. Interrogé à ce sujet, l'auteur du signalement a répondu d'une manière étrangement prompte.

Il répondait à des questions qui n'avaient pas été posées par l'équipe de cURL et incluait ce qui semble être des instructions de base sur la manière d'utiliser l'outil git pour appliquer un nouveau correctif. L'auteur du signalement n'a pas non plus fourni le nouveau fichier correctif demandé, a cité des fonctions qui n'existent pas dans les bibliothèques sous-jacentes et a suggéré des tactiques de renforcement pour des utilitaires autres que cURL.

L'équipe de cURL a finalement fermé le rapport, mais l'a également rendu public pour servir d'exemple. Alex Rice, cofondateur, directeur technique et responsable de la sécurité des systèmes d'information de HackerOne, a déclaré que les rapports contenant « des vulnérabilités hallucinées, un contenu technique vague ou incorrect, ou d'autres formes de bruit à faible effort » sont traités comme du spam et font l'objet d'une mise en application.

Conclusion

Les rapports de bogue de mauvaise qualité générés par l'IA sont devenus un problème pour les mainteneurs de logiciels libres et open source. Ce phénomène met en évidence les défis posés par l'utilisation non encadrée de l'IA dans la détection de vulnérabilités. Selon Daniel Stenberg et d'autres, cela souligne la nécessité d'une approche plus rigoureuse et collaborative pour maintenir la qualité et la sécurité des projets libres et open source.

« Je suis très heureux que ce problème attire l'attention afin que nous puissions éventuellement faire quelque chose à ce sujet et éduquer le public sur l'état des choses. Les LLM ne peuvent pas trouver de problèmes de sécurité, du moins pas de la manière dont ils sont utilisés ici », a-t-il déclaré.

Source : Daniel Stenberg

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'utilisation de l'IA pour la détection de problèmes de sécurité ?
Selon vous, les systèmes d'IA actuels sont-ils adaptés à ce cas d'utilisation ? Pourquoi ?
Selon vous, quels impacts ce phénomène pourrait-il avoir sur l'écosystème des logiciels libres et open source ?

Voir aussi

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis

Les outils de développement GenAI n'améliorent pas l'efficacité du codage et augmentent le nombre de bogues : avec Microsoft Copilot les développeurs ont constaté une augmentation de 41 % des bogues

[Mathis Lucas]

AI Slop ? Pas cette fois. Un chercheur en sécurité utilise l'IA pour repérer une cinquantaine de bogues réels dans le code du projet open source cURL
démontrant son efficacité sous supervision humaine

Le projet cURL a été confronté à une avalanche de rapports de bogues générés automatiquement par l'IA ces dernières années. Ces rapports sont souvent de faible qualité, souvent incohérents ou non pertinents. Cette situation a entraîné une surcharge de travail pour les mainteneurs, qui avaient donc été contraints d'interdire les rapports de bogues générés par l'IA. Cependant, un chercheur en sécurité a récemment utilisé l'IA pour soumettre des rapports à cURL et ces rapports ont permis d'identifier environ 50 vulnérabilités dans le code. Les mainteneurs ont salué la qualité de ces découvertes, soulignant que l'IA peut aider lorsqu'elle est bien utilisée.

cURL est un outil et une bibliothèque de ligne de commande essentiels pour interagir avec les ressources Internet. Le projet open source reçoit des rapports de bogues et des problèmes de sécurité par le biais de nombreux canaux, notamment HackerOne, un service de signalement qui aide les entreprises à gérer les rapports de vulnérabilité et les primes aux bogues. Mais les pratiques ont évolué au cours de ces deux dernières années.

HackerOne s'est passionné pour les outils d'IA. « Une plateforme, une force double : l'esprit humain + la puissance de l'IA », peut-on lire sur sa page d'accueil. Ainsi, les utilisateurs s'appuient de plus en plus sur les outils d'IA de la plateforme pour générer des rapports de bogue et de sécurité.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, expert en cybersécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue viral en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

Les rapports de bogues de mauvaise qualité générés par l'IA ont posé problème non seulement à cURL, mais aussi à la communauté Python, à Open Collective et au projet Mesa. Ce déluge a incité Daniel Stenberg, responsable du projet open source cURL, à publier plusieurs articles de blogue sur le sujet afin de convaincre les chasseurs de bogues de faire preuve de retenue et de ne pas faire perdre de temps aux contributeurs avec des problèmes invalides.

Impacts de rapports de mauvaise qualité 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. Seth Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

À titre d'exemple, Daniel Stenberg a évoqué un rapport de bogue datant du 4 mai 2025. Il suggérait un « nouvel exploit exploitant les cycles de dépendance de flux dans la pile de protocoles HTTP/3 ». La mauvaise gestion des dépendances de flux, lorsqu'un aspect d'un programme attend la sortie d'un autre aspect, peut conduire à l'injection de données malveillantes, à des conditions de course et à des plantages, ainsi qu'à d'autres problèmes.

Le rapport en question suggère que cela pourrait rendre cURL, qui est compatible avec HTTP/3, vulnérable à des exploits pouvant permettre l'exécution de code à distance. Mais comme le souligne le personnel de cURL, le correctif « configuration de serveur malveillant » soumis ne s'appliquait pas aux dernières versions d'un outil Python en question. Interrogé à ce sujet, l'auteur du signalement a répondu d'une manière étrangement prompte.

Il répondait à des questions qui n'avaient pas été posées par l'équipe de cURL et incluait ce qui semble être des instructions de base sur la manière d'utiliser l'outil git pour appliquer un nouveau correctif. L'auteur du signalement n'a pas non plus fourni le nouveau fichier correctif demandé, a cité des fonctions qui n'existent pas dans les bibliothèques sous-jacentes et a suggéré des tactiques de renforcement pour des utilitaires autres que cURL.

L'équipe de cURL a finalement fermé le rapport, mais l'a également rendu public pour servir d'exemple. Alex Rice, cofondateur, directeur technique et responsable de la sécurité des systèmes d'information de HackerOne, a déclaré que les rapports contenant « des vulnérabilités hallucinées, un contenu technique vague ou incorrect, ou d'autres formes de bruit à faible effort » sont traités comme du spam et font l'objet d'une mise en application.

Le problème viendrait des utilisateurs et non de la technologie

Ce phénomène souligne un problème plus général : les projets open source fonctionnent grâce à quelques bénévoles. L’utilisation abusive de l'IA peut nuire à l’écosystème, en gaspillant l'énergie précieuse des personnes qui le maintiennent. Les hallucinations des modèles constituent un problème majeur de l'IA générative auquel les chercheurs n'ont pas encore trouvé de solution. Selon une étude de 2024, il pourrait s'agir d'un problème insoluble.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Il apparaît désormais que le problème vient davantage des personnes que de la technologie. En septembre 2025, le projet cURL a reçu des dizaines de signalements potentiels de Joshua Rogers, un chercheur en sécurité basé en Pologne. Joshua Rogers a identifié divers bogues et vulnérabilités à l'aide de plusieurs outils d'analyse propulsés par l'IA. Ses rapports se sont révélés non seulement valables, mais également beaucoup appréciés des mainteneurs.

Dans un billet publié sur Mastodon, Daniel Stenberg a déclaré : « ce sont vraiment des découvertes impressionnantes ». Dans sa mise à jour sur la liste de diffusion du projet, il a déclaré : « la plupart d'entre eux étaient de petites erreurs et des détails insignifiants dans le style d'un analyseur de code statique ordinaire, mais il s'agissait tout de même d'erreurs qu'il valait mieux corriger. Plusieurs des problèmes détectés étaient des découvertes assez impressionnantes ».

Parmi les vulnérabilités découvertes figurait une lecture hors limites dans Kerberos5 FTP qui n'a pas été considérée comme une faille de sécurité, mais qui a néanmoins été corrigée. Selon Daniel Stenberg, une cinquantaine de corrections de bogues basées sur les rapports de Joshua Rogers avaient été fusionnées.

Il faut néanmoins rester prudent quant à la façon d'utiliser l'IA

Le principal responsable du projet cURL Daniel Stenberg a reconnu la valeur de ces signalements. Les problèmes détectés allaient de petites incohérences à des bogues réels dans le code de la bibliothèque cURL. Toutefois, Daniel Stenberg reste prudent. Il explique que ces nouveaux outils représentent une évolution utile, non pas une révolution. L’IA ne remplace pas les développeurs, mais sert d’assistant capable de repérer des zones de code problématiques.

« Je ne pense pas que cela ait beaucoup changé mon opinion sur l'IA, si ce n'est peut-être prouver qu'il existe d'excellents outils d'analyse de code basés sur l'IA. Cela souligne peut-être aussi à quel point les rapports que nous recevons encore de la part des utilisateurs les plus naïfs sont ridicules », a-t-il écrit.

Joshua Rogers a rédigé un résumé des outils d'IA d'analyse des vulnérabilités qu'il a testés. Il a conclu que ces outils (Almanax, Corgea, ZeroPath, Gecko et Amplify) sont capables de détecter de réelles vulnérabilités dans des codes complexes. « Ce type de systèmes sera probablement la technologie la plus influente, voire la plus intéressante et la plus efficace pour détecter les vulnérabilités dans un avenir proche, du genre de celles que l'on n'avait plus vues depuis 2013 environ, lorsque le fuzzing est redevenu populaire avec afl-fuzz », a-t-il écrit.

L'industrie se tourne vers la recherche de bogues assistée par l'IA

Le projet OSS-Fuzz de Google a déclaré que la recherche de bogues assistée par l'IA est efficace. Mais le message est plus crédible lorsqu'il provient d'un chercheur en sécurité individuel plutôt que d'un fournisseur d'IA disposant d'énormes ressources. Dans le même temps, l'expérience rapports de mauvaise qualité prouve que l'IA est loin d'être prête à travailler de manière autonome. Joshua Rogers a particulièrement fait l'éloge de l'outil ZeroPath.

« En analysant des logiciels open source, il a littéralement trouvé des centaines de vulnérabilités et de bogues réels dans des logiciels très critiques : sudo, libwebm, Next.js, Avahi, hostap, cURL, Squid (pas si critique, mais il a littéralement trouvé plus de 200 bogues réels). Oui, enfin, l'IA a trouvé de vrais bogues dans cURL ! En effet, non seulement ZeroPath a trouvé une multitude de vulnérabilités, mais il s'est également révélé redoutablement efficace pour trouver des bogues normaux, lorsqu'on lui a donné une règle personnalisée pour le faire », a déclaré le chercheur en sécurité.

Malgré tout, ces outils ont leurs limites. Joshua Rogers a déclaré qu'aucun des outils d'IA d'analyse de code n'avait été capable de détecter un bogue de boucle infinie précédemment identifié dans le package npm image-size. Selon lui, cette vulnérabilité n'avait toujours pas été corrigée en septembre 2025, malgré un correctif soumis en avril. Là encore, c'est un problème humain.

Conclusion

Les rapports de bogue de mauvaise qualité générés par l'IA sont devenus un problème pour les mainteneurs de logiciels libres et open source. Ce phénomène met en évidence les défis posés par l'utilisation non encadrée de l'IA dans la détection de vulnérabilités. Selon Daniel Stenberg et d'autres, cela souligne la nécessité d'une approche plus rigoureuse et collaborative pour maintenir la qualité et la sécurité des projets libres et open source.

Toutefois, l’expérience de cURL montre que l’IA peut être efficace lorsqu’elle est utilisée sous supervision humaine. Ce n’est pas l’outil en lui-même qui fait la différence, mais la façon dont il est exploité. Les humains doivent toujours vérifier, filtrer et valider les rapports avant d’agir. Lorsqu'ils sont utilisés par une personne ayant une expérience significative dans le domaine, les outils d'IA peuvent être très utiles, voire surprenants.

Sources : Daniel Stenberg, responsable du projet open source cURL ; Joshua Rogers, chercheur en sécurité

Et vous ?

Quel est votre avis sur le sujet ?
Que vous inspire l'expérience de cURL ?
Que pensez-vous des outils actuels d'IA d'analyse de code ?
Ces outils pourront-ils un jour être déployés sans supervision humaine ?

Voir aussi

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis