En bref. Google Project Zero a annoncé le 13 novembre 2026 une nouvelle politique de divulgation : une vulnérabilité signalée à un éditeur sera rendue publique un nombre fixe de jours après le signalement, que la faille soit corrigée ou non. Le délai est de 90 jours aujourd'hui, il passera à 60 jours le 2 février 2027 puis à 30 jours le 3 janvier 2028. La raison avancée : l'IA accélère la découverte et l'exploitation des failles, et un attaquant peut désormais déduire presque immédiatement les détails d'une faille à partir de son correctif.
Ce qui a été annoncé
Depuis 2021, Project Zero, l'équipe de recherche en vulnérabilités de Google, appliquait une règle dite « 90 + 30 » : jusqu'à 90 jours pour corriger, plus 30 jours de délai pour le déploiement des correctifs (soak time).
L'équipe estime ce calendrier « clairement insuffisant » face à la découverte et l'exploitation de vulnérabilités assistées par l'IA. Sa nouvelle politique s'appelle « Full X » : les vulnérabilités sont divulguées X jours après leur signalement à l'éditeur.
Le calendrier :
- depuis le 13 novembre 2026 : « Full 90 », divulgation 90 jours après le signalement ;
- à partir du 2 février 2027 : « Full 60 », 60 jours ;
- à partir du 3 janvier 2028 : « Full 30 », 30 jours.
La plupart des cas particuliers disparaissent, dont le délai de grâce et la politique sur les variantes. Il reste trois exceptions :
- les vulnérabilités activement exploitées dans la nature (in the wild), traitées selon la politique de divulgation de sécurité applicative de Google ;
- les vulnérabilités déjà publiques : Project Zero peut en publier les détails, à sa discrétion, si d'autres l'ont déjà fait ;
- la demande de l'éditeur : les détails sont publiés si l'éditeur le demande.
Project Zero indique aussi avoir déjà accordé, en de rares occasions, des exceptions pour le matériel, dont Spectre et Meltdown, et continuera à le faire.
Pourquoi ce changement
Le texte de Project Zero avance trois effets des grands modèles de langage (LLM, Large Language Models).
La découverte est plus rapide et plus partagée. Les attaquants trouvent et exploitent plus vite, et le risque que plusieurs acteurs, dont des malveillants, découvrent la même faille augmente. Une vulnérabilité signalée aujourd'hui présente, selon l'équipe, un risque immédiat bien plus élevé qu'une vulnérabilité signalée l'an dernier.
Le correctif révèle la faille. Les LLM réduisent le temps nécessaire pour analyser un correctif et en déduire l'exploitation, au point que Project Zero retient un délai nul entre correctif et exploitation comme modèle « raisonnable, bien qu'imparfait » du comportement des attaquants. Le délai de déploiement de 30 jours perd son sens : il peut donner une fausse impression de secret alors que le correctif publié suffit à comprendre la faille.
Le volume augmente. L'équipe écrit trouver plusieurs vulnérabilités par semaine sur des cibles où elle en trouvait quelques-unes par an. Négocier avec chaque éditeur la question « est-ce corrigé ? » ou l'application d'un délai de grâce devient ingérable.
D'où trois objectifs affichés : pousser à corriger plus vite, réduire le patch gap et rendre la politique automatisable, chez Project Zero comme chez les éditeurs.
Le patch gap, notion clé
Project Zero définit le patch gap comme le temps entre la publication d'un correctif et son installation par l'utilisateur. Pour Project Zero, il est tout aussi crucial de réduire ce délai, soit en accélérant le déploiement, soit en protégeant les utilisateurs par d'autres moyens pendant la correction.
Pourquoi une baisse progressive
Project Zero a consulté les éditeurs à qui il signale le plus de vulnérabilités. Leur crainte principale : un changement immédiat mettrait des failles non corrigées à la disposition des attaquants pendant qu'ils améliorent leurs processus. Project Zero estime que l'intérêt de retarder la divulgation diminue, mais qu'il en reste à court terme. Deux préoccupations plus subtiles ont été citées :
- un délai trop agressif ferait passer en priorité les failles signalées par Project Zero, même moins graves que d'autres ;
- imposer d'emblée un délai que certains éditeurs ne sont pas équipés pour tenir pourrait les amener à accepter de ne pas corriger dans les temps, et à ne plus essayer.
D'où un calendrier que l'équipe qualifie d'exigeant mais réaliste.
La gravité ne compte pas pour la date
Project Zero ne signale que des vulnérabilités d'une gravité substantielle avec un impact démontré. Mais, selon l'équipe, la gravité n'est pas un bon critère de décision de divulgation : elle ne change pas la probabilité qu'un attaquant trouve la faille, seulement son impact. L'équipe précise aussi que sa politique suppose des signalements de qualité (reproductibles, lisibles, atteignables, avec un impact démontré) et qu'il est raisonnable pour un éditeur de traiter autrement des signalements de faible qualité.
« Corrigé » n'est plus un critère
Project Zero continuera de suivre si les failles sont corrigées et le signalera, mais ce ne sera plus un critère de décision. L'équipe note que des éditeurs expérimentent des remédiations qui ne sont pas des correctifs, comme la désactivation temporaire de chemins de code, ce qui devrait rendre la question encore plus complexe.
Qui est concerné
- Les éditeurs à qui Project Zero signale des failles, matériel compris. Ils sont directement soumis au calendrier.
- Tous les éditeurs, indirectement. Nous lisons cette politique comme un signal : si une équipe de recherche trouve plusieurs failles par semaine là où elle en trouvait quelques-unes par an, d'autres chercheurs, et des attaquants, peuvent le faire aussi.
- Les équipes qui déploient les correctifs. La réduction du patch gap les concerne au premier chef : si l'analyse d'un correctif suffit à l'exploiter, chaque jour entre sa publication et son installation compte.
Ce que doit faire un éditeur
Les étapes suivantes sont des bonnes pratiques de gestion des vulnérabilités, déduites des objectifs de Project Zero.
1. Mesurer votre délai réel
Pour chaque vulnérabilité des douze derniers mois, relevez la date de signalement, la date du correctif et la date à laquelle la majorité de vos clients l'avaient installé. Calculez la médiane et le pire cas. Si votre médiane dépasse 60 jours, la date du 2 février 2027 vous concerne déjà pour toute faille signalée par Project Zero.
2. Séparer tri et correction
Un délai fixe ne laisse pas de place à une négociation sur la gravité. Fixez un délai maximal de qualification (par exemple quelques jours ouvrés) après lequel la vulnérabilité est confirmée ou rejetée, et suivez-le comme un indicateur.
3. Réduire le patch gap
- Mises à jour automatiques activées par défaut quand votre produit le permet.
- Pour les produits installés chez le client, une notification claire et un correctif cumulatif facile à appliquer.
- Pour le SaaS, un pipeline de déploiement capable de pousser un correctif de sécurité en production dans la journée, avec tests et retour arrière.
4. Préparer des mesures sans correctif
Project Zero encourage les éditeurs à prévoir comment réagir à la divulgation imminente d'une faille grave, y compris par des stratégies autres que le correctif. Concrètement : drapeaux de fonctionnalité (feature flags) pour désactiver un composant, règles de pare-feu applicatif, recommandations de configuration publiables vite.
5. Ne pas compter sur le secret du correctif
Partez du principe qu'un correctif publié est analysé rapidement. Le jour où il sort, votre avis de sécurité et vos consignes doivent être prêts, pas dans les semaines suivantes.
6. Automatiser le suivi
Project Zero veut une politique automatisable ; faites de même côté éditeur. Chaque signalement entrant doit avoir une date d'échéance calculée automatiquement dans votre outil de suivi, visible par l'équipe produit et la direction.
Méthode de vérification
Un exercice simple consiste à prendre une vulnérabilité fictive signalée un lundi et à dérouler le processus jusqu'au correctif disponible et installé chez un client test, en chronométrant chaque étape. L'écart entre ce chronomètre et 30 jours mesure le travail à faire d'ici janvier 2028.
Le lien avec le CRA
Pour les éditeurs qui vendent dans l'Union européenne, ce calendrier rejoint un mouvement réglementaire : selon la Commission européenne, le Cyber Resilience Act (CRA) impose aux fabricants de traiter les vulnérabilités pendant une période de support qu'ils déterminent et, depuis le 11 septembre 2026, de signaler les vulnérabilités activement exploitées ; le rapport final est dû au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation. Le texte de Project Zero ne mentionne pas le CRA ; le rapprochement est le nôtre. Les obligations précises sont détaillées dans notre article sur le programme de divulgation de vulnérabilités au titre du CRA.
FAQ
Qu'est-ce que la politique « Full 90 » de Project Zero ?
Une vulnérabilité signalée à un éditeur est rendue publique 90 jours après le signalement, sans délai supplémentaire de déploiement. Le délai passe à 60 jours le 2 février 2027 et à 30 jours le 3 janvier 2028.
Qu'est-ce qui change par rapport à « 90 + 30 » ?
L'ancienne règle donnait 90 jours pour corriger, plus 30 jours de délai pour le déploiement des correctifs. La nouvelle supprime les 30 jours, le délai de grâce et la politique sur les variantes.
Une faille exploitée activement suit-elle ce calendrier ?
Non. Les vulnérabilités activement exploitées dans la nature suivent la politique de divulgation de sécurité applicative de Google.
Pourquoi Project Zero raccourcit-il les délais ?
Parce que, selon l'équipe, les LLM accélèrent la découverte des failles, augmentent le risque de découverte par plusieurs acteurs et permettent de déduire presque immédiatement les détails d'une faille à partir de son correctif.
Sources
- Google Project Zero, Policy and Disclosure: 2026 Edition, 13 novembre 2026 : https://projectzero.google/2026/11/disclosure-policy.html
- Commission européenne, Cyber Resilience Act – Reporting obligations : https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- Commission européenne, The Cyber Resilience Act - Summary of the legislative text : https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Pour mesurer vos délais de correction et construire un pipeline capable de livrer un correctif de sécurité vite, WeeSec accompagne les équipes en DevSecOps.