CVE MCP Server est un serveur MCP Python qui donne à un client comme Claude accès à des outils de renseignement sécurité : NVD, EPSS, CISA KEV, OSV, GitHub, MITRE et plusieurs sources threat intel. Mon verdict court : ça vaut l’essai si vous faites de la veille vulnérabilités ou du triage patch, mais il faut accepter une couche MCP encore très orientée ingénieur et quelques angles morts selon les API.
CVE MCP Server, c’est quoi ?
CVE MCP Server transforme des sources de vulnérabilités en outils appelables par un LLM via le Model Context Protocol. L’idée est simple : au lieu d’ouvrir NVD, CISA KEV, FIRST EPSS, OSV et GitHub à la main, le modèle peut appeler des fonctions dédiées et recouper les résultats.
Le dépôt annonce 27 outils sur 21 sources. Dans mon test, le serveur a bien enregistré 27 outils MCP, dont lookup_cve, get_epss_score, check_kev, check_package_vulns, calculate_risk_score et compare_cves.
Ce n’est pas une application web avec un tableau de bord. C’est une brique d’infra pour connecter un assistant IA à des données sécurité. Donc le bon public, ce sont les équipes sécu, DevOps, AppSec, les freelances qui font du triage et les gens qui veulent brancher un assistant à des sources fiables.
| Point | Détail observé |
|---|---|
| Langage | Python 3.10 ou plus |
| Serveur | FastMCP via stdio |
| Installation testée | pip install -e .[test] |
| Outils MCP | 27 outils listés au démarrage |
| Sources testées | NVD, CISA KEV, FIRST EPSS, OSV, GitHub |
| Clés nécessaires | Pas pour mon scénario de base, mais utile pour GitHub, NVD, Shodan, VirusTotal |
| Cas testé | Triage de Log4Shell, CVE-2021-44228 |
Installation de CVE MCP Server
J’ai cloné le dépôt dans /tmp, installé les dépendances dans un environnement Python isolé, puis lancé les tests. Première surprise : les tests MCP du dépôt utilisent la commande python -m cve_mcp.server. Dans mon conteneur, ça pointait d’abord vers le Python système, pas vers le venv, donc les tests MCP ne trouvaient pas le module.
Une fois le PATH et PYTHONPATH posés correctement, la suite passe :
git clone https://github.com/mukul975/cve-mcp-server.git
cd cve-mcp-server
python3 -m venv .venv
.venv/bin/python -m pip install -e '.[test]'
PYTHONPATH=$PWD/src PATH=$PWD/.venv/bin:$PATH .venv/bin/python -m pytest -q tests
Résultat réel : 30 passed in 5.41s.
Côté lancement, le serveur parle en stdio MCP. Il charge au démarrage le catalogue CISA KEV. Dans mon run, il a récupéré 1617 entrées depuis CISA, puis il a répondu aux appels d’outils depuis un client MCP Python.
CVE MCP Server à l’usage : mon scénario Log4Shell
Je voulais un cas concret, pas un simple démarrage. J’ai donc simulé une question de triage : “que faire avec CVE-2021-44228, Log4Shell, et comment la prioriser face à CVE-2024-3094 ?”.
J’ai appelé ces outils MCP :
lookup_cve(CVE-2021-44228)
get_epss_score(CVE-2021-44228,CVE-2024-3094)
check_kev(CVE-2021-44228)
check_package_vulns(org.apache.logging.log4j:log4j-core, Maven, 2.14.1)
calculate_risk_score(CVE-2021-44228)
compare_cves([CVE-2021-44228, CVE-2024-3094])
health_check()
Le résultat est utile. lookup_cve remonte le statut NVD, la date de publication, la date de mise à jour, les CWE, le score CVSS 10.0, le vecteur CVSS, et la description longue de la faille.
check_kev confirme que CVE-2021-44228 est dans le catalogue CISA KEV, avec usage ransomware connu, date d’ajout et échéance de remédiation. get_epss_score donne aussi un signal prioritaire : 94,36 % de probabilité EPSS pour Log4Shell, et 84,80 % pour CVE-2024-3094 au moment du test.
Le plus intéressant est calculate_risk_score. Pour Log4Shell, le serveur a produit :
Risk Score: CVE-2021-44228
Score: 100.0/100 (CRITICAL)
Urgency: PATCH IMMEDIATELY
Recommendation: CVE-2021-44228 is actively exploited and in the CISA KEV catalog with high exploitation probability; apply vendor patches immediately.
La comparaison est lisible aussi : Log4Shell sort premier avec 100/100, CVE-2024-3094 sort second avec 65,7/100 et une recommandation de patch sous 72 heures.
Ce que j’aime dans CVE MCP Server
Le vrai point fort, c’est la corrélation. Un CVSS élevé seul ne suffit pas. Le fait de combiner CVSS, EPSS, KEV et présence de PoC donne une réponse beaucoup plus proche d’un triage terrain.
J’aime aussi le format des sorties. Ce n’est pas du JSON brut illisible pour humain. Les réponses sont textuelles, prêtes à être injectées dans une conversation ou un rapport. Pour un assistant IA, c’est pratique : le modèle reçoit déjà un résumé structuré.
Autre bon point : le serveur ne force pas une clé payante pour commencer. Mon test de base a fonctionné avec des API publiques. Les clés restent importantes pour lever les limites de débit ou accéder à Shodan, VirusTotal, AbuseIPDB et GitHub sans erreurs 401 sur certaines recherches.
Enfin, la suite de tests passe quand l’environnement Python est correctement câblé. C’est rassurant pour une brique qu’on voudrait intégrer dans une chaîne d’outillage.
Les limites de CVE MCP Server
La première limite est l’expérience développeur. Le projet est propre, mais il reste très “serveur MCP”. Si vous cherchez une interface web prête à cliquer, ce n’est pas le bon outil.
Deuxième limite : certaines API imposent vite leurs contraintes. Pendant mon test, la recherche de templates Nuclei via GitHub Code Search a répondu 401 sans token GitHub. Ce n’est pas un bug fatal, mais il faut prévoir les clés si vous voulez une couverture complète.
Troisième limite : le nommage des packages OSV peut piéger. Un appel naïf sur log4j-core en Maven ne m’a rien remonté. L’appel correct était org.apache.logging.log4j:log4j-core, et là OSV a retourné 7 vulnérabilités. C’est logique côté écosystème Maven, mais un assistant devra être bien guidé pour éviter ce faux négatif.
Dernier détail : le parseur CVSS affiche Version: 1 pour un vecteur CVSS 3.1. Le score est bon, 9.8, mais cette ligne peut surprendre dans un rapport.
Est-ce que CVE MCP Server marche vraiment ?
Oui, pour le cœur du besoin. J’ai vu le serveur lancer de vrais appels HTTPS vers NVD, CISA, FIRST EPSS, OSV et GitHub, puis produire des sorties exploitables : résumé CVE, statut KEV, scores EPSS, vulnérabilités de package, score de risque et ranking de patch.
Il ne remplace pas un analyste. Il automatise la collecte et donne une première priorisation. C’est exactement là que je le trouve utile : réduire le temps perdu à copier coller entre cinq sites, pas décider seul d’un plan de remédiation.
Faut-il adopter CVE MCP Server ?
Mon verdict : à essayer si vous avez déjà un client MCP ou un assistant interne. Pour une équipe DevOps ou sécu qui fait de la veille CVE, c’est une brique intéressante et assez concrète.
Je ne l’adopterais pas comme source unique de vérité. Je l’utiliserais comme agrégateur, avec logs, cache, clés API configurées et validation humaine avant décision. Pour un freelance sécu, c’est typiquement le genre d’outil qui peut accélérer un audit de dépendances ou une note d’urgence client.
Si vous n’utilisez pas encore MCP, passez peut-être votre tour pour l’instant. Si vous avez déjà Claude Desktop, Claude Code ou un agent compatible MCP, CVE MCP Server mérite une place dans votre lab.
FAQ
CVE MCP Server nécessite-t-il une clé OpenAI ?
Non pour le serveur lui-même. Il expose des outils MCP, puis c’est le client LLM qui les appelle. Les clés importantes sont plutôt celles des sources sécurité : NVD, GitHub, Shodan, VirusTotal, AbuseIPDB.
Peut-on utiliser CVE MCP Server sans clé API sécurité ?
Oui, pour les fonctions de base testées ici. NVD, CISA KEV, FIRST EPSS et OSV ont répondu sans clé dans mon scénario. En revanche, certaines recherches GitHub et sources threat intel seront limitées ou indisponibles.
CVE MCP Server remplace-t-il un scanner de vulnérabilités ?
Non. Il aide à enrichir et prioriser des vulnérabilités connues. Pour détecter ce qui est installé en production, il faut toujours un inventaire, un scanner, du SBOM ou une intégration CI/CD.