La suspension du Google OSS VRP révèle le coût caché des rapports de bugs générés par l’IA

Google a cessé d’accepter de nouveaux signalements de vulnérabilités produit via son programme de bug bounty open source le 1er octobre, après que des rapports IA non valides ont submergé son processus d’examen. La suspension du Google OSS VRP ne met pas fin à toutes les composantes du programme. Elle ferme toutefois une voie majeure de signalement jusqu’à ce que Google achève sa refonte.

Le problème immédiat n’est pas que l’intelligence artificielle soit incapable de détecter des failles logicielles. Les systèmes d’IA découvrent déjà des défauts valides dans de vastes bases de code soumises à des examens approfondis. Le problème est que produire un rapport plausible coûte désormais bien moins cher que d’en prouver l’impact sur la sécurité.

Ce déséquilibre a fait du triage des vulnérabilités la ressource rare. Google doit distinguer les découvertes réelles des scénarios d’attaque hallucinés, du code inaccessible, des doublons et des erreurs de programmation ordinaires. GitHub, les mainteneurs de Linux et les petits projets open source font face à la même pression.

Google indique que les rapports soumis avant la date limite continueront d’être examinés. Les rapports liés à la chaîne d’approvisionnement restent ouverts, tandis que certaines failles dans des dépôts Google Cloud peuvent passer par le Cloud Vulnerability Reward Program. L’entreprise prévoit de communiquer une nouvelle mise à jour d’ici le premier trimestre 2027.

Cette pause met en lumière une contradiction révélatrice. L’IA promet d’étendre la recherche défensive en sécurité, mais une automatisation non vérifiée peut accaparer l’attention humaine nécessaire à la correction de vulnérabilités réelles. L’avenir de la chasse aux bugs assistée par IA dépend désormais moins du volume brut de découvertes que de la qualité des preuves.

La suspension du Google OSS VRP est limitée, mais immédiate

Google a gelé une catégorie de soumissions, sans abandonner sa relation plus large avec les chercheurs externes en sécurité.

Le programme concerné est l’Open Source Software Vulnerability Reward Program, couramment appelé OSS VRP. Google l’a lancé en 2022 afin de récompenser les chercheurs qui divulguent de manière responsable des vulnérabilités affectant des projets open source éligibles.

Le programme couvre des logiciels hébergés dans des dépôts publics appartenant à Google ainsi que certains projets hébergés ailleurs. Son périmètre comprend à la fois les vulnérabilités produit et les compromissions de chaîne d’approvisionnement. Ces catégories répondent à des risques différents et suivent désormais des parcours de soumission distincts.

Les vulnérabilités produit concernent des défauts dans le code, la logique ou la conception d’un projet. Un rapport convaincant doit démontrer que des attaquants peuvent atteindre le défaut et produire des conséquences significatives sur la sécurité. Le simple fait d’identifier une fonction apparemment non sûre ne suffit pas à établir une exploitation.

Les rapports sur la chaîne d’approvisionnement concernent les menaces pesant sur la manière dont les logiciels sont construits, empaquetés, signés ou distribués. Une chaîne de publication compromise peut diffuser du code malveillant même lorsque le code source sous-jacent paraît légitime. Google a maintenu cette catégorie de signalement ouverte.

La suspension s’applique aux nouveaux rapports de vulnérabilités produit déposés à partir du 1er octobre 2026. Les soumissions antérieures restent éligibles à un examen selon le processus précédent. Google a également orienté les chercheurs vers ses autres programmes de récompense des vulnérabilités lorsque cela s’applique.

Certains rapports concernant des dépôts Google Cloud peuvent toujours être éligibles via le Cloud VRP. Cette exception dépend du fait que le problème affecte un produit Google Cloud, et non simplement du fait que le dépôt source appartient à Google.

Google a annoncé ce changement via son compte Bug Hunters sur X. Selon le premier compte rendu détaillé publié, l’entreprise a lié sa décision à un afflux de soumissions non valides générées par l’IA.

La pause fait suite à des mois de durcissement, plutôt qu’à un revirement soudain. Dans une mise à jour des règles publiée en avril, Google a décrit une hausse des rapports de faible qualité et non valides reçus par OSS VRP.

Google a identifié deux schémas récurrents. Certaines soumissions contenaient des explications hallucinées sur la manière dont une vulnérabilité présumée pouvait être déclenchée. D’autres relevaient de véritables erreurs de code, sans parvenir à démontrer que le code était atteignable ou que l’impact sur la sécurité était significatif.

Cette distinction compte, car les défauts logiciels et les vulnérabilités de sécurité ne sont pas interchangeables. Un plantage dans un utilitaire de test inaccessible a des conséquences différentes d’une exécution de code à distance dans un service de production.

Google avait déjà cessé d’offrir des récompenses ou une reconnaissance pour certaines vulnérabilités produit et d’autres problèmes de sécurité dans des catégories de projets moins prioritaires. L’entreprise a également mis l’accent sur les découvertes exploitables, les étapes de reproduction vérifiées et les démonstrations d’impact.

L’action d’octobre prolonge donc un effort existant pour réduire le bruit. Au lieu d’ajuster les critères d’éligibilité alors que les rapports continuent d’affluer, Google a fermé le canal de réception concerné pendant une refonte plus large.

L’entreprise n’a pas communiqué le nombre exact de rapports rejetés, l’ampleur de son retard de traitement ni son taux d’acceptation. Les affirmations faisant état de milliers de soumissions restent des chiffres rapportés, plutôt que des statistiques complètes sur le programme.

L’absence de ces données limite l’analyse externe. Pourtant, l’enchaînement des modifications de règles, des avertissements publics et du gel final montre qu’un filtrage progressif n’a pas résolu le problème de charge de travail.

Pourquoi les rapports de bugs IA non valides paralysent le triage de sécurité

L’IA modifie l’économie du signalement, car les soumissions peuvent être produites à grande échelle automatiquement, tandis que leur validation exige toujours un jugement humain rare.

La recherche traditionnelle de vulnérabilités exige plusieurs étapes coûteuses. Un chercheur doit comprendre la cible, identifier une faiblesse, construire une attaque reproductible, évaluer l’impact et communiquer clairement le résultat.

Les grands modèles de langage peuvent accélérer certaines parties de ce travail. Ils peuvent examiner le code source, suggérer des flux de données dangereux, rédiger des cas de test et transformer des notes sommaires en texte soigné. Des agents automatisés peuvent répéter ces étapes dans de nombreux dépôts.

Les mêmes outils peuvent également produire des explications assurées mais erronées. Un modèle peut supposer que les attaquants contrôlent une entrée qui demeure fiable. Il peut ignorer une vérification d’autorisation, mal comprendre une configuration de déploiement ou inventer un chemin d’exécution atteignable.

Ces échecs deviennent coûteux après la soumission. Un ingénieur en sécurité ne peut pas rejeter un rapport qui semble crédible sur la seule base de son ton. Il doit examiner le code cité, reproduire les conditions, suivre les données et vérifier si l’impact allégué existe.

Un faux rapport peut ainsi prendre quelques minutes à créer et des heures à écarter. Un millier de rapports similaires transforme ce déséquilibre en déni de service opérationnel, même sans intention malveillante.

La présentation du rapport peut aggraver le problème. Les modèles de langage produisent facilement de longs récits de vulnérabilités, des étiquettes de gravité, des schémas d’attaque et des conseils de remédiation. Aucune de ces additions ne remplace une reproduction fonctionnelle.

Un langage soigné peut même augmenter les coûts de triage. Les examinateurs doivent retrouver l’affirmation factuelle au milieu de pages de contexte généré. Ils doivent également déterminer quelles déclarations proviennent de tests et lesquelles résultent d’une inférence du modèle.

Les règles antérieures de Google portaient sur cette différence entre détection et validation. Une alerte d’un analyseur statique peut signaler du code suspect. Elle ne prouve pas automatiquement que ce code crée une violation exploitable d’une frontière de sécurité.

L’atteignabilité est un test essentiel. Les examinateurs ont besoin de preuves qu’une entrée non fiable peut atteindre l’opération dangereuse dans des conditions réalistes. Les rapports doivent également tenir compte de l’assainissement des données, des privilèges, de la configuration et des défenses existantes.

L’impact est un autre test. Un dépassement de tampon semble grave, mais son emplacement et les contrôles qui l’entourent déterminent ce qu’un attaquant peut accomplir. Certaines failles ne font que mettre fin à un processus isolé sans exposer de données ni de contrôle.

La nouveauté compte également. Les systèmes automatisés peuvent redécouvrir des problèmes connus, répéter des théories déjà rejetées ou produire plusieurs descriptions de la même cause racine. Chaque doublon consomme néanmoins des capacités de réception et d’examen.

Cette charge de travail repose sur des personnes spécialisées. Les mainteneurs expérimentés et les ingénieurs en sécurité comprennent des hypothèses architecturales que les modèles négligent souvent. Les mobiliser pour des validations répétitives retarde les correctifs, les audits, les revues de conception et la réponse aux incidents.

Le coût d’opportunité s’étend au-delà de Google. Les projets open source comptent souvent de petits groupes de mainteneurs, même lorsque leur code prend en charge des services largement utilisés. Une campagne de rapports automatisés peut dépasser l’ensemble de leurs capacités de sécurité.

Les équipes peuvent préserver le contexte en conservant les décisions, les reproductions et les découvertes précédentes dans une base de connaissances d’ingénierie consultable. Cette pratique réduit les investigations répétées, mais ne peut pas éliminer le besoin de vérification par des experts.

La pause du bug bounty de Google rend cette contrainte de main-d’œuvre visible. Les programmes de sécurité ont été conçus autour de soumissions impliquant un effort significatif de la part des chercheurs. L’IA permet à l’auteur du signalement de transférer une grande partie de cet effort à l’équipe qui le reçoit.

Les rapports de bugs IA créent un problème de qualité, pas une interdiction de l’IA

Le conflit central oppose la recherche vérifiée à l’automatisation non vérifiée, et non les chercheurs humains à l’intelligence artificielle.

Google n’a pas soutenu que les chercheurs devaient éviter entièrement l’IA. Sa position déclarée est que les personnes doivent valider les résultats de l’IA durant leurs recherches. Cette exigence traite l’IA comme un instrument plutôt que comme un rapporteur responsable.

Une soumission utile assistée par IA peut toujours inclure des preuves directes. Les chercheurs peuvent fournir les versions affectées, les commandes exactes, des cas de test minimisés, des journaux, des captures d’écran et les résultats observés. Ils peuvent également expliquer la frontière de sécurité violée.

La question décisive est de savoir si une personne a confirmé l’affirmation. Une hypothèse générée par un modèle devient précieuse lorsque des tests prouvent que le code concerné est atteignable et que le résultat affecte la confidentialité, l’intégrité ou la disponibilité.

Cette norme protège l’automatisation légitime. Les fuzzers produisent des découvertes de sécurité depuis des années en envoyant des entrées inattendues et en enregistrant les échecs. Leur valeur provient de résultats concrets et reproductibles, plutôt que de descriptions persuasives.

Les agents d’IA peuvent étendre ce modèle. Ils peuvent raisonner sur le code source, créer des harnesses, enquêter sur des plantages et proposer des correctifs. Leur espace de recherche plus large peut faire apparaître des défauts que les outils conventionnels ne détectent pas.

Cependant, les systèmes de raisonnement introduisent un autre mode d’échec. Ils peuvent combler les éléments de preuve manquants avec un langage plausible. Un scanner conventionnel signale généralement le motif qu’il a détecté, tandis qu’un modèle de langage peut inventer tout un récit d’attaque.

Cette différence explique pourquoi les programmes de divulgation ne peuvent pas simplement évaluer les rapports selon leur fluidité. Les examinateurs ont besoin d’artefacts liés à des comportements observables. Les affirmations sur des conséquences théoriques méritent moins de confiance que les résultats démontrés.

La preuve la plus solide contre un rejet général de l’IA provient de travaux de sécurité IA réussis. Des systèmes d’IA ont détecté de véritables vulnérabilités dans de grands projets open source, y compris des failles que les examinateurs humains n’avaient pas repérées.

Ces résultats montrent pourquoi interdire tous les rapports assistés par IA serait à courte vue. Les équipes défensives veulent une couverture plus large, en particulier sur de vastes graphes de dépendances et des bases de code matures. Elles ne veulent pas de spéculations illimitées et non testées.

Google utilise lui-même l’IA dans la recherche défensive en sécurité. Ses travaux de sécurité plus larges incluent la découverte de vulnérabilités assistée par IA et le fuzzing open source. L’objection de l’entreprise concerne la qualité de la validation à la frontière du signalement.

Cette frontière soulève une question de responsabilité. Lorsqu’un agent autonome soumet un rapport, qui répond aux questions de suivi ? Quelqu’un doit clarifier les hypothèses, modifier la reproduction et distinguer le comportement observé du comportement prédit.

Un rapport sans chercheur responsable transfère ces tâches au mainteneur. Le destinataire devient chargé d’achever l’enquête engagée par l’auteur de la soumission.

Une divulgation claire du recours à l’IA peut aider, mais la divulgation seule ne peut établir la qualité. Un rapport rédigé par un humain peut également être erroné. Un rapport généré par IA peut être exact, concis et rigoureusement testé.

Les programmes ont donc besoin de critères fondés sur les preuves plutôt que de détecteurs de style. Les classificateurs de texte IA peuvent mal étiqueter les écrits techniques, surtout lorsque les chercheurs utilisent des modèles ou rédigent dans une seconde langue.

Un meilleur système de réception évalue le fond du rapport. Il peut exiger une reproduction minimale, des détails sur l’environnement, les commits affectés, une preuve d’accessibilité et une explication directe des capacités de l’attaquant.

La suspension du Google OSS VRP donne à l’entreprise le temps de concevoir de tels critères. Le risque est qu’un système plus strict exclue aussi des nouveaux venus compétents, dépourvus de réputation mais détenteurs d’une découverte valide.

Ce compromis ne peut pas disparaître. Les programmes ouverts attirent des découvertes inattendues parce que tout le monde peut y participer. Restreindre l’accès améliore la qualité moyenne tout en réduisant la probabilité qu’un chercheur inconnu atteigne la bonne équipe.

GitHub et les mainteneurs open source resserrent le même filtre

La décision de Google s’inscrit dans une évolution à l’échelle du secteur, des réceptions ouvertes vers la réputation, les preuves et des canaux de soumission plus étroits.

GitHub a été confronté à son propre arriéré de rapports peu soignés et générés par IA en 2026. L’entreprise a réagi en restructurant son programme de primes et en créant des parcours distincts pour les chercheurs publics et invités.

Le programme public a ajouté une exigence de signal HackerOne, qui utilise les antécédents d’un chercheur sur la plateforme comme mesure d’éligibilité. Le programme sur invitation offre une voie distincte aux chercheurs ayant déjà établi leur fiabilité.

GitHub a déclaré que son objectif était de réduire le volume de rapports peu soignés tout en préservant la recherche externe sérieuse. Son annonce de restructuration a appliqué la nouvelle structure aux rapports soumis à partir du 27 juillet 2026.

Des directives antérieures expliquaient quelles preuves la plateforme jugeait utiles. Un rapport solide devait comporter un résumé concis, des étapes de reproduction accompagnées d’artefacts justificatifs et une déclaration claire de l’impact qu’un attaquant peut réellement obtenir.

GitHub a également averti que les récits théoriques et le contenu de remplissage généré par IA ralentissaient le triage. Le problème ne se limitait pas à un contenu inexact. Des explications excessives pouvaient enfouir la découverte réelle et retarder l’examen.

Google et GitHub ont choisi des réponses immédiates différentes. GitHub a conservé une voie publique avec des seuils de réputation et de qualité plus élevés. Google a suspendu une catégorie de son OSS VRP tout en laissant disponibles ses autres programmes de vulnérabilités.

Les deux approches protègent l’attention des évaluateurs. Elles créent aussi des frictions pour les nouveaux chercheurs qui n’ont pas encore construit de réputation sur les plateformes. Un excellent premier rapport peut venir d’une personne sans long historique de primes aux bugs.

Les mainteneurs open source font face à une version encore plus aiguë de ce problème. De nombreux projets ne disposent ni de personnel de sécurité dédié, ni d’équipes de triage rémunérées, ni d’infrastructure formelle de soumission. Un mainteneur peut examiner les rapports sur son temps personnel.

Les recommandations du secteur placent de plus en plus la responsabilité des deux côtés. L’Open Source Security Foundation conseille aux chercheurs de vérifier leurs découvertes, de comprendre les politiques des projets et d’indiquer clairement comment l’IA a contribué au travail.

Ses recommandations destinées aux mainteneurs reconnaissent également que l’IA peut appuyer une analyse défensive légitime. La réponse recommandée s’articule autour d’une intégration sûre et d’un examen humain.

La tendance générale ressemble au contrôle du spam. Lorsque l’envoi devient presque gratuit, les destinataires doivent introduire des filtres, des signaux de réputation, des limites de débit ou des coûts de soumission. Sinon, le volume de faible qualité submerge les communications utiles.

Les programmes de primes aux bugs ne peuvent pas reproduire exactement les filtres antispam ordinaires. Les rapports de sécurité contiennent des détails techniques inédits et proviennent souvent de chercheurs inconnus. Rejeter trop agressivement les contenus inhabituels peut masquer la découverte la plus importante.

Les programmes combineront probablement plusieurs contrôles. Des formulaires structurés peuvent imposer des réponses concrètes. Des vérifications automatisées peuvent tester l’existence des artefacts requis. La réputation peut déterminer des limites de soumission plutôt qu’une éligibilité absolue.

Les limites de débit pourraient devenir particulièrement importantes pour les agents autonomes. Une personne peut examiner plusieurs candidats générés par machine et ne soumettre que les plus solides. Un système sans supervision peut inonder un programme avant que les mainteneurs ne fournissent un retour.

Des dépôts ou cautions de soumission remboursables créeraient des coûts plus importants, mais soulèveraient des préoccupations d’accès. Les chercheurs des régions à faibles revenus pourraient faire face à des obstacles disproportionnés. La complexité juridique et administrative augmenterait également.

Les programmes privés ou accessibles sur invitation évitent le volume public, mais perdent une large participation. Ils concentrent la confiance parmi des chercheurs connus, risquant ainsi de passer à côté de personnes extérieures possédant une connaissance spécialisée d’un composant particulier.

La refonte de Google a donc des implications au-delà d’une seule entreprise. D’autres opérateurs de programmes étudieront si elle restaure le signal sans fermer la porte aux nouveaux talents.

Des filtres plus stricts peuvent aussi masquer de vraies vulnérabilités

Réduire le bruit de l’IA est nécessaire, mais chaque filtre crée le risque qu’un rapport valide et inhabituel n’atteigne jamais le bon ingénieur.

Google a décrit les raisons de la suspension, mais n’a pas publié de données complètes sur les performances. Les observateurs externes ne peuvent pas comparer les taux de faux positifs avant et après l’adoption de l’IA, ni mesurer la gravité réelle de l’arriéré.

Sans ces chiffres, plusieurs interprétations restent possibles. Les soumissions générées par IA peuvent dominer la file, ou un groupe plus restreint d’auteurs répétitifs peut créer l’essentiel de la charge. Des causes différentes exigent des contrôles différents.

La qualité des modèles sous-jacents compte également. Une politique conçue autour des taux d’hallucination actuels peut vite vieillir. De meilleurs agents peuvent produire des reproductions plus solides, mais aussi générer de plus grands volumes de rapports.

La conception du programme doit distinguer la confiance des preuves. Un agent qui attribue une forte probabilité à l’exploitation n’a pas prouvé l’exploitation. À l’inverse, un rapport incomplet peut toujours décrire une faille grave méritant un suivi.

Les nouveaux chercheurs soumettent souvent des rapports imparfaits parce qu’ils manquent d’expérience en matière de divulgation. Leur écriture peut ressembler à une production automatisée de faible qualité, même lorsque l’observation sous-jacente est authentique.

La langue et l’accessibilité créent des risques similaires. Exiger un anglais soigné peut désavantager des chercheurs possédant une connaissance technique approfondie. Les formulaires devraient demander des preuves précises sans transformer le style en indicateur indirect de crédibilité.

Les critères de réputation renforcent également les accès antérieurs. Les chercheurs établis reçoivent davantage d’occasions de construire des signaux, tandis que les nouveaux venus peinent à entrer. Une boucle fermée peut améliorer l’efficacité, mais affaiblir la diversité.

L’automatisation du côté des destinataires introduit une autre incertitude. Google peut utiliser des modèles pour résumer, dédupliquer ou prioriser les rapports. Ces systèmes exigent un audit, car un faux négatif entraîne des conséquences différentes d’un faux positif.

Un faux positif fait perdre du temps aux évaluateurs. Un faux négatif peut laisser une vulnérabilité non découverte. Les systèmes de réception devraient donc automatiser plus volontiers l’orientation et les contrôles de preuves que le rejet final.

Les recours offrent une garantie. Un chercheur dont le rapport est rejeté devrait comprendre quel élément a échoué et si des preuves supplémentaires peuvent rouvrir le dossier. Les messages de rejet génériques encouragent les soumissions répétées et la frustration publique.

Des exemples transparents peuvent également améliorer les comportements. Les programmes peuvent publier des cas anonymisés montrant du code inaccessible, des affirmations d’impact non étayées, des causes profondes de doublons et des reproductions acceptables.

Google propose déjà des conseils de signalement dans ses programmes de vulnérabilités. Son cadre de qualité met l’accent sur les informations relatives à la cible, la reproductibilité, l’impact et la communication.

La refonte doit décider si ces normes deviennent des prérequis appliqués par machine. Elle doit également déterminer quels rapports méritent une appréciation humaine malgré l’absence d’un champ formel.

Il existe un autre danger à qualifier toute soumission indésirable de bouillie IA. Cette étiquette peut masquer de véritables désaccords sur les modèles de menace. Les chercheurs et les fournisseurs évaluent souvent différemment la possibilité d’exploitation.

Une entreprise peut rejeter un problème parce qu’un attaquant a besoin d’une interaction utilisateur. Un chercheur peut soutenir que cette interaction reste réaliste. Ces différends sont antérieurs à l’IA générative et ne peuvent être résolus par la détection de l’auteur.

La même prudence s’applique aux défauts de code ordinaires. Certains bugs n’ont pas d’impact immédiat, mais deviennent dangereux après un autre changement de produit. Les programmes ont besoin de limites, mais celles-ci ne doivent pas être confondues avec des jugements universels sur la gravité.

La suspension est donc une intervention de triage, et non la preuve que les dépôts concernés sont devenus plus sûrs. Les vulnérabilités continuent d’exister alors qu’une voie de signalement reste fermée.

Les chercheurs doivent identifier un autre canal approprié ou contacter directement le projet concerné. Des voies de divulgation fragmentées peuvent accroître les délais, les publications accidentelles et les efforts dupliqués.

Google peut réduire ce risque en orientant clairement les rapports exclus. Son répertoire public de programmes sépare déjà les périmètres Google, Cloud, Chrome, Android, IA, abus et open source.

La refonte ne réussira que si les chercheurs valides peuvent prévoir la bonne destination. Une file plus courte importe peu si des rapports graves disparaissent entre des règles de programme qui se chevauchent.

Ce qu’il faut surveiller avant que Google ne rouvre les rapports sur les produits

Le prochain test sera de savoir si Google remplace une boîte de soumission ouverte par un système qui vérifie les preuves sans faire taire les chercheurs inconnus.

Le premier signal sera la mise à jour promise d’ici le premier trimestre 2027. Google devrait préciser si les soumissions de vulnérabilités de produits rouvriront, seront déplacées ailleurs ou reviendront via un processus à accès limité.

Une réouverture assortie d’exigences structurées en matière de preuves conforterait l’idée que la suspension était un triage temporaire. Une fermeture indéfinie montrerait que Google ne considère plus l’ancien modèle public comme viable.

Le deuxième signal réside dans la conception du filtre de réception. Des reproductions requises, les versions affectées, les commits testés, les traces d’exécution et des déclarations concises d’impact répondraient directement aux modes de défaillance documentés.

Des restrictions fondées uniquement sur la réputation représenteraient un choix différent. Elles pourraient réduire rapidement le volume, mais accorderaient davantage de poids à l’historique du chercheur qu’aux preuves contenues dans chaque rapport.

Le traitement des agents autonomes par Google sera particulièrement important. L’entreprise pourrait exiger qu’une personne nommée atteste que chaque soumission a été reproduite. Elle pourrait également imposer des limites de débit aux signalements assistés par machine.

Une politique pertinente devrait distinguer l’assistance par IA des soumissions de masse sans supervision. Les chercheurs utilisent couramment l’automatisation, les débogueurs, les fuzzers, les scanners et les modèles de langage. La question décisive est de savoir qui valide et assume la responsabilité de l’affirmation.

Le troisième signal sera de savoir si l’arriéré s’améliore sans réduire le nombre de découvertes confirmées. Google n’a pas publié suffisamment de données pour cette comparaison, mais une transparence future aiderait d’autres programmes à tirer les leçons de la refonte.

Des métriques utiles incluraient le volume de soumissions, le temps de validation, les taux de doublons, les découvertes acceptées, les recours des rapporteurs et la part des rapports contenant des reproductions fonctionnelles. Des chiffres agrégés pourraient protéger les détails sensibles.

Les chercheurs devraient également surveiller les autres VRP de Google. Si des rapports de bugs IA invalides migrent vers Cloud, Chrome ou les canaux généraux de Google, la suspension n’aura fait que déplacer la charge de travail au lieu de la résoudre.

Le système plus large de bug bounty de l’entreprise reste actif. L’annuaire des programmes de Google continue d’orienter les problèmes de sécurité éligibles vers plusieurs programmes spécialisés.

Les mainteneurs en dehors de Google ne devraient pas attendre la politique finale. Ils peuvent définir les éléments de preuve acceptés, publier des modèles de menace, limiter les soumissions automatisées et créer des modèles distinguant les observations de l’impact supposé.

Les chercheurs peuvent aussi s’adapter. Avant de soumettre un rapport, ils devraient reproduire le comportement, réduire le cas de test au minimum, confirmer la révision affectée et expliquer l’accès requis pour un attaquant.

Ils devraient supprimer le contenu généré qui n’étaye pas la découverte. Un rapport court reposant sur des preuves directes est plus facile à valider qu’un essai soigné construit autour d’une hypothèse incertaine.

La recherche en sécurité assistée par IA continuera de s’étendre, car ses avantages légitimes sont considérables. Les modèles peuvent parcourir davantage de code, générer des tests ciblés et aider les enquêteurs à relier des composants peu familiers.

Toutefois, le volume de découvertes n’est plus le meilleur indicateur de progrès. Un rapport ne devient utile que lorsqu’il fournit aux mainteneurs suffisamment de preuves fiables pour agir.

La suspension du VRP OSS de Google marque le moment où cette distinction est devenue impossible à ignorer. La conception du prochain programme devra récompenser les informations vérifiées, préserver l’accès et maintenir l’attention humaine sur les risques réels.

Avant de soumettre une nouvelle découverte assistée par IA, posez-vous une question plus exigeante que celle de savoir si le modèle a repéré du code suspect : un autre ingénieur peut-il reproduire l’impact sur la sécurité à partir des éléments de preuve fournis ?