CVE Watch : transformer le catalogue mondial en findings exploitables pour votre périmètre

La plupart des organisations connaissent deux extrêmes : un catalogue CVE mondial trop vaste pour être actionnable, ou un scanner local qui produit des alertes sans contexte d’exploitation. CVE Watch relie ces deux mondes. Il transforme les sources globales en findings spécifiques à vos périmètres.

Le principe est simple : vous surveillez des produits, CPE ou périmètres ; la plateforme rapproche ces éléments du catalogue enrichi ; les CVE pertinentes deviennent des findings avec statut et priorité.

Du global au local

Le catalogue global agrège NVD, OpenCVE, KEV, GCVE, EPSS, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei et advisories fournisseurs. Cette richesse est nécessaire, mais elle ne doit pas produire une alerte pour chaque CVE.

Le périmètre ajoute le contexte :

• quels produits sont présents ;
• quelles versions sont surveillées ;
• quel propriétaire est responsable ;
• quelle criticité métier est attachée ;
• quel statut de remédiation existe.

Cette transformation est ce qui rend CVE Watch utile au quotidien.

Les findings comme unité de travail

Un finding n’est pas seulement une ligne. C’est un objet opérationnel : CVE, produit, sévérité, EPSS, KEV, exploitation active, statut, date de détection, note, export. Il peut être trié, filtré, assigné, exporté et révisé.

Les statuts comme NEW, ACKNOWLEDGED, PATCHED ou ACCEPTED_RISK évitent la confusion. Une CVE peut être connue, mais non encore traitée ; reconnue, mais temporairement mitigée ; corrigée, mais à vérifier ; acceptée, mais avec date d’expiration.

Priorisation dans CVE Watch

Une priorité réaliste combine :

• sévérité CVSS ;
• EPSS élevé ;
• présence KEV ;
• exploitation active ou PoC ;
• exposition du périmètre ;
• criticité du produit ;
• disponibilité du correctif ;
• signaux d’advisory.

Pour comprendre les scores, lisez EPSS vs CVSS vs KEV. Pour la vision lifecycle, consultez CVE Vulnerability Lifecycle.

Export et intégration

Les findings doivent sortir du dashboard. Un programme mature les envoie vers ticketing, SIEM, SOAR, reporting ou data warehouse. Les routes et endpoints sont présentés dans API Docs. Les formats de partage peuvent aussi rejoindre STIX/TAXII selon les usages.

Un export utile doit garder le contexte : CVE ID, produit, version, EPSS, KEV, statut, due date, lien advisory et note.

Rituels d’exploitation

CVE Watch fonctionne mieux lorsqu’il s’inscrit dans un rituel régulier. Les équipes peuvent revoir chaque semaine les nouveaux findings, les KEV ouvertes, les CVE EPSS élevé, les risques acceptés proches de l’expiration et les périmètres sans propriétaire. Cette routine transforme la vulnérabilité en processus vivant.

Les incidents majeurs appellent une revue exceptionnelle. Lorsqu’une CVE médiatique sort, l’équipe vérifie immédiatement les périmètres, les CPE, les findings, les advisories et l’exposition. Si le matching ne trouve rien, cela ne suffit pas : il faut aussi vérifier que l’inventaire est à jour.

Rôles et responsabilités

Un finding doit avoir un propriétaire. Le SOC peut détecter et prioriser, mais l’équipe applicative ou infrastructure corrige. Le RSSI arbitre les exceptions. Le métier accepte ou refuse le risque résiduel. Sans cette séparation, les findings restent “à la sécurité” et ne sont jamais résolus.

Les statuts doivent refléter cette gouvernance. ACKNOWLEDGED signifie que quelqu’un a pris connaissance du risque. PATCHED doit idéalement être vérifié. ACCEPTED_RISK doit avoir une justification, un owner et une date de révision.

Mesures de succès

Les métriques utiles incluent le temps moyen de correction des KEV, le nombre de findings EPSS élevé ouverts, le taux de périmètres avec CPE, le nombre d’exceptions expirées et le volume de findings récurrents. Ces indicateurs montrent si l’organisation réduit le risque ou déplace simplement des tickets.

De la vue analyste à la vue dirigeant

Les analystes ont besoin de détails : CVE ID, CPE, score, advisory, statut, note. Les dirigeants ont besoin d’un résumé : combien de vulnérabilités exploitées ouvertes, combien de périmètres critiques touchés, combien de risques acceptés, quelle tendance par rapport à la semaine précédente. CVE Watch doit donc supporter plusieurs niveaux de lecture.

Une bonne pratique consiste à conserver la granularité dans les findings et à produire des agrégats pour le reporting. Le même système peut alimenter une revue technique et un comité risque, à condition de ne pas mélanger les métriques globales du catalogue avec les métriques propres au périmètre.

Exemple de journée opérationnelle

Le matin, l’équipe consulte les nouvelles CVE KEV et EPSS élevé. Elle filtre par périmètre, vérifie les owners, ouvre ou met à jour les tickets. Dans la journée, les équipes techniques appliquent les correctifs ou documentent une mitigation. Le SOC ajoute une règle de surveillance temporaire pour les actifs non corrigés. En fin de cycle, les statuts passent à PATCHED ou ACCEPTED_RISK avec justification.

Cette routine simple empêche le backlog CVE de redevenir une masse opaque.

Conclusion

CVE Watch n’a pas vocation à remplacer toutes les briques vulnérabilité. Il sert de couche de décision : relier les sources globales aux périmètres réels, créer des findings, suivre les statuts et rendre le risque visible. C’est le passage du “monde entier est vulnérable” à “voici ce qui nous concerne maintenant”.