API CVE, dashboards et SIEM : automatiser la vulnérabilité sans perdre le contexte

Les données CVE deviennent vraiment puissantes lorsqu’elles sortent du dashboard. Un analyste peut explorer une CVE à la main, mais une organisation doit automatiser : dashboards exécutifs, SIEM, SOAR, ticketing, exports, alerting, reporting conformité et data pipelines.

L’API est le contrat qui rend cette automatisation possible. Elle doit exposer suffisamment de contexte pour éviter les décisions aveugles : NVD, OpenCVE, KEV, GCVE, EPSS, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei, advisories, CPE, périmètres et statuts.

Ce qu’une API CVE doit fournir

Une réponse CVE utile ne se limite pas à id et severity. Elle doit inclure :

• CVE ID ;
• description ;
• CVSS et sévérité ;
• dates publication/modification ;
• EPSS ;
• KEV et exploitation active ;
• PoC ou templates ;
• advisories ;
• produits et CPE ;
• liens vers détails ;
• statut si la CVE est liée à un périmètre.

Les endpoints isMalicious sont documentés dans API Docs. Les usages threat intelligence plus larges sont présentés dans Data Feeds.

Dashboards : global versus périmètre

Un dashboard global répond à “que se passe-t-il dans le monde CVE ?” Un dashboard périmètre répond à “qu’est-ce qui nous touche ?” Les deux sont utiles mais ne doivent pas être confondus.

La timeline globale peut afficher l’historique complet par mois. Les métriques périmètre doivent montrer les findings par statut, KEV, EPSS, high/critical et remédiation. Mélanger les deux crée de mauvaises décisions : un total catalogue élevé ne signifie pas une exposition directe ; zéro finding ne signifie pas que le monde est calme.

SIEM : enrichir sans noyer

Pousser tout le catalogue CVE dans un SIEM est rarement utile. Il faut enrichir les événements pertinents. Par exemple :

• une IP scanne un produit exposé lié à une CVE KEV ;
• un endpoint exécute un binaire associé à une exploitation ;
• un service vulnérable contacte une infrastructure suspecte ;
• une tentative web correspond à un template public.

Les pages IP Threat Intelligence, Domain Threat Intelligence et STIX/TAXII montrent comment relier CVE et indicateurs d’infrastructure.

Automatisation de la remédiation

L’automatisation doit créer des actions, pas seulement des alertes. Un workflow peut :

1. détecter une CVE KEV sur un CPE surveillé ;
2. créer un ticket avec advisory et version cible ;
3. notifier le propriétaire ;
4. ajouter une règle de surveillance temporaire ;
5. vérifier le statut patch ;
6. clôturer ou réouvrir selon la preuve.

Pour les pipelines SOC, consultez SIEM/SOAR Threat Intelligence Workflows et Automating Threat Intelligence.

Gouvernance des accès API

Les données CVE peuvent révéler indirectement votre surface technologique. L’API doit donc être protégée : authentification, rate limits, scopes, journalisation et séparation entre routes publiques et routes organisationnelles. Une recherche publique de CVE n’a pas le même niveau de sensibilité qu’un export des findings d’un client.

Les clés API doivent être traitées comme des secrets. Les intégrations SIEM et SOAR doivent utiliser des comptes dédiés, avec rotation et permissions minimales. Les logs d’accès API aident à comprendre qui exporte quelles données et à détecter une intégration défaillante.

Modèles de données pour le SIEM

Pour que le SIEM exploite les CVE, il faut normaliser les champs. cveId, severity, epssScore, isKev, ssvcExploitation, vendor, product, status et detectedAt doivent être faciles à requêter. Les tags comme kev, epss-high, internet-facing ou accepted-risk améliorent les règles.

Le SIEM peut ensuite corréler : une alerte réseau sur un produit vulnérable, une IP malveillante ciblant un service exposé, ou un endpoint qui montre des signes post-exploitation après une fenêtre de vulnérabilité.

Éviter l’automatisation aveugle

Automatiser ne signifie pas patcher tout sans validation. Certaines actions doivent rester humaines : accepter un risque, redémarrer un service critique, appliquer un contournement dégradant, publier une communication client. L’API doit donc fournir le contexte qui permet à l’humain de décider vite.

Le bon objectif est l’automatisation assistée : préremplir les tickets, enrichir les alertes, proposer les owners, joindre les advisories, calculer l’urgence et vérifier la clôture.

Tableaux de bord pour différentes audiences

Un dashboard ingénieur doit montrer les détails exploitables : produit, version, statut, advisory, EPSS, KEV et note. Un dashboard SOC doit mettre en avant l’exploitation, les tentatives, les corrélations IP/domain et les contrôles compensatoires. Un dashboard dirigeant doit réduire la complexité : tendances, SLA, risques acceptés, périmètres critiques et dette restante.

L’API doit permettre ces trois vues sans dupliquer la logique. Les mêmes données normalisées alimentent plusieurs restitutions. C’est ce qui évite la divergence entre reporting exécutif et réalité opérationnelle.

Qualité et fraîcheur des données

L’automatisation ne vaut que si les données sont fraîches. Les pipelines doivent exposer les dates de dernière synchronisation : NVD, OpenCVE, KEV, EPSS, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei et advisories fournisseurs. Lorsqu’une source échoue, le dashboard doit le montrer plutôt que présenter une fausse impression de complétude.

Cette transparence est particulièrement importante pour les décisions urgentes. Un score EPSS ancien ou un statut KEV non synchronisé peut retarder une action. La donnée CVE doit donc être surveillée comme une dépendance critique du SOC.

Conclusion

Une API CVE ne doit pas être un simple export de base. Elle doit préserver le contexte qui rend la donnée exploitable : sources, scores, exploitation, advisories, périmètres et statuts. C’est cette richesse qui permet aux dashboards, SIEM et workflows de remédiation d’améliorer la sécurité au lieu d’ajouter du bruit.