Certains serveurs sur HostedMCP portent un badge Verified. Cette page explique précisément ce que ce badge mesure, afin que vous puissiez décider de l'importance que vous souhaitez lui accorder.
Verified signifie qu'un serveur a passé nos contrôles automatisés, version 2, sur son dépôt public, ses packages, ses dépendances, ses descriptions d'outils et son endpoint. Cela ne signifie pas qu'une personne a examiné le code, et nous n'exécutons jamais le serveur en votre nom. Considérez cela comme « aucun problème évident détecté dans les données publiques », et non comme une garantie de sécurité.
Les vérifications
Nous effectuons onze vérifications, une fois par semaine et chaque fois que le README ou les packages d'une fiche changent. Chaque résultat conserve sa preuve ainsi qu'un lien vers la source publique d'origine, afin que vous puissiez effectuer vos propres vérifications.
| Groupe | Vérification | Poids | Source | Motif d'échec |
|---|---|---|---|---|
| Origin | Dépôt source | 10 | GitHub | un package sans dépôt lié, ou un dépôt inaccessible |
| Origin | Nom du package identique au dépôt | 5 | npm, PyPI | les métadonnées du package pointent vers un dépôt différent |
| Origin | Provenance du build | 10 | Sigstore attestations sur npm et PyPI | ne compte que lorsqu'une attestation existe ; son absence n'est pas considérée comme une anomalie |
| Origin | Licence | 5 | GitHub, SPDX | absence de licence, ou licence non approuvée par l'OSI |
| Practices | Maintenance | 5 | GitHub | aucun commit ni aucune release au cours des 365 derniers jours |
| Practices | OpenSSF Scorecard | 15 | OpenSSF | un score inférieur à 7 sur 10 impacte le poids, proportionnellement au score |
| Supply chain | Nom du package | 10 | notre liste de packages populaires | un nom à une ou deux lettres d'un package populaire appartenant à un autre propriétaire |
| Supply chain | Advisories | 15 | deps.dev, OSV | une advisory critique dans le package ou dans n'importe quelle dépendance résolue de cette version |
| Tool safety | Instructions cachées | 15 | descriptions des outils, README | texte ciblant le modèle ("ignore previous instructions", blocs <IMPORTANT>), Unicode invisible, ou une description d'outil pointant vers des fichiers comme ~/.ssh |
| Tool safety | Outils destructifs | 5 | annotations des outils | un outil nommé comme delete_*, drop_* ou exec* sans l'annotation destructiveHint |
| Endpoint | Handshake MCP | 5 | une requête en direct de notre part | un endpoint distant en HTTP simple, ou un endpoint qui ne répond pas à initialize |
Calcul du score
Un contrôle n'est comptabilisé que si nous disposons des données nécessaires. Un serveur hébergé n'ayant pas de package, les contrôles relatifs au package, à la provenance et aux avis (advisories) ne s'appliquent pas ; un dépôt n'ayant pas été analysé par Scorecard ne possède pas de résultat Scorecard. Les contrôles ignorés (skipped) ne sont pas déduits du total, de sorte qu'un serveur n'est jamais pénalisé pour un élément que nous n'avons pas pu examiner.
Le score correspond au poids des contrôles réussis par rapport au poids total des contrôles effectués. Pour être considéré comme Verified, un serveur doit répondre aux critères suivants :
- un score de 80 ou plus,
- aucune vulnérabilité critique (nom de package, HTTP non sécurisé, instructions cachées ou avis critique),
- au moins 60 des 100 points contrôlés, afin qu'une fiche ne disposant presque aucune donnée ne puisse être validée par défaut,
- un dépôt source public ayant réussi son contrôle.
Chaque page de serveur liste chaque contrôle avec son résultat, sa preuve, la date de l'exécution et, lorsque Scorecard le précise, le commit concerné. Nous conservons les dix derniers résultats par serveur.
Ce que cela ne vous dit pas
Les vérifications lisent des données publiques et effectuent une seule requête de handshake vers des points de terminaison distants. Elles n'exécutent pas le code d'un serveur et n'auditent pas sa logique. Un serveur peut réussir toutes les vérifications tout en effectuant une action indésirable, et un serveur bien conçu peut échouer si les données dont nous avons besoin ne sont pas publiées. Un serveur officiel provenant du fournisseur du produit est généralement un meilleur gage de confiance que ce badge.
Avant d'installer un serveur local, n'oubliez pas qu'il s'exécute avec les permissions de votre utilisateur. Lisez le code source, privilégiez les serveurs publiés par l'entreprise propriétaire du produit, et attribuez à chacun un token avec l'accès le plus restreint possible. Notre guide de sécurité MCP approfondit ces points.
Un problème ?
Si une vérification a signalé votre serveur par erreur, revendiquez la fiche et informez-nous, ou envoyez un e-mail à legal@hostedmcp.org. Si vous pensez qu'un serveur Verified est préjudiciable, écrivez à la même adresse et nous l'examinerons sous 72 heures.