Pourquoi Google suspend une partie de son bug bounty open source

Google a cessé le 1er octobre 2026 d'accepter les signalements de vulnérabilités « produit » dans son programme de récompenses consacré aux logiciels open source, l'OSS VRP. Le compte officiel @GoogleVRP justifie cette pause par « une hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides ». La mesure est annoncée comme temporaire, sans date de reprise : Google s'engage à faire un point au premier trimestre 2027.

Google rejoint curl, l'Internet Bug Bounty de HackerOne et arXiv, qui ont refermé ou filtré leur guichet depuis janvier. Pour les éditeurs, le sujet prend un tour réglementaire. Depuis le 11 septembre 2026, le Cyber Resilience Act oblige tout fabricant qui vend dans l'Union à émettre une alerte sous 24 heures pour toute vulnérabilité activement exploitée dans ses produits dont il a connaissance. Encore faut-il la repérer dans le flot.

Ce que Google a suspendu, et ce qui reste ouvert

La suspension vise le seul volet « vulnérabilités produit » de l'OSS VRP, c'est-à-dire les failles trouvées dans le code des projets open source de Google. Les rapports portant sur la chaîne d'approvisionnement logicielle restent recevables. Google invite les chercheurs à se tourner vers ses autres programmes de récompense ou vers son Patch Rewards Program.

Les règles du programme, mises à jour, apportent deux précisions. Les vulnérabilités « produit » déposées avant le 1er octobre ne sont pas concernées. Certains dépôts liés à des produits Google Cloud peuvent encore faire l'objet de signalements par l'intermédiaire du Cloud VRP.

Cette pause prolonge un premier tour de vis. Le 19 mars 2026, dans un billet intitulé « Streamlining Google's OSS VRP: Key Rule Updates » et complété en avril, Google faisait état d'« une hausse massive des rapports générés par IA ». L'entreprise y répartissait ses projets en quatre paliers, de OT0 (Bazel, Angular, Golang) à OT3. Sur les deux premiers, une corruption mémoire devait être reproduite avec OSS-Fuzz ou accompagnée d'un correctif fusionné. Les paliers OT2 et OT3 ne donnaient plus droit à aucune récompense pour les vulnérabilités « produit ». Le but affiché était de « filtrer les rapports de faible qualité » pour se concentrer « sur l'impact réel ». La pause du 1er octobre étend la restriction à tous les paliers.

curl, de plus de 15 % à moins de 5 % de rapports confirmés

Un précédent chiffré vient de curl, l'outil open source de transfert de données. Le 26 janvier 2026, son créateur Daniel Stenberg expliquait sur son blog la fin du bug bounty du projet au 31 janvier, décision rendue publique par une pull request ouverte le 14 janvier. Lancé en avril 2019 avec HackerOne, le programme avait permis de confirmer 87 vulnérabilités et de verser plus de 100 000 dollars aux chercheurs. Les années précédentes, plus de 15 % des soumissions aboutissaient à une vulnérabilité confirmée. En 2025, ce taux est tombé sous 5 %. « Pas même un sur vingt n'était réel », écrit-il, en mettant en cause « la bouillie d'IA abrutissante », des humains « plus mauvais que jamais » et une volonté de « percer des trous plutôt que d'aider ».

curl a alors supprimé toute récompense financière, quelle que soit la gravité, et redirigé les signalements vers la fonction de signalement privé de GitHub. Le 22 avril, un second billet dressait un bilan d'étape. Le projet est revenu sur HackerOne en mars 2026, GitHub n'étant « pas assez bon ». Il reçoit environ deux fois plus de rapports qu'en 2025, mais le taux de vulnérabilités confirmées est remonté « dans une fourchette de 15 à 16 % ». Presque tous les rapports recourent à l'IA, constate Daniel Stenberg, et ils sont désormais « pour la plupart de très haute qualité ».

L'Internet Bug Bounty et arXiv ont aussi resserré le filtre

L'Internet Bug Bounty (IBB), le fonds mutualisé hébergé par HackerOne qui a longtemps payé les primes de curl, a gelé les nouvelles soumissions le 27 mars 2026. Sa page de programme explique que la recherche assistée par IA « étend la découverte de vulnérabilités » et que « l'équilibre entre les découvertes et la capacité de correction de l'open source a substantiellement changé ». Au 6 octobre, l'API de HackerOne le donne toujours en état « paused ». arXiv, de son côté, a plafonné les dépôts le 1er octobre en citant, sur son blog, une hausse des articles « denses, écrits par IA ».

Un rapport coûte peu à produire et cher à réfuter

Daniel Stenberg avance une explication : « l'idée d'être payé » compte pour beaucoup, la prime attirant de vrais rapports mais permettant « trop facilement d'être pénible, avec peu ou pas de pénalité ».

L'asymétrie se joue à la vérification. Les rapports invalides prennent « parfois aussi beaucoup de temps à réfuter », écrit le mainteneur. Les pull requests ne posent pas ce problème à curl, puisqu'elles doivent passer « 200 tâches d'intégration continue » avant toute relecture humaine. Un signalement de sécurité n'a pas d'équivalent automatique : quelqu'un doit reproduire le scénario et lire le code. Cloudflare a fait le même constat de tri dans un autre cadre, en ne retenant que 49 pistes, après revue humaine, sur 1 107 tentatives de modèles d'IA contre son pare-feu.

Cyber Resilience Act : 24 heures pour une faille exploitée

L'article 14 du règlement (UE) 2024/2847 sur la cyberrésilience s'applique depuis le 11 septembre 2026, quinze mois avant l'essentiel du texte, applicable le 11 décembre 2027 selon son article 71. Il oblige tout fabricant d'un produit comportant des éléments numériques à notifier deux catégories d'événements : les vulnérabilités activement exploitées et les incidents graves ayant des répercussions sur la sécurité du produit. La notification passe par la plateforme unique de signalement de l'ENISA, ouverte le 11 septembre, et parvient en même temps au CSIRT coordinateur de l'État membre de son établissement principal.

Un rapport non vérifié ne déclenche rien par lui-même, mais la date à laquelle le fabricant « a eu connaissance » d'une exploitation dépend de la vitesse à laquelle il trie ses signalements. L'article 64 prévoit pour le manquement aux articles 13 et 14 une amende pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Ce régime de sanctions ne s'applique, comme l'essentiel du texte, qu'à partir du 11 décembre 2027. L'article 64, paragraphe 10, éclairé par le considérant 120, écarte toutefois l'amende dans deux cas. Le premier vise les micro et petites entreprises qui manquent le délai de 24 heures de l'alerte précoce. Le second couvre toute infraction commise par un intendant de logiciels ouverts. Un rectificatif à la version anglaise du règlement étend cette dérogation aux paragraphes 2 à 9 de l'article, donc à l'amende des articles 13 et 14. L'article 13, paragraphe 6, crée par ailleurs un flux en sens inverse. Un fabricant qui identifie une vulnérabilité dans un composant, y compris open source, doit la signaler à la personne ou à l'entité qui en assure la maintenance. Il doit aussi y remédier et lui transmettre le correctif qu'il a développé. Les mainteneurs déjà sollicités par les rapports automatisés reçoivent donc aussi ces signalements.

Les « intendants de logiciels ouverts », personnes morales qui soutiennent de façon continue des logiciels libres destinés à des activités commerciales, relèvent d'un régime à part. L'article 24 leur étend l'obligation de notification lorsqu'ils participent au développement des produits, mais il ne s'appliquera qu'au 11 décembre 2027, a rappelé l'ENISA le 11 septembre.

Reproduction, preuve d'exploitation, correctif

Les réorganisations récentes vont dans le même sens. Google exigeait depuis le 19 mars 2026, pour les corruptions mémoire sur ses deux premiers paliers de projets, une reproduction OSS-Fuzz ou un correctif fusionné. Il renvoie aussi vers son programme de récompense des correctifs (Patch Rewards). L'IBB cherche des incitations pour que les découvertes « se traduisent en corrections durables ». Daniel Stenberg reprochait en janvier à nombre d'auteurs de rapports de rarement proposer un correctif ou travailler avec l'équipe. Pour un RSSI qui gère un programme de divulgation, cela se traduit en exigences vérifiables : un scénario de reproduction sur une version identifiée, une preuve d'exploitation plutôt qu'une hypothèse, un auteur joignable pendant la correction. Ces critères n'excluent pas les rapports assistés par IA, que curl accepte à condition que l'usage d'une IA soit déclaré dans le rapport, selon sa politique sur HackerOne, sans exiger de préciser quel outil a servi.

Des rapports assistés par IA aboutissent aussi à des failles confirmées. Le 25 juillet, trois chercheurs de Hacktron ont compromis le dépôt interne d'OpenAI avec Claude Opus 5, le modèle ayant produit l'exploit en quelques heures. Et le 2 septembre, la CISA ajoutait à son catalogue des failles exploitées un contournement d'authentification de LiteLLM, soit le type d'événement que vise l'article 14.

La vérification devient le goulot d'étranglement

Ces épisodes décrivent un déplacement de la contrainte. La découverte automatisée n'est plus le facteur limitant ; la vérification et la correction le sont, et elles restent humaines. Daniel Stenberg le formulait en avril : certains projets auront du mal à absorber cette hausse « sans mainteneurs supplémentaires ». Pour un éditeur soumis au CRA, la capacité à trier un rapport devient une composante de la conformité, au même titre que le suivi des composants. Elle détermine en effet le moment où il a connaissance d'une exploitation, point de départ du délai de 24 heures.

Google a promis un point d'étape au premier trimestre 2027. Le 11 décembre 2027, les intendants de logiciels ouverts entreront à leur tour dans le champ des notifications, sans exposition aux amendes administratives, en même temps que l'ensemble des exigences du règlement.