Google suspend ses primes open source pour les failles dans le code

Le changement tient en un paragraphe, ajouté au règlement du programme sur le site Google Bug Hunters : « Depuis le 1^er octobre 2026, nous n’acceptons plus les vulnérabilités produit soumises à l’OSS VRP » (traduction de la rédaction, comme les citations suivantes). Google s’engage à « donner un point d’étape au premier trimestre 2027 ». La page ne donne pas de raison. Celle-ci a été avancée sur X par le compte officiel du programme, selon BleepingComputer et Help Net Security, qui citent tous deux le message : la pause serait due à « une hausse significative des signalements automatisés, dont la grande majorité ne sont pas valides ».

Un programme de primes, à quoi ça sert

Un programme de primes aux failles (bug bounty) paie des chercheurs extérieurs qui signalent, de façon confidentielle, une vulnérabilité à l’éditeur d’un logiciel, pour qu’elle soit corrigée avant d’être exploitée. L’OSS VRP (Open Source Software Vulnerability Reward Program) de Google couvre les logiciels libres que l’entreprise publie elle-même : selon le règlement, tous les dépôts publics de ses organisations GitHub et une sélection de dépôts hébergés ailleurs, ainsi que leur configuration et, sous conditions, les failles de dépendances tierces qui se manifestent dans ces projets.

Le règlement distingue trois familles de signalements :

• les compromissions de la chaîne d’approvisionnement, présentées comme la priorité : tout ce qui permettrait de modifier le code source d’un projet ou les paquets distribués aux utilisateurs (configuration des GitHub Actions, fuite d’identifiants de publication, vol de clés de signature) ;
• les vulnérabilités « produit », c’est-à-dire les failles dans le code lui-même. Google donne comme exemples les corruptions de mémoire dans les analyseurs de formats de fichiers ou de protocoles réseau, les défaillances des fonctions censées neutraliser du HTML dangereux, ou les traversées de répertoires ;
• les autres problèmes de sécurité, comme des identifiants laissés dans un dépôt personnel.

Ce qui est suspendu, ce qui ne l’est pas

Seule la deuxième famille est touchée. Dans la grille de récompenses du règlement, la ligne « vulnérabilités produit » ne contient que des tirets, pour tous les niveaux de projets. Les failles de chaîne d’approvisionnement restent rémunérées : de 3 133,70 à 31 337 dollars pour les projets « phares » (niveau OT0), de 1 337 à 13 337 dollars pour les projets « importants » (OT1), de 500 à 3 133,70 dollars pour les projets « standard » (OT2). Les « autres problèmes de sécurité » valent toujours 1 000 dollars en OT0 et 500 dollars en OT1.

Le règlement précise aussi trois points :

• les vulnérabilités produit soumises avant le 1^er octobre ne sont pas concernées ;
• pour certains dépôts liés à Google Cloud, ces failles peuvent encore être acceptées par le programme dédié au cloud (Cloud VRP) ;
• Google invite les chercheurs à se tourner vers ses autres programmes de récompenses ou vers le Patch Rewards Program, qui, selon le règlement, récompense les améliorations de sécurité apportées à ses projets open source.

Il ne s’agit donc pas d’une fermeture de l’OSS VRP, mais du retrait de sa catégorie la plus ouverte, celle où un signalement peut porter sur n’importe quelle ligne de code.

Pourquoi cette catégorie-là : notre lecture

Google ne dit pas pourquoi il a suspendu cette catégorie plutôt qu’une autre. Ce qui suit est notre analyse, à partir du règlement. Trouver une faille de chaîne d’approvisionnement suppose de démontrer une attaque concrète sur l’infrastructure d’un projet ; le règlement exige par exemple de prouver qu’on peut contourner l’approbation des contributions par un mainteneur. Une vulnérabilité produit peut, elle, se décrire en quelques paragraphes plausibles, que seul un ingénieur pourra confirmer ou réfuter après examen du code. Cette catégorie nous paraît donc la plus exposée aux rapports produits en masse.

Le règlement fixait d’ailleurs des conditions strictes pour ces signalements. Les corruptions de mémoire dans les projets OT0 et OT1 n’étaient acceptées qu’avec des étapes de reproduction exactes dans OSS-Fuzz, le service de test automatisé de Google, ou avec un correctif déjà intégré au projet. Dans les projets OT2 et OT3, les vulnérabilités produit n’étaient pas rémunérées.

Le cœur du problème est une asymétrie : un outil automatisé peut produire un rapport d’apparence technique en quelques secondes, mais sa vérification mobilise toujours du temps humain qualifié. Google ne parle toutefois, dans le message rapporté par la presse, que de signalements « automatisés » : il ne dit pas quelle part provient d’outils d’IA, ni combien de rapports il reçoit.

Curl et arXiv, même goulet d’étranglement

Google n’est pas le premier à réagir. Le projet curl, outil et bibliothèque libres de transfert de données, a mis fin à son programme de primes le 31 janvier 2026. Dans le billet annonçant cette décision, son créateur Daniel Stenberg dresse le bilan : 87 vulnérabilités confirmées et plus de 100 000 dollars versés depuis avril 2019. Il décrit aussi la dégradation : les années précédentes, plus de 15 % des signalements aboutissaient à une vulnérabilité confirmée ; à partir de 2025, ce taux est tombé sous les 5 %. Il évoque « une explosion de rapports-déchets générés par IA », dont le flot ininterrompu « pèse lourdement sur le moral » de ceux qui doivent les traiter et prend parfois longtemps à réfuter. Curl accepte toujours les signalements, par la fonction de signalement privé de GitHub ou par courriel, mais sans récompense.

Le phénomène dépasse la sécurité. Le même 1^er octobre, arXiv, le dépôt de prépublications scientifiques, a limité chaque déposant à deux soumissions par mois civil et à trois soumissions en cours simultanément. Le service a reçu 40 363 soumissions en septembre 2026, un record, contre 20 569 en septembre 2024. Il estime que les outils d’IA permettent d’« inonder » les dépôts d’articles « de faible valeur », et qu’une proportion relativement faible d’auteurs accapare une part disproportionnée du temps des modérateurs. arXiv présente la mesure comme provisoire, le temps de définir de nouvelles règles pour les travaux réalisés avec l’aide de l’IA.

Dans les trois cas, d’après ce que décrivent les intéressés, le point de saturation n’est pas la production mais le filtre humain : mainteneurs, équipes de tri, modérateurs bénévoles.

L’IA trouve aussi de vraies failles

Ce n’est pas pour autant une histoire de l’IA contre la sécurité. Google lui-même utilise des modèles de langage pour chercher des vulnérabilités. Son équipe Project Zero a annoncé en novembre 2024 que son agent Big Sleep avait découvert une faille exploitable de corruption de mémoire dans SQLite, présentée comme « le premier exemple public » d’un agent d’IA trouvant une telle faille inconnue dans un logiciel réel largement utilisé. Elle a été corrigée le jour même de son signalement, avant toute version officielle.

La différence, à notre sens, tient moins à l’outil qu’à ce qui accompagne le résultat : une preuve reproductible, examinée par des spécialistes avant d’être transmise. C’est le type de preuve que le règlement exigeait pour les corruptions de mémoire, avec la reproduction dans OSS-Fuzz.

Ce que ça change

Pour les chercheurs de bonne foi, la porte n’est pas fermée : une faille dans un projet open source de Google peut toujours être signalée, et Google l’oriente vers ses autres programmes. Mais l’incitation financière disparaît pour toute une catégorie de découvertes, au moins jusqu’au point d’étape promis pour le premier trimestre 2027. Le risque, impossible à mesurer à ce stade, est que certaines failles réelles soient moins activement cherchées. Après curl, le cas de Google suggère qu’ouvrir largement la porte aux signalements rémunérés devient coûteux à tenir, y compris pour un acteur de cette taille.

Ce qu’on ne sait pas encore

• Les volumes. Google ne publie ni le nombre de rapports reçus ni la proportion jugée invalide.
• La part de l’IA. Google parle de signalements « automatisés » ; il ne précise pas lesquels relèvent d’outils d’IA.
• La forme du programme en 2027. Google promet seulement de « retravailler » ce volet et d’en reparler au premier trimestre 2027.
• La cohérence du règlement. Sous l’avis de suspension, la page conserve un paragraphe décrivant les vulnérabilités produit comme « également couvertes » par le programme, vraisemblablement un reste de l’ancienne version.
• Le message d’origine. Nous n’avons pas pu consulter directement la publication de Google sur X ; sa teneur est connue par les deux médias qui la citent.