Évaluations & Projet Certifiant : M1 DevOps - CI/CD¶

Établissement : Sup de Vinci
Promotion : Mastère DevOps — M1 (Promotion 2026-2027)
Titre RNCP : RNCP 40165 - Bloc 5 (option) : Piloter l'alignement stratégique entre architectures et DevSecOps
Contribution certifiante : Section "Industrialisation et sécurisation des pipelines" pour le Dossier écrit individuel du Bloc 5 (MSPR 4.1).
Volume horaire : 28 heures (4 journées de 7 heures)

Modalités Globales de Validation & Barème¶

L'évaluation de ce module est conçue pour valoriser à la fois l'appropriation personnelle des concepts d'ingénierie et la capacité à concevoir et défendre en équipe une usine logicielle sécurisée répondant aux exigences strictes d'une PSSI :

pie title Répartition de la note finale du module (100%)
    "QCM Individuel Wayground (40 questions)" : 50
    "Projet Certifiant MSPR & Soutenance Orale" : 50

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

Philosophie de l'Épreuve¶

Ce questionnaire n'est pas un test de mémorisation théorique : il évalue vos réflexes d'ingénieurs DevOps / Platform face à des situations concrètes d'architecture, de configuration et de production.

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

Pour vous préparer efficacement, voici la cartographie des sujets abordés, tous directement issus de vos manipulations lors des travaux pratiques :

1. Fondations CI/CD & GitLab CI

• Ordonnancement des pipelines : Déclaration et séquencement des stages:, exécution parallèle des jobs d'un même stage.
• Cache vs Artifacts : Différence d'usage cruciale (optimisation best-effort pour accélérer les dépendances node_modules vs transmission garantie de fichiers distribuables entre stages).
• Runners & Sélecteurs : Typologie des runners (partagés vs dédiés), ciblage par tags:, exécuteurs conteneurisés.
• Variables de CI : Utilisation des variables masquées (Masked) et protégées (Protected), règles de filtrage dans les logs.
• Gestion des échecs : Rôle de la directive allow_failure: true pour les contrôles non bloquants.
• Stratégie de branching : Principes du Trunk-Based Development (branches courtes, intégration continue quotidienne, Feature Flags) vs Git Flow.

2. Conteneurisation Industrielle & Docker dans la CI

• Multi-stage Builds : Pourquoi et comment isoler l'étape de compilation (outils lourds, devDependencies) de l'image de production finale.
• Images de base minimales : Intérêt de choisir des images Alpine ou Distroless (réduction drastique de la surface d'attaque et des CVE).
• Sécurité du runtime conteneur : Principe de moindre privilège et déclaration systématique d'un utilisateur non privilégié (USER non-root).
• Isolation Docker en CI : Risques d'évasion de conteneur liés au montage du socket /var/run/docker.sock par rapport à des approches isolées (dind / k8s).
• Mise en cache BuildKit : Optimisation des builds sur des runners éphémères via --cache-from.
• Variables de registre : Exploitation de $CI_REGISTRY_IMAGE et $CI_COMMIT_SHORT_SHA.

3. Pyramide des Tests & Feedback Loop

• Pyramide des tests : Pourquoi les tests unitaires doivent être majoritaires et exécutés en premier (Fail Fast).
• Services éphémères : Démarrage de bases de données ou de caches avec la directive services: (PostgreSQL, Redis).
• Rapports natifs dans GitLab : Export au format JUnit XML (artifacts:reports:junit) pour visualiser l'état des tests dans les Merge Requests.
• Couverture de code (Code Coverage) : Signification de la métrique, configuration du badge et seuils minimaux.
• Exécution conditionnelle : Utilisation de la directive moderne rules: et du filtre changes:.

4. Shift Left & Détection de Secrets

• Philosophie Shift Left : Pourquoi corriger une faille au plus tôt (dès le commit) coûte jusqu'à 100 fois moins cher qu'en production.
• Détection des secrets avec Gitleaks : Détection basée sur les regex de signatures connues et le calcul d'entropie de Shannon.
• Pre-commit hooks vs Pipeline CI : Barrière locale préventive (pre-commit) complétée par la barrière bloquante de la CI.
• Procédure de remédiation : Révocation et rotation immédiate de tout secret committé (un nouveau commit masquant le secret ne suffit jamais).
• Gestion moderne des secrets : Chiffrement asymétrique avec Mozilla SOPS ou injection dynamique via HashiCorp Vault.

5. Analyse Statique de Sécurité (SAST) & Clean Code

• Fonctionnement du SAST : Analyse à froid sur arbres syntaxiques (AST) sans exécution.
• SonarQube / Semgrep : Fichier sonar-project.properties et analyse des flux de données non assainis.
• Quality Gate bloquante : Rôle contractuel de la Quality Gate et interruption du pipeline si de nouvelles vulnérabilités apparaissent.
• Linter vs SAST : Vérification formelle de style et syntaxe (Linter) vs détection de faiblesses exploitables CWE (SAST).
• Gestion des faux positifs : Procédure formelle de justification et validation traçable pour audit PSSI.

6. Software Composition Analysis (SCA) & Vulnérabilités Conteneurs

• SCA vs SAST : Audit des dépendances open source tierces et de leurs CVE publiques vs code source propriétaire.
• Scan de conteneurs avec Trivy : Audit de sécurité des images Docker (trivy image).
• Seuils bloquants : Utilisation du drapeau d'échec (--exit-code 1 --severity CRITICAL).
• SBOM (Software Bill of Materials) : Rôle, valeur pour la traçabilité de la supply chain et standards (CycloneDX, SPDX).
• Mise à jour continue : Rôle d'outils comme Renovate ou Dependabot, et gestion d'exceptions via .trivyignore.

7. Analyse Dynamique (DAST) & Concepts IAST

• Fonctionnement du DAST : Test en boîte noire de l'application vivante via des requêtes HTTP (OWASP ZAP).
• Scan Passif vs Scan Actif : Analyse neutre du trafic légitime vs génération de payloads d'attaques agressifs (injections SQL, XSS).
• Exécution automatisée en CI : Lancement de scripts headless (zap-baseline.py) via l'image conteneurisée officielle.
• Authentification d'API : Injection d'en-têtes de session ou de jetons JWT (Authorization: Bearer <token>).
• Technologie IAST : Fonctionnement par agent d'instrumentation dans le runtime applicatif (analyse de l'intérieur, quasi-zéro faux positif).

8. GitOps, Métriques DORA & Conformité PSSI

• Modèle GitOps (ArgoCD) : Pourquoi le modèle Pull (opérateur interne au cluster) est plus sécurisé que le modèle Push de la CI.
• Métriques DORA : Définition des 4 indicateurs et focus sur le MTTR (Time to Restore Service).
• Conformité & Traçabilité PSSI : Rôle probant de la pipeline CI/CD comme preuve immuable du contrôle des changements lors des audits de sécurité et de conformité.

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

Scénario d'Entreprise : SecurePay Solutions¶

Vous intervenez en tant qu'Ingénieurs Platform & DevSecOps pour le compte de SecurePay Solutions, une FinTech en pleine croissance soumise à des exigences de sécurité et des audits stricts (PSSI d'entreprise).

Actuellement, l'équipe de développement déploie manuellement ses micro-services sur des serveurs Linux via SSH. Des audits récents ont révélé :

• Des clés d'API et secrets cloud codés "en dur" dans l'historique Git.
• Des images Docker massives (> 1.2 Go) tournant en tant que root avec des centaines de vulnérabilités connues (CVE critiques).
• Une absence totale de tests automatisés avant la mise en production.
• Aucune traçabilité des modifications ni barrière de contrôle (Quality Gate).

Votre Mission¶

Concevoir, implémenter et documenter une usine logicielle CI/CD industrielle et inviolable capable de bloquer automatiquement toute livraison non conforme à la PSSI (Politique de Sécurité des Systèmes d'Information).

Les binômes doivent forker ou cloner le dépôt modèle officiel :

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

Architecture du Pipeline Attendu¶

Votre pipeline .gitlab-ci.yml (ou GitHub Actions) devra orchestrer les étapes suivantes de manière ordonnée et optimisée :

flowchart LR
    LINT["1. Lint & Secrets\n(Gitleaks)"] --> TEST["2. Tests Auto\n(Unit & Intégration)"]
    TEST --> SAST["3. Analyse SAST\n(SonarQube / Semgrep)"]
    SAST --> BUILD["4. Build Multi-stage\n(Docker & BuildKit)"]
    BUILD --> SCAN["5. Scan Image\n(Trivy)"]
    SCAN --> DEPLOY["6. Deploy Staging\n(Review App)"]
    DEPLOY --> DAST["7. Scan DAST\n(OWASP ZAP)"]

1. Gestion des Secrets & Pre-commit (Compétence B5C1)

• Mise en place d'un job de détection de secrets basé sur Gitleaks.
• Le job doit échouer immédiatement si un secret ou une clé privée est détecté dans le commit.
• Configuration propre des variables sensibles sous forme de variables Masked et Protected.

2. Pyramide des Tests & Feedback Loop

• Stage de tests unitaires avec calcul du taux de couverture de code (code coverage).
• Stage de tests d'intégration utilisant un service de base de données éphémère (services: PostgreSQL ou Redis).
• Export des rapports au format JUnit XML (artifacts:reports:junit) pour affichage natif dans l'interface de Merge Request.

3. Analyse Statique de Sécurité (SAST & Clean Code)

• Intégration de SonarQube (ou SonarCloud / Semgrep) pour scanner le code source propriétaire.
• Configuration d'une Quality Gate bloquante : le pipeline doit obligatoirement échouer si de nouvelles vulnérabilités de sévérité CRITICAL ou HIGH sont introduites.

4. Build Docker Industriel & SBOM (Supply Chain Security)

• Rédaction d'un Dockerfile multi-stage optimisé :
  • Séparation stricte de l'environnement de build et de l'environnement de runtime.
  • Image finale minimale (Alpine ou Distroless).
  • Exécution sous utilisateur non privilégié (USER 1001 / non-root).
• Utilisation de Docker Buildx / BuildKit avec cache distant (--cache-from).
• Génération d'un inventaire des composants logiciels (SBOM) au format CycloneDX ou SPDX.

5. Scan des Vulnérabilités de l'Image Conteneur avec Trivy (Compétence B5C1)

• Scan de l'image Docker finale construite (trivy image).
• Détection des vulnérabilités au niveau de l'OS de base et des dépendances logicielles embarquées.
• Paramétrage d'un seuil de rupture : si une vulnérabilité CRITICAL est détectée sans correctif disponible, le pipeline s'interrompt avec code retour 1.

6. Déploiement Staging & DAST Automatisé (Compétence B5C2)

• Démarrage automatique du conteneur dans un environnement de test éphémère.
• Exécution d'un scan dynamique en boîte noire avec OWASP ZAP (ghcr.io/zaproxy/zaproxy:stable).
• Récupération du rapport HTML de scan en tant qu'artefact téléchargeable.
• Blocage du pipeline en cas de détection de failles majeures (XSS, injections, en-têtes de sécurité manquants).

Livrables Attendus (Jour 4 avant 13h30)¶

Chaque binôme doit fournir :

1. Le Dépôt Git du Projet :

   • Code source de l'application : initialisé à partir du dépôt modèle officiel Momotoculteur/securepay-api.
   • Fichier .gitlab-ci.yml structuré, factorisé et largement commenté.
   • Dockerfile multi-stage sécurisé.
   • README.md expliquant l'architecture, le déclenchement et les étapes de build local.

2. La Note d'Architecture Sécurité (2 à 3 pages PDF) :

   • Document formalisant l'architecture de sécurité, directement exploitable pour la section Bloc 5 (MSPR 4.1) de votre mémoire de certification.
   • Justification de chaque barrière de sécurité face aux exigences de la PSSI.
   • Tableau de bord des vulnérabilités traitées et plan de remédiation associé.

3. Le Support de Soutenance :

   • 6 à 8 slides synthétiques présentant l'architecture, les choix techniques, les blocages de sécurité et les métriques de pipeline.

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

• Durée totale : 25 minutes par binôme.
  • 15 minutes de présentation et Démonstration Live :
    • Présentation synthétique de l'architecture et des métriques de pipeline (5 min).
    • Démonstration en direct du passage nominal du pipeline complet (5 min).
    • Scénario d'attaque / injection en direct (5 min) : Vous devrez pousser une branche contenant volontairement un faux secret ou une faille critique et prouver en direct devant l'examinateur que votre pipeline bloque net la livraison.
  • 10 minutes d'échanges techniques :
    • Questions de l'intervenant sur vos choix d'implémentation, la conformité RNCP, et la gestion des faux positifs en environnement réel.

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