Google met son bug bounty open source sur pause : l’IA a transformé la chasse aux failles en usine à spam

Le bug bounty de Google vient de se faire DDoS par des rapports de bugs

Depuis le 1er octobre 2026, Google n’accepte temporairement plus de nouvelles vulnérabilités produit dans son Open Source Software Vulnerability Reward Program, ou OSS VRP. L’entreprise explique cette pause par une hausse importante des soumissions automatisées, dont la grande majorité se révèle invalide . Le programme récompensait depuis 2022 les chercheurs découvrant des problèmes de sécurité dans les projets open source de Google et certains dépôts associés. Désormais, cette partie précise du dispositif est mise sur pause pendant que Google cherche une manière de revoir son fonctionnement. Une mise à jour est promise pour le premier trimestre 2027.

Attention néanmoins au gros raccourci : Google n’a pas arrêté tous ses bug bounties et n’interdit pas non plus la recherche assistée par IA. Les rapports déjà envoyés avant le 1er octobre continuent d’être traités, les vulnérabilités liées à la chaîne d’approvisionnement restent acceptées dans l’OSS VRP et certains problèmes affectant Google Cloud peuvent toujours passer par le programme Cloud VRP. Les autres programmes de Google Bug Hunters restent eux aussi actifs. C’est donc une suspension ciblée, pas le rideau métallique baissé sur toute la sécurité open source de Google.

Le problème était écrit en gros sur le mur depuis mars

Cette décision n’arrive pas exactement comme une météorite. Dès le mois de mars, Google expliquait déjà être confronté à une explosion de rapports générés avec l’aide de l’IA et avait commencé à durcir fortement les règles de son programme. Les équipes décrivaient notamment des rapports contenant des informations incorrectes ou des « hallucinations » sur la manière de déclencher une vulnérabilité, mais aussi des signalements techniquement plausibles portant sur du code inaccessible ou n’ayant pratiquement aucun impact réel sur la sécurité.

Google avait alors introduit un classement de ses projets open source par importance, de OT0 pour les plus critiques jusqu’à OT3 pour les projets moins sensibles. Pour certaines vulnérabilités touchant les projets les plus importants, l’entreprise demandait désormais des preuves beaucoup plus solides : par exemple une reproduction exacte via OSS-Fuzz ou un correctif déjà fusionné. Quelques semaines plus tard, les projets OT2 et OT3 avaient même cessé d’être éligibles aux récompenses pour plusieurs catégories de vulnérabilités produit. Le message était déjà limpide : montrer vaguement une ligne de C en expliquant qu’un LLM pense qu’elle « pourrait peut-être entraîner une corruption mémoire » ne suffisait plus.

Générer un rapport prend dix secondes, démontrer qu’il est faux peut prendre une heure

C’est là que l’économie de l’IA produit un problème assez vicieux. Un modèle peut analyser une énorme quantité de code et produire des centaines d’hypothèses en très peu de temps. Même si seulement quelques-unes sont réellement exploitables, cela peut rester utile pour le chercheur qui vérifie lui-même chaque résultat avant de le transmettre.

Mais si personne n’effectue cette vérification, le coût change simplement de camp.

L’utilisateur de l’IA dépense quelques secondes et quelques tokens pour produire un rapport extrêmement convaincant expliquant qu’une fonction possède une vulnérabilité critique. À l’autre bout, un mainteneur doit récupérer la version concernée, comprendre le raisonnement, vérifier le chemin d’exécution, reproduire les conditions et déterminer si l’attaque est réellement possible. Trente rapports générés automatiquement peuvent donc représenter quelques minutes de travail pour leur expéditeur et plusieurs jours pour ceux qui doivent les examiner.

C’est essentiellement du spam, mais avec beaucoup plus de segfault.

Le phénomène dépasse largement Google

Google n’est pas le premier à rencontrer ce problème. The Register décrivait déjà au printemps la pression exercée par les rapports assistés par IA sur les mainteneurs open source . Le projet curl, par exemple, avait vu évoluer la situation : les premiers rapports générés par IA étaient souvent manifestement absurdes, mais les outils sont devenus progressivement meilleurs et produisent désormais des signalements suffisamment plausibles pour qu’un humain doive réellement les étudier. Le problème n’est donc plus simplement « l’IA raconte n’importe quoi ». Le problème devient « l’IA raconte quelque chose d’assez crédible pour coûter cher à vérifier ».

Le mainteneur Linux Willy Tarreau résumait justement cette nouvelle réalité en estimant qu’il fallait demander davantage de travail aux personnes qui soumettent des rapports assistés par LLM, afin que le coût de la vérification ne repose pas entièrement sur les mainteneurs. Même un bon rapport découvert grâce à l’IA peut donc devenir problématique si le chercheur se contente de copier-coller la sortie du modèle et considère que la validation appartient à quelqu’un d’autre.

Autrement dit, le problème n’est pas forcément l’utilisation de l’IA pour chercher des failles.

C’est l’absence d’humain entre « l’IA pense avoir trouvé quelque chose » et « envoyer ».

Google veut désormais des preuves, pas des dissertations

La direction prise par Google devient particulièrement visible lorsqu’on regarde son autre programme, OSS Patch Rewards . Ici, l’objectif n’est plus simplement d’expliquer qu’une vulnérabilité pourrait exister, mais de proposer une amélioration de sécurité concrète et généralement déjà intégrée au projet. Google continue de verser des récompenses allant de petits correctifs jusqu’à 15 000 dollars pour certains changements complexes et à fort impact. Des multiplicateurs temporaires existent même pour des améliorations de sécurité mémoire sur certains projets critiques.

La logique est intéressante : si les outils automatisés rendent la découverte de problèmes extrêmement bon marché, peut-être faut-il déplacer la récompense vers la validation et la correction. Trouver une fonction suspecte devient progressivement une commodité. Démontrer qu’elle représente réellement une vulnérabilité, construire un exploit reproductible, comprendre son impact et produire un patch correct restent en revanche des tâches beaucoup plus difficiles à automatiser entièrement.

On pourrait donc voir évoluer le bug bounty d’un modèle « signalez-nous ce qui semble cassé » vers quelque chose ressemblant davantage à « revenez lorsque vous avez prouvé que c’est cassé et, idéalement, lorsque vous savez comment le réparer ».

Moins spectaculaire

Beaucoup plus utile

L’open source commence à payer la facture de la génération infinie

Ce problème touche particulièrement l’open source parce que la capacité de production des rapports a soudainement explosé sans que la capacité humaine de vérification suive la même courbe. Un projet peut avoir des millions d’utilisateurs et seulement quelques personnes capables d’examiner sérieusement une vulnérabilité complexe. Ajouter cent agents automatisés capables de scanner le code 24 heures sur 24 ne crée malheureusement pas cent mainteneurs supplémentaires pour lire leurs découvertes.

La Linux Foundation avait d’ailleurs annoncé en mars 12,5 millions de dollars de financement pour améliorer la sécurité et aider l’écosystème open source à absorber l’augmentation des découvertes automatisées . Le projet, financé notamment par plusieurs géants de la tech et de l’IA, partait exactement du même constat : les systèmes automatisés augmentent énormément la quantité de résultats de sécurité, mais les mainteneurs ne disposent pas nécessairement des outils ou des ressources pour les trier efficacement.

C’est un joli paradoxe. L’IA devait augmenter la productivité du développement logiciel. Dans certains cas, elle augmente effectivement la productivité d’une personne en transférant simplement une montagne de travail supplémentaire vers quelqu’un d’autre.

Un gain de productivité extrêmement performant.

Surtout si l’on ne mesure que son côté de la feuille Excel.

Alors, faut-il bannir les rapports générés par IA ?

Probablement pas. Ce serait d’ailleurs passer à côté du problème réel. Google lui-même reconnaît que l’IA peut accélérer la découverte de vulnérabilités et son durcissement des règles de l’OSS VRP ne cherchait pas à interdire ces outils, mais à imposer davantage de validation et de preuves. Une IA capable de repérer une erreur subtile dans des millions de lignes de code peut devenir un outil formidable entre les mains d’un chercheur compétent.

Ce qui risque de disparaître, en revanche, c’est le modèle où l’on peut lancer un scanner agentique sur 400 dépôts pendant la nuit puis envoyer automatiquement tout ce qu’il produit en espérant qu’un mainteneur fera gratuitement le tri le lendemain matin.

Les futurs programmes pourraient donc exiger davantage de reproductibilité, limiter le nombre de soumissions, introduire des systèmes de réputation ou demander un proof-of-concept réellement fonctionnel avant même qu’un humain ne commence l’analyse. L’IA effectuerait toujours la première partie du travail, mais son utilisateur resterait responsable de la seconde.

Concept révolutionnaire : vérifier ce que l’on envoie.

La chasse aux bugs entre dans une nouvelle époque

La suspension de Google ressemble finalement moins à un échec de l’intelligence artificielle qu’à une conséquence assez prévisible de son succès. Les outils deviennent suffisamment puissants pour explorer beaucoup plus de code qu’un humain. Mais cette abondance transforme complètement la valeur de ce qu’ils produisent.

Lorsque découvrir une anomalie coûte cher, chaque signalement mérite naturellement de l’attention. Lorsque dix mille agents peuvent générer dix millions d’hypothèses, l’information rare n’est plus l’hypothèse.

C’est la preuve qu’elle est vraie.

La sécurité open source va donc probablement devoir adapter ses mécanismes de récompense, ses outils de tri et ses règles de soumission à cette nouvelle réalité. Les chercheurs continueront d’utiliser l’IA. Les mainteneurs aussi. Mais entre les deux, il faudra reconstruire un filtre qui empêche les files de bugs de devenir une décharge de raisonnements automatiques vaguement plausibles.

Google donnera des nouvelles de son OSS VRP au premier trimestre 2027.

D’ici là, une règle simple semble plutôt raisonnable : si votre agent IA découvre une vulnérabilité critique à trois heures du matin, félicitez-le.

Puis vérifiez quand même qu’elle existe avant de demander 10 000 dollars.