L'essentiel
Google a gelé son bug bounty open source parce que les rapports de vulnérabilité générés par IA rendaient le programme trop coûteux à opérer, et non parce que le code serait devenu plus sûr. Depuis le 1er octobre 2026, l'OSS VRP n'accepte plus de nouveaux rapports de vulnérabilités produit pour les projets maintenus par Google, comme Go, Angular, Bazel et Protocol Buffers. Google promet un point d'étape au premier trimestre 2027.
Pour les équipes qui s'appuient sur ces bibliothèques, un filet de sécurité externe vient de s'amincir. Pour celles qui gèrent leur propre boîte de signalement, c'est un avertissement : la même vague arrivera chez vous. C'est le bon moment pour vérifier que vos tests d'intrusion et audits de sécurité ne reposent pas sur l'espoir que des chercheurs externes trouvent les failles en premier.
Qu'a annoncé Google ?
L'équipe vulnerability rewards de Google a annoncé que l'OSS VRP n'accepte plus de nouvelles soumissions. Dans son communiqué, Google explique que la pause « est due à une hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides ». TechCrunch, qui a révélé le changement le 4 octobre, décrit des ingénieurs de Google et des mainteneurs open source débordés par des rapports invalides, certains contenant des détails hallucinés.
Depuis 2022, le programme rémunérait des chercheurs externes pour des failles dans le code open source maintenu par Google : le langage Go et sa chaîne d'outils, Angular, Bazel, Protocol Buffers, Fuchsia ainsi que les paramètres de dépôts et de chaîne d'approvisionnement associés. Google ne ferme pas toutes les portes. Les correctifs de sécurité peuvent toujours rapporter jusqu'à 15 000 dollars via le Patch Rewards Program, les failles dans les dépôts open source de Google Cloud affectant des produits Cloud peuvent toujours passer par le Cloud VRP, et les rapports soumis avant le 1er octobre seront traités comme avant.
Pourquoi les bug bounties cèdent-ils sous les rapports IA ?
Les LLM et les scripts de chasse aux bugs automatisés ont fait tomber presque à zéro le coût de rédaction d'un rapport de vulnérabilité plausible, alors que le coût de sa vérification n'a pas bougé. Chaque rapport exige toujours un ingénieur qui connaît le code pour le lire, tenter de le reproduire et expliquer pourquoi il s'agit ou non d'un bug. Quand la plupart des rapports sont faux, ce travail part dans le bruit et les vraies trouvailles attendent plus longtemps.
Google n'est pas le premier à renoncer à payer le volume. Le projet curl a mis fin à son bug bounty sur HackerOne en janvier 2026 après une vague de rapports générés par IA, et selon BleepingComputer, Intel a supprimé les récompenses financières de son programme Intigriti en septembre. Le schéma est constant : les programmes qui paient par découverte valide mais acceptent un nombre illimité de soumissions sont les premiers à céder.
Ce que cela signifie pour les équipes logicielles en France
D'abord, vos dépendances perdent une source de contrôle externe. Beaucoup de services back-end sont écrits en Go, beaucoup de front-ends utilisent Angular, et Protocol Buffers se trouve au cœur de la plupart des stacks gRPC. Google continue de corriger ces projets, mais pendant des mois, moins de chercheurs externes rémunérés s'y intéresseront. Traitez les avis de sécurité de ces bibliothèques comme quelque chose que vous surveillez et appliquez, pas comme une faille que quelqu'un d'autre a forcément déjà trouvée.
Ensuite, votre propre boîte de signalement est la prochaine. Si vous gérez un programme de divulgation de vulnérabilités ou une adresse security@ publique, les outils qui ont enseveli Google peuvent submerger une équipe sécurité de trois personnes bien plus vite. Une file remplie de rapports assurés mais faux ne fait pas que perdre du temps : c'est ainsi qu'un vrai rapport exploitable passe à la trappe.
Enfin, dans l'UE, un rapport ignoré peut devenir un problème de conformité. Le Cyber Resilience Act attend des fabricants de produits logiciels une politique de divulgation coordonnée des vulnérabilités et le traitement des rapports reçus ; ses obligations de notification des failles activement exploitées s'appliquent depuis le 11 septembre 2026. « Nous étions submergés de spam IA » n'expliquera pas un signalement manqué. La capacité de tri doit désormais être planifiée au même titre que la capacité de correction.
Que faire maintenant ?
- Cartographiez votre exposition. Listez, à partir de votre SBOM ou de vos manifestes de dépendances, les services qui embarquent des modules Go, Angular, des artefacts construits avec Bazel ou Protocol Buffers, avec leurs versions exactes.
- Surveillez les avis, pas les bounties. Abonnez-vous à la base de vulnérabilités Go, aux GitHub Security Advisories et aux flux OSV pour ces dépendances, et branchez-les sur les alertes que votre équipe d'astreinte lit déjà.
- Relevez le niveau d'exigence des rapports. Exigez une version affectée précise, des étapes de reproduction et une preuve de concept. Un formulaire structuré filtre bien plus de bruit qu'une simple adresse e-mail.
- Pré-filtrez automatiquement. Faites vérifier en premier passage que les fichiers, fonctions et versions cités existent avant qu'un ingénieur n'y consacre du temps. Les chemins de code hallucinés sont l'indice le plus fréquent.
- Protégez le signal. Gardez une voie rapide pour les chercheurs et clients connus, publiez périmètre et contact dans security.txt, et suivez la part de rapports valides pour voir quand la file commence à déborder.
Questions fréquentes
Qu'est-ce que Google a suspendu ?
Google a suspendu les nouvelles soumissions à son Open Source Software Vulnerability Rewards Program (OSS VRP), le bug bounty des projets open source maintenus par Google comme Go, Angular, Bazel, Protocol Buffers et Fuchsia. La pause est effective depuis le 1er octobre 2026. Google l'explique par une hausse significative des soumissions automatisées, dont la grande majorité n'étaient pas valides.
Combien de temps durera la pause de l'OSS VRP ?
Aucune date de fin n'a été fixée. Google remanie le programme et prévoit un point d'étape au premier trimestre 2027. Les rapports soumis avant le 1er octobre 2026 ne sont pas concernés, selon BleepingComputer et Help Net Security.
Les chercheurs peuvent-ils encore signaler des bugs dans les projets open source de Google ?
Oui, par d'autres canaux. Le Patch Rewards Program paie toujours jusqu'à 15 000 dollars pour les correctifs de sécurité à fort impact, et les failles des dépôts open source de Google Cloud affectant des produits Cloud peuvent passer par le Cloud VRP. Les vulnérabilités peuvent toujours être signalées aux mainteneurs ; seule la voie rémunérée pour les failles produit est suspendue.
Go, Angular ou Protocol Buffers deviennent-ils moins sûrs ?
Pas directement. Google continue de maintenir et de corriger ces projets, et ses propres équipes sécurité y travaillent toujours. Concrètement, une incitation rémunérée pour les chercheurs externes disparaît : les équipes qui utilisent ces bibliothèques doivent s'appuyer sur leur propre analyse des dépendances et leur veille des avis, plutôt que de compter sur les chasseurs de bugs pour trouver les problèmes en premier.
Comment protéger notre propre programme de divulgation du spam IA ?
Exigez une preuve de concept reproductible sur une version nommée, utilisez un formulaire structuré, publiez un périmètre clair dans security.txt et dans votre politique, et pré-filtrez automatiquement les rapports sans étapes de reproduction ou citant des chemins de code hallucinés avant qu'un ingénieur ne les lise. Gardez une voie rapide pour les rapporteurs ayant fait leurs preuves et mesurez la part de rapports valides.
Sources
Google Bug Hunters — Open Source Software Vulnerability Reward Program rules
TechCrunch — Google froze its open source bug bounty program due to a ‘significant rise’ in AI submissions (Oct 4, 2026)
BleepingComputer — Google halts open-source bug bounty program amid AI spam surge
Help Net Security — AI slop submissions force Google to freeze its open-source bug bounty