Après Mythos : pourquoi les bug bounties ont besoin de preuves plus solides

Il y a quelques semaines, j’ai écrit sur Anthropic Mythos et Project Glasswing. À ce moment-là, je regardais surtout la grande ligne : si les modèles deviennent vraiment meilleurs pour retrouver d’anciennes vulnérabilités, combiner des chemins d’exploitation et comprendre des bases de code entières, alors la recherche de vulnérabilités change.

Le nouvel article de Sophos sur les bug bounties à l’ère Mythos montre maintenant le côté opérationnel de ce changement.

La question n’est plus seulement de savoir si l’IA trouve de meilleures failles. La question est de savoir si les programmes de bug bounty, les équipes sécurité et les organisations d’ingénierie peuvent encore distinguer assez vite les déchets, les affirmations plausibles et les vrais problèmes de sécurité.

Le vrai problème n’est pas seulement le slop IA

Quand on parle aujourd’hui d’IA et de bug bounties, on pense vite au slop : rapports générés automatiquement, messages d’erreur à moitié compris, chaînes d’exploitation inventées, affirmations non reproductibles et beaucoup de texte pour peu de substance.

C’est réel. Et pour les mainteneurs, les équipes product security et les personnes qui font le triage, c’est franchement pénible.

Mais ce n’est qu’un côté du sujet.

L’autre côté est plus dangereux : de bons chercheurs peuvent utiliser les mêmes modèles pour trouver plus vite de vraies vulnérabilités, tester des hypothèses sur de plus grandes bases de code et parcourir systématiquement les variantes d’un même motif. Ce qui prenait autrefois des jours ou des semaines de travail manuel peut arriver demain dans la file en quelques heures.

Le problème se déplace donc. Avant, on demandait souvent : recevons-nous assez de bons findings externes ? Aujourd’hui, la question devient plutôt : pouvons-nous reconnaître, valider, prioriser et transformer les vrais findings en correctifs assez vite, alors que le bruit augmente en même temps ?

Pourquoi Sophos est une source intéressante ici

L’article de Sophos n’est pas un commentaire générique sur l’IA. Sophos revient sur son propre programme de bug bounty et donne des chiffres concrets.

Selon Sophos, le programme public fonctionne sur Bugcrowd depuis décembre 2017. Sophos écrit qu’au moment de l’article, 1 343 vulnérabilités avaient été récompensées, sur 7 091 soumissions au total, pour 599 695 dollars versés.

Pour 2025, Sophos cite notamment :

• 59 400 dollars versés pour plus de 52 rapports
• environ 420 chercheurs participants
• jusqu’à 80 000 dollars pour Intercept X Endpoint sous certaines conditions
• jusqu’à 50 000 dollars pour Sophos Central
• jusqu’à 50 000 dollars pour Sophos Firewall
• 13 bugs Sophos Firewall valides en 2025, pour 21 500 dollars versés au total
• 13 bugs Sophos Central valides en 2025, pour 11 650 dollars versés au total

Ce ne sont pas des montants astronomiques, et c’est précisément pour cela qu’ils sont intéressants. Ils montrent tout le travail de tri derrière un programme déjà assez mature. Des milliers de soumissions ne veulent pas dire des milliers de vrais problèmes de sécurité. Et l’IA ne va probablement pas améliorer ce ratio.

Elle va le rendre plus dur.

La reproductibilité devient le ticket d’entrée

La conséquence la plus importante, à mon avis, est banale mais inconfortable : un rapport de sécurité sans bonne reproductibilité vaut moins.

Pas parce que les équipes de triage sont paresseuses. Parce que leur temps devient plus rare.

Si un rapport prétend montrer une exécution de code à distance, un contournement d’authentification ou une exposition critique de données, il doit prouver clairement :

• quelle version est touchée
• quelle configuration est nécessaire
• quels droits l’attaquant doit avoir
• quelles étapes mènent de manière reproductible au résultat
• quels logs, requêtes, traces ou captures soutiennent l’affirmation
• quel impact est réellement démontré
• où se situe la limite entre hypothèse et preuve

C’est strict. Et c’est volontaire. C’est ce qu’il faudra si les équipes sécurité ne veulent pas se noyer dans des textes qui sonnent juste.

Un rapport généré par IA peut paraître très convaincant. Il peut citer du code, adopter un style de CVE et simuler une structure propre. Cela ne le rend pas vrai. À l’inverse, un rapport court et sec avec un bon proof of concept peut avoir énormément de valeur.

La nouvelle monnaie n’est pas la formulation. La nouvelle monnaie, c’est la preuve.

L’IA rend les bugs d’autorisation particulièrement pénibles

Un point de l’article Sophos me paraît très concret : l’IA peut aider à étendre un contournement d’autorisation trouvé sur une surface de scope beaucoup plus large.

C’est exactement ce que l’on voit déjà dans les environnements SaaS réels. L’autorisation n’est presque jamais un seul interrupteur. Elle vit dans les rôles, tenants, IDs d’objet, sous-domaines, versions d’API, interfaces d’administration, endpoints mobiles, routes legacy et fonctionnalités à moitié migrées.

Si un chercheur trouve un motif, l’IA peut aider à tester les variantes :

• Le contournement touche-t-il un seul endpoint ou toute une famille ?
• Fonctionne-t-il seulement dans un tenant ou aussi entre tenants ?
• La même logique existe-t-elle dans les anciennes et nouvelles APIs ?
• Les rôles admin et utilisateur sont-ils vraiment séparés partout ?
• Un objet peut-il être chargé directement par ID même si l’UI ne l’afficherait pas ?

C’est là que l’IA devient dangereusement utile. Pas comme hacker magique, mais comme accélérateur de tests ennuyeux, larges et systématiques.

Et c’est mauvais pour les organisations dont la sécurité dépend encore du fait que personne n’a assez de temps pour tester toutes les variantes ennuyeuses.

Un bug bounty n’est pas une boîte de réception PR

Beaucoup d’entreprises traitent encore les bug bounties comme un sujet d’image : nous avons un programme, donc nous sommes ouverts, modernes et sérieux sur la sécurité.

Ce n’est plus suffisant.

Un programme de bug bounty est un système de production. Il lui faut des règles claires, un bon triage, une reproduction technique, une proximité produit, une responsabilité engineering et un lien avec l’incident response. Sinon, il devient simplement une boîte de réception publique où chercheurs externes, slop IA et vrais attaquants utilisent la même porte.

Sophos réunit deux points inconfortables.

D’abord : les bons chercheurs aident. Une perspective externe, d’autres modes de pensée et une pression continue sont précieux.

Ensuite : un système avec de l’argent et de la confiance peut aussi être détourné. Sophos évoque des expériences autour de Pacific Rim, Asnarök et Personal Panda, où la proximité temporelle entre exploitation active et rapports bug bounty ultérieurs a au moins soulevé des questions. Sophos ne dit pas que chaque rapport de ce type était malveillant. Mais le point opérationnel reste là : un programme de bug bounty ne peut pas être naïf.

Concrètement :

• Les rapports doivent être corrélés avec la télémétrie.
• Un nouveau finding devrait pouvoir déclencher des threat hunts rétrospectifs.
• Le triage doit savoir si des tentatives d’exploitation similaires étaient déjà visibles.
• La réputation du chercheur aide, mais ne remplace pas la vérification technique.
• Le safe harbor est important, mais ne remplace pas la détection d’abus.

La réalité sobre est celle-ci : les bug bounties font partie de Secure by Design, ils ne le remplacent pas.

Des preuves plus dures impliquent aussi plus de responsabilité

Il y a ici une tension qu’il ne faut pas masquer.

Historiquement, on dit souvent aux chercheurs : arrêtez-vous assez tôt. Montrez le bug, mais n’allez pas trop loin. Ne touchez pas aux données clients. Pas de mouvement latéral. Pas d’actions destructrices.

C’est juste.

En même temps, la charge de preuve va augmenter. Si l’IA produit en masse des rapports plausibles mais faux, les programmes demanderont plus d’éléments. La question difficile devient alors : comment un chercheur peut-il mieux prouver l’impact sans glisser vers un comportement dangereux ?

La réponse ne peut pas être : “faites simplement plus.” Elle doit devenir plus contrôlée :

• règles d’engagement plus claires
• environnements de test dédiés
• chemins de reproduction sûrs
• limites convenues pour prouver l’impact
• meilleurs sandboxes et labs
• replays automatisés de proofs of concept

Pour les grands éditeurs, cela devient presque obligatoire. Si l’on paie sérieusement des bounties élevés, il faut aussi l’infrastructure pour valider les rapports proprement et rapidement.

Pour les petits projets, c’est plus amer. Ils reçoivent la même vague de slop, mais pas les mêmes ressources. C’est pour cela que certains réduiront les bug bounties financiers ou les arrêteront. Pas parce qu’ils ne prennent pas la sécurité au sérieux, mais parce que le fonctionnement du programme devient lui-même une charge.

Ce que les admins et MSPs peuvent en apprendre

On pourrait dire que cela ne concerne que les éditeurs et les programmes Bugcrowd.

Je ne le crois pas.

Le même mécanisme touche aussi les MSPs, les équipes IT internes et les responsables sécurité. Partout où des findings externes ou internes doivent être évalués, la pression augmente :

• Les scanners livrent plus de findings.
• Les assistants IA les expliquent de façon plus convaincante.
• Les développeurs apportent des notes sécurité générées par IA.
• Les clients demandent des réponses sur des CVE avant d’en connaître le contexte.
• Le management veut savoir si un risque est réel ou seulement bruyant.

La réponse pratique n’est pas de tout ignorer. La réponse est un processus de validation plus dur.

Pour moi, il comprend au minimum ces questions :

1. Le problème est-il reproductible ?
2. Le scope touché est-il clair ?
3. Existe-t-il un chemin d’attaquant réaliste ?
4. L’impact est-il prouvé techniquement ou seulement affirmé ?
5. Des logs ou de la télémétrie pourraient-ils montrer une exploitation ?
6. Le correctif est-il un patch, une configuration, un workaround ou seulement un pansement ?
7. Faut-il rechercher rétrospectivement si cela a déjà été exploité ?

C’est plus de travail. Mais c’est un meilleur travail que de réagir dans l’urgence à chaque rapport bien écrit.

Pourquoi cela colle à Mythos

Le point décisif de Mythos, pour moi, n’a jamais été seulement : “wow, un modèle trouve des bugs.”

Le point était celui-ci : si ces capacités deviennent plus réelles, le temps entre trouver, comprendre, reproduire et exploiter diminue. C’est exactement là que les programmes de bug bounty sont touchés. Ils se trouvent à l’intersection de la recherche, du potentiel offensif, de l’ingénierie et de la responsabilité.

Sophos le formule de façon proche : la question n’est pas de stopper les soumissions IA. La question est de préserver la confiance et le signal quand la bonne recherche et le bruit peuvent tous deux être produits à vitesse machine.

C’est, à mon avis, le résumé le plus propre du problème.

Toutes les organisations n’ont pas besoin d’un grand programme de bug bounty. Mais toutes ont besoin de meilleurs mécanismes pour vérifier les affirmations techniques. Le flot d’informations sécurité ne va pas diminuer. Il va devenir plus rapide, plus bruyant et mieux rédigé.

Mon avis

Je trouve que l’article de Sophos est un bon suivi de Mythos, parce qu’il sort le débat de la salle des modèles pour le ramener dans la salle d’exploitation.

Mythos est le signal spectaculaire. Le triage bug bounty est l’établi où l’on voit si les processus sécurité suivent.

Ma thèse est simple :

• Celui qui ne fait que collecter plus de rapports perdra.
• Celui qui exige une preuve reproductible priorisera mieux.
• Celui qui relie bug bounty, télémétrie, engineering et incident response réagira plus vite.
• Celui qui voit l’IA seulement comme générateur de texte sous-estime sa valeur pour le travail sécurité systématique.
• Celui qui ne filtre pas le slop IA brûle le temps des personnes qui doivent résoudre les vrais problèmes.

C’est moins glamour qu’un frontier model trouvant des zero-days. Mais c’est là que se décide si le gain de sécurité arrive chez les défenseurs ou si tout le monde se noie dans plus de bruit.

À la prochaine,
Joe