La prime aux bugs open source de Google suspendue alors que les rapports d’IA submergent les examinateurs

Google a suspendu sa prime aux bugs open source après une hausse des rapports automatisés, affirmant que la grande majorité était invalide. La suspension a commencé le 1er octobre 2026 et concerne les nouvelles soumissions de vulnérabilités produit au programme Open Source Software Vulnerability Reward Program.

Cette décision crée une contradiction frappante pour la recherche en sécurité assistée par l’IA. Les modèles peuvent désormais inspecter davantage de code et produire des rapports convaincants à une vitesse sans précédent. Pourtant, chaque soumission exige toujours qu’une personne détermine si la faille alléguée existe, est importante et peut être reproduite.

Google n’est pas seul. Curl a mis fin aux récompenses financières après que son taux de vulnérabilités confirmées est tombé sous les 5 % en 2025. Les responsables de Linux ont également modifié leurs pratiques de divulgation après avoir reçu des vagues de résultats d’IA dupliqués. Ensemble, ces cas montrent que la découverte de vulnérabilités s’est développée plus rapidement que leur examen.

La prime aux bugs open source de Google cesse d’accepter les rapports produit

Google a temporairement fermé un important canal de réception parce que les soumissions automatisées généraient davantage de travail d’examen que de résultats de sécurité utiles.

Le Google OSS VRP, abréviation de Open Source Software Vulnerability Reward Program, récompense les chercheurs qui divulguent de façon responsable des failles de sécurité dans des projets open source éligibles. Google a lancé ce programme en 2022 afin de couvrir les logiciels maintenus dans ses dépôts publics ainsi que certains projets externes sélectionnés.

Ce canal de vulnérabilités produit a cessé d’accepter de nouveaux rapports le 1er octobre. Google a indiqué prévoir une nouvelle mise à jour au cours du premier trimestre 2027.

« Cette pause est due à une hausse significative des soumissions automatisées, dont la grande majorité ne sont pas valides », a déclaré Google dans son avis. Cette formulation compte, car elle distingue l’automatisation de la recherche de vulnérabilités vérifiée.

La pause n’efface pas les rapports soumis avant la date limite. Elle ne ferme pas non plus toutes les voies associées au programme plus large. Les soumissions concernant des vulnérabilités de la chaîne d’approvisionnement restent éligibles, selon les règles du programme mises à jour.

Certaines vulnérabilités impliquant des dépôts Google Cloud peuvent toujours être éligibles via le Cloud VRP. Google a également orienté les chercheurs vers ses autres programmes de récompense pendant qu’il réévalue le processus de réception open source.

Ce périmètre plus restreint rend le terme « gel » plus exact que celui de « fermeture ». Google a suspendu les nouvelles soumissions de vulnérabilités produit au sein du programme OSS, sans abandonner la recherche externe en sécurité à l’échelle de l’entreprise.

L’entreprise n’a publié ni nombre de soumissions, ni taux de rapports invalides, ni volume total de dossiers en attente de triage pour le canal concerné. Les affirmations selon lesquelles les examinateurs auraient reçu un nombre précis de mauvais rapports restent donc non vérifiées.

Ce que Google a révélé constitue toutefois le signal décisif. Les rapports automatisés étaient devenus suffisamment nombreux et peu fiables pour rendre le processus existant insoutenable.

Ce processus repose sur bien plus que la réception d’un document soigné. Un examinateur doit inspecter le chemin de code, recréer les conditions, évaluer l’exploitabilité, rechercher les doublons et identifier l’équipe responsable du projet.

Un rapport plausible peut mobiliser un temps considérable même lorsqu’il est erroné. Les grands modèles de langage aggravent ce problème, car ils peuvent produire des explications détaillées, des extraits de code et des affirmations confiantes sur la gravité sans démontrer la vulnérabilité sous-jacente.

Google avait déjà durci ses règles plus tôt en 2026 après avoir constaté une « hausse massive » des rapports générés par l’IA. La pause d’octobre suggère que les seules exigences de filtrage n’ont pas rétabli un rapport signal-bruit acceptable.

La prime aux bugs open source de Google est donc devenue un cas d’étude d’un problème de sécurité plus large. Générer une affirmation est désormais peu coûteux, tandis que la réfuter reste onéreux.

Pourquoi les rapports de bugs par IA créent un coût asymétrique

L’IA modifie l’économie de la divulgation, car une machine peut générer des rapports plus rapidement que les responsables de maintenance ne peuvent les valider.

La recherche traditionnelle de bugs impose des coûts significatifs au chercheur. Une personne doit comprendre une base de code, isoler un comportement inattendu, vérifier s’il a un impact sur la sécurité et documenter un cas reproductible.

L’IA générative réduit une partie de cette charge de travail. Un agent peut analyser des dépôts, suivre des fonctions, comparer des schémas, rédiger du code de preuve de concept et transformer des résultats préliminaires en rapports d’apparence professionnelle.

Ces capacités peuvent aider les chercheurs légitimes. Elles peuvent aussi permettre à des utilisateurs inexpérimentés de soumettre des affirmations qu’ils ne comprennent pas et qu’ils ne peuvent pas défendre lors des questions de suivi.

L’asymétrie apparaît après la soumission. Produire un rapport supplémentaire peut nécessiter peu d’effort additionnel, mais son triage continue de mobiliser une attention d’ingénierie rare.

Christopher Robinson, directeur technique de l’Open Source Security Foundation, a décrit cette charge dans un rapport sur la sécurité publié en mars. Les projets populaires recevaient autrefois deux ou trois rapports au cours d’une semaine moyenne, a-t-il estimé. Certains en ont ensuite reçu des centaines d’un seul coup.

Robinson a indiqué qu’un rapport individuel peut exiger de deux à huit heures de travail imprévu de la part d’un responsable de maintenance. Ce coût existe même lorsque la réponse finale est qu’aucune vulnérabilité n’existe.

Les faux positifs ne sont pas le seul problème. Les systèmes automatisés peuvent envoyer des découvertes dupliquées, mal interpréter un comportement documenté, ignorer les modèles de menace ou exagérer des défauts à faible impact.

Une vulnérabilité hallucinée est particulièrement coûteuse, car le rapport peut sembler cohérent sur le plan interne. Les examinateurs peuvent suivre une argumentation technique détaillée avant de découvrir qu’une fonction, un chemin de contrôle ou une condition d’exploitation citée a été inventée.

Vlad Ionescu, cofondateur de l’entreprise de sécurité IA RunSybil, a décrit cette expérience dans une précédente enquête sur l’AI slop. Il a déclaré que les rapports peuvent paraître techniquement solides jusqu’à ce que les examinateurs enquêtent et constatent que le modèle a fabriqué les détails.

Cela crée un goulot d’étranglement de vérification. L’IA accroît l’offre de résultats possibles, mais n’augmente pas automatiquement le nombre d’examinateurs dignes de confiance.

Les primes aux bugs créent également une incitation financière à soumettre des affirmations incertaines. Un chercheur peut envoyer de nombreux rapports spéculatifs tandis que les responsables de maintenance absorbent la plus grande partie du coût de validation.

Les systèmes de réputation et les limites de débit peuvent réduire les abus, mais ils introduisent leurs propres compromis. Des barrières strictes peuvent exclure de nouveaux chercheurs qui n’ont pas d’historique sur la plateforme, mais disposent d’une découverte légitime.

Les exigences d’identité peuvent décourager la divulgation responsable par des personnes exposées à des risques juridiques, professionnels ou géographiques. Des frais de soumission créeraient une barrière encore plus importante.

Le filtrage automatisé présente une autre complication. Un filtre qui rejette des rapports parce qu’ils semblent générés par une machine peut écarter de véritables vulnérabilités découvertes ou documentées avec l’aide de l’IA.

La distinction essentielle n’est pas de savoir si l’IA a participé au rapport. Elle consiste à déterminer si le soumetteur a vérifié le comportement et peut étayer son affirmation avec des preuves reproductibles.

Cette norme devient plus difficile à imposer lorsque les agents peuvent créer des documents persuasifs à grande échelle. La qualité du texte ne fournit plus un signal fiable de la qualité de la recherche.

La réponse pratique impliquera probablement des exigences de preuve plus strictes. Les programmes peuvent demander des reproductions minimales, les détails des versions affectées, des traces d’exploitation, des cas de test ou des correctifs fonctionnels avant d’attribuer un examen humain.

Ces exigences reportent une partie du coût de vérification sur le soumetteur. Elles favorisent également les chercheurs qui comprennent le code et restent disponibles pour répondre aux questions.

Le problème des rapports de bugs IA de Google est aussi une réussite de la sécurité par IA

La même technologie qui génère des soumissions de faible qualité découvre de véritables vulnérabilités que les chercheurs humains n’avaient pas détectées.

Considérer chaque rapport assisté par l’IA comme un déchet reviendrait à mal interpréter les preuves. Des modèles avancés ont démontré des capacités significatives d’analyse de code dans des conditions contrôlées.

Anthropic a indiqué que Claude Opus 4.6 avait découvert plus de 500 vulnérabilités jusque-là inconnues dans des projets open source lors de tests internes. Des chercheurs humains ou externes en sécurité ont validé chaque découverte avant sa divulgation, selon l’entreprise.

Mozilla a reçu 112 rapports issus de cet effort en deux semaines. L’organisation a publié 22 avis de sécurité, dont 14 pour des failles de gravité élevée, tout en classant de nombreux résultats restants comme des bugs non liés à la sécurité.

Ces résultats illustrent un processus différent de la soumission automatisée de masse. Anthropic a associé la découverte par machine à une validation humaine, une divulgation coordonnée et une communication ciblée avec les responsables de maintenance.

Dans un cas, le modèle aurait créé une preuve de concept pour établir qu’une faille suspectée était réelle. Cette étape transforme un schéma spéculatif en preuve que les examinateurs peuvent tester.

Les découvertes concernant Firefox montrent également pourquoi interdire purement et simplement la recherche par IA serait contre-productif. Les modèles peuvent examiner du code mature et abondamment testé tout en faisant émerger des défauts conséquents.

Le conflit n’oppose donc pas les humains à l’IA. Il oppose la recherche vérifiée à la génération de rapports sans responsabilité.

Un processus de qualité assisté par l’IA conserve un responsable humain. Cette personne vérifie le résultat, élimine les faux positifs, comprend l’impact et assume la responsabilité de communiquer avec les responsables de maintenance.

Un processus de faible qualité traite le point de terminaison de divulgation comme une autre destination automatisée. L’agent identifie un schéma, rédige un récit sur la gravité et le soumet sans reproduction indépendante.

Les deux processus peuvent produire une prose soignée. Un seul réduit la charge de travail du destinataire.

Cette distinction explique pourquoi la pause de Google ne prouve pas que la recherche de bugs par IA a échoué. Elle montre que son architecture de soumission ne pouvait pas absorber le mélange actuel de découvertes utiles, de doublons et d’hallucinations.

La sécurité assistée par l’IA pourrait à terme améliorer les deux côtés de cette architecture. Les programmes peuvent utiliser des modèles pour regrouper les doublons, comparer les affirmations aux problèmes connus, tester les chemins d’exploitation et identifier les preuves manquantes.

HackerOne et d’autres plateformes ont commencé à introduire une assistance au triage fondée sur l’IA. De tels outils peuvent prioriser les rapports, mais leurs performances doivent être évaluées au regard des taux de faux rejets et de vulnérabilités manquées.

Un examinateur automatisé peut lui aussi halluciner. Si les programmes placent un modèle entre les chercheurs et les responsables de maintenance, ils ont besoin de voies d’escalade pour les découvertes que le filtre ne peut pas classer avec confiance.

Le modèle le plus robuste sera probablement stratifié. Les machines effectuent des vérifications peu coûteuses, des spécialistes expérimentés examinent les rapports retenus, et les responsables de maintenance des projets ne traitent que les découvertes crédibles.

Cette approche ressemble à l’intégration continue pour les contributions logicielles. Les tests rejettent les échecs évidents avant qu’un responsable de maintenance ne consacre du temps à un examen détaillé.

Les affirmations de sécurité restent plus difficiles à tester que les changements de code ordinaires. L’exploitabilité dépend du contexte, de la configuration, des frontières de confiance et des capacités de l’attaquant, que les vérifications automatisées peuvent mal comprendre.

Néanmoins, exiger des preuves vérifiables par machine peut améliorer le niveau de base. Un rapport comportant un test défaillant, une trace d’exécution ou un plantage reproductible donne aux examinateurs un élément concret à évaluer.

Les organisations ont également besoin de dossiers durables pour ce travail. Une base de connaissances d’ingénierie consultable peut aider les équipes à comparer de nouvelles conclusions avec des rapports, décisions et correctifs antérieurs.

L’objectif n’est pas de ralentir les découvertes légitimes. Il s’agit d’empêcher une génération illimitée d’épuiser un budget limité de revue humaine.

Curl et Linux montrent qu’il s’agit d’un problème industriel

La pause de Google s’inscrit dans une tendance où les projets open source restreignent leurs canaux de divulgation après que l’IA a submergé les systèmes de confiance existants.

Curl offre l’exemple antérieur le plus clair. Le projet de transfert de données largement utilisé a mis fin à sa prime monétaire pour les bugs le 31 janvier 2026, après avoir exploité le programme depuis 2019.

Le mainteneur Daniel Stenberg a indiqué que le programme avait permis de confirmer 87 vulnérabilités. Cependant, la tendance en matière de qualité s’est fortement dégradée au cours de 2025.

Curl confirmait auparavant plus de 15 % des soumissions comme vulnérabilités. Ce taux est tombé sous les 5 % en 2025, ce qui signifie que moins d’un rapport sur vingt s’est avéré valide.

Stenberg a imputé cette situation à trois tendances liées : le contenu généré de mauvaise qualité par l’IA, la baisse de qualité des autres soumissions et des rapporteurs davantage concentrés sur les récompenses que sur l’amélioration du projet.

« Les soumissions interminables de contenu médiocre pèsent lourdement sur le plan mental », a-t-il écrit en annonçant la décision de curl.

Curl n’a pas cessé d’accepter les signalements de sécurité. Le projet a supprimé les récompenses financières, maintenu HackerOne comme canal recommandé et orienté les chercheurs vers des rapports GitHub privés ou l’e-mail.

Cette réponse ciblait les incitations plutôt que la technologie elle-même. Stenberg a fait valoir que les récompenses attiraient des découvertes légitimes, mais rendaient également les soumissions spéculatives trop faciles.

Il a reconnu le compromis. Supprimer les paiements peut réduire le bruit, mais cela peut aussi affaiblir les incitations pour les chercheurs indépendants qualifiés qui consacrent beaucoup de temps à des investigations difficiles.

La communauté du noyau Linux a rencontré un problème connexe impliquant des découvertes en double. Plusieurs chercheurs ont exécuté des outils d’IA similaires sur le même code et soumis les mêmes problèmes via un canal privé.

La divulgation privée empêchait les chercheurs de voir qu’une autre personne avait déjà signalé ou discuté d’une découverte. Les mainteneurs ont redirigé à plusieurs reprises les doublons ou indiqué des correctifs déjà disponibles publiquement.

Linus Torvalds a décrit la liste de sécurité privée comme « presque entièrement impossible à gérer ». Il a estimé que les découvertes détectées par l’IA devraient généralement passer par les canaux publics du projet, sauf lorsqu’un secret est réellement nécessaire.

La documentation Linux a également relevé le niveau d’exigence attendu des soumissionnaires. Les chercheurs doivent fournir des éléments de preuve concis, contacter les mainteneurs concernés et contribuer un correctif lorsque cela est possible.

Cette politique préserve la responsabilité humaine. L’IA peut aider à la découverte, mais une personne doit comprendre le rapport et rester responsable de ses conséquences.

Google, curl et Linux ont choisi des interventions différentes parce que leurs programmes ont des structures différentes. Google a suspendu une catégorie de soumission. Curl a supprimé les récompenses. Linux a redirigé de nombreux rapports et mis l’accent sur leur traitement public.

Leur conclusion commune est plus importante que les détails de chaque politique. Une réception ouverte sans coûts significatifs pour les soumissions ne fonctionne pas lorsque des agents automatisés peuvent produire un nombre presque illimité d’affirmations.

Les petits projets courent le plus grand risque. Google peut affecter des ingénieurs et repenser son infrastructure, tandis que les mainteneurs bénévoles peuvent ne disposer d’aucune équipe de triage dédiée.

Les logiciels open source sont souvent intégrés à des produits commerciaux, des services cloud, des outils de développement et des systèmes critiques. Pourtant, la responsabilité de l’examen des rapports de sécurité peut reposer sur quelques contributeurs non rémunérés.

L’IA amplifie ce décalage. Elle permet à des tiers d’analyser en continu du code important sans fournir le travail nécessaire pour valider, corriger et coordonner chaque découverte possible.

Le résultat ressemble à un problème de déni de service, même lorsque les soumissionnaires ont de bonnes intentions. Chaque rapport demande de l’attention aux mainteneurs, et le volume cumulé peut évincer les vulnérabilités réelles.

Des contrôles plus stricts peuvent aussi masquer de vraies vulnérabilités

Les programmes doivent réduire le volume de faible qualité sans créer un système de sécurité auquel seuls les chercheurs établis peuvent accéder.

La pause de Google protège les examinateurs à court terme, mais elle supprime aussi une voie de signalement pour les découvertes légitimes. Une vulnérabilité valide d’un produit découverte après le 1er octobre peut nécessiter un autre programme éligible ou canal de divulgation.

Cette friction est importante, car les chercheurs ne comprennent pas toujours les frontières organisationnelles d’une entreprise. Une faille dans un dépôt open source peut affecter un produit cloud, une dépendance ou une application en aval.

Des règles de routage complexes augmentent le risque de divulgation tardive ou mal dirigée. Elles peuvent également encourager la publication publique lorsque les chercheurs ne parviennent pas à identifier un canal privé accepté.

L’accès fondé sur la réputation crée un autre risque. Il est plus facile de faire confiance aux chercheurs expérimentés, mais de nouveaux participants ont historiquement contribué à des découvertes importantes dans les programmes de primes.

Un système favorisant les identités établies peut reproduire les inégalités d’accès existantes. Il peut désavantager les chercheurs indépendants, les étudiants et les personnes extérieures aux grandes communautés de sécurité.

Des exigences strictes de preuve de concept peuvent également devenir dangereuses. Démontrer l’exploitabilité peut nécessiter de manipuler des données réelles, de contourner des protections ou d’effectuer des tests qui enfreignent les règles du programme.

Les programmes ont donc besoin de normes de preuve solides mais sûres. Un reproducteur minimal, un test contrôlé ou un chemin de code détaillé peut établir la crédibilité sans nécessiter une exploitation nuisible.

Il n’existe pas non plus de détecteur fiable des textes générés par l’IA. Les chercheurs utilisent couramment des modèles pour la traduction, l’édition, l’explication de code ou la mise en forme, même lorsque le travail sous-jacent est légitime.

Rejeter des rapports sur la base du style pénaliserait une divulgation soigneuse et inciterait à dissimuler l’usage de l’IA. Cela ne permettrait pas d’établir si la faille signalée est réelle.

La déclaration publique de Google laisse plusieurs questions sans réponse. L’entreprise n’a pas indiqué quelles mesures de filtrage ont échoué, combien de découvertes légitimes ont été prises dans cette vague, ni quelle refonte elle envisage.

On ignore également si la pause prendra fin avec davantage d’automatisation, des seuils de preuve plus élevés, un accès restreint ou un modèle de récompense différent.

L’absence de chiffres limite l’évaluation externe. « La grande majorité » exprime la gravité de la situation, mais ne révèle pas si le taux de validité est légèrement tombé sous un seuil existant ou s’est presque entièrement effondré.

Les lecteurs devraient également éviter de considérer l’expérience de Google comme universelle. Mozilla avait auparavant indiqué que son taux de rejet des rapports invalides était resté stable durant une période antérieure, malgré les préoccupations plus larges du secteur.

La conception du programme, la visibilité du projet, les incitations liées aux récompenses et les règles de soumission influent tous sur le volume et la qualité des rapports. Une politique efficace pour un projet peut échouer pour un autre.

Les systèmes d’IA eux-mêmes évoluent rapidement. De meilleurs modèles peuvent produire des faux positifs plus convaincants, mais ils peuvent aussi générer des preuves plus solides et réduire les hallucinations.

Ce double mouvement rend les règles statiques fragiles. Les programmes ont besoin de contrôles de qualité mesurables qui évaluent les preuves plutôt que de deviner quel outil a produit le contenu.

Pour les responsables de la sécurité, l’indicateur central ne devrait pas être le volume brut de rapports. Parmi les mesures utiles figurent le taux de vulnérabilités confirmées, le taux de doublons, le délai médian de triage, le délai de correction et la charge de travail des examinateurs.

Un programme peut recevoir davantage de rapports tout en devenant moins efficace. À l’inverse, une réception plus stricte peut réduire le volume tout en augmentant la part des découvertes sérieuses qui atteignent les mainteneurs.

La suspension du OSS VRP de Google devrait donc être jugée à l’aune de ce qui la remplacera. Fermer une file d’attente submergée est compréhensible, mais un résultat de sécurité durable exige une voie de confiance pour les rapports valides.

Que se passera-t-il ensuite pour la prime Google dédiée aux bugs open source ?

Trois signaux révéleront si la pause de Google débouche sur un meilleur système de divulgation ou sur un repli durable de la participation ouverte.

Le premier signal sera la mise à jour promise par Google au cours du premier trimestre 2027. Les détails les plus importants concerneront l’éligibilité, les normes de preuve, le filtrage automatisé et les procédures de recours.

Une réouverture assortie d’exigences de reproduction claires renforcerait l’idée que Google a utilisé la pause pour repenser la réception des signalements. Une prolongation indéfinie suggérerait que la soumission ouverte demeure économiquement difficile.

Il faudra observer si Google demande aux rapporteurs de fournir des tests exécutables, des commits affectés, des traces d’exploitation ou des correctifs proposés. Ces règles transféreraient une part de la responsabilité aux chercheurs sans interdire l’assistance de l’IA.

Le deuxième signal sera le taux de rapports confirmés après toute réouverture. Google n’a pas publié de référence actuelle ; la transparence sur les futurs taux de validité et de doublons aiderait donc à évaluer le nouveau système.

Un taux de confirmation plus élevé avec un accès stable à la divulgation appuierait un filtrage plus strict. Une baisse marquée de la participation pourrait indiquer que les barrières excluent les chercheurs légitimes en même temps que le spam.

Le temps de triage compte aussi. Si les examinateurs peuvent évaluer plus vite les rapports crédibles, Google disposera d’éléments montrant que la refonte a réduit le travail invisible plutôt que simplement le volume visible.

Le troisième signal sera la réaction d’autres projets et plateformes. Curl a supprimé les récompenses, Linux a redirigé les découvertes automatisées et Google a suspendu une catégorie de soumission.

Si davantage de programmes adoptent des reproductions vérifiées, des exigences de correctifs ou des seuils de réputation, ces pratiques pourraient devenir la norme pour la divulgation assistée par l’IA.

Les plateformes pourraient aussi mettre en place des défenses partagées. La détection des doublons entre les programmes, des preuves standardisées lisibles par machine et des identités d’agents responsables pourraient réduire le travail répétitif.

L’issue la plus constructive séparerait l’échelle de découverte de l’échelle de soumission. Les chercheurs pourraient exécuter des agents à grande échelle, mais seules les découvertes validées et dédupliquées entreraient dans les files de revue humaine.

Ce modèle exige de la responsabilité à chaque transfert. Les développeurs d’outils doivent concevoir pour la vérification, les chercheurs doivent tester leurs découvertes, les plateformes doivent filtrer avec soin et les mainteneurs ont besoin de voies d’escalade claires.

Les développeurs qui utilisent des outils de sécurité basés sur l’IA devraient déjà se comporter comme si ces règles existaient. Ils devraient reproduire chaque affirmation, comprendre le code concerné, vérifier l’historique public des problèmes et documenter un impact réaliste.

Ils devraient également rester disponibles après la soumission. Un rapporteur incapable de répondre à des questions techniques élémentaires transfère l’intégralité du coût de l’enquête au projet.

Pour les entreprises, la leçon dépasse les primes aux bugs. Tout système de réception public peut être surchargé lorsque l’IA rend la génération de contenu peu coûteuse et que l’évaluation reste coûteuse.

Les files d’assistance, les candidatures, les programmes de subventions, les pull requests et les rapports de conformité font face au même déséquilibre fondamental. La ressource rare n’est plus l’écriture. C’est une revue digne de confiance.

La pause de la prime Google dédiée aux bugs open source rend ce déséquilibre visible dans un contexte à forts enjeux. Un faux rapport de sécurité fait perdre du temps, tandis qu’une véritable vulnérabilité manquée peut exposer des millions d’utilisateurs en aval.

Le défi ne consiste pas à choisir entre l’IA et les chercheurs humains. Il consiste à concevoir un système de divulgation où l’automatisation augmente le travail de sécurité vérifié au lieu de multiplier les affirmations non étayées.

Google a désormais jusqu’à sa prochaine mise à jour pour montrer à quoi ressemble ce système. L’entreprise rouvrira-t-elle avec des exigences de preuve plus solides et un accès significatif, ou la participation ouverte continuera-t-elle de se restreindre à mesure que le volume des rapports augmente ?