Évaluations & Projet Certifiant : M2 DevOps - Mise en Application DevSecOps¶

Établissement : Sup de Vinci
Promotion : Mastère DevOps — M2 (Session 2026-2027)
Titre RNCP : RNCP 40165 - Bloc 5 (option) : Piloter l'alignement stratégique entre architectures et DevSecOps
Contribution certifiante : Source principale de données techniques du Dossier écrit collectif du Bloc 5 (MSPR 4.1).
Volume horaire : 42 heures (6 journées de 7 heures)

Modalités Globales de Validation & Barème¶

L'évaluation de ce module valorise à la fois l'appropriation personnelle des concepts d'ingénierie et la capacité à faire évoluer, défendre et documenter en équipe une plateforme multi-environnements, preuves à l'appui :

pie title Répartition de la note finale du module (100%)
    "QCM Individuel Wayground (40 questions)" : 50
    "Projet Certifiant & Soutenance (trinôme, avec exercice Red Team / Blue Team)" : 50

1. Guide de l'Évaluation QCM (50%)¶

Philosophie de l'Épreuve¶

Ce questionnaire évalue vos réflexes d'ingénieurs Platform & Sécurité face aux décisions qui rendent une plateforme gouvernable et défendable : séparer, tracer, détecter, contenir, restaurer. Il ne reprend pas les notions du module Mise en application DevOps, que l'on suppose acquises.

L'objectif est de valider votre maîtrise personnelle :

1. De l'intégration des contrôles de sécurité dans une chaîne multi-environnements (B5C1).
2. De l'automatisation et du pilotage des tests de sécurité applicative (B5C2).
3. De la démonstration de la robustesse des briques de sécurité elles-mêmes (B5C3).
4. Des stratégies de renforcement : secrets, identités, services, données et exécution (B5C4).

Référentiel des 8 Domaines de Révision¶

Les questions portent sur 8 domaines techniques, directement issus des présentations et des TP du module :

1. Environnements Étanches & Supply Chain avant Production

• AppProjects ArgoCD : dépôts sources, destinations et ressources autorisées comme frontière de confiance.
• Fenêtres de synchronisation : encadrer quand un changement peut atteindre la production.
• Quality Gates par environnement : Audit en staging, Deny en production, seuils justifiés par le risque.
• Promotion : le digest validé en staging, jamais une reconstruction ; signature et attestations exigées à l'admission.
• Vulnérabilités émergentes : scan continu des images en cours d'exécution et surveillance des SBOM.

2. Tests de Sécurité Applicative

• DAST sur environnement déployé : pourquoi scanner staging plutôt qu'un conteneur isolé, authentification JWT.
• ZAP Automation Framework : plan YAML versionné, exécution headless, rapports.
• IAST : principe de l'agent dans le runtime, dépendance à la couverture des tests, rareté des faux positifs.
• Optimisation des ressources : scans différentiels sur les MR, scans complets planifiés, parallélisation, cache.
• Non-régression : chaque faille corrigée devient un test automatisé.

3. Gestion des Vulnérabilités

• DefectDojo : agrégation, déduplication, statuts, responsables.
• Gouvernance : faux positifs justifiés et validés, acceptation de risque datée et révisable.
• Indicateurs : délai de remédiation par sévérité, constats hors SLA.
• SBOM et VEX : inventaire durable vs connaissance des vulnérabilités à un instant donné, statuts VEX.

4. Gestion des Secrets

• OpenBao : scellement et descellement, KV v2, politiques, dispositif d'audit et hachage HMAC des valeurs sensibles.
• Étanchéité par environnement : instances, rôles et politiques disjoints, tests négatifs.
• External Secrets Operator : synchronisation, comportement quand le fournisseur est indisponible.
• CI sans secret statique : authentification JWT avec les id_tokens de GitLab et bound_claims.

5. Gouvernance des Identités & Audit

• Profils et séparation des tâches : développeur, opérateur, sécurité, auditeur, compte d'urgence.
• SSO OIDC : groupes GitLab, Dex, politique RBAC d'ArgoCD.
• Moindre privilège des workloads : ServiceAccount dédié, automountServiceAccountToken.
• Politique d'audit Kubernetes : niveaux None, Metadata, Request, RequestResponse et choix pour les secrets.
• Compte d'urgence : conservation, détection de l'usage, rotation.

6. Durcissement des Services, des Données & de l'IaC

• Stockage objet : accès minimal, chiffrement, versioning, verrouillage d'objets (modes governance et compliance).
• Sauvegardes : règle 3-2-1, immuabilité, RPO et RTO, exercice de restauration.
• cert-manager : émission et renouvellement automatiques des certificats.
• IaC cloud : scan avant apply (Trivy, Checkov) et politiques maison (conftest).

7. Sécurité Runtime & Réponse

• Falco : appels système capturés par eBPF, structure d'une règle, enrichissement Kubernetes.
• Falcosidekick : routage des événements vers l'alerting, le stockage et la réponse.
• Réponse proportionnée : confinement réseau plutôt que suppression, conservation des preuves.
• Détection vs prévention : complémentarité avec le contrôle d'admission.
• Couverture : tests de détection rejouables, cartographie MITRE ATT&CK.

8. Robustesse, Chaos des Briques de Sécurité & Exercice

• Webhooks d'admission : failurePolicy Fail vs Ignore, compromis sécurité/disponibilité.
• Security Chaos Engineering : fautes injectées dans les contrôles ou simulant un attaquant.
• Limitation de débit : réponses 429 et protection du SLO des clients légitimes.
• Autoscaling métier : HPA sur le débit de requêtes plutôt que sur le CPU.
• Exercice Red Team / Blue Team : temps de détection, temps de confinement, cause racine, preuves.

2. Projet Certifiant & Soutenance Orale (50%)¶

Contexte Métier & Enjeux¶

Trois mois après la levée du gel, la plateforme SecurePay tient la charge et se répare seule. Le comité sécurité a pourtant ouvert une revue après une série d'événements :

• Compte compromis : le compte GitLab d'un développeur, hameçonné, a servi à tenter une lecture des secrets de production.
• Secrets partagés : un jeton prévu pour les tests permettait de lire la clé Stripe de production.
• CVE découverte par un client : une vulnérabilité critique publiée après le déploiement est restée trois semaines en production, faute de surveillance continue.
• Fatigue d'alerte : 1 400 constats de scanners non triés, que plus personne ne lit.
• Minage silencieux : un conteneur compromis chez un partenaire a miné de la cryptomonnaie pendant trois jours sans être détecté.
• Rançongiciel : un partenaire a perdu ses sauvegardes, chiffrées avec le reste de son infrastructure.
• Audit PSSI : l'auditeur demande de prouver, pour chaque environnement, qui a accès à quoi et qui a fait quoi.

Votre Mission¶

En tant qu'équipe Platform & Sécurité, vous faites évoluer votre plateforme vers une architecture multi-environnements, gouvernée et défendue : environnements étanches, tests de sécurité pilotés, secrets et identités maîtrisés, stack durcie de bout en bout, détection et réponse à l'exécution. Vous en apportez la preuve par des tests de stress, de défaillance et d'attaque simulée.

Chaque trinôme repart de sa plateforme du module DevOps. Un trinôme qui n'en disposerait pas repart des deux dépôts de départ :

git clone https://github.com/Momotoculteur/securepay-api.git
git clone https://github.com/Momotoculteur/securepay-platform.git

Architecture Cible¶

flowchart LR
    MR["Merge Request"] --> CI["Pipeline securepay-api\nSAST diff · Tests · Build\nScan · SBOM · Cosign"]
    CI -->|"rapports"| DOJO["DefectDojo"]
    CI -->|"JWT OIDC"| BAOS
    CI -->|"MR staging"| GITOPS["securepay-platform"]
    GITOPS -->|"pull"| ARGO["ArgoCD + Dex\n(SSO GitLab)"]
    subgraph K3D["Cluster k3d"]
        ARGO --> STG["securepay-staging"]
        ARGO -->|"MR de promotion\n(même digest)"| PRD["securepay-prod"]
        BAOS["OpenBao staging"] -->|"ESO"| STG
        BAOP["OpenBao prod"] -->|"ESO"| PRD
        KYV{"Kyverno\nsignature + attestations"} --> PRD
        FALCO["Falco → quarantaine"] --> PRD
        VELERO["Velero"] --> S3["Stockage objet\nverrouillé"]
    end
    DAST["ZAP authentifié\n+ IAST"] --> STG

Spécifications Techniques Attendues¶

1. Environnements Étanches & Intégrité de la Supply Chain (Compétence B5C1)

• Audit de reprise de la plateforme existante (docs/reprise.md) et registre des risques v2 (au moins 6 nouveaux risques).
• Environnements securepay-staging et securepay-prod générés par ApplicationSet, un AppProject par environnement (sources, destination et ressources autorisées), fenêtre de synchronisation en production.
• Aucun flux réseau entre environnements, prouvé par test négatif.
• Matrice des Quality Gates par environnement (docs/quality-gates.md) : contrôle, seuil staging, seuil production, risque couvert.
• Promotion vers la production du digest validé en staging, par Merge Request, sans reconstruction.
• Admission en production conditionnée à la signature de la pipeline et aux attestations SBOM et de scan ; staging en mode Audit.
• Scan continu des images en cours d'exécution (Trivy Operator) ; surveillance des SBOM par Dependency-Track en option.

2. Tests de Sécurité Applicative & Gestion des Vulnérabilités (Compétence B5C2)

• DAST authentifié (JWT) sur l'environnement de staging déployé, décrit par un plan ZAP Automation Framework versionné, incluant un scan d'API à partir d'une définition OpenAPI.
• IAST : agent commercial en version d'essai, ou à défaut corrélation documentée d'une attaque DAST avec la trace OpenTelemetry de la requête.
• Stratégie d'optimisation des ressources : scans différentiels sur les MR, scans complets planifiés, gain de temps de pipeline mesuré.
• Tests de non-régression pour chaque faille corrigée.
• DefectDojo alimenté automatiquement par la CI : déduplication, triage, faux positifs justifiés, acceptations de risque datées, SLA par sévérité et indicateurs (docs/vulnerabilites.md), au moins un document VEX justifié.

3. Gestionnaire de Secrets Distinct par Environnement (Compétence B5C4)

• Une instance OpenBao par environnement, clés de descellement hors du dépôt et procédure documentée.
• Moteur KV v2, politiques minimales, authentification Kubernetes liée au ServiceAccount de chaque environnement, External Secrets Operator avec un SecretStore par namespace.
• Rotation d'un secret de production sans redéploiement manuel, temps de propagation mesuré.
• Authentification JWT de la CI sur OpenBao (bound_claims sur le projet et la branche protégée) ; plus aucun secret statique correspondant dans les variables GitLab.
• Preuve exigée par le jury : tests négatifs prouvant qu'une identité de staging est refusée sur l'instance de production, et journaux d'audit de chaque instance.

4. Gouvernance des Identités & Journaux d'Audit (Compétence B5C4)

• Matrice des profils (docs/identites.md) : développeur, opérateur, sécurité, auditeur, compte d'urgence ; groupe GitLab, droits par environnement et justification.
• SSO GitLab pour ArgoCD (Dex intégré) et Grafana, RBAC ArgoCD par groupe et par AppProject : synchronisation de production réservée au profil opérateur.
• Séparation des tâches : l'auteur d'une MR de production ne peut pas l'approuver seul.
• Politique d'audit de l'API Kubernetes (secrets au niveau Metadata) ; journaux Kubernetes et OpenBao centralisés dans Loki.
• Compte d'urgence stocké hors ligne, utilisation détectée et alertée.
• Tests négatifs de droits (kubectl auth can-i --as) joués en CI.

5. Durcissement des Services, des Données & de l'IaC Cloud (Compétence B5C4)

• Stockage objet SeaweedFS hors du cluster : buckets privés, une identité et une clé par usage, chiffrement, bucket de sauvegarde verrouillé en mode compliance.
• Sauvegardes Velero planifiées, chiffrées avec votre propre clé de dépôt, rétention définie et au moins égale à celle du verrou.
• TLS interne par cert-manager (ingress et OpenBao).
• Module Terraform de la cible cloud validé en CI par Trivy et Checkov, et par au moins une politique conftest propre à la PSSI. Aucun apply n'est exigé.

6. Sécurité Runtime & Réponse Automatisée (Compétence B5C4)

• Falco (sur tous les nœuds) et Falcosidekick déployés par ArgoCD, routés vers Alertmanager, Loki et Falco Talon.
• Au moins 3 règles maison propres à SecurePay.
• Confinement automatique : un pod qui déclenche une règle critique est isolé du réseau par un label de quarantaine et conservé pour l'analyse.
• Jeu de tests de détection rejouable (security-tests/) et matrice de couverture règle → technique ATT&CK → preuve ; runbook de réponse à incident de sécurité.

7. Robustesse, Chaos des Briques de Sécurité & Reprise après Sinistre (Compétence B5C3)

• Scénarios k6 sur staging puis production : nominal, stress par paliers, pic.
• HPA sur le débit de requêtes (Prometheus Adapter ou KEDA) et limitation de débit par client sur l'ingress (429 sans violation du SLO des clients légitimes).
• Latence d'admission mesurée pendant une rafale de déploiements sous charge.
• Expériences sur les briques de sécurité : perte d'OpenBao de production, perte de Kyverno (comportement selon failurePolicy, puis haute disponibilité), certificat expiré, compromission simulée d'un pod.
• Reprise après sinistre : suppression de securepay-prod et restauration Velero, RTO et RPO mesurés et comparés aux objectifs.
• Preuve exigée par le jury : captures horodatées des tests de stress (k6, Grafana) dans docs/preuves/.

8. Analyse des Défaillances & Dossier Écrit Collectif

• Pour chaque incident simulé : composant défaillant et cause principale établis automatiquement (alertes qualifiées, événements, journaux), chronologie et temps de rétablissement.
• Rapport de résilience v2 (docs/resilience.md) et au moins un postmortem blameless.
• Dossier écrit collectif rédigé au fil des jours (voir ci-dessous).

Évolution du Dépôt Plateforme¶

securepay-platform/
├── apps/                      # + ApplicationSet des environnements, AppProjects staging et production
├── environments/
│   ├── staging/               # Valeurs propres à staging (seuils Audit, ressources réduites)
│   └── production/            # Valeurs propres à la production (seuils Deny, fenêtre de synchronisation)
├── policies/                  # + politiques de production (signature et attestations)
├── security/
│   ├── openbao/               # Configuration, politiques et rôles par environnement
│   ├── falco/                 # Règles maison et routage Falcosidekick
│   └── identity/              # Dex, RBAC ArgoCD et Kubernetes, politique d'audit
├── backup/                    # Velero, stockage objet
├── iac/terraform/             # Cible cloud et politiques conftest
├── security-tests/            # Tests de détection et tests négatifs de droits
├── tests/robustness/          # + scénarios staging/production, rafale de déploiements
└── docs/
    ├── reprise.md             # Audit de reprise de la plateforme
    ├── quality-gates.md       # Matrice des Quality Gates par environnement
    ├── vulnerabilites.md      # SLA, indicateurs, VEX
    ├── identites.md           # Matrice des profils
    ├── exercice/              # Rapport de l'exercice Red Team / Blue Team
    └── preuves/               # Dossier de preuves horodatées

Jalons du Projet¶

Dossier Écrit Collectif (MSPR 4.1)¶

Ce module est la source principale du Dossier écrit collectif du Bloc 5. Le dossier est rédigé au fil des jalons, chaque journée alimentant au moins une section :

1. Contexte, périmètre et architecture de la plateforme.
2. Analyse de risques v2 et gouvernance des contrôles (risque → contrôle → preuve).
3. Chaîne DevSecOps multi-environnements et intégrité de la supply chain (B5C1).
4. Tests de sécurité applicative et gestion des vulnérabilités (B5C2).
5. Gestion des secrets et gouvernance des identités (B5C4).
6. Stratégie de durcissement et sécurité runtime (B5C4).
7. Robustesse et résilience : tests de stress, de défaillance et de reprise, preuves à l'appui (B5C3).
8. Analyse des défaillances et causes racines.
9. Matrice de conformité PSSI et plan d'amélioration.

Format attendu : 20 à 30 pages hors annexes, preuves horodatées en annexe et référencées depuis le corps du texte.

Livrables Attendus¶

Chaque trinôme doit fournir :

1. Avant le jour 6 à 09h00 : les dépôts gelés au tag v2.0.0-exercice.
2. Avant le jour 6 à 13h30 :
   • Les dépôts finaux au tag v2.0.0.
   • Le dossier de preuves complet et indexé.
   • Le rapport de l'exercice Red Team / Blue Team, rédigé en commun avec l'équipe adverse et déposé par MR (docs/exercice/).
   • La version intermédiaire du Dossier écrit collectif, avec toutes les sections amorcées.
   • Le support de soutenance : 8 à 10 slides synthétiques.
3. Au plus tard 7 jours après le jour 6 : la version finale du Dossier écrit collectif (PDF).

Exercice Red Team / Blue Team (Jour 6 - Matin)¶

Deux manches de 40 minutes : chaque trinôme attaque une fois et défend une fois, selon une attribution circulaire communiquée en fin de jour 5. L'exercice se joue en direct sur le poste de l'équipe défenseuse.

Règles d'engagement :

• Seuls les scénarios du catalogue ci-dessous sont autorisés, et uniquement sur les namespaces applicatifs.
• Aucune destruction de données hors du scénario de restauration, aucune action sur la VM ni sur les dépôts.
• L'intervenant arbitre et peut interrompre l'exercice à tout moment.
• L'équipe attaquante horodate chaque action ; l'équipe défenseuse horodate détection, réponse et cause racine.

Catalogue de scénarios et mesures :

Pour chaque scénario, le rapport commun indique le résultat, les mesures, la cause racine établie par la défense et les écarts à corriger.

Modalités de la Soutenance Orale (Jour 6 - Après-midi)¶

• Durée totale : 25 minutes par trinôme.
  • 15 minutes de présentation et Démonstration Live :
    • Présentation synthétique de l'architecture, des risques v2 et des contrôles associés (5 min).
    • Démonstration en direct (10 min) : l'intervenant choisit un scénario parmi les suivants, et le trinôme doit prouver en direct que le contrôle tient, que l'événement est détecté et que la cause est établie :
      • lecture d'un secret de production refusée depuis staging ;
      • image non attestée refusée en production ;
      • compromission simulée détectée et confinée.
  • 10 minutes d'échanges techniques :
    • Questions individuelles de l'intervenant sur les choix d'implémentation, les compromis sécurité/disponibilité, les résultats de l'exercice et la conformité RNCP.

Grille d'Évaluation & Barème (/20)¶

Preuves exigées par le jury : en l'absence des captures des tests de stress, le critère 5 est plafonné à la moitié de ses points. En l'absence de preuve d'un gestionnaire de secrets distinct par environnement, le critère 3 est plafonné de la même façon.

Modulation individuelle : la note de groupe est modulée de ± 2 points par étudiant selon ses réponses aux questions individuelles et sa contribution visible dans l'historique Git et dans le dossier collectif.

Bonus (plafonnés à + 2 points, note finale plafonnée à 20)¶