Un programme de primes qui a cessé de recevoir des rapports
Google a cessé d’accepter les nouveaux rapports de vulnérabilités de produit via son Open Source Software Vulnerability Reward Program, et la raison avancée est le volume de soumissions écrites par des machines qui arrivent au programme. La suspension est entrée en vigueur le 1er octobre 2026. Google n’a fixé aucune date de reprise et se contente d’annoncer une mise à jour au premier trimestre 2027.
L’entreprise attribue cette décision à “une hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides”, selon l’avis du programme rapporté par Help Net Security. Le programme couvre les vulnérabilités des logiciels libres de Google, dont des projets comme Go, Angular et Protocol Buffers, qui soutiennent une quantité considérable de logiciels que Google ne contrôle pas.
C’est un programme de primes qui renonce à payer pour qu’on regarde. Voilà ce qui compte : le goulet d’étranglement n’est plus l’offre de personnes prêtes à chercher des failles, mais la capacité des ingénieurs qui doivent lire ce qui arrive.
Ce qui reste couvert
La suspension est plus étroite qu’une fermeture. Les rapports déposés avant le 1er octobre ne sont pas affectés et seront toujours traités. Les rapports sur la chaîne d’approvisionnement adressés au même programme — la catégorie qui couvre la manière dont le code libre de Google est construit et distribué, et non ce que le code fait de mal — continuent d’être acceptés. Certaines vulnérabilités de produit touchant des dépôts Google Cloud peuvent encore être soumises via le Cloud Vulnerability Reward Program, selon les informations publiées.
Les chercheurs qui trouvent quelque chose entre-temps sont renvoyés vers le Patch Rewards Program de Google, qui paie des améliorations de sécurité plutôt que la découverte d’une faille précise. C’est une proposition différente. Une prime au correctif exige du chercheur qu’il fasse aussi le travail d’ingénierie, ce qui filtre exactement les soumissions que Google dit subir — mais cela relève aussi la barre pour ceux qui travaillaient correctement.
Une plainte que l’écosystème formulait déjà
Google n’est pas le premier mainteneur à le dire tout haut. Le schéma — des rapports longs, assurés et bien écrits décrivant des vulnérabilités inexistantes — est documenté dans les projets libres depuis environ deux ans, et le projet curl comme la Linux Foundation figurent parmi ceux qui décrivent la même érosion du temps de relecture. Ce qui est nouveau, c’est la taille de l’organisation qui agit et la brutalité du remède.
L’économie est implacable. Produire aujourd’hui un rapport de vulnérabilité vraisemblable ne coûte presque rien, et le réfuter coûte toujours du temps humain réel. Tout programme qui paie par trouvaille valide est exposé à cette asymétrie, et un programme incapable de trier plus vite que les rapports n’arrivent n’a que deux issues : recruter, ou fermer la porte.
Ce que cela coûte
Le coût ne se voit pas de l’extérieur, car rien ne casse. Les projets libres de Google ne deviennent pas moins sûrs le jour où le formulaire cesse d’accepter les soumissions. Ce qui change, c’est le rythme auquel de vraies failles sont trouvées par des personnes extérieures à l’entreprise, dans du code dont dépendent des milliers d’autres organisations et que peu d’entre elles auditent elles-mêmes.
Il faudra voir si la mise à jour promise pour le premier trimestre 2027 rouvre le programme avec un filtre, des frais, une exigence de réputation ou autre chose. Les primes aux bogues reposaient sur l’hypothèse que les soumissions étaient coûteuses à produire et bon marché à vérifier. Cette hypothèse est désormais inversée, et Google est le plus grand opérateur à le concéder publiquement.
