Google a cessé d’accepter les nouveaux signalements de vulnérabilités produit dans son Open Source Software Vulnerability Reward Program le 1er octobre 2026. L’entreprise invoque une forte hausse des envois automatisés, dont la grande majorité serait invalide. Une nouvelle information est prévue au premier trimestre 2027.
Il s’agit d’une catégorie suspendue, pas de la fermeture de tous les programmes Google ni d’une interdiction des recherches assistées par IA. La panne est plus précise : produire une affirmation de sécurité plausible coûte peu, mais établir sa réalité demande toujours une expertise rare.
Ce qui ferme et ce qui reste accessible
Google a lancé OSS VRP en 2022 pour les problèmes de sécurité open source admissibles. Les signalements produit concernent des défauts de code, de logique ou de conception. La pause porte sur les nouveaux envois de cette catégorie ; les rapports antérieurs restent admissibles à l’examen.
Les signalements de chaîne d’approvisionnement restent ouverts. Certains problèmes de dépôts Google Cloud peuvent relever du Cloud VRP, selon le produit et les règles. Les autres programmes, notamment Chrome, Android, appareils et sécurité de l’IA, continuent également. Les chercheurs doivent vérifier le périmètre réel plutôt que supposer une voie alternative identique pour tous les dépôts.
La suspension suit des changements antérieurs. Les règles de 2026 demandaient de valider les résultats assistés par IA et de démontrer un impact réel. En avril, Google a supprimé récompenses et reconnaissance publique pour certaines catégories produit de moindre niveau et d’autres problèmes. Ces mesures plus ciblées n’ont pas empêché la pause ultérieure.
Google n’a publié ni nombre précis de soumissions, ni taux d’acceptation, ni taille de la file concernée. La presse évoquait des milliers de rapports médiocres, mais ce nombre ne figure pas dans l’avis Google. « Majoritairement invalides » signale un problème grave sans fournir une référence statistique complète.
Le dispositif de remplacement demeure publiquement indéfini. Reproductions testées, limites d’envoi, identité et présélection automatisée sont des possibilités, pas les conditions annoncées d’une réouverture.
Un rapport convaincant peut ne décrire aucune vulnérabilité
Un modèle peut repérer une opération suspecte, raconter une exploitation et joindre une évaluation professionnelle de gravité. Pourtant, l’opération peut ne jamais recevoir de données adverses, être inaccessible ou déjà protégée. Un véritable défaut de programmation peut aussi n’avoir aucune conséquence de sécurité dans le modèle de menace du projet.
Les examinateurs reconstruisent ces conditions. Ils inspectent les révisions, reproduisent le comportement, vérifient les protections et recherchent des doublons. Une fonction ou une condition inventée peut se cacher dans un récit cohérent. La qualité de présentation ne remplace plus la preuve.
Christopher Robinson, de l’Open Source Security Foundation, estimait en mars que des projets recevant auparavant deux ou trois rapports par semaine pouvaient ensuite en recevoir des centaines simultanément. Il évaluait une enquête à deux à huit heures de travail imprévu pour un mainteneur. Ce sont des observations attribuées sur plusieurs projets, pas des mesures de la file Google.
Les incitations financières peuvent aggraver ce déséquilibre. L’auteur génère beaucoup d’hypothèses tandis que le destinataire paie l’essentiel de la validation. Doublons, gravité exagérée et comportement documenté mal compris concurrencent les vraies découvertes. Même bien intentionné, le volume peut évincer les réparations.
La distinction pertinente n’est pas la participation d’un modèle à l’écriture. Traduction, explication et génération de tests peuvent améliorer une recherche sérieuse. Une personne doit néanmoins comprendre le chemin atteignable, reproduire le résultat et répondre aux questions. Reformuler humainement une hypothèse IA non testée ne la valide pas.
Les recherches validées empêchent de rejeter toute IA
Google poursuit les défenses assistées par IA, dont OSS-Fuzz, Big Sleep et CodeMender. Ses équipes peuvent définir les cibles, recueillir des preuves d’exécution et vérifier les correctifs. Un programme externe reçoit des rapports d’outils et d’environnements différents sans la même chaîne contrôlée.
Les récompenses générales de Google restent importantes. Son bilan indique plus de 17 millions de dollars versés à plus de 700 chercheurs en 2025, soit une hausse supérieure à 40 % sur 2024. Ces sommes couvrent les programmes plus larges, pas le budget ou la productivité de la catégorie OSS suspendue.
Les articles décrivent un autre contraste utile. Anthropic affirmait que Claude Opus 4.6 avait trouvé plus de 500 vulnérabilités open source inconnues, toutes validées par des humains ou experts externes avant divulgation. Mozilla a reçu 112 rapports en deux semaines et publié 22 avis, dont 14 de gravité élevée. De nombreux autres résultats ont été classés comme défauts non sécuritaires.
Ces unités ne sont pas interchangeables : rapports, avis et vulnérabilités validées se comptent différemment. L’exemple soutient une découverte automatisée suivie d’expertise, pas une garantie pour chaque rapport généré.
Le tri automatique peut regrouper les doublons ou demander des preuves manquantes. Il peut lui-même se tromper. L’accord de deux modèles est moins probant qu’un test reproductible indépendamment. Les cas inhabituels et désaccords nécessitent toujours une escalade humaine.
Curl, Linux et HackerOne modifient des relais différents
Curl a arrêté les primes monétaires le 31 janvier 2026 après un programme ouvert en 2019. Daniel Stenberg indiquait 87 vulnérabilités confirmées sur toute sa durée. La part de rapports confirmés avait cependant chuté de plus de 15 % auparavant à moins de 5 % en 2025.
Son explication associait bruit généré par IA, dégradation d’autres signalements et recherche excessive de récompenses. L’arrêt des paiements n’a pas supprimé la divulgation responsable : GitHub privé et courriel restaient des voies possibles. La décision cible les incitations, avec le risque de démotiver aussi de bons chercheurs indépendants.
Linux recevait des découvertes répétées de personnes utilisant des outils similaires. Le traitement privé masquait les discussions et correctifs existants aux autres chercheurs, multipliant le travail des mainteneurs. Torvalds recommandait des canaux publics pour de nombreux problèmes facilement redécouvrables, sauf nécessité réelle de confidentialité.
Cela ne demande pas de publier tout exploit non corrigé. Les règles du noyau exigent descriptions concises, révisions touchées, conditions, reproductions testées et conséquences réalistes. Les auteurs doivent comprendre le code, contacter les bons responsables et proposer un correctif si possible.
HackerOne a signalé une hausse de plus de 100 % du volume sectoriel après l’apparition d’outils IA plus puissants en février 2026. Son analyse inclut découvertes utiles, doublons et affirmations invérifiables. La plateforme insiste sur preuve reproductible, gravité exacte et défenses existantes ; de gros lots non vérifiés peuvent entraîner des sanctions. C’est une observation de plateforme, pas le taux d’invalidité Google.
Les interventions diffèrent : Google suspend une catégorie, curl retire l’argent, Linux adapte attentes et orientation. Leur limite commune est le temps expert, particulièrement lorsque des dépendances commerciales reposent sur des bénévoles.
Rouvrir exige des preuves et une voie pour les nouveaux venus
Des contrôles stricts protègent les examinateurs mais peuvent cacher de vraies failles. La réputation favorise les chercheurs établis. Dépôts financiers et invitations opaques peuvent exclure les débutants. Exiger une exploitation complète peut encourager des tests dangereux alors qu’une reproduction minimale contrôlée suffirait.
Un bon dossier identifie commit, environnement, influence adverse, entrée déclenchante et frontière de sécurité franchie. Il documente les essais réellement exécutés, distingue observation et inférence, et protège les détails confidentiels. Il ne devrait pas imposer de dommages ni l’envoi de code sensible à un service de modèle non autorisé.
Les filtres doivent viser le manque de preuves, pas traiter un style IA comme démonstration d’invalidité. Aucun test stylistique fiable ne détermine si une faille existe. Recours et escalade spécialisée comptent, car des chaînes inhabituelles résistent aux formulaires simples.
La prochaine mise à jour dira si Google privilégie des exigences claires ou moins de participants. Les résultats utiles incluent confirmation, doublons, délais de revue et de correction, charge et rejets erronés, pas seulement moins d’envois. Les expériences varient : Mozilla avait auparavant décrit un taux stable de rejet des rapports invalides. Google ne représente donc pas tout l’écosystème.
La frontière constructive sépare l’échelle de découverte de celle des soumissions. Les agents peuvent explorer largement ; les humains devraient recevoir des résultats validés, dédoublonnés et portés par un responsable. La pause ne prouve pas que l’IA ne trouve pas de bugs. Elle montre que des hypothèses illimitées ne deviennent une valeur de sécurité qu’une fois démontrées.
Sources
Règles Google OSS · Charge des mainteneurs · Enquête sur les faux rapports · Résultats validés Mozilla · Décision de curl · Base technique · Annonce de la suspension · Anciennes règles Google · Primes Google 2025 · Analyse des volumes HackerOne · Règles de signalement Linux · TechCrunch sur la pause de Google · Techmeme sur la pause de Google