Google aurait mis en pause une catégorie de son programme de récompenses pour les vulnérabilités ; des détails manquent encore

La mesure décrite concerne une partie du programme, pas nécessairement l’ensemble du dispositif

Les informations disponibles décrivent une pause dans la réception de certains signalements au sein du programme de récompenses pour les vulnérabilités des logiciels open source de Google, appelé OSS VRP. La portée évoquée est plus limitée qu’une suspension générale : elle concernerait les vulnérabilités de produit, tandis que les signalements liés à la chaîne d’approvisionnement ne seraient pas concernés. Cette distinction apparaît dans les informations disponibles, mais aucun avis officiel de Google fourni ici ne détaille les catégories touchées.

Il serait donc imprudent de résumer ce changement comme la fermeture du programme ou d’affirmer que Google n’accepte plus aucun type de découverte. Aucune date confirmée n’est disponible pour le début de la pause, sa réévaluation ou la reprise des soumissions. L’existence d’un programme de récompenses et les initiatives de Google en matière de sécurité et d’IA ne répondent pas à ces questions : il s’agit de sujets différents, qui nécessitent des confirmations spécifiques.

Pour toute personne souhaitant signaler une vulnérabilité, la démarche opérationnelle la plus importante consiste à consulter les règles en vigueur pour la catégorie concernée avant de préparer une soumission. La documentation fournie ne permet pas de savoir si la pause est toujours active, comment elle s’applique sur la plateforme de réception ni quelles solutions sont proposées entre-temps.

Le lien avec l’IA reste une explication incomplète

La pause a été associée à une hausse des rapports invalides liés à des outils d’intelligence artificielle. Toutefois, la documentation officielle fournie sur la stratégie de sécurité de Google confirme l’annonce d’un programme de récompenses consacré aux vulnérabilités de l’IA, et non la pause de l’OSS VRP. Les éléments disponibles ne contiennent ni explication de cette décision, ni données sur les rapports rejetés, ni attribution causale aux modèles génératifs.

Cette distinction est importante. Le fait que certains rapports aient été préparés avec l’aide de l’IA ne prouve pas que l’outil ait produit l’erreur, que le rapport soit invalide ou que toute utilisation de l’IA génère des résultats inutiles. Pour établir un lien de causalité, il faudrait au minimum des critères clairs permettant d’identifier l’utilisation de ces outils et des données comparables sur la validité des soumissions. Aucun chiffre ni aucune méthodologie de ce type n’ont été fournis.

Il reste aussi à préciser ce que signifie exactement « généré par l’IA » dans ce contexte. L’expression peut désigner un texte rédigé par un modèle, une hypothèse suggérée au cours d’une enquête ou une analyse automatisée du code. Ces usages diffèrent et n’ont pas la même valeur probante. En l’absence d’une définition publiée et applicable au programme, il ne convient pas de transformer cette étiquette en règle générale sur la qualité d’un rapport.

Aucun chiffre vérifié ne permet de mesurer le problème

L’explication publique disponible évoque une charge de vérification provoquée par des rapports qui ne décrivent pas de vulnérabilités valides ou exploitables. Mais les sources fournies ne donnent ni nombre total de soumissions, ni taux de rejet, ni comparaison avec des périodes précédentes, ni ventilation permettant de distinguer les rapports réalisés avec l’aide de l’IA des autres. Sans ces données, il est impossible de mesurer l’ampleur du problème ou de savoir si le changement répond à une tendance durable ou à une décision préventive.

Il est également impossible de déterminer si les rapports ont été considérés comme invalides parce que la faille n’existait pas, parce qu’elle ne pouvait pas être reproduite, parce qu’elle était déjà connue ou parce que la soumission manquait d’informations. Ces situations ne sont pas équivalentes : certaines peuvent révéler une hypothèse erronée, tandis que d’autres relèvent d’un problème de documentation ou de classification. Les regrouper sous une seule étiquette empêcherait de savoir quel type de filtre serait nécessaire.

Pour la même raison, l’expression « AI slop » ne doit pas être présentée comme une catégorie technique mesurée par Google. Il s’agit d’une caractérisation subjective, non d’un chiffre ni d’un critère vérifiable dans la documentation fournie. L’article peut évoquer les préoccupations suscitées par le volume de rapports peu utiles, mais doit conserver l’incertitude concernant leur nombre, leur évaluation et le rôle joué par l’IA.

Ce qui rendrait un rapport vérifiable

Les conditions officielles complètes que Google appliquerait pendant la pause n’ont pas été fournies. Il est toutefois possible de distinguer, à titre de critères généraux d’évaluation et non de règles confirmées du programme, les informations qui facilitent l’examen d’une découverte. L’essentiel est qu’une autre personne puisse comprendre l’environnement, répéter les étapes et observer le même comportement sans devoir se fier à une conclusion rédigée par un outil.

Une soumission utile devrait distinguer les observations des hypothèses : indiquer le composant et la version examinés, décrire une configuration reproductible, énumérer les étapes minimales et expliquer le résultat observé par rapport au résultat attendu. Si un impact sur la sécurité est allégué, il est également utile de montrer quelle limite de sécurité est franchie et dans quelles conditions, sans exagérer la portée du problème. Les tests doivent être sûrs et se limiter aux systèmes pour lesquels leur auteur dispose d’une autorisation.

L’automatisation peut aider à explorer du code ou à améliorer la rédaction, mais elle ne remplace pas ces vérifications. Un texte fluide ne prouve pas l’existence d’un défaut ; inversement, l’intervention d’un outil n’invalide pas automatiquement une démonstration reproductible. L’évaluation doit porter sur les éléments techniques du cas et sur les exigences publiées pour le programme concerné.

La durée de la pause reste indéterminée

Les descriptions disponibles divergent sur le caractère temporaire ou définitif de la restriction. L’une la présente comme une pause ; une autre qualifie de permanent le blocage des rapports générés par l’IA. La documentation officielle fournie ne permet pas de trancher cette différence. Rien ne suffit non plus à établir si ces descriptions portent exactement sur la même règle, sur des catégories différentes ou sur des déclarations faites à des moments distincts.

Il n’est donc pas possible d’annoncer une date de reprise ni d’affirmer que Google a interdit de façon permanente tous les rapports pour lesquels l’IA a été utilisée. La formulation la plus précise est qu’une pause limitée à certains rapports a été décrite, mais que sa durée et ses conditions exactes ne sont pas confirmées par les éléments primaires disponibles.

Cette question a également des conséquences pratiques pour les chercheurs et les responsables de la maintenance. Si une pause empêche l’envoi d’une catégorie précise, des instructions officielles claires sont nécessaires pour indiquer la marche à suivre en cas de découverte urgente, préciser si elle peut être communiquée par un autre canal et définir les informations acceptées. Les sources fournies ne détaillent pas ces possibilités ; il serait donc irresponsable de recommander un canal alternatif précis ou de supposer que les règles d’une autre catégorie s’appliquent.

Ce que les chercheurs et les responsables de maintenance doivent surveiller

Pour les personnes qui recherchent des vulnérabilités, la priorité est de consulter les conditions actuelles du programme avant de consacrer du temps à une soumission. Si la catégorie est toujours suspendue, l’absence d’accusé de réception automatique ne doit pas être interprétée comme la confirmation que la découverte a été évaluée. Et si le rapport a été préparé à l’aide d’outils d’IA, documenter les vérifications manuelles peut aider à distinguer une suggestion automatisée d’un élément reproductible, même si aucune règle officielle fournie n’impose cette déclaration.

Pour les responsables de la maintenance, le sujet souligne un besoin différent : recevoir des rapports faciles à reproduire et qui laissent peu de place à l’ambiguïté. Un modèle de soumission peut demander les versions concernées, la configuration, les étapes minimales, le résultat observé et la justification de l’impact. Il s’agit d’une mesure éditoriale et opérationnelle raisonnable, et non de la description d’une politique précise de Google. Les équipes doivent également éviter de rejeter une découverte uniquement en raison de la manière dont elle a été élaborée, lorsque les éléments permettent de la valider.

La confirmation la plus importante encore attendue serait un avis officiel précisant la catégorie concernée, la date d’entrée en vigueur, la durée ou la date de réévaluation, les exceptions et les critères d’acceptation. Une ventilation anonymisée des soumissions et des rejets aiderait aussi à déterminer si la cause était le volume, le manque de reproductibilité ou un autre facteur. Tant que ces informations ne sont pas disponibles, toute explication plus catégorique dépasserait ce que les éléments disponibles permettent d’affirmer.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.