Concept Divulgation coordonnée
Découvreur, éditeur et coordinateur s'accordent sur un délai avant de publier une faille, le temps de préparer le correctif. Normes ISO/IEC 29147 et 30111.
SFEIR AI · Publié le 21 octobre 2026
Principe et normes
La divulgation coordonnée organise le temps qui sépare la découverte d'une faille de sa publication. Le découvreur signale le défaut à l'éditeur, parfois par l'intermédiaire d'un coordinateur (un CERT national, un programme de bug bounty), un embargo court pendant que le correctif se prépare, puis la faille est publiée avec sa version corrigée et son identifiant CVE. L'ENISA la définit en 2022 comme « un processus par lequel les découvreurs de vulnérabilités travaillent ensemble et partagent l'information » ; à cette date, quatre États membres seulement disposaient d'une politique nationale, et la future directive NIS2 prévoyait d'en imposer une à chacun.
Deux normes ISO/IEC décrivent le processus. ISO/IEC 29147:2018 (deuxième édition, octobre 2018, confirmée en 2024) traite de la divulgation, c'est-à-dire de la réception des signalements et de la publication des avis par l'éditeur. ISO/IEC 30111:2019 (deuxième édition, octobre 2019, confirmée en 2025) traite du traitement interne de la vulnérabilité, de l'analyse à la correction. Le rapport technique ISO/IEC TR 5895:2022 précise leur application quand plusieurs parties sont impliquées. Au 21 octobre 2026, les deux normes restent en vigueur et l'ISO a enregistré, le 26 septembre 2025, un projet de troisième édition pour chacune.
Les délais : la référence Project Zero
Google Project Zero fixe la référence du marché avec un délai de 90 jours entre le signalement et la publication. Sa politique de 2021, dite « 90+30 », laisse 90 jours à l'éditeur pour corriger, puis 30 jours de délai d'adoption du correctif avant la publication des détails techniques. L'édition 2025 de la politique, signée Tim Willis le 29 juillet 2025, maintient ce cœur : « notre délai de divulgation de 90 jours reste en vigueur ».
La même édition ajoute un essai appelé Reporting Transparency : environ une semaine après avoir signalé une faille, Project Zero publie le nom de l'éditeur ou du projet, le produit concerné, la date du signalement et la date d'expiration du délai de 90 jours. Aucun détail technique ni preuve de concept ne sort avant l'échéance : les utilisateurs savent qu'un correctif est attendu, sans que les attaquants reçoivent de quoi le devancer.
Le cadre européen : CRA, plateforme unique et EUVD
Le règlement (UE) 2024/2847, dit Cyber Resilience Act, ajoute une obligation de signalement qui ne relève pas de la divulgation coordonnée volontaire : son article 14 impose aux fabricants de produits comportant des éléments numériques de notifier « toute vulnérabilité activement exploitée » dont ils ont connaissance, simultanément au CSIRT désigné comme coordinateur et à l'ENISA. Trois échéances s'enchaînent : une alerte précoce « sans retard injustifié et en tout état de cause dans les 24 heures », une notification de vulnérabilité dans les 72 heures, et un rapport final « au plus tard 14 jours après qu'une mesure correctrice ou d'atténuation est disponible ».
L'article 71 fixe le calendrier : le règlement s'applique à partir du 11 décembre 2027, mais l'article 14 s'applique depuis le 11 septembre 2026. Ce jour-là, l'ENISA a mis en service la plateforme unique de signalement (Single Reporting Platform, SRP), qui permet de « déclarer une fois » et transmet l'information au CSIRT compétent et à l'ENISA, le CSIRT coordinateur la relayant ensuite aux autres États membres où le produit est distribué. Depuis le 13 mai 2025, l'ENISA exploite aussi la base européenne de vulnérabilités (EUVD), prévue par la directive NIS2, qui agrège les avis des CSIRT, les correctifs des éditeurs, les données CVE et le catalogue KEV de la CISA.
En France, le CERT-FR, opéré par l'ANSSI, écrit sur sa page de services qu'il « assure le traitement coordonné des vulnérabilités qui lui sont signalées », via un formulaire de déclaration hébergé sur club.ssi.gouv.fr. Il joue le rôle de coordinateur pour les signalements CRA adressés à la France.
Le cas PHP2Shell
PHP2Shell montre un processus de divulgation coordonnée qui tient deux mois, puis dérape sur les dernières 48 heures. Wiz Research signale les deux failles du moteur PHP le 24 août 2026 ; l'équipe PHP accuse réception le 21 septembre et prépare un correctif coordonné avec les distributions Linux et les éditeurs. Selon watchTowr, cité par Tenable, la publication était prévue sous embargo le jeudi 22 octobre.
Le 20 octobre, les identifiants CVE circulent sur Hacker News et les réseaux sociaux, et une vidéo d'une chaîne d'exploitation est partagée. Le soir même, à 19h33, l'équipe PHP publie un préavis sur le Discourse de la PHP Foundation : sortie le mercredi 21 octobre à 14h00 UTC, avec une clause explicite : « nous nous réservons le droit de publier plus tôt si les détails de l'une des vulnérabilités deviennent publics » ou « si nous voyons des preuves d'exploitation active ». Les versions corrigées sont sorties le 21 octobre, en avance sur l'horaire annoncé. Le CERT-FR a publié le jour même l'alerte CERTFR-2026-ALE-014, en précisant que les contournements provisoires « ne sont pas qualifiés par le CERT-FR » et en recommandant la migration vers une version maintenue.
La clause de préavis de PHP résume la règle non écrite du secteur : l'embargo protège les utilisateurs tant qu'il reste étanche, et il saute dès qu'une fuite ou une exploitation le rend contre-productif.
L'argument nouveau : la « Defender's Window »
La recherche de vulnérabilités par IA change les proportions du processus. OpenAI nomme « Defender's Window » le temps gagné quand « l'IA frontier a trouvé ces vulnérabilités avant les attaquants », et s'attend à ce que ces découvertes « augmentent fortement dans les mois à venir ». Le programme Patch the Planet est construit sur ce principe : trouver par IA, relire par des humains, corriger sous embargo, publier.
L'embargo prend donc une valeur nouvelle. Wiz écrit que les mêmes modèles aident à « adapter un exploit à différentes versions, configurations et dispositions mémoire », et le Google Threat Intelligence Group mesure, au 30 septembre 2026, 18 vulnérabilités exploitées par mois contre 10,5 en 2025. Avec un correctif rattrapé en heures, la divulgation coordonnée n'est plus une courtoisie entre chercheurs et éditeurs : c'est le seul moment où le défenseur a de l'avance.
Questions fréquentes
Combien de temps avant qu'une faille soit rendue publique ?
La référence est le délai de 90 jours de Google Project Zero, prolongé de 30 jours d'adoption du correctif quand l'éditeur a corrigé à temps. Les éditeurs négocient des délais différents selon la gravité, et le délai se raccourcit en cas de fuite ou d'exploitation active, comme pour PHP2Shell en octobre 2026.
Quelle différence entre divulgation coordonnée et divulgation responsable ?
Les deux expressions désignent la même pratique. « Divulgation responsable » sous-entendait que publier sans attendre serait irresponsable ; les normes ISO/IEC 29147 et 30111 et l'ENISA emploient « divulgation coordonnée », qui décrit le mécanisme sans jugement : plusieurs parties s'accordent sur un calendrier.
Que doit signaler un fabricant en Europe depuis le 11 septembre 2026 ?
En application de l'article 14 du Cyber Resilience Act, toute vulnérabilité activement exploitée dans un produit comportant des éléments numériques : alerte précoce dans les 24 heures, notification dans les 72 heures, rapport final au plus tard 14 jours après la disponibilité d'une mesure correctrice. Le dépôt se fait via la plateforme unique de l'ENISA, qui transmet au CSIRT compétent.
Qu'est-ce que l'EUVD ?
La base européenne de vulnérabilités, exploitée par l'ENISA et opérationnelle depuis le 13 mai 2025 en application de la directive NIS2. Elle agrège les avis des CSIRT nationaux, les correctifs des éditeurs, les données CVE et le catalogue KEV de la CISA, avec pour chaque fiche les produits touchés, la sévérité et le statut d'exploitation.
À qui signaler une faille en France ?
Au CERT-FR, opéré par l'ANSSI, qui assure le traitement coordonné des vulnérabilités qui lui sont signalées, via le formulaire de déclaration de club.ssi.gouv.fr. Les fabricants soumis au Cyber Resilience Act passent par la plateforme unique de l'ENISA, qui relaie au CERT-FR quand la France est compétente.
Sources
- ISO, ISO/IEC 29147:2018, « Information technology. Security techniques. Vulnerability disclosure » (édition 2, octobre 2018, confirmée en 2024) · 2018-10-01
- ISO, ISO/IEC 30111:2019, « Information technology. Security techniques. Vulnerability handling processes » (édition 2, octobre 2019, confirmée en 2025) · 2019-10-01
- ISO, ISO/IEC AWI 29147 « Cybersecurity. Vulnerability disclosure processes » : projet de troisième édition, nouveau projet approuvé le 26 septembre 2025 · 2025-09-26
- ENISA, « Coordinated Vulnerability Disclosure policies in the EU » : définition de la CVD, état des politiques nationales, exigence de la future NIS2 · 2022-04-13
Coordinated vulnerability disclosure (CVD) is a process by which vulnerabilities finders work together and share information
- Google Project Zero, Tim Willis, « Policy and Disclosure: 2025 Edition » : délai de 90 jours maintenu, politique 90+30, essai Reporting Transparency · 2025-07-29
Our core 90-day disclosure deadline will remain in effect.
- EUR-Lex, règlement (UE) 2024/2847 (Cyber Resilience Act) : article 14 (24 heures, 72 heures, 14 jours) et article 71 (application de l'article 14 au 11 septembre 2026, du règlement au 11 décembre 2027) · 2024-11-20
However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.
- ENISA, « The CRA Single Reporting Platform is launched » : mise en service de la SRP le 11 septembre 2026, déclaration unique, rôle du CSIRT coordinateur · 2026-09-11
The CRA's reporting obligations apply to manufacturers from 11 September 2026
- Commission européenne, « Cyber Resilience Act - Reporting obligations » : vulnérabilités activement exploitées et incidents graves, délais, dépôt via la SRP · 2026-09-11
- ENISA, communiqué « Consult the European Vulnerability Database to enhance your digital security! » : EUVD opérationnelle, prévue par la directive NIS2, sources agrégées · 2025-05-13
- CERT-FR, page Services : traitement coordonné des vulnérabilités signalées, formulaire de déclaration · 2026-10-21
Le CERT-FR assure le traitement coordonné des vulnérabilités qui lui sont signalées.
- CERT-FR, alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP » : contournements non qualifiés, migration vers une version maintenue · 2026-10-21
- PHP Foundation Discourse, préavis du 20 octobre 2026 à 19h33 : sortie annoncée le 21 octobre à 14h00 UTC, clause d'avancement en cas de fuite ou d'exploitation active · 2026-10-20
We reserve the right to release earlier if details of either vulnerability become public
- Tenable, « php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ » : divulgation initialement prévue le 22 octobre selon watchTowr, circulation des identifiants CVE le 20 octobre · 2026-10-21
the vulnerabilities were originally set to be disclosed on Thursday, October 22, under embargo.
- Wiz Research, « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet » : signalement du 24 août, accusé de réception du 21 septembre, adaptation des exploits par LLM · 2026-10-21
- OpenAI, « Patch the Planet: global response coordination as agents uncover critical vulnerabilities » : Defender's Window, hausse attendue des découvertes · 2026-10-21
we expect similar findings to increase sharply in the coming months
- Google Threat Intelligence Group, « Vulnerability Discovery and Exploitation Trends in the AI Era » : 18 vulnérabilités exploitées par mois en 2026 contre 10,5 en 2025 · 2026-09-30
Divulgation coordonnée dans vos projets
Échanger avec SFEIRArticles liés
PHP2Shell : l'IA a trouvé la faille avant les attaquants, la course au patch commence
Le 21 octobre 2026, PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35 contre deux RCE critiques trouvées par des chercheurs équipés de GPT-5.6 Sol et de Gemini 4 Argon. Deux mois de « Defender's Window », puis une fenêtre d'exploitation ouverte dès la publication. Ce qu'il faut faire aujourd'hui.
GLM 5.3 = GLM 5.2 + une pincée de cyber
Z.ai a annoncé GLM-5.3 le 14 août 2026 sans réentraîner son modèle de base : tous les gains viennent du post-training. Le laboratoire chinois retarde de deux semaines la publication des poids à cause d'une capacité cyber qu'il dit ne pas avoir planifiée. Lecture SFEIR.