Un bug à 25 $ qui en vaut 500 000 : l'IA vient de faire voler en éclats l'économie des VDP

Le coût de la découverte d’un bug critique vient de s’effondrer. Un chercheur de Searchlight Cyber a lancé un modèle de pointe sur le cœur de WordPress, dépensé environ 25 $ de calcul en une dizaine d’heures, et mis au jour une injection SQL pré-authentification qui dégénère en exécution de code à distance — une classe de bugs que les courtiers en exploits valorisent jusqu’à 500 000 $. Ce n’est pas une histoire de spam généré par IA. C’est l’inverse, et c’est le scénario catastrophe que presque aucun programme de divulgation des vulnérabilités n’avait budgété : un afflux de découvertes réellement valides et réellement critiques, arrivant plus vite qu’aucune équipe de triage humaine ne puisse en accuser réception, les vérifier ou les payer.

Si vous gérez un VDP ou un programme de bug bounty, tout votre modèle de coûts repose sur une hypothèse tacite : trouver un bug critique coûte cher et reste rare. Cette hypothèse vient de voler en éclats. Voici ce que cela change pour vos SLA, votre budget de primes et votre file de triage — et ce qu’il faut modifier dès ce trimestre.

Ce qui s’est réellement passé, et ce qui est vérifié

Adam Kues, chercheur chez Searchlight Cyber, a transformé une recette de prompts IA en un dispositif multi-agents de chasse aux vulnérabilités, puis a pointé un modèle de pointe sur le code source de WordPress. D’après lui, il a fallu plus de dix heures d’exécution du modèle, et environ 25 $, pour découvrir une injection SQL pré-authentification débouchant sur une RCE. Il l’a ensuite reproduite sur une installation WordPress standard, en demandant au modèle de dérober l’adresse e-mail de l’administrateur : le modèle a affiché l’adresse en quelques minutes. Il a suspendu la publication et préparé un rapport de divulgation.

Deux points d’ancrage comptent ici, et un seul est vérifié de manière indépendante. Le chiffre de 25 $ et les dix heures d’exécution relèvent du récit que le chercheur fait de son propre travail : à prendre comme rapportés, non comme établis. La valorisation à 500 000 $, elle, est vérifiable : la grille tarifaire publique de l’Exploit Acquisition Program de Crowdfense affiche « WordPress (RCE) : 500 000 USD », au même niveau que l’exécution de code à distance sur Apache HTTP Server et Microsoft IIS, au-dessus de Nginx à 350 000 $ et bien au-dessus d’autres systèmes de gestion de contenu comme Joomla (40 000 $) ou Drupal (25 000 $). Le plafond du marché gris est réel, pas une figure de style. Aucun CVE n’a été attribué dans la source, et la désignation exacte du modèle relève du cadrage de l’article, non d’une fiche produit.

L’écart, c’est toute l’histoire. Coût pour le trouver : environ 25 $. Valeur pour un attaquant : jusqu’à un demi-million de dollars. Ces deux chiffres étaient autrefois à peu près corrélés, parce qu’une expertise humaine rare s’intercalait entre eux. L’IA vient de supprimer l’humain comme goulot d’étranglement.

Le « contenu IA bâclé » était le problème facile

Depuis deux ans, la conversation du secteur sur l’IA et les bug bounties tourne autour du bruit. CVE fabriqués, noms de fonctions hallucinés, rapports générés à partir de modèles — ce flot de déchets de piètre qualité qui a poussé Daniel Stenberg, mainteneur de curl, à dénoncer publiquement les rapports générés par IA qui lui font perdre son temps. Nous avons nous-mêmes traité de ce scénario dans Contenu IA bâclé et bug bounty : trier un VDP submergé. Le contenu bâclé fait perdre des heures de triage. C’est agaçant, c’est coûteux à grande échelle, et les défenseurs ont fourni de réels efforts pour régler des filtres capables de le rejeter.

La découverte WordPress, c’est l’inverse — et sans doute pire. Il s’agit d’un signal de haute qualité et de forte gravité, produit à la vitesse de la machine et à un coût marginal quasi nul. Le contenu bâclé menace votre temps de triage. Un déluge de véritables vulnérabilités critiques menace trois choses à la fois : votre SLA d’accusé de réception, votre budget de primes et votre chaîne de correctifs. Vous avez réglé votre filtrage d’entrée pour rejeter les déchets. Vous n’aviez pas budgété une abondance d’or.

La réalité opérationnelle est inconfortable : les deux scénarios catastrophe arrivent désormais de concert. La même technologie qui produit des vulnérabilités critiques valides fabrique aussi de faux rapports convaincants, des CVE réels mais anciens resoumis comme neufs, des références de code plausibles vers des fonctions qui n’existent pas. Le triage ne peut plus partir du principe qu’un rapport est soit fiable, soit bon pour la corbeille. Il doit supposer que les deux modes coexistent dans la même file, chaque jour.

Pourquoi une découverte bon marché fait exploser l’économie des bug bounties

La tarification des bug bounties encode un marché implicite. Trouver un bug critique coûte cher et reste rare : une récompense de quelques milliers de dollars constitue donc un partage équitable de la valeur avec un expert rare qui a préféré la divulgation au marché gris. Lorsque le coût de découverte s’effondre à 25 $, ce marché s’inverse. Le courtier paie toujours 500 000 $, car la valeur offensive d’une RCE pré-authentification sur des centaines de millions d’installations n’a pas changé. Mais le paiement du programme, souvent un à trois ordres de grandeur en dessous, ressemble désormais à une erreur d’arrondi face à la valeur réelle du bug comme au volume de ceux qui vont affluer.

Mettez trois chiffres dans le même cadre :

Le décalage ne tient pas à la pingrerie des programmes. Il tient au fait que l’effondrement du coût de découverte a creusé un écart déjà large entre ce qu’un bug vaut pour un attaquant et ce qu’un défenseur peut raisonnablement payer, tout en multipliant le nombre de bugs de ce type qu’un programme va recevoir. Un chercheur capable de produire des vulnérabilités critiques pour 25 $ pièce se retrouve face à un choix tranché : soumettre à un programme qui paie 5 000 $ au mieux et impose des conditions de divulgation, ou vendre à un courtier pour 500 000 $. Une découverte bon marché ne fait pas que peser sur la capacité de triage. Elle renforce l’attrait du marché gris précisément pour les découvertes de plus forte gravité que votre programme a le plus besoin de recevoir.

Aucun programme auto-hébergé n’égalera jamais un courtier. Ce n’est pas le but, et prétendre le contraire ruine votre crédibilité. L’objectif réaliste est de capter la vaste population de chercheurs qui préféreraient divulguer, à condition que la friction et l’écart de paiement restent importants sans devenir insultants. C’est un problème de conception de programme, et il a trois leviers.

Les trois choses que tout responsable de VDP doit réajuster dès maintenant

Une découverte bon marché n’exige pas une nouvelle plateforme. Elle exige de réajuster trois primitives que votre programme possède déjà, ou devrait posséder : les niveaux de SLA, l’économie des récompenses et la capacité de triage. Le module CSIRT auto-hébergé de Kit encode chacune d’elles sous forme de configuration ; j’utiliserai donc ses valeurs par défaut comme point de repère concret. Les principes valent que vous utilisiez Kit, HackerOne, ou un simple security.txt doublé d’une boîte de réception partagée.

Réajuster le SLA : séparer « nous vous avons entendu » de « nous avons corrigé »

Un SLA uniforme s’effondre sous un afflux de vulnérabilités critiques valides. La solution consiste à scinder une promesse en deux. L’accusé de réception est rapide et peu coûteux : il dit « un humain a votre rapport et le chronomètre tourne ». La résolution est lente et coûteuse : elle dit « c’est corrigé ». Les confondre, c’est laisser chaque pic de rapports entrants menacer votre engagement public à corriger les choses dans un délai que vous ne maîtrisez plus.

Réservez vos fenêtres de résolution les plus serrées au seul niveau de gravité supérieur, pour qu’une vague de vulnérabilités critiques ne puisse pas saturer votre file par déni de service. Le Csirt::SlaConfig de Kit livre cette forme par défaut : une promesse d’accusé de réception de 72 heures, puis des cibles de résolution graduées par gravité — 24 heures pour super critique, 72 heures pour critique, 7 jours pour élevée, et des délais progressivement plus longs pour moyenne et faible. L’idée directrice : l’accusé de réception reste constant et peu coûteux, tandis que la résolution s’ajuste à la gravité. Quand une centaine de rapports valides arrivent en une semaine, vous pouvez encore tenir « nous vous avons entendu, sous 72 heures » pour tous, et tenir « nous avons corrigé, sous 24 heures » uniquement pour les véritables 10.0.

Retarifer les récompenses : bâtir un niveau supérieur défendable et une politique de déduplication

Votre vocabulaire de gravité a besoin d’un palier au-dessus de « critique ». L’IA s’apprête à faire remonter plus de véritables CVSS 10.0 que les programmes n’en voyaient historiquement en un an, et une RCE pré-authentification sur un immense parc d’installations, c’est précisément cela. Kit modélise ce cas avec un niveau super_critical (CVSS 10.0) placé au-dessus de critical (9.0 à 9.9), et une BountyMatrixConfig graduée qui va de 0 $ pour l’informatif jusqu’à une fourchette de 5 000 à 10 000 $ pour super critique.

Soyez honnête sur ce qu’est ce niveau supérieur. Le plafond auto-hébergé de Kit, pourtant généreux — 5 000 $ à 10 000 $ —, reste 50 à 100 fois inférieur au prix du courtier pour le bug exact qu’a trouvé Kues. Vous ne comblerez pas cet écart : cessez d’essayer. Ce que vous pouvez faire, c’est raidir la courbe et élargir le sommet, pour que les découvertes de plus forte gravité méritent clairement d’être signalées plutôt que mises de côté. Nous détaillons cela dans des niveaux de récompense bug bounty auxquels les chercheurs font vraiment confiance.

Ajoutez ensuite une politique de déduplication, car elle devient soudain déterminante. Quand de nombreux chercheurs pointent le même modèle sur la même cible populaire, la collision sur des bugs identiques n’est pas un risque : c’est le résultat prévisible. Sans une règle du premier rapport valide claire et publiée, vous userez votre crédibilité à arbitrer des litiges à égalité parfaite — le scénario exact que nous traitons dans litiges sur les primes de bug bounty : SLA et équité dans votre VDP. C’est pour cela que Kit active la déduplication par défaut dans sa TriageConfig.

Trier à la vitesse de la machine : filtrer le contenu bâclé et prioriser les vraies vulnérabilités critiques

Le triage a désormais deux missions qui tirent dans des directions opposées. Il doit rejeter des faux convaincants et valider rapidement un signal réel de forte gravité, souvent dans la même file et le même jour. Un triage au rythme humain ne peut assurer les deux en grand volume.

La présélection en est la première moitié. Le Csirt::AiScreening de Kit attribue un ai_confidence_score (0.0 à 1.0, la probabilité qu’un rapport soit du contenu IA bâclé) et signale des indices de fabrication connus : fonctions hallucinées, CVE fabriqués, CVE antérieur cité comme nouveau, ou rapports sans preuve de concept précise. Cette couche a été bâtie pour le problème du contenu bâclé, et elle doit toujours tourner, car ce contenu ne va pas disparaître.

Mais la présélection ne règle que la moitié du nouveau problème. Le vrai front, c’est de prioriser en urgence les vulnérabilités critiques valides. Cela suppose une escalade automatique et un routage vers l’astreinte, pour qu’une vulnérabilité super critique ne reste jamais en file à attendre que quelqu’un la remarque. La TriageConfig de Kit prend en charge des gravités d’escalade (critique et super_critical par défaut), des exigences de retest et l’auto-attribution à l’astreinte, reliée à une rotation d’astreinte et à PagerDuty. La leçon pour tout responsable de programme : filtrer le contenu bâclé est désormais un prérequis de base ; la validation rapide et la priorisation du signal réel en grand volume, voilà la capacité qu’il vous faut réellement bâtir ensuite.

Que faire ce trimestre

Vous ne pouvez pas surenchérir sur un courtier, et vous n’en avez pas besoin. Il vous faut un programme assez rapide, crédible et bien outillé pour qu’un chercheur qui préfère divulguer n’ait aucune excuse liée à la friction pour passer plutôt par un courtier. Concrètement :

1. Scindez votre SLA. Publiez une fenêtre d’accusé de réception rapide et constante, et des fenêtres de résolution graduées par gravité. Réservez votre cible de résolution la plus serrée à un niveau supérieur au-dessus de « critique ».
2. Ajoutez un palier super critique et retarifez le sommet. Élargissez et raidissez la courbe des primes pour que les véritables 10.0 méritent d’être signalés. Acceptez l’écart avec les prix des courtiers ; ne comblez que celui qui rend votre offre insultante.
3. Publiez une règle de déduplication avant d’en avoir besoin. Le premier rapport valide et entièrement reproductible l’emporte. Écrivez-le noir sur blanc maintenant, pas au milieu d’un litige.
4. Menez un triage à double face. Notez la probabilité d’origine IA pour attraper les faux, et escaladez automatiquement les vulnérabilités critiques valides vers l’astreinte pour que rien de grave n’attende en file.
5. Instrumentez le délai d’accusé de réception. Si vous ne voyez pas votre délai d’accusé de réception par gravité, vous ne pourrez pas le défendre quand le volume arrivera.

Le coût de la découverte d’un bug critique est tombé à 25 $. Sa valeur pour un attaquant n’a pas bougé. Votre programme vit dans l’écart entre ces deux chiffres, et cet écart vient de s’élargir et de se remplir. Les programmes qui survivront à l’année qui vient ne seront pas ceux dotés des plus grosses cagnottes de primes. Ce seront ceux qui accusent réception vite, tarifent honnêtement, dédupliquent équitablement et escaladent les vraies vulnérabilités critiques avant même que quiconque n’ouvre le ticket.

Comment le CSIRT de Kit encaisse l’afflux

Kit est une plateforme nativement IA pour startups, et son module CSIRT et VDP auto-hébergé existe précisément parce que les fondateurs finissent par hériter du triage de sécurité par défaut. Il fournit les quatre leviers qu’exige ce basculement sous forme de configuration plutôt que de projet : un palier de gravité super_critical au-dessus de critique, des SLA d’accusé de réception et de résolution distincts, une grille des primes graduée que vous pouvez retarifer, la déduplication et l’escalade automatique vers l’astreinte, et une présélection IA qui note la probabilité qu’un rapport soit du contenu bâclé.

Ce qu’il ne fait pas, c’est prétendre être un courtier à 500 000 $ — et c’est là tout l’intérêt de cette honnêteté. Un programme bien outillé, rapide et transparent capte les chercheurs qui préfèrent divulguer plutôt que vendre, tant que vous ne rendez pas la divulgation lente, opaque ou insultante. La courbe de coût de la découverte des bugs critiques s’est effondrée. La conception de votre programme est le seul levier que vous maîtrisez encore entièrement : réglez-le avant le déluge, pas pendant.