Backfill NVD : pourquoi la complétude du catalogue CVE change toute la priorisation

Une plateforme CVE peut sembler fonctionnelle avec quelques centaines de lignes récentes. Les pages se chargent, les filtres répondent, quelques graphiques apparaissent. Mais si le catalogue historique est incomplet, tout le reste devient fragile : le total global est faux, les tendances sont plates, les périmètres ratent des correspondances, et les équipes surestiment la maturité de leur couverture.

Le backfill NVD consiste à remplir le catalogue avec des vulnérabilités publiées sur une période passée. Dans isMalicious, cette donnée sert à alimenter CVE Search, les tableaux de bord, les enrichissements et les workflows de CVE Watch. C’est une fondation : si elle manque, même les bons algorithmes priorisent une réalité tronquée.

Le NVD comme socle de catalogue

Le NVD apporte les champs fondamentaux : CVE ID, description, dates de publication et modification, sévérité, CVSS et références structurées. Ces informations permettent d’indexer, rechercher, filtrer et expliquer les vulnérabilités.

Un pipeline moderne peut aussi recevoir des CVE par OpenCVE, advisories fournisseurs ou synchronisations de périmètre. Mais le NVD reste un socle utile pour la complétude historique. Il évite qu’un produit surveillé semble sain uniquement parce que la base locale ne contient pas les CVE anciennes qui le concernent.

Ce qui se casse quand le catalogue est incomplet

Un catalogue incomplet crée des symptômes visibles :

• les métriques “total CVE” sont trop basses ;
• les timelines all-time semblent pauvres ;
• les vues EPSS ou KEV ont peu de données ;
• les recherches par CVE historique retournent vide ;
• les rapprochements CPE ignorent des vulnérabilités anciennes ;
• les équipes patch pensent avoir moins de dette qu’en réalité.

Ces symptômes ne sont pas seulement cosmétiques. Ils peuvent conduire à une décision dangereuse : reporter un correctif parce que le système ne sait pas que la CVE existe.

Backfill ne veut pas dire bruit

Importer plus de CVE ne doit pas noyer les analystes. Le catalogue global sert à conserver la connaissance ; les findings organisationnels servent à dire ce qui vous concerne. La distinction est importante. Une CVE dans le catalogue ne devient pas automatiquement une alerte. Elle devient une alerte lorsqu’elle correspond à un CPE, un produit surveillé, une exposition ou un signal critique.

C’est pour cela que le backfill doit être combiné avec :

• OpenCVE pour vendor/product et suivi de changements ;
• CISA KEV et GCVE pour exploitation confirmée ;
• EPSS pour probabilité d’exploitation ;
• CERT-FR, MSRC, GHSA et advisories fournisseurs pour contexte de correction ;
• Exploit-DB et Nuclei pour signaux PoC ou templates ;
• CPE et périmètres pour transformer le catalogue en findings.

La timeline doit couvrir l’historique disponible

Une erreur fréquente consiste à afficher uniquement les 30 derniers jours. C’est utile pour une activité récente, mais insuffisant pour comprendre la dette de vulnérabilité. Une vue all-time mensuelle permet de visualiser la profondeur du catalogue, les périodes de publication intense, les pics de high/critical et l’impact des enrichissements.

L’article Sources de données CVE explique comment chaque source complète cette timeline. Pour la priorisation des scores, EPSS vs CVSS vs KEV donne un modèle décisionnel.

Qualité des dates : published, modified, created

Les dates sont piégeuses. publishedAt raconte l’arrivée publique de la CVE. lastModifiedAt indique les modifications de la fiche. createdAt peut représenter l’entrée dans votre base. Pour un graphe récent, lastModifiedAt est pertinent. Pour une timeline all-time, il faut éviter de perdre les lignes sans modification récente : un COALESCE(lastModifiedAt, publishedAt, createdAt) donne une meilleure couverture.

Cette nuance explique pourquoi un dashboard peut sembler vide alors que le catalogue contient bien des données : le filtre temporel ou le champ date choisi exclut l’historique.

Backfill et gouvernance

Un backfill massif doit être gouverné. Les équipes doivent décider :

• quelle fenêtre historique importer ;
• quels rate limits respecter ;
• comment gérer les erreurs API ;
• comment éviter les doublons ;
• comment relancer l’ingestion ;
• quand enrichir par EPSS, KEV et advisories.

Les contrats cron CVE sont documentés dans API Docs et les flux de données plus larges dans Data Feeds. Pour la chaîne supply chain, SBOM Security relie catalogue CVE et dépendances applicatives.

Contrôles post-backfill

Après un backfill, il ne suffit pas de regarder le nombre de lignes insérées. Les équipes doivent vérifier plusieurs indicateurs de qualité. Le premier est la distribution des sévérités : un catalogue sans high ou critical sur plusieurs années signale probablement un problème de parsing. Le deuxième est la présence de dates cohérentes : publication, modification et création doivent permettre de construire des timelines all-time et récentes. Le troisième est le taux d’enrichissement : combien de CVE ont un score EPSS, combien sont croisées avec KEV, combien disposent d’advisories exploitables.

Un autre contrôle utile consiste à rechercher des CVE connues et anciennes, comme des vulnérabilités emblématiques dans des produits très répandus. Si elles ne sont pas présentes, le backfill n’est pas assez profond ou l’ingestion a échoué sur certains intervalles. Enfin, les équipes doivent surveiller les doublons : le champ CVE ID doit rester l’identifiant canonique.

Quand relancer un backfill

Le backfill initial est rarement le dernier. Il faut le relancer lorsqu’un nouvel environnement est restauré, lorsqu’une migration de base a perdu des lignes, lorsqu’un enrichissement dépend d’un historique plus ancien, ou lorsqu’une nouvelle fonctionnalité explore des périodes non couvertes. Il peut aussi être utile après l’ajout d’un nouveau fournisseur de données, afin de recalculer les enrichissements sur tout le catalogue.

La cadence quotidienne relève plutôt de l’ingestion incrémentale. Le backfill, lui, est un outil de remise à niveau. Cette distinction évite de lancer des tâches lourdes inutilement tout en garantissant que les dashboards ne racontent pas seulement les dernières semaines.

Conclusion

Le backfill NVD n’est pas un luxe. C’est ce qui empêche une plateforme CVE de prendre des décisions sur un échantillon trop court. Une fois le socle complet, les enrichissements KEV, EPSS, OpenCVE, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei et CPE peuvent jouer leur rôle : transformer une base historique en système de priorisation vivant.