Évaluation & Travaux : DevSecOps (3 jours)¶

Établissement : Sup de Vinci
Promotions : B3 (tronc commun), Mastère Cybersécurité M2, Mastère DevOps M2 (sessions à des dates distinctes)
Volume horaire : 21 heures (3 journées de 7 heures)
Projet fil rouge : https://github.com/Momotoculteur/securepay-api

Modalités d'Évaluation¶

Pour les M2, le livrable réalisé pendant le module alimente le Dossier écrit individuel de la certification (MSPR 1.1 pour la Cybersécurité, MSPR 4.1 pour le DevOps), évalué par le jury.

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

Philosophie de l'Épreuve¶

Le même questionnaire est proposé aux trois promotions. Les questions vont des fondamentaux aux notions plus avancées, et portent toutes sur ce qui a été présenté et pratiqué pendant les trois jours.

L'objectif est de vérifier que vous savez :

1. Expliquer la démarche DevSecOps et la place de la sécurité dans un pipeline.
2. Reconnaître les vulnérabilités fréquentes et les risques d'une architecture.
3. Choisir et interpréter les outils d'analyse : secrets, SAST, SCA, SBOM, conteneurs, IaC.
4. Définir des contrôles automatisés justifiés par les risques, et les relier aux standards.

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

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

1. DevOps, CI/CD & démarche DevSecOps

• DevSecOps : la sécurité intégrée à chaque étape, automatisée et partagée entre les équipes.
• CI/CD : intégration continue, livraison et déploiement continus, rôle d'un pipeline.
• Shift Left : pourquoi corriger tôt coûte moins cher.

2. Risques & vulnérabilités fréquentes

• CVE et CVSS : identifier une vulnérabilité, mesurer sa sévérité, et les limites de ce score.
• OWASP Top 10 : injections, configuration défaillante, composants vulnérables.
• Dépendances : pourquoi une bibliothèque vulnérable rend l'application vulnérable.

3. Architecture, flux & modélisation des menaces

• Diagramme de flux de données : composants, flux, données sensibles, frontières de confiance.
• STRIDE : les six catégories de menaces.
• BPMN et UML : ce que révèlent un processus métier et un diagramme de séquence.
• Document de conception technique : traiter la sécurité dès la conception.

4. Secrets

• Fuite de secret : pourquoi la révocation est la priorité.
• Gitleaks : expressions régulières et entropie, analyse de tout l'historique.
• Stockage : variables masquées et protégées, gestionnaire de secrets, hook pre-commit.

5. Analyse statique (SAST)

• Principe : analyser le code sans l'exécuter, localiser la ligne en cause.
• Linter vs SAST : qualité du code ou vulnérabilités exploitables.
• Faux positifs et règles personnalisées : justifier, exclure au plus près, encoder les risques propres au projet.

6. Dépendances, SBOM & chaîne d'approvisionnement

• SCA : dépendances directes et transitives confrontées aux vulnérabilités connues.
• SBOM : contenu, formats (CycloneDX, SPDX), utilité quand une nouvelle CVE est publiée.
• Supply chain : typosquatting, outils compromis, épinglage des versions.

7. Conteneurs & infrastructure as code

• Image : utilisateur non-root, build multi-stage, image minimale, analyse avec trivy image.
• IaC : erreurs de configuration détectées avant le déploiement (Trivy, Checkov), base de données exposée.

8. Pipeline, Quality Gates & standards

• Quality Gates : bloquer ce qui est critique, justifier et revoir les seuils.
• Standards : OWASP Top 10, CIS Benchmarks, ISO 27001, recommandations de la CNIL.
• DAST et IAST : ce qu'ils voient de plus que le SAST.
• Analyse différentielle : en Merge Request, ne bloquer que les nouveaux constats ; traiter la dette existante à part.

2. Travaux Pratiques & Livrables (non notés)¶

Contexte : SecurePay Solutions¶

SecurePay Solutions est une FinTech qui fournit une API de paiement aux sites de commerce en ligne. Son dépôt securepay-api a été écrit vite, sans contrôle de sécurité. Un audit externe s'annonce. Votre mission est de comprendre les risques du projet, de cartographier son architecture et ses flux, puis d'automatiser la détection des failles et de proposer un plan de correction.

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

Les travaux pratiques¶

Chaque TP du programme précise ce que chaque promotion pousse plus loin.

Livrable B3 : rapport de sécurité et restitution¶

Rapport de sécurité de SecurePay (4 à 6 pages) :

1. Contexte : l'application, ses composants, son flux de paiement (un schéma).
2. Constats : tableau des failles trouvées (à la main et par les outils), avec gravité et emplacement.
3. Outils : ce que chaque scanner a détecté, ce qu'il a raté, ses faux positifs.
4. Corrections réalisées : pipeline bloquant, Dockerfile durci, et leur effet mesuré (nombre de vulnérabilités, taille d'image).
5. Recommandations : ce qui reste à faire, par ordre de priorité.

Restitution orale (5 minutes par binôme, non notée) : « comment j'ai sécurisé mon projet ? » Montrez un constat, l'outil qui le détecte, et le pipeline qui le bloque.

Livrable M2 Cybersécurité : analyse des architectures logicielles (B1C4)¶

Section « Analyse des architectures logicielles » du Dossier écrit individuel du Bloc 1 (MSPR 1.1) :

1. Document de conception technique (DCT) : composants, choix technologiques, dépendances externes, exigences de sécurité.
2. Cartographie des flux de données : flux du paiement et de l'authentification, données sensibles, frontières de confiance. La fiche exige que les flux soient « cartographiés avec précision ».
3. Modélisations produites avec un logiciel dédié (draw.io, StarUML) :
   • processus de paiement en BPMN ;
   • diagramme de séquence UML de l'authentification et du paiement ;
   • diagramme de déploiement UML.
4. Points faibles de la topologie : menaces STRIDE par flux, vulnérabilités potentielles, priorisation.
5. Chaîne d'approvisionnement logicielle : lecture du SBOM, composants critiques, vulnérabilités connues, plan de suivi.
6. Infrastructure as Code : tests de conformité et étanchéité des environnements.

Conseil certifiant de la fiche : fournir une cartographie précise des flux et une modélisation BPMN ou UML pour valider rigoureusement la compétence B1C4.

Livrable M2 DevOps : gouvernance et alignement DevSecOps (B5C1, B5C2, B5C4)¶

Section « Gouvernance et alignement DevSecOps » du Dossier écrit individuel du Bloc 5 (MSPR 4.1) :

1. Registre des risques de SecurePay et chaîne de traçabilité risque → contrôle → preuve.
2. Choix des outils SAST, DAST et IAST, justifiés par les risques identifiés (et non par leur popularité), avec leur place dans le cycle de livraison.
3. Quality Gates : matrice contrôle, seuil, risque couvert, preuve ; stratégie MR (scans différentiels) et planifiée (scans complets).
4. Stratégie de durcissement alignée sur les standards (OWASP, CIS, NIST, ISO 27001, recommandations de la CNIL) : tableau exigence → référentiel → contrôle → outil.
5. Pilotage : indicateurs (constats par sévérité, délai de remédiation, faux positifs) et gouvernance des exceptions.

Conseil certifiant de la fiche : le jury évalue la capacité à justifier le choix des outils SAST, DAST et IAST par rapport aux risques identifiés, et à prouver l'efficacité de la stratégie de durcissement au regard des standards de l'industrie.

Grille de retours (non notée)¶

Utilisée par l'intervenant pour les retours en séance, et par les étudiants pour s'auto-évaluer.