Contenu IA bâclé et bug bounty : trier un VDP submergé
En 2026, curl, HackerOne et Nextcloud ont tous plié sous le contenu IA bâclé déversé dans les bug bounties. Voici le manuel de triage qui garde un VDP en vie sous le volume.
Ernest Bursa
Pour trier les rapports de bug bounty générés par IA, actionnez cinq leviers dans l’ordre : (1) un premier filtrage assisté par IA qui signale automatiquement les fonctions hallucinées et l’absence de preuve de concept avant qu’un humain ne lise le rapport, (2) une limitation de débit dès la réception pour qu’un seul acteur ne puisse pas noyer la file, (3) un score de réputation qui pénalise le contenu bâclé avéré, (4) un suivi des SLA qui protège le temps rare des relecteurs, et (5) des primes qui rémunèrent l’impact, pas le nombre de soumissions. Les programmes qui se sont éteints en 2026 n’avaient pas un problème de contenu bâclé. Ils avaient un problème de triage.
Si vous gérez une boîte de réception security.txt, un programme de divulgation des vulnérabilités (VDP) ou un bug bounty, vous le sentez déjà. Le volume de soumissions grimpe et le taux de rapports valides s’effondre. Chaque rapport plausible mais bidon coûte encore entre 30 minutes et trois heures à un ingénieur senior pour être réfuté. C’est le problème de l’exploitation sous charge : la question n’est pas « faut-il avoir un VDP » (oui, et nous avons couvert comment en monter un), mais « la file déborde, comment la garder en vie sans épuiser les relecteurs ni perdre les vrais chercheurs ? »
Les victimes de 2026 : curl, HackerOne et Nextcloud
Au premier semestre 2026, trois des noms les plus crédibles de la divulgation de vulnérabilités ont visiblement plié sous le bruit généré par IA. Ce ne sont pas des programmes marginaux. Ce sont les implémentations de référence d’une divulgation bien menée, et ils ont tous heurté le même mur : le coût de production d’un faux rapport est tombé à presque zéro tandis que celui de sa réfutation est resté humain, et élevé.
Pourquoi curl a débranché la prise
curl a fermé son bug bounty HackerOne à compter du 31 janvier 2026. Son fondateur, Daniel Stenberg, documentait le déclin depuis des mois. Dans son billet de juillet 2025 « Death by a thousand slops », il rapportait qu’environ 20 % de toutes les soumissions de 2025 étaient du contenu IA bâclé et que seulement 5 % environ des soumissions de 2025 se révélaient être de véritables vulnérabilités, une chute brutale par rapport aux années précédentes (source : daniel.haxx.se).
L’arithmétique était impitoyable à l’échelle humaine. Chaque rapport mobilisait trois à quatre des sept membres de son équipe de sécurité pendant 30 minutes à environ trois heures de validation, presque exclusivement du temps bénévole. Le début 2026 a tranché à sa place : sur les 21 premiers jours de 2026, curl a reçu une vingtaine de soumissions et confirmé zéro vulnérabilité, dont sept rapports HackerOne dans une seule fenêtre de 16 heures (source : daniel.haxx.se ; BleepingComputer).
Depuis le 1er février 2026, curl redirige les rapports vers le signalement privé de GitHub et [email protected], sans récompense monétaire, explicitement, selon les mots de Stenberg, pour « supprimer l’incitation à soumettre de la camelote ». Sur toute sa durée de vie, le programme a payé pour 87 vulnérabilités confirmées et plus de 100 000 dollars depuis 2019. La prime a fonctionné pendant des années. C’est le contenu IA bâclé qui l’a brisée.
La hausse de 76 % chez HackerOne et la pause de l’Internet Bug Bounty
HackerOne a fait deux gestes distincts. D’abord, son Internet Bug Bounty (IBB), le fonds mutualisé qui rémunère les dépendances open source critiques, a suspendu les nouvelles soumissions fin mars 2026, en invoquant un déséquilibre entre la découverte assistée par IA et la capacité humaine de remédiation (source : Privacy Guides ; InfoWorld).
Ensuite, en avril 2026, en parallèle du lancement d’un service de validation payant, HackerOne a dévoilé le chiffre macro qui a fait les gros titres : les soumissions de vulnérabilités ont bondi de 76 % sur un an, atteignant un record en mars 2026, tandis qu’environ 25 % des découvertes ont été confirmées exploitables, un taux resté à peu près stable (source : communiqué de presse HackerOne). Lisez ce chiffre attentivement : le nombre absolu de vrais bugs continue de croître, mais le bruit qui les entoure aussi, et le bruit croît plus vite. En mai 2026, l’IBB a fortement réduit les montants des récompenses sur tous les niveaux de sévérité (source : The Register).
Le phénomène touche tout l’écosystème
Il serait facile de balayer curl comme un projet open source sous-financé et HackerOne comme les douleurs de croissance d’une seule plateforme. Le schéma est plus large que cela.
| Programme | Ce qui s’est passé | Quand |
|---|---|---|
| Nextcloud | A mis fin aux primes en invoquant une « augmentation massive de rapports de faible qualité » ; a gardé la réception ouverte jusqu’à « trouver comment filtrer correctement les soumissions » | Avril 2026 |
| A cessé d’accepter certains rapports générés par IA | Mars 2026 | |
| Cosmos Labs (crypto) | Le co-PDG a fait état d’un bond de 900 % sur un an, soit 20 à 50 soumissions par jour | 2026 |
| Bugcrowd | Les soumissions ont plus que quadruplé sur une période de trois semaines, en majorité des faux positifs ou des découvertes IA de faible qualité | Mars 2026 |
| Noyau Linux | Linus Torvalds a qualifié la liste de sécurité de « quasiment ingérable » sous les doublons de rapports assistés par IA | 2026 |
Sources : heise ; Computing.co.uk ; Cointelegraph via TradingView.
La formule de Nextcloud est la plus parlante. Ils n’ont pas coupé la réception. Ils ont gardé le canal ouvert et arrêté de payer jusqu’à pouvoir filtrer correctement. Cet écart, « nous voulons les rapports mais n’avons pas les moyens de les trier », c’est exactement le problème dont traite cet article.
Pourquoi le contenu IA bâclé casse l’économie des bug bounties
Un bug bounty est un mécanisme de signal coûteux. L’hypothèse de départ : un humain a investi un effort réel pour trouver un bug, il produit donc un rapport précis et reproductible, et le trier vaut le temps du relecteur. Tout le modèle repose sur le fait que l’effort de soumission soit assez cher pour filtrer le bruit à la source.
L’IA fait s’effondrer cette hypothèse. Elle rend la production d’un rapport d’apparence plausible quasiment gratuite, alors que le coût de sa réfutation reste obstinément humain. Un rapport généré peut citer un CVE d’apparence réelle, décrire une fonction d’apparence réelle et exposer des étapes de reproduction assurées, le tout halluciné. Un relecteur doit malgré tout ouvrir le code, suivre la piste de l’affirmation et prouver une négation. Prouver qu’un bug est réel est rapide. Prouver qu’un faux convaincant n’est pas réel est lent.
Et c’est pire encore. L’IA a tendance à faire remonter de nombreuses instances du même problème sous-jacent, le même motif de cross-site scripting avec vingt charges utiles différentes, et à soumettre chacune comme une découverte distincte. Le volume gonfle sans que la sécurité progresse. Le goulot d’étranglement se déplace entièrement vers la validation, la seule partie du pipeline que vous ne pouvez pas automatiser à moindre coût par défaut (source : Pen Test Partners).
À garder en perspective : les VDP et les bug bounties affichaient historiquement 60 à 80 % de soumissions invalides, même avant l’IA (source : Yogosha). La taxe de triage a toujours existé. L’IA n’a pas inventé le problème. Elle a supprimé la limite de débit naturelle qui le gardait supportable.
Le manuel de triage : cinq leviers qui gardent un VDP en vie
On ne règle pas cela avec un seul outil. On le règle en inversant l’économie : en augmentant le coût de soumission du contenu bâclé et en réduisant le coût de son filtrage. Voici les cinq leviers, par ordre d’effet de levier.
- Premier filtrage assisté par IA à la réception. Classez automatiquement le contenu manifestement bâclé (fonctions hallucinées, CVE fabriqués, absence de preuve de concept, langage de modèle générique) avant qu’un humain n’y passe une heure.
- Limitation de débit et contrôles anti-spam. Un plafonnement à fenêtre glissante pour qu’un seul acteur ne puisse pas noyer la file en une rafale de 16 heures.
- Score de réputation qui pénalise le contenu bâclé. Faites en sorte que le contenu bâclé avéré coûte quelque chose à l’auteur, pour que les récidivistes s’auto-excluent.
- Suivi des SLA qui protège le temps des relecteurs. Accusez réception et résolvez dans les temps pour que les vrais chercheurs ne rendent pas public par frustration.
- Des primes pour l’impact, pas pour le volume. Payez selon la sévérité, fixez les découvertes informatives à zéro, et imposez la consolidation pour que mille découvertes identiques ne soient payées qu’une fois.
1. Premier filtrage assisté par IA à la réception
Le geste à plus fort effet de levier consiste à empêcher les soumissions brutes d’atteindre un humain en premier. Une passe de tri par LLM peut repérer les indices que presque tout rapport bâclé partage : des références à des fonctions ou des éléments de code qui n’existent pas, des CVE cités comme nouveaux alors qu’ils ont des années ou sont fabriqués, du texte de remédiation générique, et l’absence de toute preuve de concept précise et exécutable.
Le choix de conception décisif, c’est que ce filtrage est assistant, pas un rejet automatique. La première passe doit recommander, pas décider : haute confiance pour passer, à examiner, ou à signaler. Un humain tranche encore tout cas limite. Vous ne construisez pas un robot gardien. Vous construisez un Choixpeau qui détourne le contenu manifestement bâclé de l’attention de vos ingénieurs seniors.
2. Limitation de débit et contrôles anti-spam
curl a reçu sept rapports en 16 heures. Aucune équipe humaine ne trie cela en temps réel. Un simple plafonnement à fenêtre glissante, disons cinq rapports par acteur toutes les cinq minutes avant un blocage temporaire, neutralise le schéma de rafale-déluge sans gêner les chercheurs légitimes, qui ne soumettent presque jamais en rafale. C’est le levier le moins coûteux à mettre en place et l’un des plus efficaces contre la forme d’attaque spécifique de 2026.
3. Score de réputation qui pénalise le contenu bâclé
Les systèmes de karma sont une vieille histoire dans l’univers des bounties, mais la plupart ne récompensent que le travail valide. L’environnement de 2026 exige l’inverse : le contenu bâclé avéré et le spam rejeté devraient retirer des points. Quand la réputation d’un auteur baisse, vous pouvez restreindre ses futures soumissions ou les déprioriser automatiquement. L’objectif est de donner un coût au contenu bâclé, pour que ceux qui jouent le volume cessent d’y trouver leur compte.
4. Suivi des SLA qui protège le temps des relecteurs
Voici le lien que l’on rate : le suivi des SLA ne sert pas seulement à être réactif. Il sert à ne pas perdre les bons chercheurs. Les vrais chercheurs rendent public quand les accusés de réception traînent, que les correctifs sont déployés en silence, ou que la sévérité est discrètement revue à la baisse, c’est exactement le mode de défaillance que nous avons couvert dans quand les chercheurs rendent public. Sous la charge du contenu bâclé, les délais d’accusé de réception sont les premiers à déraper, et c’est précisément le moment où vous pouvez le moins vous permettre d’aliéner les vrais auteurs noyés dans le bruit. Un compteur d’accusé de réception (72 heures, par exemple) plus des objectifs de résolution par sévérité gardent à vos côtés les personnes avec qui vous tenez le plus à continuer de vous coordonner.
5. Des primes pour l’impact, pas pour le volume
Si votre prime paie par découverte acceptée quelle que soit la sévérité, vous payez les gens pour soumettre du volume, et l’IA se fait un plaisir d’obtempérer. Liez les versements à une grille de sévérité où les découvertes informatives paient 0 $ et où seul l’impact réel paie de l’argent réel. Couplez cela à une déduplication pour que mille instances d’un même bug racine se résolvent en un ticket et un versement. C’est exactement le levier que curl a fini par actionner : retirer l’incitation monétaire à soumettre de la camelote. Vous n’êtes pas obligé d’aller jusqu’au zéro comme curl, mais vous devez cesser de récompenser la quantité.
Ne jetez pas les bons chercheurs assistés par IA
L’ennemi, c’est le volume non validé, pas l’IA. La distinction compte, car la réaction paresseuse, « interdire les rapports assistés par IA », écarterait vos meilleurs contributeurs.
Le contre-exemple le plus net est Joshua Rogers, dont le travail assisté par IA a fait remonter une cinquantaine de vrais bugs dans curl, chacun validé par un humain avant soumission. Mêmes outils que les marchands de contenu bâclé, résultat inverse, parce qu’un humain compétent se tenait entre le modèle et le bouton « envoyer ». Stenberg a été explicite : la recherche assistée par IA menée de façon responsable est la bienvenue ; c’est le déluge de production non vérifiée qu’il ne peut pas absorber.
Le manuel a donc une tâche précise : filtrer sur les preuves et la validité, pas sur la participation ou non de l’IA. Un rapport avec une preuve de concept fonctionnelle et une vraie référence de code passe, qu’il ait été rédigé par un humain ou un modèle. Un rapport avec des fonctions hallucinées et sans PoC échoue pour la même raison, quel que soit son auteur. Filtrez le signal, pas l’outil.
Comment Kit rend ce manuel opérationnel
Voici la vérité inconfortable pour toute équipe qui construirait cela en interne : les cinq leviers ci-dessus représentent environ six mois d’outillage maison. La verticale Csirt:: de Kit les implémente sous forme de configuration. La correspondance est presque terme à terme.
| Levier du manuel | Fonctionnalité Kit CSIRT | Ce qu’elle fait |
|---|---|---|
| Premier triage assisté par IA | Csirt::AiScreening |
Le tri par LLM renvoie pass / review / flag selon la confiance, et détecte les signaux explicites de contenu bâclé : fonctions hallucinées, CVE fabriqués, CVE antérieur cité comme nouveau, remédiation générique, absence de PoC précise, langage de modèle, étapes de reproduction vagues, références à du code inexistant |
| Limitation de débit / anti-spam | Csirt::SpamConfig |
Plafonnement à fenêtre glissante (par défaut 5 rapports par 5 minutes, puis blocage temporaire) avec blocage automatique en cas de récidive |
| Réputation qui pénalise le contenu bâclé | Csirt::KarmaEvent |
Le contenu IA bâclé avéré coûte du karma à l’auteur ; le rejet pour spam et le « non applicable » en retirent aussi ; les résolutions valides et les primes en ajoutent, avec des bonus de sévérité |
| Déduplication | Csirt::TriageConfig |
Déduplication activée par défaut, pour que les instances répétées d’une même cause racine ne deviennent pas une centaine de tickets |
| Suivi des SLA | Csirt::SlaConfig |
Compteur d’accusé de réception (72 h par défaut) plus des objectifs de résolution par sévérité |
| Primes basées sur l’impact | Csirt::BountyMatrixConfig |
Tranches de versement par niveau de sévérité ; l’informatif paie 0 $, jusqu’au critique |
| Prise en charge sous la charge | Csirt::OnCallConfig |
Assignation automatique de l’astreinte pour que les accusés de réception ne dérapent pas quand la file s’emballe |
| Moins de bruit hors périmètre |
Csirt::ScopeConfig, Csirt::SecurityTxtConfig
|
Un périmètre et une politique publics réduisent les soumissions invalides à la source |
Une précision sur le tri par IA : c’est un triage assistant, une recommandation accompagnée d’un score de confiance, pas un rejet automatique. Les humains tranchent encore chaque flag et chaque review. Kit ne prétend pas bloquer tout le contenu bâclé. Il filtre la première passe et réajuste le prix des incitations pour que les heures de vos relecteurs aillent aux vrais bugs, et qu’un rapport à la Joshua Rogers avec une PoC fonctionnelle passe sans accroc tandis qu’un rapport halluciné se fait intercepter.
À retenir : un problème de contenu bâclé est en réalité un problème de triage
Les programmes qui se sont éteints en 2026 n’ont pas été battus par l’IA. Ils ont été battus par un pipeline de réception conçu pour un monde de signal coûteux qui n’existe plus. Le contenu bâclé n’est que du volume. La défaillance était structurelle : pas de première passe automatique, pas de limitation de débit, pas de pénalité de réputation, et une prime qui payait la quantité.
Chacun de ces points est corrigeable, et chacun est un réglage plutôt qu’un projet de recherche. Si vous montez un programme de zéro, commencez par le guide de mise en place d’un VDP. Si vous êtes déjà sous l’eau, le geste consiste à inverser l’économie : automatisez la première passe, endiguez les déluges, donnez un coût au contenu bâclé, protégez le temps de vos relecteurs avec des SLA, et ne payez jamais que pour un impact réel. Gardez dehors les rapports qui ont tué curl, et dedans les rapports à la Joshua Rogers.
C’est exactement ce que le module CSIRT de Kit est conçu pour faire. Démarrez un essai gratuit et transformez une boîte de réception submergée en une file filtrée, à débit limité et adossée à des SLA.
Articles similaires
Pret a recruter plus intelligemment ?
Commencez gratuitement. Aucune carte de credit requise. Configurez votre premier pipeline de recrutement en quelques minutes.
Commencer gratuitement