Fin du programme de bug bounty de Curl : pourquoi les rapports générés par l'IA ont poussé à l'abandonner

Le 22 janvier 2026, une nouvelle a secoué la communauté de la cybersécurité : le projet open-source curl a annoncé la fin de son programme de bug bounty via HackerOne. Cette décision, prise par Daniel Stenberg, le fondateur et développeur principal, fait suite à une avalanche de rapports de vulnérabilités de basse qualité, générés en grande partie par l’IA. Une situation qui illustre un défi croissant pour les mainteneurs de projets open-source face à l’automatisation malveillante.

L’explosion des rapports de “slop” et son impact sur les équipes de sécurité

Le terme “AI slop” (ou “slop” généré par l’IA) désigne un flot croissant de contenus de mauvaise qualité, générés automatiquement, qui semblent plausibles en surface mais ne contiennent rien d’utile ni de productif. Dans le cas de curl, ce phénomène a pris une ampleur critique. Daniel Stenberg a expliqué sur sa liste de diffusion personnelle que l’équipe de sécurité du projet a été submergée par ces soumissions. Il a déclaré : “Nous avons commencé la semaine en recevant sept problèmes HackerOne en seize heures. Certains étaient de véritables bugs, et s’occuper de ce lot a pris du temps. Finalement, nous avons conclu qu’aucun d’eux n’identifiait une vulnérabilité, et nous comptons déjà vingt soumissions faites en 2026.”

L’impact n’est pas seulement technique, mais aussi humain. Stenberg a souligné que ce torrent de soumissions mettait une charge énorme sur l’équipe de sécurité de curl, un petit projet open-source avec un nombre limité de mainteneurs actifs. Pour assurer la survie du projet et protéger la santé mentale des développeurs, il a pris la décision radicale de mettre fin au programme de récompenses. La principale motivation est de supprimer l’incitation à soumettre du “déchet” et des rapports peu approfondis, qu’ils soient générés par l’IA ou non.

“Le but principal de l’arrêt du bounty est de supprimer l’incitation pour les gens de nous soumettre du déchet et des rapports peu recherchés. L’IA générée ou non. Le torrent actuel de soumissions met une charge élevée sur l’équipe de sécurité de curl, et c’est une tentative de réduire le bruit.” — Daniel Stenberg

La montée en puissance des soumissions en 2025

Les données internes de curl confirment cette tendance alarmante. Selon Stenberg, le programme de bug bounty de curl a connu une augmentation fulgurante du taux de soumission tout au long de l’année 2025, tandis que plusieurs autres programmes open-source hébergés sur HackerOne n’ont pas connu la même hausse. Ce décalage suggère que le statut de curl, en tant qu’outil fondamental pour les transferts de données, en fait une cible privilégiée pour les attaques automatisées.

L’automatisation des tests de sécurité est une arme à double tranchant. D’un côté, elle permet de couvrir un large périmètre rapidement. De l’autre, elle peut générer un volume de faux positifs qui noie les vraies menaces. Dans le cas de curl, la combinaison d’un outil très utilisé et d’un programme de bounty bien établi a probablement attiré l’attention des scripts automatisés et des chercheurs cherchant à maximiser leurs gains sans effort substantiel.

Exemples concrets de rapports inutiles

Stenberg a partagé des exemples de ce qu’il considère comme du “slop” généré par l’IA. Bien que non détaillés publiquement, ces rapports présenteraient des caractéristiques typiques : des descriptions de vulnérabilités génériques (par exemple, “risque de débordement de tampon”) sans preuve de concept exploitables, des références à des CVE obsolètes, ou des analyses superficielles basées sur des signatures de code basiques. Ces soumissions obligent les mainteneurs à consacrer du temps précieux à les évaluer, à les rejeter et à communiquer avec les soumissionnaires, au détriment du développement et de la maintenance du code. Cette situation rappelle l’importance de la protection contre le spam automatisé sur les plateformes de soumission.

Les changements concrets apportés par le projet curl

La décision de curl n’est pas une simple annonce ; elle se traduit par des modifications concrètes dans la documentation et les processus du projet.

Mise à jour de la documentation et du fichier BUG-BOUNTY.md

Le changement a d’abord été découvert dans un commit en attente de curl sur le fichier BUG-BOUNTY.md. Une fois fusionné, ce fichier sera mis à jour pour stipuler que le projet curl n’offre plus aucune récompense pour les bugs ou vulnérabilités signalés. Il indiquera également que le projet n’aidera pas les chercheurs en sécurité à obtenir des récompenses de sources tierces pour des problèmes liés à curl.

Le message est sans équivoque : “Jusqu’à la fin de janvier 2026, il y avait un bounty de curl. Il n’existe plus. Le projet curl n’offre plus aucune récompense pour les bugs ou vulnérabilités signalés. Nous n’aidons pas non plus les chercheurs en sécurité à obtenir de telles récompenses pour des problèmes curl d’autres sources.”

Transition vers un processus de soumission interne

La transition se fera par étapes, reflétant une approche pragmatique pour ne pas laisser de soumissions en suspens. Jusqu’au 31 janvier 2026, le projet continuera d’accepter les soumissions via HackerOne. Tout rapport en cours à cette date continuera d’être traité normalement.

À partir du 1er février 2026, le projet cessera d’accepter de nouvelles soumissions via HackerOne. Les chercheurs en sécurité seront invités à signaler les problèmes de sécurité directement via GitHub, en utilisant probablement le système de “Security Advisories” intégré à la plateforme. Ce changement vise à simplifier le processus et à le gérer en interne, sans l’intermédiaire d’une plateforme de bounty qui, par sa nature, peut encourager les soumissions massives.

Mise à jour du fichier security.txt

La nouvelle position du projet est également reflétée dans une récente mise à jour de son fichier security.txt. Ce fichier, standardisé pour indiquer comment contacter les équipes de sécurité, a été modifié pour inclure un avertissement clair. Il stipule que le projet n’offre aucune compensation monétaire pour les vulnérabilités signalées et met en garde contre les soumissions de mauvaise qualité. Stenberg a précisé que les personnes qui soumettront du “déchet” seront bannies et ridiculisées publiquement. Cette mesure, bien que sévère, vise à dissuader les comportements opportunistes et à protéger l’équipe des soumissions inutiles.

Les implications pour la sécurité des projets open-source

La décision de curl a des répercussions plus larges sur l’écosystème de la sécurité open-source, en particulier dans un contexte où les programmes de bug bounty sont devenus un pilier de la défense des vulnérabilités, face à des menaces comme les attaques ransomware et la sécurité de la chaîne d’approvisionnement.

Le dilemme des récompenses financières

Les programmes de bug bounty, comme celui d’HackerOne, sont conçus pour récompenser financièrement les chercheurs qui découvrent et signalent des vulnérabilités de manière responsable. Ils ont prouvé leur efficacité pour identifier des problèmes que les tests internes pourraient manquer. Cependant, ils créent également un incentive financier qui peut être détourné. L’IA, en automatisant la recherche de vulnérabilités superficielles, a exacerbé ce problème, transformant un programme de sécurité en une source de “bruit” coûteux en temps.

L’impact sur les petits projets

Stenberg a souligné que curl est un “petit projet open-source” avec un nombre limité de mainteneurs. Les grands projets, comme le noyau Linux ou les navigateurs, disposent souvent de ressources dédiées pour gérer les soumissions de bounty. En revanche, pour les projets plus modestes, le volume de soumissions, même de mauvaise qualité, peut être écrasant. La survie du projet et la santé mentale des mainteneurs deviennent alors des priorités absolues, au détriment parfois d’un programme de bounty qui coûte plus en temps qu’il ne rapporte en sécurité.

Le futur de la détection de vulnérabilités

L’arrêt du programme de bounty de curl ne signifie pas la fin de la recherche de vulnérabilités. Le projet s’oriente vers un processus de soumission directe via GitHub. Cette approche pourrait permettre un contrôle plus fin sur la qualité des rapports. Cependant, elle risque aussi de réduire l’attrait pour les chercheurs sérieux, habitués aux récompenses financières. Le défi pour les projets open-source sera de trouver un équilibre entre attirer l’expertise externe et se protéger contre les soumissions automatisées.

Tableau comparatif : Avant et après pour le programme de bug bounty de curl

Étapes pratiques pour les chercheurs en sécurité

Pour les chercheurs qui souhaitent continuer à signaler des problèmes de sécurité dans curl, voici les étapes à suivre à partir du 1er février 2026 :

1. Vérifier la documentation de sécurité : Consultez le fichier security.txt du projet curl pour connaître les procédures actuelles de contact.
2. Utiliser le système de sécurité GitHub : Signalez les vulnérabilités potentielles via le système de “Security Advisories” intégré à la plateforme GitHub. Ce système permet une communication privée et sécurisée avec les mainteneurs.
3. Préparer un rapport détaillé : Incluez une description claire du problème, les étapes de reproduction, l’impact potentiel et, si possible, une preuve de concept. Un rapport bien structuré a plus de chances d’être pris au sérieux.
4. Éviter les soumissions automatisées : Ne soumettez pas de rapports générés par des scripts ou des outils d’analyse automatique sans validation humaine. Les rapports de mauvaise qualité seront rejetés et pourraient entraîner un bannissement.
5. Appliquer les bonnes pratiques de sécurité : Assurez-vous de suivre les bonnes pratiques de sécurité dans vos propres environnements, y compris la gestion sécurisée des identifiants.
6. Respecter les délais : Pour les soumissions en cours, assurez-vous qu’elles sont complétées avant le 31 janvier 2026 pour être traitées dans le cadre du programme actuel.

Conclusion : Un signal fort pour l’écosystème de la sécurité

La décision de curl d’abandonner son programme de bug bounty en raison de l’avalanche de rapports générés par l’IA est un signal fort pour l’ensemble de l’écosystème de la sécurité open-source. Elle met en lumière une faille dans le modèle actuel de récompense financière, qui peut être exploité par l’automatisation à faible coût. Pour les mainteneurs de projets comme curl, la priorité est désormais de préserver la viabilité du projet et la santé de leurs équipes.

Cette situation soulève une question cruciale pour l’avenir : comment les projets open-source peuvent-ils continuer à bénéficier de la recherche externe tout en se protégeant contre le flot de soumissions automatisées et de mauvaise qualité ? La réponse réside peut-être dans des modèles plus ciblés, comme des programmes d’invités ou des collaborations privilégiées, plutôt que dans des bounties ouverts et accessibles à tous.

En attendant, le projet curl s’oriente vers un processus de soumission plus contrôlé via GitHub. Les chercheurs sérieux sont toujours les bienvenus, mais le message est clair : la qualité prime sur la quantité. Pour les utilisateurs et les contributeurs, la sécurité de curl reste une priorité, mais elle sera désormais assurée par l’expertise et la vigilance de son équipe de mainteneurs, sans le filtre financier de HackerOne.

Prochaine action : Si vous êtes un chercheur en sécurité ou un mainteneur de projet open-source, réfléchissez à la manière dont les programmes de bounty peuvent être adaptés pour résister aux abus automatisés. Partagez vos expériences et vos idées pour renforcer la résilience de l’écosystème face à ce nouveau défi.