La fin des bug bounties : pourquoi l'IA a tué le programme de sécurité de curl

Une statistique récente de l’Internet Bug Bounty a révélé qu’en 2025, les soumissions de vulnérabilités pour le projet curl ont bondi de plus de 300% par rapport à 2024. Cette explosion n’est pas le signe d’une sécurité renforcée, mais le symptôme d’une crise nouvelle : l’inondation de rapports de bugs générés par l’IA, une « slop » (déchets) à faible valeur qui a fini par submerger les équipes de sécurité, un phénomène qui rappelle les vagues de spam massif ciblant les systèmes de support. Le constat est sans appel : la sécurité logicielle traditionnelle, basée sur les programmes de bug bounty, est en train d’être démantelée par l’automatisation. La fin du programme de récompenses de curl en est l’exemple le plus retentissant à ce jour.

Le projet curl, composant incontournable pour tout transfert de données sur le web, a annoncé la clôture de son programme de bug bounty sur HackerOne à la fin janvier 2026. Cette décision n’est pas une simple mise à jour de politique, mais un signal d’alarme pour l’ensemble de l’écosystème open-source. Face à une avalanche de soumissions malveillantes ou négligentes, souvent générées par des scripts d’IA, le mainteneur principal, Daniel Stenberg, a préféré sacrifier les récompenses financières pour protéger la santé mentale de ses contributeurs et la survie même du projet.

La montée en puissance du fléau des rapports “slop”

Le terme AI slop (déchets générés par l’IA) décrit parfaitement la nature du problème. Il s’agit de contenus générés automatiquement qui imitent la forme de rapports techniques sérieux mais manquent totalement de substance, de vérification ou de pertinence. Dans le cas de curl, ces rapports inondent la plateforme HackerOne, saturant l’attention des mainteneurs.

Daniel Stenberg a détaillé l’ampleur du phénomène dans un message à sa liste de diffusion personnelle. Il a rapporté avoir reçu sept soumissions en seulement seize heures, dont aucune n’a finalement identifié une véritable vulnérabilité. « Nous avons maintenant compté vingt soumissions dès le début de 2026 », explique-t-il. Cette charge de travail supplémentaire, qui ne génère aucun résultat positif, est devenue intenable pour une petite équipe de bénévoles.

Citation : « L’objectif principal de la fermeture du programme de récompenses est de supprimer l’incitation pour les gens de nous soumettre des rapports de mauvaise qualité et mal recherchés. Que ce soit généré par l’IA ou non. Le torrent actuel de soumissions impose une charge importante sur l’équipe de sécurité de curl, et c’est une tentative de réduire le bruit. » — Daniel Stenberg, fondateur et développeur principal de curl.

Ce n’est pas un problème isolé. Stenberg a partagé des données indiquant que le taux de soumission pour curl a connu une augmentation vertigineuse en 2025, alors que d’autres programmes open-source hébergés sur HackerOne sont restés stables. Cette divergence suggère que le projet est spécifiquement ciblé, probablement en raison de sa popularité et de la nature de son code, qui peut sembler accessible à des scripts automatisés.

L’impact sur la sécurité et la viabilité du projet open-source

La décision de retirer le programme de bug bounty a des implications profondes. Historiquement, ces programmes ont été un pilier de la sécurité logicielle, incitant les chercheurs en sécurité à trouver et à signaler des vulnérabilités de manière responsable, en échange de récompenses financières. Pour un projet comme curl, utilisé par des millions d’applications et de serveurs, ce système a permis de renforcer la sécurité au fil du temps, notamment face aux menaces comme les ransomwares et les attaques de la chaîne d’approvisionnement.

Toutefois, le rapport coût-bénéfice s’est inversé. L’équipe de sécurité de curl, déjà réduite, doit désormais trier manuellement une masse de soumissions non pertinentes. Ce travail ingrat consomme un temps précieux qui pourrait être alloué au développement, à la maintenance ou à la gestion de véritables vulnérabilités. Le risque est double : d’une part, la fatigue des mainteneurs menace la pérennité du projet ; d’autre part, le bruit ambiant risque de masquer les signaux faibles de menaces réelles.

Stenberg a souligné cet aspect dans les commentaires de la demande de retrait (pull request) : « Retirer de HackerOne n’arrêtera probablement pas la marée de rapports de mauvaise qualité. Cependant, curl est un petit projet open-source avec un nombre limité de mainteneurs actifs. Pour assurer sa survie et protéger la santé mentale des développeurs, je devais prendre cette mesure. »

Les nouvelles procédures de signalement et la fin des récompenses

Le changement s’opère en plusieurs étapes. Jusqu’au 31 janvier 2026, curl continue d’accepter les soumissions via HackerOne. Tous les rapports en cours à cette date seront traités normalement. À partir du 1er février 2026, la plateforme HackerOne sera fermée pour de nouvelles soumissions.

Les chercheurs en sécurité souhaitant signaler une vulnérabilité dans curl ou libcurl devront désormais utiliser la voie traditionnelle : créer un ticket sur le dépôt GitHub du projet. Cette méthode est plus directe et ne comporte aucune incitation financière.

Le projet a également mis à jour son fichier security.txt, qui décrit désormais clairement la nouvelle politique :

Nous ne proposons aucune compensation monétaire pour les vulnérabilités signalées.
Nous n'aidons pas les chercheurs à obtenir des récompenses auprès de tiers.
Les personnes qui soumettent des rapports de mauvaise qualité seront bannies et ridiculisées publiquement.

Cette dernière phrase, bien que brutale, est un signal fort pour dissuader les soumissions opportunistes. Elle reflète la frustration d’une communauté qui voit son travail bénévole érodé par des pratiques automatisées et sans éthique.

Une crise plus large : l’automatisation contre la sécurité

Le cas de curl n’est que la partie émergente de l’iceberg. L’utilisation de l’IA pour générer du contenu malveillant ou de mauvaise qualité est un problème croissant dans de nombreux domaines : le spam de courriels, les faux avis produits, les tentatives de phishing, et maintenant, les rapports de bugs. Les outils d’IA grand public permettent à n’importe qui, sans compétence technique, de produire des textes qui semblent plausibles à première vue.

Dans le contexte de la sécurité logicielle, cela crée un nouveau vecteur de déni de service. Il suffit de quelques lignes de code pour automatiser la soumission de rapports basés sur des modèles pré-établis, ciblant des projets populaires. Les plateformes comme HackerOne sont conçues pour faciliter la collaboration, mais elles peinent à filtrer ce type de soumissions à grande échelle.

Tableau comparatif : Avant et après la fin du bug bounty

Recommandations pour les chercheurs en sécurité et les organisations

Cette situation offre des leçons précieuses pour tous les acteurs de l’écosystème de la sécurité.

1. Qualité sur la quantité : Les organisations doivent revoir leurs critères de soumission. Exiger une démonstration fonctionnelle, une analyse d’impact et des preuves de concept solides peut filtrer la majorité des rapports générés par l’IA.
2. Diversifier les canaux : Se reposer uniquement sur une plateforme comme HackerOne peut être risqué. Maintenir des canaux alternatifs (GitHub, courriel) offre une flexibilité précieuse.
3. Mise à jour des politiques : Comme curl, il est crucial de communiquer clairement les attentes et les conséquences des soumissions de mauvaise foi. Une politique de tolérance zéro pour les abus est nécessaire.
4. Utilisation d’outils d’analyse : Les projets open-source, souvent sous-financés, pourraient bénéficier d’outils d’analyse statique ou dynamique automatisés pour détecter les vulnérabilités courantes, réduisant ainsi la dépendance aux soumissions externes. Par ailleurs, les chercheurs doivent veiller à la sécurité de leurs propres environnements, comme la suppression des mots de passe sauvegardés dans les navigateurs.

Conclusion : Un nouveau paradigme pour la sécurité open-source

La fin du programme de bug bounty de curl n’est pas une défaite, mais une adaptation nécessaire à un environnement en mutation. Elle souligne les limites des modèles de sécurité traditionnels face à l’automatisation malveillante. Pour la communauté open-source, l’heure est à la prudence et à la réinvention.

Les mainteneurs sont contraints de prioriser leur bien-être et la viabilité de leurs projets. Les chercheurs en sécurité authentiques devront s’adapter à un processus plus informel, basé sur la réputation et la qualité du travail, plutôt que sur les récompenses financières. Finalement, cet événement marque un retour à l’essence même du logiciel libre : la collaboration communautaire, fondée sur la confiance et le respect mutuel, plutôt que sur des transactions financières. La sécurité de curl, et celle de nombreux autres projets, reposera désormais sur la vigilance collective et la qualité des contributions, pas sur le volume des soumissions.

Prochaine étape : Si vous êtes développeur ou chercheur, prenez le temps de revoir les politiques de sécurité des projets que vous utilisez ou que vous ciblez. Une communication claire et des attentes réalistes sont la première ligne de défense contre le slop généré par l’IA.