Google suspend temporairement les signalements de vulnérabilités produit open‑source après un afflux de rapports IA

Le 1 octobre 2026, Google a annoncé une suspension temporaire des nouvelles soumissions de vulnérabilités produit dans le cadre de son Open Source Software Vulnerability Reward Program (OSS VRP). L’entreprise a indiqué publier une mise à jour détaillée d’ici le premier trimestre 2027, mais la pause reste effective uniquement pour le flux de vulnérabilités produit, et non pour l’ensemble de ses programmes de primes.

Ce que la pause couvre et ce qu’elle exclut

La suspension s’applique uniquement à la catégorie « product‑vulnerability » du OSS VRP. Les autres pistes de primes Google, comme le Cloud Vulnerability Reward Program, continuent d’accepter des rapports, tout comme les soumissions liées à la chaîne d’approvisionnement OSS. Les failles signalées avant le 1 octobre restent prises en compte, et certaines vulnérabilités dans les dépôts Google Cloud impactant les produits Cloud peuvent encore être traitées via le Cloud VRP distinct.

L’analyse interne de Google a relié la pause à une « augmentation significative des soumissions automatisées et générées par IA, dont la grande majorité était jugée invalide ». Ce pic a submergé les mainteneurs open‑source, qui ont dû consacrer du temps précieux à reproduire et rejeter des rapports décrivant des défauts halluciné, inexploitable ou tout simplement inexistants, au lieu de corriger de véritables problèmes de sécurité.

Pourquoi le bruit généré par l’IA pose problème

La réduction du coût du scan et de la génération de rapports a démocratisé la recherche de vulnérabilités, permettant à davantage de chercheurs de découvrir de vrais défauts. Cependant, la même facilité a éliminé une barrière naturelle qui filtrait auparavant les soumissions de faible qualité. Les outils automatisés peuvent désormais produire des milliers de rapports synthétiques avec peu de supervision humaine, gonflant le volume de bruit que les administrateurs du programme doivent trier.

• Des scripts automatisés génèrent des rapports à grande échelle
• Les grands modèles de langage fabriquent des chemins de code plausibles mais faux
• Les chercheurs peuvent soumettre sans vérification manuelle
• Les mainteneurs doivent allouer du temps pour reproduire et rejeter chaque rapport

Les mainteneurs open‑source, dont beaucoup sont bénévoles, ont signalé que cet afflux de rapports invalides détournait les ressources des travaux de sécurité réels. Le temps passé à reproduire des défauts halluciné retardait non seulement le développement de correctifs, mais augmentait aussi le burnout parmi les contributeurs communautaires.

Réaction de Google et perspectives futures

Google a précisé que la pause est une mesure temporaire le temps de retravailler la partie concernée du OSS VRP. L’entreprise n’a pas encore publié de nouvelles règles de validation, mais elle a souligné que le programme n’est pas définitivement fermé. Google envisage d’introduire des critères plus stricts pour accepter les soumissions, probablement en exigeant des preuves reproductibles, un impact vérifié et une étape de révision humaine avant qu’un rapport ne soit intégré au pipeline de primes.

TechCrunch et Tom’s Hardware ont relié cette décision à un problème plus large rencontré par Linux et d’autres écosystèmes open‑source, où les mainteneurs sont de plus en plus submergés par des rapports de mauvaise qualité. Les deux publications ont rapporté le même calendrier et la même justification, mais toute affirmation supplémentaire concernant d’autres programmes est attribuée exclusivement à ces médias.

Pour les équipes de sécurité qui s’appuient sur des divulgations externes, la pause rappelle l’importance de mettre en place des processus de filtrage internes. Exiger des preuves reproductibles, des déclarations d’impact claires et une revue manuelle avant de créer un ticket peut aider à filtrer le bruit IA et à protéger les analystes des menaces fantômes.

La situation souligne également le besoin d’une meilleure coordination entre les plateformes de primes et les projets open‑source. Des directives claires sur ce qui constitue un rapport valide, combinées à un pré‑filtrage automatisé qui signale les hallucinations probables, pourraient alléger la charge des mainteneurs tout en préservant les avantages d’un écosystème de bug‑bounty dynamique.

Pour les organisations francophones participant à des programmes de sécurité open‑source, la pause implique d’ajuster leurs flux de gestion des vulnérabilités. Les équipes devront anticiper un délai de validation plus long pour les rapports de vulnérabilités produit soumis au OSS VRP de Google, privilégier les soumissions riches en preuves, et envisager des canaux alternatifs – comme le Cloud VRP ou la coordination directe avec les mainteneurs – pour les découvertes critiques. En pratique, cela se traduit par un ralentissement temporaire des incitations financières pour certains bugs open‑source, tout en offrant l’opportunité de se concentrer sur des divulgations de haute qualité, plus rapidement exploitables.