Google n’accepte plus, depuis le 1er octobre 2026, de nouvelles soumissions de failles de produits à son programme de récompenses pour les vulnérabilités des logiciels open source (OSS VRP). Les règles actuelles du programme précisent la date limite. Les signalements concernant la chaîne d’approvisionnement restent acceptés et Google affirme que les signalements de produits déposés avant le 1er octobre ne sont pas concernés. Pour certains dépôts maintenus par Google Cloud, lorsque les failles touchent des produits Cloud, le programme Cloud VRP peut encore accepter un signalement de produit.
La suspension fait suite à la mise à jour des règles du 19 marsdans laquelle Google disait constater une hausse de signalements générés par l’IA comportant des déclencheurs erronés ou un impact de sécurité négligeable. Dans sa déclaration du 1er octobre, Google a évoqué une hausse des soumissions automatisées dont la grande majorité, selon l’entreprise, était invalide. La déclaration d’octobre n’a pas qualifié chaque signalement automatisé de résultat de l’IA. Google a promis une mise à jour au premier trimestre 2027, sans annoncer de date de reprise.
Le grand changement
L’OSS VRP acceptait auparavant les signalements admissibles de failles de produits dans certains projets open source de Google, sous réserve du niveau du projet et des preuves requises. Depuis le 1er octobre, la voie de signalement des nouvelles failles de produits est suspendue. La voie concernant la chaîne d’approvisionnement accepte toujours les failles susceptibles de compromettre le code source ou les versions distribuées, et les signalements de produits déjà déposés restent en cours de traitement. Les chercheurs doivent désormais déterminer le type de découverte et son impact sur le produit avant de choisir un formulaire. Ce sont les règles de Google, et non le seul fait qu’un dépôt appartienne à Google, qui indiquent si un autre programme est disponible.
Déterminer la voie avant de signaler
Commencez par consulter les règles de l’OSS VRP et vérifier l’identité du dépôt concerné ainsi que sa version actuelle. Google indique que le programme couvre les dernières versions de logiciels dans les dépôts publics des organisations GitHub appartenant à Google, ainsi que certains dépôts sur d’autres plateformes. Cela ne signifie pas que toute faille ouvre droit à une récompense.
Découverte | Voie actuellement prévue par les règles de Google |
|---|---|
Nouvelle faille de produit dans un logiciel open source de Google, par exemple un défaut dans un logiciel utilisé par un produit en aval | Ne la soumettez pas comme nouveau signalement de produit OSS VRP pendant la suspension. Vérifiez si l’impact démontré répond aux règles d’un autre programme. |
Faiblesse susceptible de compromettre l’intégrité du code source de Google OSS ou les artefacts de compilation distribués | Vérifiez les critères de la chaîne d’approvisionnement OSS VRP, puis utilisez le formulaire de signalement en sélectionnant OSS VRP et en indiquant l’URL du dépôt. Cette voie reste ouverte. |
Découverte concernant un produit, signalée avant le 1er octobre | Poursuivez le signalement existant. Google précise que la suspension ne concerne pas les dossiers en cours. |
Dépôt maintenu par Google Cloud avec un impact sur un produit ou service Google Cloud | Consultez les règles Cloud VRP, y compris le niveau du produit touché. Google indique que certains signalements de ce type peuvent y être acceptés ; l’emplacement du dépôt ne suffit pas à lui seul. |
Problème dans un produit d’IA de Google ou d’Alphabet où un LLM ou un autre système d’IA générative joue un rôle essentiel | Consultez les règles AI VRP. Utiliser l’IA pour découvrir une faille classique dans du code ne rend pas, à lui seul, cette faille admissible au programme AI VRP. |
Amélioration de sécurité proposée ou correctif | Consultez les règles distinctes du programme Patch Rewards pour connaître les projets et changements admissibles. Il s’agit d’un programme de correctifs, et non d’une autre voie de dépôt pour la même faille dont le signalement est suspendu. |
Les règles OSS de Google contiennent encore leurs anciens critères d’acceptation des failles de produits, notamment la reproduction par OSS-Fuzz ou un correctif fusionné pour certaines corruptions mémoire. Ces paragraphes décrivent les exigences de ce type de signalement, mais figurent sous la nouvelle limite d’octobre. Ils ne permettent pas de déposer une nouvelle faille de produit OSS VRP pendant la suspension.
Ce qu’exige un signalement OSS toujours accepté
Pour une faille de chaîne d’approvisionnement, les règles de Google demandent de démontrer un chemin exploitable permettant de modifier le code source OSS de Google, les artefacts de compilation ou les paquets distribués. Un scénario qui ne fonctionne qu’après l’approbation d’une demande de fusion externe par un responsable est traité comme un risque interne et peut être crédité, mais pas récompensé comme faille de chaîne d’approvisionnement. Google cite notamment la configuration des dépôts et des compilations, l’infrastructure de publication et les identifiants de diffusion. Ces descriptions du périmètre n’autorisent pas à tester l’infrastructure d’un tiers.
Ce guide s’appuie sur la documentation des programmes Google vérifiée le 5 octobre 2026. BIG CHANGE n’a testé aucune faille et n’a envoyé aucun signalement. Avant l’envoi, rassemblez les éléments demandés dans les consignes de signalement :
- L’URL du dépôt, la version du logiciel concernée et une compilation ou configuration récente à laquelle la découverte s’applique.
- Une description concise du défaut, des conditions nécessaires pour le déclencher et de son impact sur la sécurité. Expliquez le scénario d’attaque sans supposer qu’un avertissement de code prouve à lui seul l’existence d’une faille exploitable.
- Des instructions de reproduction et, si possible, une preuve de concept compilable. Ajoutez les sorties pertinentes ou un vidage mémoire s’ils sont disponibles. Distinguez le résultat observé de l’impact que vous en déduisez.
- Le programme approprié et le bon formulaire. Pour un signalement de chaîne d’approvisionnement OSS, sélectionnez OSS VRP à l’étape Bug Location du formulaire et précisez l’URL du dépôt. Pour Cloud ou AI, appliquez les règles de périmètre et les instructions propres à ces programmes.
Google recommande de tester localement lorsque c’est possible, d’éviter de perturber les autres utilisateurs et de ne pas lancer de tests automatisés générant beaucoup de trafic. Ses règles Cloud interdisent de tester des ressources appartenant aux clients. Les règles AI exigent que l’auteur vérifie le problème et explique en termes simples une menace comprise dans le périmètre. Ces limites comptent autant que la qualité du rapport.
Les pages des programmes sont publiques et indiquent qu’aucun frais n’est demandé pour déposer un signalement de faille. Il faut concrètement une découverte, une cible admissible et un rapport conforme aux règles du programme choisi. Les récompenses restent discrétionnaires et varient selon le programme, le niveau du projet et l’impact. Le barème OSS actuel ne prévoit pas de récompense pour de nouvelles failles de produits ; il indique toujours des fourchettes de récompenses pour les failles de chaîne d’approvisionnement des niveaux admissibles. Ni le dépôt ni la qualité formelle d’un rapport ne garantissent un paiement.
Pourquoi Google a modifié la réception des signalements
Dans sa publication de mars, Google présentait la recherche assistée par IA comme utile lorsque les chercheurs en vérifient les résultats. L’entreprise disait que certains rapports inventaient un déclencheur ou relevaient une erreur de programmation sans démontrer un impact de sécurité réel et significatif. Une mise à jour d’avril a supprimé les récompenses ou crédits pour les failles de produits et d’autres problèmes dans les projets de niveaux inférieurs OT2 et OT3. La suspension d’octobre va plus loin pour les nouveaux signalements de produits OSS VRP, quel que soit le niveau du projet. TechCrunch a également rapporté cette suspension. Les déclarations publiques de Google établissent le changement de règles et sa justification déclarée, mais ne donnent ni le nombre de soumissions ni une mesure indépendante du nombre de signalements invalides ayant utilisé l’IA.
La tâche immédiate d’un chercheur consiste à classer la découverte selon les règles en vigueur, à démontrer une conséquence réelle pour la sécurité, puis à utiliser uniquement une voie de signalement actuellement admissible. Google dit mettre à jour la voie des signalements de produits au premier trimestre 2027 ; d’ici là, la limite du 1er octobre s’applique aux nouvelles soumissions de produits OSS VRP.
Sources et lectures complémentaires
- Règles OSS VRP de Google ; règles actuelles vérifiées le 5 octobre 2026. Elles précisent la limite du 1er octobre, le périmètre maintenu pour la chaîne d’approvisionnement, les exigences de signalement et les limites des récompenses.
- Mise à jour des règles de Google du 19 mars 2026et mise à jour d’avril. Ces textes documentent les observations antérieures de Google, spécifiquement liées à l’IA, ainsi que les changements de niveaux de projet.
- Déclaration de Google VRP du 1er octobre 2026 . Le message X direct n’était pas accessible dans notre environnement de recherche ; son texte et son identifiant ont été retrouvés via une copie tierce et son périmètre a été vérifié au regard des règles actuelles de Google.
- Règles Cloud VRP , AI VRP et Patch Rewards , vérifiées le 5 octobre 2026. Chaque programme a ses propres critères d’admissibilité et modalités de signalement.
