Concevoir un module AppSec et SDLC sécurisé pour des étudiants ingénieurs

Pourquoi l'AppSec mérite son propre module

La sécurité applicative est encore trop souvent traitée comme un appendice du pentest, ou réduite à un chapitre consacré aux vulnérabilités OWASP glissé en fin de semestre. Cette approche crée une confusion dommageable : les étudiants apprennent à identifier des failles, mais pas à concevoir des systèmes qui en contiennent structurellement moins.

La distinction est fondamentale. Le pentest est une posture réactive : on cherche des vulnérabilités dans un système existant. L'AppSec — et plus précisément le SDLC sécurisé, le cycle de développement logiciel intégrant la sécurité à chaque étape — est une posture préventive : on construit la sécurité dans le produit dès la conception. Former des ingénieurs à ces deux postures, c'est former des professionnels capables d'agir aussi bien en amont qu'en aval du problème.

Il y a une raison pratique supplémentaire : la majorité des ingénieurs diplômés n'exerceront pas comme pentesteurs. En revanche, la quasi-totalité d'entre eux sera amenée à écrire du code, à concevoir des architectures, à participer à des revues de code ou à collaborer avec des équipes de sécurité. Leur enseigner les fondements de la sécurité applicative, c'est leur donner des compétences qu'ils utiliseront dès leur premier poste, quel que soit le secteur.

L'AppSec s'articule aussi avec les enjeux réglementaires actuels. La directive NIS2 et le Cyber Resilience Act imposent aux équipes de développement des pratiques de sécurité documentées. Un module AppSec solide prépare les étudiants à ces réalités concrètes.

Les concepts fondamentaux à enseigner

Le cycle de vie du développement logiciel sécurisé

Le SDLC sécurisé (Secure Software Development Life Cycle) est le fil conducteur du module. L'idée centrale est simple : chaque phase du développement — de la définition des besoins jusqu'à la mise en production — doit intégrer des activités de sécurité spécifiques.

Les phases à couvrir sont les suivantes :

• Planification et exigences : identification des exigences de sécurité fonctionnelles et non fonctionnelles, définition des niveaux d'assurance requis selon le contexte (données personnelles, paiement, infrastructure critique).
• Conception : modélisation des menaces, définition des contrôles de sécurité architecturaux, choix des mécanismes d'authentification et de chiffrement.
• Développement : application des principes de secure coding, revues de code par les pairs, utilisation de bibliothèques maintenues.
• Test : analyse statique (SAST), tests dynamiques (DAST), tests de pénétration ciblés sur les fonctionnalités sensibles.
• Déploiement : durcissement de l'environnement, gestion des secrets, contrôle des dépendances (SCA).
• Maintenance : processus de gestion des vulnérabilités, suivi des CVE sur les dépendances, plan de réponse aux incidents applicatifs.

Les étudiants ingénieurs ont tendance à se focaliser sur la phase de développement. L'un des objectifs pédagogiques majeurs du module est de leur faire comprendre que la sécurité est plus efficace — et moins coûteuse — quand elle est intégrée dès la phase de conception.

La modélisation des menaces

Le threat modeling est la compétence la plus différenciante que ce module peut apporter. C'est une technique de raisonnement structuré qui permet d'identifier les menaces pesant sur un système avant qu'il soit construit, de prioriser les risques et de définir les contre-mesures appropriées.

La méthode STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) est le point d'entrée recommandé pour des étudiants ingénieurs. Elle est suffisamment structurée pour être enseignée rapidement, et suffisamment complète pour s'appliquer à des architectures réelles.

Le processus se déroule en quatre étapes :

1. Décomposer le système : identifier les composants, les flux de données, les points d'entrée et les actifs sensibles (données, secrets, fonctionnalités critiques).
2. Identifier les menaces : appliquer systématiquement les catégories STRIDE à chaque composant et chaque flux de données.
3. Évaluer le risque : pour chaque menace identifiée, évaluer la probabilité et l'impact — DREAD ou une matrice de risque simplifiée conviennent à ce niveau.
4. Définir les contre-mesures : pour chaque menace prioritaire, proposer un contrôle de sécurité concret (validation côté serveur, token CSRF, journalisation des actions sensibles).

Les principes de secure coding

Les principes fondamentaux du secure coding que tout étudiant ingénieurs doit maîtriser sont :

• Validation des entrées : ne jamais faire confiance à une donnée externe, qu'elle vienne d'un utilisateur, d'une API tierce ou d'un fichier importé.
• Moindre privilège : chaque composant n'accède qu'aux ressources strictement nécessaires à sa fonction.
• Défense en profondeur : plusieurs couches de contrôles, de sorte qu'un contrôle défaillant n'entraîne pas à lui seul une compromission.
• Séparation des préoccupations : la logique métier, l'authentification et la présentation sont des responsabilités distinctes.
• Gestion explicite des erreurs : ne jamais exposer de stack trace ou d'information d'infrastructure dans les messages d'erreur.
• Gestion des secrets : aucune credential en dur dans le code, utilisation systématique de variables d'environnement ou de gestionnaires de secrets.

L'OWASP SAMM comme référentiel de maturité

OWASP SAMM (Software Assurance Maturity Model) évalue la maturité des pratiques AppSec d'une organisation. Pour les étudiants, l'enseigner comme outil de lecture du monde professionnel est suffisant : l'objectif est qu'ils sachent positionner les pratiques vues en cours sur un continuum de maturité, pas de maîtriser le référentiel dans le détail.

Structure pédagogique d'un module de 30 à 40 heures

Un module de 30 à 40 heures en M1 ou M2 permet de couvrir l'ensemble des concepts et de laisser une place significative à la pratique. La répartition recommandée est de 30 % de cours et 70 % de travaux pratiques.

Bloc 1 — Fondements (6 à 8h)

Ce bloc pose le cadre. Le point de départ concret est l'OWASP Top 10, qui offre une cartographie des risques applicatifs les plus fréquents. Chaque catégorie est illustrée par un exemple de code vulnérable et sa version corrigée.

Séance type de 2h : 45 minutes de cours sur les catégories OWASP, 45 minutes de lab dirigé sur une base de code fournie, 30 minutes de débrief collectif.

Bloc 2 — SDLC sécurisé et threat modeling (8 à 10h)

Ce bloc est le cœur du module. Les étudiants apprennent à décomposer un système en Data Flow Diagrams (DFD), à identifier les menaces avec STRIDE, et à définir des contre-mesures architecturales. Un atelier de threat modeling sur une architecture fictive (application web avec backend API et base de données) constitue le projet central de ce bloc.

Bloc 3 — Outils SAST et DAST (8 à 10h)

Les outils d'analyse sont abordés comme des aides à la décision, pas comme des oracles. L'accent est mis sur l'interprétation des résultats, la qualification des faux positifs, et la priorisation des corrections. Ce bloc requiert un environnement technique préparé à l'avance (voir la section TP).

Bloc 4 — Revue de code sécurisée (4 à 6h)

La revue de code est une compétence professionnelle quotidienne pour un développeur sécurisé. Les étudiants travaillent en binômes sur des bases de code comportant des vulnérabilités intentionnelles. L'objectif est d'apprendre à formuler des observations de sécurité précises, actionnables et sans ambiguïté dans un contexte de revue par les pairs.

Bloc 5 — Intégration DevSecOps (4 à 6h)

Ce bloc de clôture raccorde l'AppSec aux pratiques de DevSecOps : intégration des outils SAST dans une pipeline CI/CD, politique de qualité de code (quality gate), et processus de gestion des vulnérabilités identifiées en production. Il prépare les étudiants aux environnements professionnels modernes où la sécurité est intégrée au flux de livraison continue.

TP et exercices concrets

SAST avec SonarQube Community

Objectif : apprendre à lancer une analyse statique sur une base de code, interpréter les résultats et prioriser les corrections.

Prérequis techniques : SonarQube Community (LTS) déployé sur un serveur lab ou via Docker en local. La configuration initiale du scanner est à faire par les étudiants eux-mêmes — c'est formateur.

Déroulement du TP :

1. Les étudiants clonent un dépôt applicatif intentionnellement vulnérable (WebGoat ou une application interne fournie par le formateur).
2. Ils configurent le scanner SonarQube et lancent une première analyse.
3. Ils explorent le tableau de bord : catégories de vulnérabilités, niveaux de sévérité, dette technique.
4. Ils sélectionnent les trois vulnérabilités les plus critiques, expliquent leur impact, proposent et implémentent une correction.
5. Ils relancent l'analyse et comparent les résultats avant/après.

Point pédagogique clé : insister sur la qualification des faux positifs. Un SAST produit toujours des alertes qui ne sont pas de vraies vulnérabilités. Savoir les identifier et les justifier est une compétence professionnelle à part entière.

DAST avec OWASP ZAP

Objectif : comprendre comment un scanner dynamique interagit avec une application en cours d'exécution, et ce qu'il peut détecter que le SAST ne voit pas.

Prérequis techniques : OWASP ZAP (version stable) installé sur les postes étudiants, application cible déployée en local (DVWA ou Juice Shop sur Docker).

Déroulement du TP :

1. Les étudiants configurent leur navigateur pour passer par le proxy ZAP.
2. Ils naviguent manuellement dans l'application pour générer du trafic et enregistrer les points d'entrée.
3. Ils lancent un scan actif sur les URL identifiées.
4. Ils analysent les alertes générées : type de vulnérabilité, requête qui a déclenché l'alerte, réponse du serveur.
5. Ils documentent deux vulnérabilités confirmées avec une preuve de concept (capture de la requête et de la réponse HTTP).

La complémentarité SAST/DAST doit être explicitée : le SAST analyse le code source sans l'exécuter (plus de couverture, mais plus de faux positifs) ; le DAST cible l'application en cours d'exécution et détecte des problèmes de configuration et des vulnérabilités de runtime invisibles au SAST.

Revue de code orientée sécurité

Le formateur fournit une base de code en Python ou Java contenant huit à douze vulnérabilités de niveaux variés : injections SQL, gestion incorrecte des exceptions, exposition de secrets, absence de validation des entrées, mauvaise gestion des sessions.

Format : binômes, 90 minutes pour produire un rapport de revue structuré — pour chaque vulnérabilité : localisation précise (fichier, ligne), catégorie OWASP, impact potentiel, correction recommandée.

Le débrief collectif (45 min) est projeté en direct. Les désaccords entre binômes sur la classification ou la sévérité sont particulièrement utiles pédagogiquement.

Atelier threat modeling STRIDE

C'est le TP le plus structurant du module. Il est recommandé de le placer en milieu de module, une fois que les étudiants comprennent les catégories de vulnérabilités et les mécanismes de base des attaques.

Scénario : une architecture fictive d'application de gestion de dossiers médicaux — interface web, API REST, base de données relationnelle, service de notification par email, système d'authentification. Les étudiants reçoivent un diagramme d'architecture simplifié.

Déroulement :

1. Décomposition (30 min) : les groupes de trois à quatre étudiants produisent un DFD à deux niveaux, identifiant les composants, les flux de données, les points de confiance et les actifs sensibles.
2. Identification des menaces (60 min) : pour chaque flux et chaque composant, application systématique de STRIDE. Chaque menace est enregistrée dans un tableau partagé.
3. Priorisation (30 min) : les groupes sélectionnent les cinq menaces les plus critiques et justifient leur choix.
4. Contre-mesures (30 min) : pour chaque menace prioritaire, proposition d'un contrôle de sécurité concret.
5. Restitution (30 min) : chaque groupe présente ses trois menaces les plus critiques et les contre-mesures associées.

Tableau de progression

Ce tableau sert aussi à négocier avec les responsables pédagogiques le placement du module dans le cursus et les prérequis formels.

Évaluation et indicateurs de réussite

Principes d'évaluation

L'évaluation d'un module AppSec doit mesurer des compétences, pas des connaissances. Un QCM sur les catégories OWASP teste la mémorisation, pas la capacité à identifier une vulnérabilité dans un contexte réel.

L'évaluation la plus cohérente avec les objectifs du module combine trois éléments :

1. Revue de code notée (40 % de la note)

L'étudiant reçoit une base de code de 300 à 500 lignes comportant des vulnérabilités intentionnelles de différents niveaux. Il dispose de deux heures pour produire un rapport de revue structuré. La grille de notation porte sur :

• La complétude (combien de vulnérabilités identifiées parmi celles attendues)
• La précision (la localisation et la description sont-elles exactes ?)
• La pertinence des corrections proposées (sont-elles réalistes et actionnables ?)
• La priorisation (les vulnérabilités les plus critiques sont-elles traitées en premier ?)

2. Rapport de threat modeling (40 % de la note)

En groupe de trois, les étudiants produisent un rapport de threat modeling complet sur une architecture fictive fournie par le formateur. Le rapport inclut le DFD, le tableau des menaces STRIDE, la justification des cinq menaces prioritaires et les contre-mesures recommandées.

3. Oral de 15 minutes (20 % de la note)

L'étudiant présente et justifie ses choix de priorisation — sur la revue de code ou sur le threat modeling. L'oral évalue la capacité à argumenter sous contrainte, à défendre une position face aux questions du jury et à communiquer un risque technique à un interlocuteur non spécialiste.

Ce que le formateur doit surveiller

Plusieurs indicateurs permettent de vérifier que les apprentissages s'installent correctement :

• Les étudiants distinguent-ils faux positif et vulnérabilité confirmée ? C'est l'un des points de blocage les plus fréquents lors des TP SAST. Si la majorité du groupe ne parvient pas à qualifier les alertes, le bloc théorique sur le fonctionnement du SAST doit être renforcé.
• Le threat modeling produit-il des menaces spécifiques au contexte ou des menaces génériques ? Une menace du type « l'attaquant accède à la base de données » sans préciser le vecteur d'attaque n'est pas opérationnelle. Les étudiants doivent formuler des menaces ancrées dans l'architecture analysée.
• Les corrections proposées lors de la revue de code sont-elles actionnables ? « Utiliser une requête préparée à la ligne 47 » est actionnable. « Sécuriser les requêtes SQL » ne l'est pas.

Ces trois indicateurs, combinés aux livrables écrits, permettent d'ajuster le rythme du module en cours de route.

Ce qu'il faut retenir

• L'AppSec ne se résume pas au pentest applicatif. Enseigner le SDLC sécurisé, c'est former des ingénieurs capables d'intégrer la sécurité dès la conception, pas seulement de la tester après coup.
• Le threat modeling est la compétence la plus différenciante. Un ingénieur capable de mener un atelier STRIDE sur une architecture nouvelle est immédiatement utile en équipe produit. Ce n'est pas une compétence rare — c'est une compétence manquante, ce qui est différent.
• SAST et DAST s'apprennent par l'interprétation, pas par l'utilisation. L'objectif pédagogique est de qualifier les résultats et de prioriser les corrections, pas de maîtriser toutes les options de l'outil. Garder le cap sur cet objectif évite de passer deux heures sur la configuration de SonarQube au détriment du temps de lab.
• La revue de code est une compétence quotidienne, pas un exercice ponctuel. La mettre au cœur du module — et de l'évaluation — prépare les étudiants à une pratique qu'ils rencontreront dès le premier jour en entreprise.
• Un tableau de progression sert aussi à négocier. Présenter aux responsables pédagogiques un tableau clair des niveaux, des compétences et des livrables associés facilite le placement du module dans le cursus et la définition des prérequis formels.
• Évaluer des compétences, pas des connaissances. Revue de code, rapport de threat modeling et oral de justification permettent de mesurer ce que les étudiants savent faire, pas ce qu'ils ont mémorisé.

Vous cherchez un intervenant pour animer un module AppSec ou SDLC sécurisé dans votre établissement ?
Cyber Teachers met en relation les écoles d'ingénieurs et les universités avec des professionnels de la sécurité applicative expérimentés, capables d'animer des ateliers de threat modeling, des TP SAST/DAST et des revues de code dans des contextes pédagogiques réels.