Sources de données CVE : comment construire une vision fiable du risque vulnérabilité

Un programme CVE sérieux ne commence pas par une couleur rouge dans un scanner. Il commence par une question plus humble : quelle donnée décrit vraiment le risque, et d’où vient-elle ? Un identifiant CVE est utile parce qu’il donne un langage commun aux éditeurs, chercheurs, équipes SOC, outils de ticketing et responsables métier. Mais l’identifiant seul ne dit pas si la vulnérabilité touche votre parc, si elle est exploitée, si un correctif existe, ni si l’alerte mérite de casser une fenêtre de changement.

Chez isMalicious, la logique CVE repose donc sur une approche multi-sources. Le catalogue global alimente la recherche publique via CVE Search, la surface d’analyse vulnérabilité via Vulnerability Intelligence, et les workflows opérationnels de CVE Watch. Cette chaîne relie des sources complémentaires : NVD, OpenCVE, CISA KEV, GCVE, FIRST EPSS, CERT-FR, MSRC, GitHub Security Advisories, Exploit-DB, Nuclei, advisories fournisseurs, CPE et miroirs vendor/product.

La couche fondation : NVD et OpenCVE

La première couche sert à répondre à une question simple : “quelles CVE existent, avec quelle description, quelle sévérité et quelles dates ?” Le NVD fournit une base de référence avec identifiants, descriptions, métriques CVSS, dates de publication et de modification. C’est le socle qui rend possible une recherche robuste par CVE ID, produit, gravité ou période.

OpenCVE complète ce socle par des vues pratiques sur les éditeurs, produits et changements. Dans une plateforme opérationnelle, ce n’est pas anecdotique : connaître les couples vendor/product permet de rapprocher une vulnérabilité d’un périmètre réel. Le miroir OpenCVE vendor/product est utile pour des interfaces de recherche, des suggestions de périmètres et des analyses de tendance.

Pour aller plus loin sur le cycle complet d’une vulnérabilité, l’article CVE & Vulnerability Management in 2026 détaille la progression de la découverte au patch.

La couche exploitation : CISA KEV et GCVE

La gravité technique ne suffit pas. Une CVE CVSS 9.8 peut rester théorique pour votre organisation, tandis qu’une CVE moins spectaculaire peut être massivement exploitée dans les campagnes en cours. C’est le rôle de CISA KEV : signaler les vulnérabilités confirmées comme exploitées.

GCVE apporte une couche d’évidence plus large autour de l’exploitation. Dans une architecture CVE moderne, les champs de type KEV, exploitation active, source primaire, confiance, première et dernière observation créent une hiérarchie utile : toutes les vulnérabilités ne doivent pas passer par le même chemin de remédiation.

En pratique, une CVE présente dans KEV et exposée dans votre périmètre doit être traitée comme un événement de sécurité, pas comme une simple dette technique. Elle mérite un propriétaire, une date cible, des compensating controls et une vérification après patch.

La couche probabilité : EPSS

EPSS estime la probabilité d’exploitation d’une CVE. Ce signal répond à une autre question que CVSS : non pas “quel serait l’impact maximal ?”, mais “quelle vulnérabilité risque d’être exploitée prochainement ?” Cette distinction est capitale pour les équipes qui gèrent des milliers de tickets.

Dans isMalicious, les scores EPSS alimentent les vues de priorisation, les tableaux de bord et les filtres de type “EPSS élevé”. Ils sont particulièrement utiles lorsque le backlog contient beaucoup de vulnérabilités high/critical. Pour comparer EPSS, CVSS et KEV, consultez EPSS vs CVSS vs KEV.

La couche advisories : CERT-FR, MSRC, GHSA et fournisseurs

Les advisories apportent du contexte éditorial et opérationnel. CERT-FR peut signaler des avis ou alertes importants pour les organisations francophones et européennes. MSRC est essentiel pour l’écosystème Microsoft : titres, exploitation, KB, informations de correctifs. GitHub Security Advisories relie les CVE aux dépendances open source, packages et chaînes CI/CD. Les advisories fournisseurs ajoutent parfois des correctifs, contournements ou versions affectées avant que les agrégateurs ne soient complets.

Cette couche transforme une CVE abstraite en décision : quel package corriger, quelle version déployer, quel bulletin citer dans une communication interne, quelle exception documenter.

La couche preuve d’exploitation : Exploit-DB, Nuclei et PoC

Les signaux de preuve de concept ne doivent pas être confondus avec l’exploitation active, mais ils accélèrent la décision. Un module Exploit-DB, un template Nuclei ou une référence publique peut indiquer que la barrière technique à l’exploitation baisse. Pour les SOC, ces signaux aident aussi à créer des détections et à valider des contrôles.

La bonne pratique consiste à traiter ces sources comme des indicateurs défensifs : elles ne doivent pas encourager l’exécution non contrôlée de PoC, mais elles peuvent enrichir la priorisation, les règles de détection et les scénarios de threat hunting.

La couche périmètre : CPE, produits et findings

Une CVE globale devient urgente uniquement lorsqu’elle touche un actif réel. C’est pour cela que les CPE, couples vendor/product/version et périmètres surveillés sont essentiels. Dans CVE Watch, les sources globales alimentent un catalogue ; les CPE surveillés transforment ce catalogue en findings propres à votre organisation.

Sans ce pont, une plateforme ne sait qu’empiler des CVE. Avec ce pont, elle peut répondre : “cette CVE touche ce produit, dans ce périmètre, avec ce statut de remédiation”.

Comment relier ces sources dans un workflow utile

Un modèle exploitable peut être résumé ainsi :

• Cataloguer avec NVD et OpenCVE.
• Enrichir avec KEV, GCVE, EPSS, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei et advisories fournisseurs.
• Mapper avec CPE, vendors, produits et périmètres.
• Prioriser avec sévérité, probabilité, exploitation confirmée, exposition et criticité métier.
• Automatiser via API, export, SIEM et dashboards. Les endpoints publics et proxifiés sont documentés dans API Docs.

Cette architecture sert aussi les intégrations de threat intelligence plus larges : STIX/TAXII, data feeds, enrichissement SIEM et workflows de réponse.

Conclusion

La valeur d’un programme CVE ne vient pas du nombre de sources branchées, mais de leur normalisation. NVD donne le socle, OpenCVE aide à relier produits et changements, KEV et GCVE signalent l’exploitation, EPSS mesure la probabilité, les advisories donnent le contexte de correction, et les signaux PoC aident à anticiper. Reliées à vos CPE et à votre périmètre, ces données deviennent actionnables.

La question n’est donc pas “quelle source CVE est la meilleure ?” mais “quelle question chaque source résout-elle dans ma chaîne de décision ?”