Le retard du NVD n'est pas résolu : prioriser sans score CVSS officiel

Le National Vulnerability Database (NVD) reste, pour une grande partie de l'industrie, la source de référence pour le scoring CVSS des vulnérabilités. Mais le constat opérationnel de ces deux dernières années ne s'est pas dissipé en 2026 : un nombre significatif de CVE nouvellement publiées attendent encore leur analyse et leur score CVSS officiel pendant des semaines. Ce retard d'enrichissement, documenté depuis 2024, continue de peser sur les équipes de gestion des vulnérabilités qui s'appuient sur le CVSS du NVD comme signal de priorisation unique.

Pour les équipes SOC et les responsables de la remédiation, cette situation n'est plus une anomalie ponctuelle à surveiller : c'est une contrainte structurelle avec laquelle il faut désormais construire ses processus.

Pourquoi attendre le NVD est une stratégie perdante

Les SLA de patch management sont généralement calés sur la sévérité déclarée : critique sous 24-72h, élevée sous 7-15 jours, etc. Ce modèle suppose qu'un score CVSS est disponible rapidement après la publication de la CVE. Or, quand ce score n'arrive que des semaines plus tard :

• le compteur de SLA ne peut pas démarrer sur une base fiable, ou démarre trop tard ;
• les équipes traitent les CVE dans l'ordre de publication plutôt que dans l'ordre de risque réel ;
• des vulnérabilités activement exploitées peuvent rester invisibles dans les tableaux de bord basés uniquement sur le score NVD ;
• les auditeurs et les clients qui exigent des preuves de remédiation rapide se retrouvent face à un vide documentaire.

Attendre passivement l'enrichissement officiel revient à laisser le NVD dicter le tempo de votre exposition au risque, alors que les attaquants, eux, n'attendent pas ce score pour développer un exploit.

Les signaux alternatifs à mobiliser dès la publication

Un score CVSS manquant ne signifie pas une absence de données exploitables. Plusieurs signaux restent disponibles dès la publication d'une CVE, ou très peu de temps après :

• La probabilité EPSS (Exploit Prediction Scoring System) : calculée par le FIRST à partir de modèles statistiques, elle peut fournir une estimation d'exploitation à court terme indépendamment du CVSS.
• Le statut CISA KEV (Known Exploited Vulnerabilities) : dès qu'une exploitation active est confirmée, la CVE est catégorisée comme urgente, qu'un score officiel existe ou non.
• Les advisories des éditeurs : les bulletins de sécurité publiés directement par le fournisseur du produit affecté contiennent souvent une sévérité propriétaire, des indications de contournement et parfois un score CVSS calculé en interne avant même que le NVD ne le publie.
• Les signaux d'exploitation observés : mentions sur les forums spécialisés, preuves de concept publiques, activité de scan ou d'exploitation détectée sur le trafic réseau, chatter sur les canaux de threat intelligence.

Aucun de ces signaux, pris isolément, ne remplace un score CVSS validé. Combinés, ils permettent de prendre une décision de priorisation défendable bien avant que le NVD ne termine son analyse.

Construire un workflow de priorisation qui ne dépend pas uniquement du CVSS

Un processus de gestion des vulnérabilités robuste face à ce retard doit traiter le score CVSS du NVD comme une donnée parmi d'autres, jamais comme un préalable bloquant. Concrètement, cela implique :

• d'ingérer les CVE dès leur publication, même sans score, et de les faire apparaître dans la file de triage ;
• d'appliquer un score de priorité composite basé sur EPSS, KEV, exposition réelle des actifs et criticité métier ;
• de revoir automatiquement le classement dès qu'un signal change (score CVSS publié tardivement, ajout au KEV, mise à jour EPSS) ;
• de documenter la justification de priorisation utilisée au moment de la décision, pour ne pas dépendre rétroactivement d'un score qui arrivera plus tard ;
• de fixer des SLA basés sur la présence de signaux disponibles (KEV, EPSS élevé, advisory critique) plutôt que sur la seule publication du CVSS.

La veille CVE Watch d'isMalicious est conçue pour ce contexte : elle suit les vulnérabilités pertinentes pour votre stack technique et expose les signaux disponibles dès la publication, sans attendre la fin du cycle d'enrichissement du NVD. La recherche CVE permet par ailleurs d'interroger directement l'état d'une vulnérabilité donnée pour vérifier ce qui est réellement documenté à un instant T.

Automatiser le comblement du vide de données

Le retard du NVD étant devenu prévisible, il peut être traité comme une contrainte d'ingénierie plutôt que comme un incident ponctuel. Cela passe par l'automatisation :

• brancher un flux d'ingestion sur les CVE nouvellement publiées, avant même la disponibilité du score CVSS officiel ;
• déclencher des webhooks lorsqu'un signal de priorisation change (nouvelle entrée KEV, score EPSS franchissant un seuil, publication tardive du CVSS) ;
• réévaluer automatiquement la file de triage plutôt que de relancer une revue manuelle complète à chaque mise à jour ;
• exposer ces signaux dans les outils déjà utilisés par les équipes (ticketing, SIEM, tableaux de bord internes) via l'API isMalicious, pour éviter que la donnée reste enfermée dans un outil isolé.

Cette automatisation ne remplace pas le jugement humain sur les décisions à fort enjeu, mais elle évite que la donnée utile reste bloquée derrière un backlog d'analyse qui ne dépend pas de vous.

CTA opérationnel

Le retard d'enrichissement du NVD n'est pas un problème que les équipes de sécurité peuvent résoudre elles-mêmes, mais il n'a pas à dicter la vitesse de votre remédiation. Connectez CVE Watch et la recherche CVE à vos processus de triage, automatisez la collecte des signaux alternatifs via l'API isMalicious, et donnez à votre SOC une file de priorisation qui reste actionnable même quand le NVD prend du retard.