Thème d'affichage

Noyé sous les rapports bidon de l'IA, Google suspend son programme de bug bounty open source

Nicolas Lecointre · 6 Oct 2026 à 07h30
Noyé sous les rapports bidon de l'IA, Google suspend son programme de bug bounty open source

Depuis ce 1er octobre, le programme de bug bounty que Google consacre à l'open source n'accepte plus les signalements de failles dans le code de ses projets.

La raison ? Une hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides, explique l'entreprise sur X.

En clair, ses ingénieurs et les mainteneurs de ses projets passaient un temps considérable à vérifier des rapports générés à la chaîne qui, la plupart du temps, ne tenaient pas debout.

Google se garde bien de désigner l'intelligence artificielle comme coupable (ah bon ?), mais la firme visait déjà nommément les rapports générés par IA, hallucinations comprises, dans un billet publié plus tôt cette année.

L'entreprise promet un point d'étape au premier trimestre 2027, le temps de revoir sa copie. D'ici là, le guichet est fermé.

Meme sorry folks we're closed

31 337 raisons de tenter sa chance

Lancé en 2022, l'OSS VRP (pour Open Source Software Vulnerability Reward Program) paie les chercheurs qui dénichent et signalent en privé des failles dans le code open source de Google, dans des projets aussi répandus que le langage Go, le framework Angular ou Protocol Buffers.

À son lancement, les primes allaient de 100 à 31 337 dollars (31337, pour "eleet" en leet speak, voilà voilà).

C'est le volet des "vulnérabilités produit", autrement dit les failles dans le code lui-même, qui fait les frais de cette pause forcée. Vous avez déniché une corruption mémoire dans un parseur ou un filtre HTML qui laisse passer du code malveillant ? Circulez, ça ne rapporte plus rien ici, du moins jusqu'à nouvel ordre.

Les rapports déjà envoyés seront bien traités, et Google invite poliment les chasseurs de primes à tenter leur chance sur ses autres programmes, comme le Patch Rewards Program, qui rémunère les correctifs plutôt que les signalements.

Le volet supply chain (les attaques qui visent la fabrication et la distribution du code plutôt que le code lui-même) reste en revanche ouvert. Si vous trouvez un moyen de compromettre le système de build d'un projet Google ou de mettre la main sur ses clés de signature, vous pouvez toujours le signaler, mes petits crackitos.

Ce n'est pas faute d'avoir essayé autre chose : Google avait déjà durci les règles de son programme en mars pour écarter les rapports de faible qualité, en exigeant notamment des preuves plus solides sur ses projets les plus sensibles. Visiblement, la digue n'a pas tenu.

La loi de Brandolini, version industrielle

Le phénomène n'a en soi rien de surprenant. Demandez à un LLM de passer un dépôt au crible et il vous trouvera des fonctions suspectes à la pelle, chacune accompagnée d'un rapport impeccablement formaté.

Sauf que l'entrée prétendument contrôlée par l'attaquant est filtrée trois appels plus haut, ou que le scénario d'exploitation suppose une configuration que personne n'utilise. Générer ce genre de rapport ne coûte presque rien, alors que démontrer qu'il ne tient pas debout peut prendre des heures à un ingénieur.

C'est la loi de Brandolini (du nom du développeur italien Alberto Brandolini) appliquée à la sécurité : il faut dix fois plus d'énergie pour réfuter une connerie que pour la produire. Ajoutez une prime à la clé et vous obtenez une machine qui récompense le volume plutôt que la vérification.

Inutile de jeter la pierre à l'IA elle-même pour autant. Google sait mieux que quiconque qu'elle est capable de trouver de vraies failles : son agent Big Sleep en a déniché une vingtaine l'an dernier dans des projets open source comme FFmpeg et ImageMagick, et l'entreprise fait partie des happy few qui ont accès à Claude Mythos, le modèle d'Anthropic qui en aurait identifié des milliers.

Le problème, c'est le rapport copié-collé sans la moindre vérification, puis envoyé en rafale dans l'espoir qu'un ticket finisse par être gagnant.

cURL, le patient zéro ?

Google n'est pas le premier à rendre les armes dans ce domaine.

En janvier, Daniel Stenberg, le créateur de cURL, a mis fin au bug bounty de son projet. Lancé en 2019 sur la plateforme HackerOne, le programme avait permis de confirmer 87 vulnérabilités et de verser plus de 100 000 dollars aux chercheurs.

Mais là où plus de 15 % des signalements débouchaient auparavant sur une vraie faille, ce taux est tombé sous les 5 % en 2025.

Logiquement, Stenberg soupçonnait l'appât du gain d'expliquer une bonne partie de cette dégringolade. L'équipe a donc supprimé toute récompense financière, et elle continue de bannir quiconque lui envoie du slop, à savoir des rapports bas de gamme générés à la chaîne par IA.

En mars, la firme de Mountain View faisait partie des sept entreprises (aux côtés d'Anthropic, AWS, Microsoft ou encore OpenAI) qui mettaient 12,5 millions de dollars sur la table pour aider les mainteneurs open source à encaisser ce flot.

Six mois après avoir sorti le chéquier pour éponger les dégâts, Google ferme purement et simplement les vannes de son côté.

À propos de l'auteur

Nicolas Lecointre

Nicolas Lecointre

Chief Happiness Officer des développeurs, ceinture noire de sudo. Pour rire, j'ai créé Les Joies du Code. J'utilise Vim depuis 10 ans parce que je sais pas comment le quitter.

Voir sa page auteur

Articles similaires

Plus de contenu

Charger +