Délais de correction des vulnérabilités : que révèlent les données publiques ?
- Trois délais se superposent : celui de l'éditeur, celui de l'exploitant et celui de l'attaquant
- Les analyses publiques convergent : l'exploitation suit la publication de plus en plus vite, parfois la précède
- Les équipements exposés sur internet sont à la fois les plus visés et parmi les plus lents à corriger
- Les bases publiques sont précieuses mais fragiles, comme l'ont montré l'arriéré de la NVD en 2024 et les incertitudes sur le programme CVE en 2025
Combien de temps faut-il pour corriger une faille ? La question paraît simple, et les réponses abondent : rapports d’éditeurs de sécurité, enquêtes, tableaux de bord. Elles se contredisent souvent, parce qu’elles ne mesurent pas la même chose. Sur les vulnérabilités logicielles, le délai de correction recouvre au moins trois durées distinctes, et les données publiques n’éclairent pas les trois avec la même précision. Cet article fait le point sur ce que l’on peut en tirer, et sur ce qu’il faut se garder d’en conclure.
Trois délais, souvent confondus
Le cycle de vie d’une vulnérabilité comporte une série d’événements datés : sa découverte, son signalement à l’éditeur, la publication d’un correctif, la publication d’un avis public, les premières exploitations observées, et le déploiement effectif du correctif chez chaque organisation concernée.
Le délai de l’éditeur va du signalement au correctif. C’est le plus documenté, parce que les chercheurs qui signalent des failles publient leurs politiques et parfois leurs statistiques. Le délai de l’exploitant va de la disponibilité du correctif à son installation sur les systèmes en service. C’est celui qui expose réellement une organisation, et le moins visible publiquement. Le délai de l’attaquant, enfin, mesure le temps qui sépare la publication d’une vulnérabilité de sa première exploitation observée. Les rapports d’incidents permettent de l’approcher.
Les sources publiques disponibles
Aucune base ne couvre tout le cycle. Chacune éclaire un segment, avec ses propres conventions de datation.
| Source | Ce qu’elle contient | Ce qu’elle permet de mesurer |
|---|---|---|
| Programme CVE | Identifiants uniques des vulnérabilités publiques, attribués par des autorités de numérotation | Volume et dates de publication |
| NVD (NIST) | Enrichissement des CVE : produits concernés, score CVSS, références | Gravité, produits touchés, dates de publication et de modification |
| Catalogue KEV (CISA) | Vulnérabilités dont l’exploitation est avérée, avec date d’ajout et date limite de correction pour les agences fédérales américaines | Ce qui est réellement exploité, et l’ancienneté des failles encore utilisées |
| Base européenne (ENISA) | Base de vulnérabilités prévue par NIS 2, mise en service en 2025 | Vision européenne, liens avec les avis des autorités nationales |
| EPSS (FIRST) | Probabilité estimée d’exploitation dans les 30 jours, mise à jour quotidiennement | Priorisation, au-delà de la seule gravité |
| Politiques de divulgation | Délais publiés par les équipes de recherche et les coordinateurs | Délai de l’éditeur, de façon indirecte |
| Rapports d’incidents | Analyses annuelles d’éditeurs et de cabinets de réponse à incident | Vecteurs d’intrusion, délai d’exploitation, déploiement des correctifs |
Ce que ces données montrent
Côté éditeurs : des délais encadrés par la divulgation coordonnée
La divulgation coordonnée a installé des repères. L’équipe Project Zero de Google applique un délai de 90 jours entre le signalement et la publication, la Zero Day Initiative un délai de 120 jours, le CERT/CC de l’université Carnegie Mellon un délai de 45 jours par défaut. Ces délais ne sont pas des obligations légales, mais ils créent une pression réelle : passé l’échéance, la vulnérabilité est publiée, correctif ou non.
Les bilans publiés par certaines de ces équipes indiquent que la plupart des éditeurs importants corrigent dans les délais, avec de fortes différences entre eux et selon la complexité des produits. Ces bilans portent toutefois sur des failles signalées par des chercheurs de haut niveau, à des éditeurs dotés d’équipes de sécurité : ils ne disent rien des petits éditeurs, des logiciels embarqués ou des composants libres maintenus par quelques bénévoles.
Côté attaquants : une fenêtre qui se referme
Les analyses publiques convergent sur une tendance : le délai entre la publication d’une vulnérabilité et sa première exploitation s’est fortement réduit. Mandiant (Google Cloud) a ainsi estimé que, pour les vulnérabilités exploitées étudiées en 2023, ce délai se comptait en jours plutôt qu’en semaines, et qu’une part importante d’entre elles avait été exploitée avant même la publication d’un correctif. Le rapport annuel de Verizon sur les violations de données (DBIR) relève de son côté, dans son édition 2025, la progression de l’exploitation de vulnérabilités comme point d’entrée des intrusions, en particulier sur les équipements de bordure de réseau : passerelles VPN, pare-feu, équipements d’accès distant.
Les chiffres précis varient d’une étude à l’autre, selon l’échantillon et la méthode. L’ordre de grandeur, lui, est stable : pour une faille critique sur un système exposé à internet, la marge de l’exploitant ne se mesure plus en mois.
Côté exploitants : une longue traîne
Le catalogue KEV révèle un autre phénomène : il contient de nombreuses vulnérabilités anciennes, publiées parfois plus de dix ans avant leur ajout, et pourtant encore exploitées. Leur présence signifie qu’un nombre suffisant de systèmes non corrigés restent en service pour que les attaquants continuent de s’en servir.
Les rapports qui mesurent le déploiement des correctifs, à partir de balayages d’internet ou de données de clients d’outils de sécurité, décrivent une courbe typique : une partie des systèmes est corrigée rapidement, puis la progression ralentit, et une fraction reste vulnérable longtemps. Les équipements de bordure, paradoxalement, sont souvent parmi les plus lents à corriger : leur mise à jour impose une interruption de service, ils sont parfois gérés par un prestataire, et ils échappent aux outils de gestion des postes de travail.
Le délai qui expose une organisation n’est pas celui de son éditeur, c’est le sien. Et il se joue surtout sur une petite catégorie d’équipements : ceux qui sont accessibles depuis internet.
Les limites de ces données
Ces constats doivent être lus avec prudence, pour quatre raisons.
Les dates sont ambiguës. La date de publication d’une CVE n’est pas toujours celle du correctif, ni celle de l’avis de l’éditeur. Selon la date retenue, le même délai peut varier de plusieurs semaines.
On ne mesure que ce que l’on voit. Le catalogue KEV ne recense que les exploitations avérées et connues de son éditeur. Une vulnérabilité exploitée discrètement, ou dans des environnements peu observés (systèmes industriels, pays peu couverts par les éditeurs de sécurité), n’y figure pas forcément.
Les échantillons sont biaisés. Les rapports d’industrie s’appuient sur les clients de leurs auteurs, ou sur les incidents qu’ils ont traités. Ils sont utiles pour dégager des tendances, beaucoup moins pour comparer des chiffres d’une année ou d’un rapport à l’autre.
L’infrastructure elle-même est fragile. En 2024, la NVD a accumulé un arriéré important dans l’analyse des nouvelles CVE, laissant de nombreuses vulnérabilités sans enrichissement pendant des mois. En avril 2025, l’incertitude sur le renouvellement du contrat qui finance le programme CVE, finalement prolongé au dernier moment, a rappelé que ce bien commun dépend largement d’un financement public américain. La mise en service de la base européenne de l’ENISA, la même année, répond en partie à cette dépendance.
Ce que cela change pour une organisation
Les données publiques ne disent pas quel délai une organisation doit viser. Elles permettent en revanche de fonder une politique de correction sur autre chose que l’habitude.
Prioriser sur l’exploitation et l’exposition, pas sur la seule gravité. Le score CVSS, dont la version 4.0 a été publiée par le FIRST fin 2023, mesure la gravité technique d’une faille. Combiné à l’information d’exploitation avérée (KEV), à une probabilité estimée (EPSS) et à la connaissance de l’exposition de ses propres systèmes, il permet de concentrer l’effort sur la petite fraction de vulnérabilités qui représente l’essentiel du risque.
Traiter à part les équipements exposés. Passerelles, pare-feu, serveurs de messagerie, portails accessibles depuis internet : ils appellent un délai beaucoup plus court, une procédure d’urgence préparée à l’avance et, quand le correctif tarde, des mesures d’atténuation documentées.
Mesurer son propre délai. Peu d’organisations savent dire combien de temps elles mettent, en pratique, à déployer un correctif critique. C’est pourtant la seule donnée qui compte pour elles, et un indicateur que les autorités de contrôle demandent de plus en plus. La directive NIS 2 inclut la gestion et la divulgation des vulnérabilités parmi les mesures de gestion des risques attendues des entités concernées.
Exiger des fournisseurs. Le Cyber Resilience Act, entré en vigueur en décembre 2024, impose aux fabricants de produits comportant des éléments numériques de traiter les vulnérabilités pendant une période de support définie, en principe d’au moins cinq ans, et de signaler les vulnérabilités activement exploitées à partir du 11 septembre 2026. Pour un acheteur, ces obligations sont autant de clauses à reprendre dès maintenant dans les contrats : durée de support, délai de publication des correctifs, canal de signalement.
Ce que l’on peut en conclure
Trois conclusions solides se dégagent, au-delà des chiffres de chaque rapport. La fenêtre entre publication et exploitation s’est réduite au point que la correction mensuelle ne suffit plus pour les systèmes exposés. Le risque se concentre sur une minorité de vulnérabilités, que l’on sait de mieux en mieux identifier. Et la donnée la plus utile, le délai réel de chaque organisation, est celle qu’aucune base publique ne fournira : il faut la produire soi-même, à partir d’un inventaire fiable.
Une question reste ouverte : à mesure que les obligations de signalement du Cyber Resilience Act entreront en application, les données publiques sur le délai de l’éditeur deviendront-elles plus complètes, et seront-elles rendues accessibles aux acheteurs ? Notre expertise cybersécurité et conformité aide à bâtir cette mesure et à l’intégrer au pilotage, et notre dossier NIS 2 détaille les obligations qui s’y rattachent.
- CISA, catalogue Known Exploited Vulnerabilities et directive opérationnelle contraignante BOD 22-01, novembre 2021.
- NIST, National Vulnerability Database, notes d’information sur le traitement des CVE, 2024.
- FIRST, Exploit Prediction Scoring System (EPSS) et Common Vulnerability Scoring System version 4.0, 2023.
- ENISA, base européenne de vulnérabilités, prévue par l’article 12 de la directive (UE) 2022/2555 (NIS 2).
- Mandiant (Google Cloud), analyse des délais d’exploitation des vulnérabilités en 2023, publiée en 2024.
- Verizon, Data Breach Investigations Report, édition 2025.
- Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 (Cyber Resilience Act).
Questions fréquentes
Quel délai de correction viser pour une vulnérabilité critique ?
Il n'existe pas de norme universelle. Une pratique répandue consiste à distinguer les vulnérabilités activement exploitées, notamment celles du catalogue KEV, à corriger ou atténuer en quelques jours, surtout sur les équipements exposés à internet, des autres vulnérabilités, traitées selon leur gravité et leur exposition dans des délais de quelques semaines à quelques mois. L'important est de fixer ces délais par écrit et de mesurer leur respect.
Le score CVSS suffit-il pour prioriser les correctifs ?
Non. Le CVSS mesure la gravité technique d'une vulnérabilité, pas sa probabilité d'exploitation ni l'exposition de vos systèmes. Le combiner avec l'information d'exploitation avérée (catalogue KEV), une estimation de probabilité (EPSS) et la connaissance de vos actifs donne une priorisation beaucoup plus juste.
Le Cyber Resilience Act impose-t-il un délai de correction ?
Le règlement impose aux fabricants de traiter les vulnérabilités sans délai et de fournir des mises à jour de sécurité pendant la période de support, et de signaler les vulnérabilités activement exploitées à partir du 11 septembre 2026, avec une alerte précoce sous 24 heures. Il ne fixe pas un délai de correction chiffré unique pour toutes les vulnérabilités.
Où trouver les vulnérabilités qui concernent mon organisation ?
Les avis de sécurité de vos éditeurs, les bulletins des autorités nationales (en France, le CERT-FR), la base européenne de l'ENISA, la NVD et le catalogue KEV sont les sources principales. Leur exploitation suppose un inventaire à jour des logiciels et équipements en service : sans inventaire, aucune veille n'est actionnable.