Roadmap : Sprint sécurité MCP — 4 domaines, 10 chantiers (LIVRÉ ✅)

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.

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)
• 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

3 releases coordonnées prévues, toutes livrées le même jour :

Voir le recap victoire pour le détail.

Tous les commits sont GPG-signés, fingerprint 33133FBFAFFFCA48AFFD3953E34BC7955D46431A :

• github.com/jmrGrav/hugo-mcp v1.9.0
• github.com/jmrGrav/mcp-oauth-proxy v2.1.0
• github.com/jmrGrav/mcp-installer 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, postmortem Cloudflare Bot Mgmt)
• Le projet de webhook Git Strategy 4 (cf. roadmap webhook git) 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é.