--- title: "Roadmap : Sprint sécurité MCP — 4 domaines, 10 chantiers (LIVRÉ ✅)" description: "Sprint de hardening LIVRÉ le 9 mai 2026 sur l'infrastructure MCP d'arleo.eu : 10 chantiers en 4 domaines, 3 releases coordonnées (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Page d'archive." url: "https://www.arleo.eu/posts/roadmap-sprint-securite-mcp/" language: "fr" datePublished: "2026-05-09T12:47:59+02:00" dateModified: "2026-05-15T23:51:25+02:00" tags: ["roadmap","security","mcp","hardening"] categories: ["roadmap"] contentSignal: "ai-train=no, search=yes, ai-input=yes" --- # Roadmap : Sprint sécurité MCP — 4 domaines, 10 chantiers (LIVRÉ ✅) Sprint de hardening LIVRÉ le 9 mai 2026 sur l'infrastructure MCP d'arleo.eu : 10 chantiers en 4 domaines, 3 releases coordonnées (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Page d'archive. ## Statut : ✅ LIVRÉ — sprint clos le 9 mai 2026 **Mise à jour 9 mai 2026 (fin de session)** : les 10 chantiers sont livrés en une session marathon, et **les 3 releases coordonnées sont publiées** (`hugo-mcp` v1.9.0, `mcp-oauth-proxy` v2.1.0, `mcp-installer` v1.3.0). Tout l'écosystème MCP est durci dans la même journée. Recap technique complet : [Sprint sécurité MCP livré : v1.9.0, 10 chantiers, écosystème durci](/posts/sprint-securite-mcp-livre/). Cette page reste publiée à fins d'archive — pour montrer la trajectoire d'un sprint annoncé puis tenu. Tout le contenu original ci-dessous est préservé. --- ## Statut original (avant livraison) Cette page documentait publiquement un sprint de hardening en cours sur l'infrastructure MCP d'arleo.eu. Pour des raisons de sécurité, les détails précis des chantiers n'étaient pas exposés tant que les correctifs n'étaient pas livrés (philosophie "sec-first" : ne pas publier de roadmap d'attaque). ## Pourquoi cette transparence J'ai débattu de publier ou non cette page. Arguments pour la transparence : - **Engagement public** = pression saine sur soi-même pour livrer - **Documentation** d'un homelab dont l'objectif est apprendre et partager - **Honnêteté** vis-à-vis des lecteurs qui consomment les autres articles techniques Arguments contre : - **Roadmap d'attaque** : si je liste précisément ce qui n'est pas encore protégé, je donne des indices à un attaquant patient - **Pression artificielle** : annoncer un sprint puis ne pas livrer = pire que ne rien annoncer Compromis adopté : publier la **direction** et les **domaines de hardening** sans préciser ce qui est faible aujourd'hui. Détail technique précis publié à la livraison. ## Domaines couverts par le sprint Le sprint couvrait 10 chantiers regroupés en 4 domaines : ### 1. Hardening applicatif (FastAPI + Pydantic) Renforcement des couches d'entrée du MCP : validation stricte des inputs, gestion d'erreurs unifiée, pas de leak d'information dans les responses (stack traces, paths internes, versions de libs). ### 2. Authentification et tokens Refonte de la gestion des tokens d'accès au MCP : durée de vie, rotation, révocation, hashing en stockage. Permettre de couper l'accès d'un client compromis sans redéployer le service. ### 3. Observabilité et audit Intégration de logs structurés JSON ingérés dans BetterStack via Vector. Chaque appel MCP doit produire un événement traçable : qui, quoi, quand, durée, statut. Permet la détection d'anomalies en quasi-temps réel. ### 4. Infrastructure et résilience TLS pour le trafic interne entre le NUC et la VM, règles ModSec dédiées au path `/mcp`, runbook de récupération en cas de désastre (vol de tokens, compromise serveur, perte de données). ## Ce qui était déjà en place avant le sprint Pour ne pas créer de fausse impression, voici les couches **déjà en place** sur l'infrastructure avant le sprint (donc hors scope) : - nginx + TLS 1.3 obligatoire (Mozilla Modern config) - Cloudflare WAF + Bot Management + IP whitelist - ModSecurity + OWASP CRS 4.x sur tous les vhosts - CrowdSec en mode WAF + bouncer Cloudflare - systemd hardening niveau 1.7 (cf. [hardening systemd](/posts/hardening-systemd-mcp/)) - HMAC validation sur les webhooks - Frontmatter validation Pydantic (1 chantier sur 4 dans la catégorie validation) Le sprint visait à **compléter** cette base, pas à la remplacer. ## Méthode Pour chaque chantier : 1. Implémenté en local + tests unitaires 2. Validé sur `mcp-test-vm` (VM de pré-prod) 3. Déployé sur prod uniquement après tests réussis 4. Audit log structuré JSON pour traçabilité du déploiement 5. Article post-mortem ou write-up technique publié **après** livraison Aucun déploiement direct prod sans étape pré-prod. ## Releases publiées {{< mermaid-svg hash="66124406" >}} 3 releases coordonnées prévues, **toutes livrées le même jour** : | Composant | Version | Statut | |-----------|---------|--------| | `hugo-mcp` | v1.9.0 | ✅ Publié | | `mcp-oauth-proxy` | v2.1.0 | ✅ Publié | | `mcp-installer` | v1.3.0 | ✅ Publié | Voir le [recap victoire](/posts/sprint-securite-mcp-livre/) pour le détail. Tous les commits sont GPG-signés, fingerprint `33133FBFAFFFCA48AFFD3953E34BC7955D46431A` : - [github.com/jmrGrav/hugo-mcp v1.9.0](https://github.com/jmrGrav/hugo-mcp/releases/tag/v1.9.0) - [github.com/jmrGrav/mcp-oauth-proxy v2.1.0](https://github.com/jmrGrav/mcp-oauth-proxy/releases/tag/v2.1.0) - [github.com/jmrGrav/mcp-installer v1.3.0](https://github.com/jmrGrav/mcp-installer/releases/tag/v1.3.0) ## ETA (historique) Démarré le 9 mai 2026. ETA prévue : fin mai 2026. **Réel** : livraison complète le **9 mai 2026 même jour**, en session marathon. ## Pourquoi maintenant Plusieurs déclencheurs convergents : - L'audit interne du code v1.6.0/v1.7.0/v1.8.1 a identifié des manques précis (sans entrer dans les détails ici) - Plusieurs incidents bénins ont mis en lumière des angles morts opérationnels (cf. [postmortem MCP timeouts](/posts/postmortem-mcp-timeouts-cloudflare/), [postmortem Cloudflare Bot Mgmt](/posts/postmortem-cf-bot-blocking-mcp/)) - Le projet de webhook Git Strategy 4 (cf. [roadmap webhook git](/posts/roadmap-webhook-git-rebuild/)) a besoin de plusieurs primitives du sprint (rate limiting, audit logs, validation stricte) avant d'être implémenté Aligner les chantiers sécu avec le besoin court-terme = bon ROI. ## Engagement tenu Le compromis annoncé en amont du sprint (sec-first, transparence sur la direction, détails à la livraison) a été tenu. Aucune information précise sur les vulnérabilités pré-sprint n'a été publiée tant que les correctifs n'étaient pas en prod. Recap complet : [Sprint sécurité MCP livré](/posts/sprint-securite-mcp-livre/). ## Tags - roadmap - security - mcp - hardening ## Categories - roadmap