Sécurité

Open Source — GitScrum MCP Server est open source sous la licence MIT. Disponible sur npm et sur GitHub. Serveur Model Context Protocol pour GitScrum — Claude, GitHub Copilot, Cursor et tout client compatible MCP disposent d'un accès opérationnel complet à votre stack de gestion de projets.

Le serveur MCP de GitScrum repose sur une philosophie de conception axée sur la sécurité. Chaque décision architecturale priorise la sécurité des données, le contrôle d'accès et la protection contre les opérations accidentelles ou malveillantes via les assistants IA. Ce document couvre le modèle de sécurité complet.

Philosophie de conception

Les assistants IA sont des outils puissants, mais ils introduisent une nouvelle catégorie de risque : une IA peut exécuter des opérations plus rapidement et à plus grande échelle qu'un humain cliquant dans une interface. Une instruction mal interprétée comme « nettoie les anciennes tâches » pourrait avoir des conséquences catastrophiques si l'IA a un accès illimité.

Le serveur MCP de GitScrum répond à cela par une défense en profondeur — plusieurs couches de protection indépendantes qui réduisent chacune le risque de manière autonome. Même si une couche échoue, les autres empêchent la perte de données ou l'accès non autorisé.

Principes fondamentaux :

• Sûr par défaut. Les opérations qui détruisent des données sont entièrement bloquées.
• Moindre privilège. Le serveur MCP n'a accès qu'à ce que votre compte GitScrum peut accéder.
• Aucun secret en transit. Les identifiants restent dans le navigateur ; les tokens restent sur votre machine.
• Erreurs transparentes. Les échecs de sécurité produisent des messages d'erreur clairs et exploitables sans exposer les détails internes.

Restrictions sur les opérations

CREATE, READ, UPDATE uniquement

Le serveur MCP applique un modèle d'opérations strict. Seuls trois types d'opérations sont autorisés :

Cette restriction s'applique aux 29 outils et à toutes les plus de 160 opérations. Il n'existe aucun outil, action ou combinaison de paramètres permettant de supprimer des données via le serveur MCP.

Pourquoi aucune opération DELETE

Supprimer des données de projet — tâches, sprints, user stories, dossiers clients — est une action irréversible avec des conséquences potentiellement graves. Lorsqu'un assistant IA interprète une instruction en langage naturel, il existe toujours une probabilité non nulle de mauvaise interprétation. L'instruction « supprime les anciennes tâches du backlog » pourrait signifier archiver, déplacer ou filtrer — pas détruire définitivement.

En bloquant DELETE au niveau MCP, nous éliminons une classe entière de risques :

• Mauvaise interprétation. L'IA ne peut pas supprimer de données même si elle comprend mal l'instruction.
• Injection de prompt. Les prompts malveillants ne peuvent pas déclencher la destruction de données via les outils MCP.
• Erreurs en lot. Une boucle traitant plusieurs éléments ne peut pas dégénérer en suppression massive.
• Portée accidentelle. « Supprime la tâche de test » ne s'étendra pas accidentellement à « supprimer toutes les tâches ».

Les opérations destructives nécessitent l'application web GitScrum, où l'interface exige une confirmation humaine explicite avec un contexte visuel de ce qui sera supprimé.

Défense en profondeur

Les opérations DELETE sont bloquées à plusieurs couches indépendantes :

1. Couche MCP. Aucun outil DELETE n'existe dans le serveur MCP. Le schéma d'outils ne peut physiquement pas exprimer une opération de suppression.
2. Couche API. L'API GitScrum valide l'origine des requêtes et bloque les requêtes DELETE des clients MCP, même si un serveur MCP modifié tentait de les envoyer.
3. Couche authentification. Le contrôle d'accès standard basé sur les rôles s'applique. Les utilisateurs en lecture seule ne peuvent supprimer via aucun canal.

Communication HTTPS uniquement

Toute communication entre le serveur MCP et l'API GitScrum utilise HTTPS :

• TLS 1.2 minimum. Les connexions utilisant des versions TLS plus anciennes sont rejetées.
• Validation de certificat imposée. Le serveur valide la chaîne de certificats SSL de l'API. Les certificats auto-signés ou invalides sont rejetés.
• Aucun repli HTTP. Le serveur ne tente en aucun cas de connexion HTTP non chiffrée.

Cela garantit que les données en transit — tâches, détails de projets, tokens d'authentification — sont chiffrées entre le serveur MCP sur votre machine et l'API GitScrum dans le cloud.

Communication locale

La communication entre le client IA (Claude Desktop, VS Code, Cursor) et le serveur MCP utilise stdio (entrée/sortie standard). Comme les deux processus s'exécutent sur votre machine locale, cette communication ne traverse jamais un réseau. Il n'y a aucune surface d'attaque réseau pour la connexion client-serveur.

Sécurité de l'authentification

OAuth 2.0 Device Authorization Grant

Le serveur MCP s'authentifie via OAuth 2.0 Device Authorization Grant (RFC 8628). Ce flux a été choisi car :

• Aucun identifiant dans le serveur MCP. Votre mot de passe est saisi uniquement dans le navigateur.
• Aucune URI de redirection nécessaire. Les serveurs MCP communiquent via stdio, pas HTTP, donc les flux de redirection OAuth traditionnels ne s'appliquent pas.
• Approbation visible par l'utilisateur. Vous voyez exactement ce qui est autorisé dans le navigateur avant d'approuver.

Pour un guide détaillé du flux d'authentification, consultez Authentification.

Isolation des tokens

Les tokens d'authentification n'existent que dans exactement deux endroits :

1. En mémoire dans le processus du serveur MCP
2. Sur le disque à ~/.gitscrum/auth.json

Les tokens ne sont jamais :

• Envoyés au fournisseur de modèle IA (Anthropic, OpenAI, etc.)
• Inclus dans le contexte ou l'historique de conversation IA
• Affichés dans la console, les fichiers ou les sorties d'erreur
• Transmis à un service tiers

L'assistant IA sait que l'authentification a réussi et quels espaces de travail sont disponibles, mais il n'a aucun accès à la valeur du token elle-même.

Permissions de stockage des tokens

Le fichier de token à ~/.gitscrum/auth.json est créé avec des permissions restreintes :

Cela empêche les autres utilisateurs de la même machine de lire vos tokens d'authentification.

Limitation de débit

Limites de débit API

L'API GitScrum applique des limites de débit pour prévenir les abus et garantir une utilisation équitable pour tous les clients :

• Les requêtes dépassant la limite de débit reçoivent une réponse 429 Too Many Requests
• Le serveur MCP transmet les erreurs de limite de débit à l'assistant IA avec un message clair
• Les limites de débit se réinitialisent automatiquement après la période de refroidissement

Limitation de débit sur l'authentification

Les points de terminaison d'authentification ont une limitation de débit supplémentaire pour prévenir les attaques par force brute :

• Les tentatives échouées de code d'appareil sont comptées par client
• Les échecs répétés déclenchent un verrouillage automatique avec une durée croissante
• Une authentification réussie réinitialise le compteur d'échecs

Gestion des limites de débit

Lorsque la limite est atteinte, l'assistant IA reçoit une erreur claire indiquant que la limite a été atteinte. L'approche recommandée est d'attendre avant de réessayer. Le serveur MCP ne retente pas automatiquement les requêtes limitées, laissant le contrôle total de la logique de nouvelle tentative à l'assistant IA.

Gestion des erreurs

Codes d'erreur standardisés

Le serveur MCP traduit les réponses API en messages d'erreur cohérents et informatifs. Chaque erreur inclut un code de statut, un message lisible par l'humain et suffisamment de contexte pour que l'assistant IA puisse soit récupérer, soit informer l'utilisateur.

Messages d'erreur sécurisés

Les messages d'erreur sont conçus pour être utiles sans exposer d'informations sensibles :

Dégradation gracieuse

Lorsque l'API GitScrum est inaccessible (problèmes réseau, maintenance), le serveur MCP :

1. Retourne une erreur claire à l'assistant IA indiquant que l'API est indisponible
2. Ne met pas en cache des données obsolètes et ne retourne pas de résultats périmés
3. Ne retente pas automatiquement, laissant l'utilisateur décider quand réessayer

Cela garantit que vous n'agissez jamais sur des données de projet obsolètes sans le savoir.

Aucune journalisation des identifiants

Le serveur MCP applique des règles strictes sur ce qui apparaît dans les journaux et la sortie :

Jamais journalisé :

• Mots de passe (le serveur n'y a jamais accès)
• Tokens d'authentification (accès ou rafraîchissement)
• Clés API
• Données personnelles utilisateur au-delà de ce qui figure dans les réponses API

Journalisé pour le débogage (lorsque le mode verbeux est activé) :

• Noms d'outils et actions appelées
• Chemins des points de terminaison API (sans en-têtes d'authentification)
• Codes de statut et messages d'erreur
• Chronométrage requête/réponse

Variables d'environnement

Deux variables d'environnement affectent le comportement de sécurité :

En utilisation en production, aucune de ces variables ne devrait être définie. La configuration par défaut route tout le trafic vers l'API GitScrum officielle via HTTPS.

Bonnes pratiques pour les environnements enterprise

Pour les développeurs

• Maintenez le serveur MCP à jour. Exécutez npx -y @gitscrum-studio/mcp-server pour toujours utiliser la dernière version, qui inclut les correctifs de sécurité.
• Déconnectez-vous sur les machines partagées. Exécutez toujours auth_logout quand vous avez terminé sur une machine accessible par d'autres.
• Ne définissez pas GITSCRUM_TOKEN dans les profils shell. Si nécessaire pour l'automatisation, utilisez un gestionnaire de secrets ou un environnement à portée limitée.
• Examinez les actions de l'IA. Avant de confirmer des opérations qui modifient des données, examinez ce que l'assistant IA propose.

Pour les administrateurs d'espace de travail

• Utilisez le contrôle d'accès basé sur les rôles. Attribuez les rôles appropriés dans GitScrum. Les opérations MCP héritent des permissions du rôle de l'utilisateur.
• Surveillez le journal d'audit. Toutes les opérations MCP sont journalisées côté serveur dans le fil d'activité GitScrum avec l'identité de l'utilisateur.
• Imposez les exigences de plan minimum. Certains outils Insights PRO nécessitent des niveaux de plan appropriés.
• Révisez l'accès aux espaces de travail. Auditez périodiquement qui a accès aux espaces de travail et aux projets.

Pour les équipes sécurité

• Le code source est ouvert. Le code source du serveur MCP est disponible sur GitHub pour examen de sécurité.
• Aucune persistance de données. Le serveur MCP ne stocke localement que le token d'authentification. Aucune donnée de projet n'est mise en cache ou écrite sur le disque.
• Aucun écouteur réseau. Le serveur MCP communique via stdio, pas par sockets réseau. Il n'ouvre pas de ports et n'accepte pas de connexions entrantes.
• Audit des dépendances. Exécutez npm audit sur l'arbre de dépendances du serveur MCP pour détecter les vulnérabilités connues.

Signalement de vulnérabilités

Si vous découvrez une vulnérabilité de sécurité dans le serveur MCP de GitScrum, signalez-la de manière privée :

Email : security@gitscrum.com Objet : [SECURITY] MCP Server Vulnerability

Incluez :

1. Description de la vulnérabilité
2. Étapes pour reproduire
3. Impact potentiel
4. Vos coordonnées

Nous répondons sous 48 heures et travaillons avec vous pour résoudre le problème avant toute divulgation publique.

Checklist de sécurité

Utilisez cette checklist pour vérifier que votre déploiement du serveur MCP est sécurisé :

• [ ] Utilisation de la dernière version de @gitscrum-studio/mcp-server
• [ ] Node.js version 18+ (inclut les correctifs de sécurité)
• [ ] Authentifié via le flux OAuth dans le navigateur (pas par variable d'environnement)
• [ ] ~/.gitscrum/auth.json a des permissions de fichier restreintes
• [ ] GITSCRUM_TOKEN n'est pas défini dans les profils shell
• [ ] GITSCRUMAPIURL n'est pas défini (utilise le point de terminaison de production par défaut)
• [ ] Le journal d'audit est révisé périodiquement dans le tableau de bord GitScrum
• [ ] Les rôles d'espace de travail sont attribués de manière appropriée
• [ ] Le serveur MCP est exécuté depuis un environnement local fiable

Étapes suivantes

• Authentification : Flux détaillé OAuth 2.0 Device Grant et gestion des tokens.
• Configuration : Configuration spécifique par client et référence des variables d'environnement.
• Démarrage rapide : Installez et authentifiez-vous en moins de 5 minutes.
• Présentation du MCP : Référence complète des outils avec les 29 outils et plus de 160 opérations.