Table des Matières

1. Objectifs et Résumé de la Leçon

2. Introduction au Secure SDLC

3. Étapes du SDLC et Contrôles de Sécurité Associés

   • Phase de Planification

   • Phase de Conception

   • Phase de Codage

   • Phase de Tests et Intégration

   • Phase de Déploiement et Exploitation

4. Exemples Concrets de Sécurité “Shift Left” dans le SDLC

   • Utilisation d’Outils SAST, SCA dès la Phase de Codage

   • Validation des Architectures et Threat Modeling en Conception

5. Choix d’Outils et Méthodes pour Chaque Étape

   • Scanners de Vulnérabilités, Revue de Code, Tests Dynamiques, etc.

6. Mise en Place Pratique : Rôles, Communication et Automatisation

   • Organisation des Responsabilités

   • Collaboration Inter-équipes

   • Automatisation des Contrôles dans les Pipelines

7. Études de Cas sur un SDLC Sécurisé

   • Exemple 1 : Développement d’une Application Web Critique

   • Exemple 2 : Conformité aux Exigences (RGPD, PCI-DSS, etc.)

8. Exercices Pratiques et Corrigés

   • Exercice 1 : Elaborer un Secure SDLC Simplifié

   • Exercice 2 : Threat Modeling Basique (Data Flow Diagram)

9. Quiz de Révision

10. Conclusion et Prévisualisation de la Leçon 4

1. Objectifs et Résumé de la Leçon

Objectifs :

• Approfondir le concept de Secure SDLC et comprendre comment insérer la sécurité à chaque phase.

• Illustrer la contribution de chaque acteur (Dev, Sec, Ops) tout au long du cycle.

• Mettre en évidence les outils et contrôles à mettre en place lors de la conception, du codage, du test et du déploiement.

• Proposer des exemples d’automatisation pour assurer la visibilité et la détection précoce des failles.

Résumé :
Cette leçon aborde le cycle de vie de développement logiciel (SDLC) en y intégrant les tests et validations de sécurité nécessaires pour construire une application robuste. On montrera comment, à chaque étape (planification, conception, codage, tests, déploiement, exploitation), on peut insérer des check-lists, des scans ou des validations pour détecter et corriger les vulnérabilités le plus tôt possible. Des cas d’entreprise et des exercices viendront renforcer la mise en pratique.

2. Introduction au Secure SDLC

Le Secure SDLC (Software Development Life Cycle) est un cadre qui injecte des pratiques de sécurité dans chacune des phases de création logicielle. Là où un SDLC classique prévoit la planification, la conception, la réalisation (codage), les tests et la mise en production, le Secure SDLC y ajoute :

• Des activités de revue ou de validation spécifiques (ex. menaces, conformité, performance).

• Des rôles et responsabilités orientés sécurité.

• Une automatisation pour éviter la régression et renforcer la confiance.

Le DevSecOps s’appuie fortement sur ce concept, car il exige que les contrôles de sécurité (tests statiques, dynamiques, composition analysis, scanning conteneurs, etc.) soient réalisés dès la phase de développement et en continu.

3. Étapes du SDLC et Contrôles de Sécurité Associés

Phase de Planification

• Objectif : Définir les besoins, les risques, et les exigences fonctionnelles et de sécurité.

• Contrôles de Sécurité :

  • Brainstorming sur les menaces potentielles (Threat Modeling préliminaire).

  • Choix des normes de sécurité (ex. ISO 27001, PCI-DSS) à respecter.

  • Mise en place des rôles (champion sécurité, équipe DevSecOps, etc.).

Phase de Conception

• Objectif : Concevoir l’architecture logicielle, les modules, et les interfaces.

• Contrôles de Sécurité :

  • Threat Modeling approfondi : Data Flow Diagrams, identification des assets critiques, scenario d’attaque.

  • Policy as Code : Définir des règles OPA (Open Policy Agent) ou mettre en place des check-lists d’architecture sécurisée.

  • Revue d’architecture : Validation par l’équipe Sec + Dev.

Phase de Codage

• Objectif : Écriture du code, mise en place des librairies, tests unitaires basiques.

• Contrôles de Sécurité :

  • SAST (Static Application Security Testing) : SonarQube, Fortify, Semgrep.

  • SCA (Software Composition Analysis) : Nexus IQ, Snyk, etc.

  • Revues de code par pairs, correction rapide des alertes critiques.

Phase de Tests et Intégration

• Objectif : Tests fonctionnels, performances, sécurité avant de pousser en staging.

• Contrôles de Sécurité :

  • DAST (Dynamic Analysis Security Testing) : OWASP ZAP, Burp Suite sur l’environnement de staging.

  • Container Scanning (Trivy, Clair) si on utilise Docker.

  • IaC scanning (Checkov, tfsec) si on décrit l’infra en Terraform, Ansible.

Phase de Déploiement et Exploitation

• Objectif : Lancement en production, suivi et maintenance.

• Contrôles de Sécurité :

  • Monitoring (ELK, Prometheus), détection d’anomalies (Falco).

  • Patch management continu (mise à jour des dépendances, images).

  • Réponse aux incidents : post-mortem, ajustements du pipeline.

4. Exemples Concrets de Sécurité “Shift Left” dans le SDLC

Utilisation d’Outils SAST, SCA dès la Phase de Codage

• Cas d’École : Dès qu’un développeur push son code, un hook Git ou un job CI exécute :

  • SonarQube ou Fortify (SAST) pour scanner le code source.

  • Snyk ou Nexus IQ pour analyser les librairies (SCA).

• En cas de vulnérabilité critique, la merge request est bloquée jusqu’à correction.

Validation des Architectures et Threat Modeling en Conception

• Avant même d’écrire une ligne de code, l’équipe élabore un Data Flow Diagram.

• Passe en revue chaque point d’entrée, vérifie comment les données circulent, identifie les menaces (OWASP Top 10, par ex.).

• Corrige la conception si une faille majeure apparaît (ex. pas de chiffrement de données sensibles, absence de pare-feu applicatif).

5. Choix d’Outils et Méthodes pour Chaque Étape

Scanners de Vulnérabilités, Revue de Code, Tests Dynamiques

• Phase Codage : SonarQube (avec plugin Security), Fortify ou Semgrep.

• Phase Test/Intégration : OWASP ZAP pour du DAST, container scanning (Trivy, Grype).

• Phase Déploiement : Scripts automatisés pour vérifier la configuration (Ansible + check de compliance).

6. Mise en Place Pratique : Rôles, Communication et Automatisation

Organisation des Responsabilités

Il convient d’allouer un champion sécurité par équipe ou squad, qui assurera :

• La mise en place des scans,

• La remontée des vulnérabilités,

• La coordination avec l’équipe Sec globale.

Collaboration Inter-équipes

On conseille des rituels (stand-up avec un point sec, post-mortem partagé en cas d’incident). Les développeurs reçoivent rapidement les alertes, les Ops fournissent les environnements de tests de sécurité, la Sec valide la conformité.

Automatisation des Contrôles dans les Pipelines

Chaque étape du SDLC est soutenue par un job dans Jenkins, GitLab CI ou GitHub Actions :

• Script de compilation,

• Script SAST (ex. semgrep –config path-to-rules .),

• Script DAST (docker run zap -t http://…),

• Script container scanning (trivy image …).

Le tout génère des rapports, archive les logs, et envoie des notifications s’il y a blocage.

7. Études de Cas sur un SDLC Sécurisé

Exemple 1 : Développement d’une Application Web Critique

• En phase de planification, définition des use cases et des menaces associées (ex. injection SQL, XSS).

• En conception, mise en place d’un design pattern sécurisant (authentification par token, cryptage des données au repos).

• En codage, SAST (SonarQube) et SCA (Nexus IQ) pour éviter les librairies vulnérables.

• En tests, un pipeline exécute un DAST (ZAP) sur l’environnent de QA.

• En exploitation, surveillance (ELK) + alertes Falco sur conteneurs.

Exemple 2 : Conformité aux Exigences (RGPD, PCI-DSS, etc.)

• Planification : Lister les obligations légales (ex. RGPD si données personnelles).

• Conception : Ajouter un module d’anonymisation ou de chiffrement pour les données sensibles.

• Codage : Revues de code spécifiques pour éviter toute fuite de données (SAST + regles semgrep RGPD).

• Tests : Vérification dynamique (DAST) que les endpoints ne retournent pas de data sensible en clair.

• Exploitation : Mise en place d’un plan de réponse aux incidents data breach.

8. Exercices Pratiques et Corrigés

Exercice 1 : Elaborer un Secure SDLC Simplifié

Objectif : Proposer un mini-SDLC (5 étapes) avec les contrôles de sécurité à chaque étape.

1. Consigne : Rédiger 1 page décrivant : Planification, Conception, Codage, Test, Déploiement. Identifier les scans ou validations correspondant à chaque phase.

2. Corrigé :

   • Planification : Brainstorming menaces, menaces majeures listées (X, Y, Z).

   • Conception : Threat Modeling, checklist d’architecture sécurisée.

   • Codage : SAST, analyse dépendances.

   • Test : DAST, container scanning.

   • Déploiement : contrôle config infra (Ansible-lint, Terraform-lint).

Exercice 2 : Threat Modeling Basique (Data Flow Diagram)

Objectif : Créer un diagramme de flux de données (Data Flow Diagram) pour une application web simple et lister 3 menaces principales.

1. Consigne : Décrire les flux (utilisateur → frontend → backend → base de données) et repérer 3 points d’entrée.

2. Corrigé :

   • Existence d’une menace d’injection SQL si le backend ne filtre pas les requêtes.

   • Risque de XSS si le frontend ne nettoie pas les inputs.

   • Chiffrement absent sur les connexions vers la base de données (risque Man-in-the-Middle).

9. Quiz de Révision

1. Pourquoi le “Secure SDLC” est-il important dans le cadre DevSecOps ?

2. Donnez deux exemples de contrôles de sécurité à la phase de codage.

3. Qu’est-ce que le Threat Modeling et à quelle étape doit-il être réalisé ?

4. Citez un outil pour l’analyse statique et un outil pour l’analyse dynamique.

5. À quel moment effectue-t-on un container scanning ?

(Proposez 5 à 10 questions au total.)

10. Conclusion et Prévisualisation de la Leçon 4

Conclusion de la Leçon 3

Dans cette Leçon 3, nous avons détaillé comment intégrer la sécurité à chaque étape du cycle de vie logiciel (SDLC) pour créer un Secure SDLC. Les concepts de Shift Left, de menaces (Threat Modeling), et l’utilisation d’outils automatisés sont au cœur du DevSecOps. Les exemples pratiques ont montré que la détection précoce des vulnérabilités réduit considérablement les coûts et les risques, tout en améliorant la qualité finale.

Prévisualisation de la Leçon 4

Dans la Leçon 4 (environ 50 pages), nous aborderons la configuration d’un environnement sécurisé (IDE, Git, gestion des secrets) et la mise en place pratique de la traçabilité du code, depuis la phase de commit jusqu’à la gestion des secrets dans des projets plus avancés, incluant la protection des clés, la rotation, et la configuration de l’IDE avec des plugins de sécurité.