Contrôler la conformité d’un serveur MCP au CIS
Cyberwatch évalue la conformité des serveurs MCP (Model Context Protocol) au CIS MCP Server Benchmark v1.0.0, publié par le CIS en septembre 2026.
Les 55 recommandations du benchmark sont disponibles sous forme de règles de conformité. Seize d’entre elles sont vérifiées automatiquement à partir de l’audit quotidien du serveur. Les autres relèvent du client, de l’hébergement ou de l’organisation, et sont à vérifier manuellement.
Créer la cible MCP
La conformité s’évalue sur un actif de type serveur MCP. Pour le créer, ajouter une cible réseau de type « Serveur MCP », en indiquant l’URL exacte de son endpoint.
L’actif reçoit le système d’exploitation « MCP Server », auquel s’appliquent les règles du benchmark.
Associer les référentiels
Une nouvelle cible MCP reçoit d’office le référentiel CIS_Benchmark_level_1, qui regroupe les 39 recommandations de niveau 1.
Pour évaluer aussi les 16 recommandations de niveau 2, ajouter le référentiel CIS_Benchmark_level_2, ou bien CIS_Benchmark, qui regroupe les deux niveaux. Ces référentiels sont présents par défaut dans Cyberwatch.
Fonctionnement de l’évaluation
Les règles évaluent les faits relevés par le dernier audit du serveur MCP, sans envoyer de nouvelle requête au serveur. L’évaluation est relancée après chaque audit dont le résultat change, et au moins tous les 30 jours.
Chaque règle automatique regroupe plusieurs contrôles. Sa sortie, visible dans l’onglet « Conformité » de l’actif, les détaille un par ligne, avec leur verdict et leur constat :
- un contrôle est conforme, non conforme, ou non évalué quand l’audit ne permet pas de conclure
- la règle est en Échec dès qu’un de ses contrôles est non conforme
- elle est en Succès si au moins un contrôle est conforme et aucun non conforme
- sinon, elle est en état Passé
La sortie de la règle rappelle aussi ce qui reste à vérifier manuellement, par exemple dans les journaux du serveur.
Recommandations vérifiées automatiquement
| Règle | Niveau | Contrôles |
|---|---|---|
| CIS-MCP-1.1 | 1 | Le serveur ne sert aucune révision du protocole antérieure à 2025-06-18, et refuse une requête dont la version est inconnue, absente, ou différente entre l’en-tête MCP-Protocol-Version et le corps |
| CIS-MCP-1.4 | 1 | Le serveur déclare son nom et sa version (serverInfo) |
| CIS-MCP-2.2 | 1 | Le serveur refuse le HTTP en clair ou le redirige vers HTTPS, négocie TLS 1.2 ou 1.3, refuse TLS 1.0 et 1.1, et présente un certificat valide |
| CIS-MCP-2.3 | 2 | Une requête anonyme est refusée (HTTP 401 ou 403) |
| CIS-MCP-2.4 | 1 | Une requête sans en-tête Mcp-Method est refusée (HTTP 400, erreur JSON-RPC -32020) |
| CIS-MCP-2.5 | 1 | Une requête dont l’en-tête Origin désigne un site tiers est refusée (HTTP 403) |
| CIS-MCP-3.1.2 | 1 | Une requête anonyme est refusée en HTTP 401, et le jeton JWT de la cible est valable au plus une heure ; un jeton valable plus longtemps est à revoir |
| CIS-MCP-3.2.2 | 1 | L’audience du jeton JWT de la cible désigne ce serveur ; une audience étrangère est à revoir |
| CIS-MCP-3.3.1 | 1 | L’audience du jeton JWT de la cible désigne ce serveur ; une audience étrangère est non conforme |
| CIS-MCP-3.3.2 | 2 | Les métadonnées OAuth sont servies en HTTPS, désignent l’endpoint comme ressource, annoncent au moins un serveur d’autorisation, et l’issuer de chacun correspond à son adresse |
| CIS-MCP-5.1.1 | 1 | Les schémas d’entrée et de sortie de chaque tool sont des schémas JSON valides |
| CIS-MCP-5.1.2 | 1 | Chaque template de resource déclare son type MIME |
| CIS-MCP-5.1.3 | 1 | Chaque argument de prompt est nommé, et son attribut required éventuel est un booléen |
| CIS-MCP-5.2.3 | 1 | Le serveur refuse les requêtes GET et DELETE (HTTP 405) et n’émet aucun en-tête Mcp-Session-Id |
| CIS-MCP-7.1.2 | 1 | Une requête dont l’identifiant JSON-RPC est null est refusée (HTTP 400, erreur JSON-RPC -32600) |
| CIS-MCP-10.1 | 1 | La réponse à tools/list porte Cache-Control: no-store ou private |
Les règles 5.1.1, 5.1.2 et 5.1.3 produisent une ligne par tool, template ou prompt, et la règle 3.3.2 une ligne par serveur d’autorisation. La règle 3.3.2 est sans objet pour un serveur qui ne publie pas de métadonnées OAuth et n’exige pas d’authentification.
Les en-têtes Mcp-Method et les sessions sans état n’existent qu’à partir de la révision 2026-07-28 du protocole : sur un serveur plus ancien, les contrôles correspondants sont non évalués, et les règles 2.4 et 5.2.3 sont en état Passé.
Jeton JWT de la cible
Les règles 3.1.2, 3.2.2 et 3.3.1 lisent le jeton configuré dans l’authentification HTTP Bearer de la cible, s’il s’agit d’un JWT. Cyberwatch décode localement son audience (aud) et sa durée de validité (iat, exp), sans vérifier sa signature ni le transmettre ailleurs qu’au serveur audité.
Sans jeton JWT, par exemple avec un jeton opaque, ces contrôles sont non évalués.
Recommandations à vérifier manuellement
Les 39 autres recommandations ne peuvent pas être vérifiées par un audit à distance de l’endpoint. Elles portent notamment sur :
- le client et l’hôte MCP (section 4 du benchmark)
- les serveurs locaux en stdio
- les données traitées par le serveur (section 6)
- sa chaîne d’approvisionnement (section 8) et son isolation (section 9)
- ses journaux
- des listes approuvées propres à votre organisation, par exemple les capacités ou les tools autorisés
- des contrôles qui exigeraient d’appeler un tool, de lire une resource ou d’obtenir un prompt
Ces règles sont en état Passé, avec la mention « Manual verification required » suivie de la raison. La fiche de chaque règle reprend la procédure d’audit du CIS.
Une fois une recommandation vérifiée, il est possible d’ignorer la règle et de commenter ce choix.