Enseigner la gestion des vulnérabilités : cycle de vie, priorisation CVSS et TP pour étudiants

Pourquoi la gestion des vulnérabilités mérite un module dédié

La gestion des vulnérabilités est l'une des disciplines les plus opérationnelles de la cybersécurité. Pourtant, elle est trop souvent traitée en quelques heures dans des cursus déjà chargés, voire réduite à une simple présentation d'outils de scan. Ce choix pédagogique a un coût : les diplômés arrivent en entreprise sans savoir prioriser un lot de CVE, rédiger un rapport de patch management ou argumenter devant un responsable technique pourquoi une vulnérabilité à score faible mérite parfois une correction urgente.

Consacrer un module entier à ce domaine n'est pas un luxe. C'est une nécessité pour former des professionnels capables de travailler dans un CSIRT, une équipe de sécurité opérationnelle ou un poste d'analyste en vulnérabilités.

Distinguer vulnérabilité, menace et risque dès le premier cours

L'une des premières difficultés pédagogiques est la confusion terminologique. Les étudiants utilisent souvent "vulnérabilité", "menace" et "risque" de manière interchangeable. Cette confusion nuit à la précision de leur raisonnement et de leurs livrables professionnels.

Quelques définitions à poser dès le début du module :

• Vulnérabilité : une faiblesse dans un système, un logiciel ou un processus susceptible d'être exploitée.
• Menace : un acteur ou un événement potentiel susceptible d'exploiter une vulnérabilité.
• Risque : la combinaison de la probabilité d'exploitation d'une vulnérabilité par une menace et de l'impact que cela aurait sur l'organisation.

Un exercice simple consiste à demander aux étudiants de classer une liste de situations concrètes dans ces trois catégories. Ce travail de définition en début de module paie sur toute la durée de la formation.

Lien avec les attentes employeurs

Les postes d'analyste vulnérabilités, de gestionnaire de correctifs ou d'ingénieur CSIRT ont en commun d'exiger une maîtrise du cycle de vie des vulnérabilités, de la lecture du score CVSS et de la capacité à produire des livrables actionnables. Les offres d'emploi dans ces domaines mentionnent régulièrement des compétences telles que l'utilisation d'outils de scan, la priorisation des correctifs et la rédaction de tableaux de bord de vulnérabilités.

Enseigner ce module avec un ancrage métier fort — en s'appuyant sur des fiches de poste réelles — permet aux étudiants de comprendre pourquoi ils apprennent ce qu'ils apprennent.

Position dans le cursus

Ce module s'inscrit naturellement après les cours sur les réseaux et les systèmes d'exploitation, qui fournissent le vocabulaire technique indispensable (ports, services, protocoles, gestion des utilisateurs). Il doit précéder les modules dédiés aux opérations SOC, pour lesquels la gestion des vulnérabilités est une compétence de base. Il peut également être enseigné en parallèle d'un cours gestion des vulnérabilités plus approfondi intégrant des aspects de threat intelligence.

Le cycle de vie d'une vulnérabilité

Comprendre qu'une vulnérabilité suit un cycle de vie structuré est fondamental. Trop d'étudiants pensent qu'une vulnérabilité apparaît brutalement, est corrigée rapidement, puis disparaît. La réalité est plus complexe, et l'enseigner honnêtement permet de préparer les futurs professionnels aux délais réels et aux décisions difficiles qu'ils rencontreront.

De la découverte à la vérification : les grandes étapes

Le cycle de vie d'une vulnérabilité comprend les étapes suivantes :

Ce tableau mérite une discussion en cours : les délais réels peuvent s'étirer considérablement selon la taille de l'organisation, la criticité du système ou la complexité du correctif. Il est utile de mentionner que certaines vulnérabilités restent non corrigées pendant des mois, voire des années, dans des environnements industriels ou embarqués.

Responsible disclosure et bug bounty

La divulgation coordonnée des vulnérabilités — souvent appelée responsible disclosure ou coordinated vulnerability disclosure (CVD) — est le processus par lequel un chercheur signale une vulnérabilité à l'éditeur concerné avant de la rendre publique. Ce processus vise à laisser à l'éditeur le temps de produire un correctif.

Les programmes de bug bounty, proposés par des entreprises comme les grandes plateformes technologiques ou via des intermédiaires spécialisés, ont accéléré et professionnalisé ce processus. En offrant une rémunération aux chercheurs qui signalent des vulnérabilités de manière responsable, ces programmes constituent un véritable accélérateur de la sécurité du logiciel.

Introduire ce sujet en cours est pertinent pour plusieurs raisons : il montre que la cybersécurité a une dimension économique et collaborative, et il ouvre la discussion sur les situations limites — notamment les divulgations publiques non coordonnées lorsque l'éditeur ne répond pas aux signalements.

Comprendre et utiliser CVSS v3 en cours

Le Common Vulnerability Scoring System (CVSS) est le standard de facto pour évaluer la sévérité d'une vulnérabilité. La version 3.1, publiée en 2019, reste la référence dominante dans les outils professionnels et les offres d'emploi. CVSS v4, publié fin 2023, apporte des améliorations notables — notamment une meilleure prise en compte des systèmes OT — mais son adoption est encore progressive. Il est recommandé de concentrer l'enseignement sur CVSS v3.1 tout en présentant les apports de la v4 de manière comparative.

Les trois groupes de métriques

CVSS v3 est organisé en trois groupes :

• Base : caractéristiques intrinsèques de la vulnérabilité, indépendantes du contexte. C'est le groupe enseigné en priorité.
• Temporal : facteurs qui évoluent dans le temps, comme la disponibilité d'un exploit ou d'un correctif officiel. Ce groupe permet d'ajuster le score Base en fonction de la maturité de l'exploitation.
• Environmental : facteurs propres à l'environnement de l'organisation — importance du système affecté, présence de mesures de compensation. Ce groupe est crucial pour prioriser les actions.

En formation initiale, il est conseillé de commencer par le groupe Base, qui est le plus documenté et le plus utilisé dans les fiches CVE.

Les métriques Base essentielles

Le groupe Base repose sur huit métriques qui décrivent les conditions d'exploitation d'une vulnérabilité :

• AV (Attack Vector) : depuis où l'attaque peut-elle être lancée ? Valeurs : Network (N), Adjacent (A), Local (L), Physical (P).
• AC (Attack Complexity) : quelles conditions particulières l'attaquant doit-il réunir ? Valeurs : Low (L), High (H).
• PR (Privileges Required) : quel niveau de privilège l'attaquant doit-il posséder avant d'exploiter ? Valeurs : None (N), Low (L), High (H).
• UI (User Interaction) : une action d'un utilisateur légitime est-elle nécessaire ? Valeurs : None (N), Required (R).
• S (Scope) : l'exploitation affecte-t-elle uniquement le composant vulnérable ou d'autres composants ? Valeurs : Unchanged (U), Changed (C).
• C (Confidentiality Impact) : quel est l'impact sur la confidentialité des données ? Valeurs : None (N), Low (L), High (H).
• I (Integrity Impact) : quel est l'impact sur l'intégrité des données ? Valeurs : None (N), Low (L), High (H).
• A (Availability Impact) : quel est l'impact sur la disponibilité du système ? Valeurs : None (N), Low (L), High (H).

Un exercice efficace consiste à demander aux étudiants de déterminer la valeur de chaque métrique pour une vulnérabilité décrite en langage naturel, avant de calculer le score avec le calculateur officiel du FIRST (first.org/cvss/calculator/3.1).

Interpréter le score CVSS

Le score final s'exprime sur une échelle de 0 à 10 et se décompose en quatre niveaux de sévérité :

Il est important d'insister auprès des étudiants sur un point souvent mal compris : le score Base ne suffit pas à prioriser. Un score de 9.8 sur un serveur isolé, sans données sensibles et sans exposition à Internet, peut être moins urgent qu'un score de 7.0 sur un serveur de production directement accessible depuis l'extérieur. C'est précisément le rôle du groupe Environmental de CVSS de permettre cet ajustement.

TP 1 : prioriser un lot de CVEs fictifs

Contexte et objectif

Ce premier travail pratique plonge les étudiants dans un scénario d'infrastructure fictive composée de trois composants : un serveur web Apache 2.4, une base de données MySQL 8.0 et un partage réseau NFS. Cinq CVEs fictifs (clairement étiquetés comme tels) ont été identifiés lors d'un scan de vulnérabilités. L'objectif est de calculer le score CVSS Environmental pour chaque vulnérabilité en tenant compte du contexte de l'infrastructure, puis de produire un tableau de priorisation argumenté.

Consigne

Pour chaque CVE fourni, les étudiants doivent :

1. Lire la description et les métriques Base fournies.
2. Évaluer les métriques Environmental en fonction du contexte (importance du système, présence de sauvegardes, existence de pare-feu, niveau d'exposition réseau).
3. Calculer le score Environmental via le calculateur CVSS officiel.
4. Classer les cinq CVEs par ordre de priorité de correction et justifier chaque décision.

Livrable attendu

Le livrable est un tableau de priorisation incluant : l'identifiant du CVE, le score Base, le score Environmental calculé, le niveau de criticité ajusté et la justification de la priorité. Ce tableau doit être accompagné d'un paragraphe d'explication pour chaque vulnérabilité prioritaire.

Erreurs fréquentes et comment les anticiper

Plusieurs erreurs reviennent systématiquement lors de ce TP :

• Confondre score Base et score Environmental : certains étudiants ignorent les métriques Environmental et se contentent du score Base pour prioriser. Insistez sur le fait que le score Base est un score "dans l'absolu", sans contexte organisationnel.
• Sous-estimer les vulnérabilités à faible score sur des systèmes critiques : un score de 5.0 sur le serveur de base de données de production mérite souvent une attention plus rapide qu'un score de 8.0 sur un poste de travail isolé.
• Ignorer les mesures compensatoires existantes : les étudiants oublient parfois de prendre en compte les pare-feu, les systèmes de détection d'intrusion ou les politiques de contrôle d'accès déjà en place, qui peuvent réduire le score Environmental.

Un débriefing collectif en fin de TP, où plusieurs groupes comparent leurs tableaux de priorisation, est particulièrement formateur. Les divergences de classement révèlent les hypothèses implicites de chaque groupe et entraînent une discussion sur la prise de décision en situation réelle.

TP 2 : simuler un processus de patch management

Scénario

Ce deuxième travail pratique simule un processus de gestion des correctifs de bout en bout. Les étudiants travaillent sur un environnement de test composé d'une machine virtuelle Linux et d'une image Docker. Trois CVEs de criticité différente (une critique, une moyenne, une faible) ont été identifiés. La simulation se déroule en cinq étapes.

Étapes du processus

Identification : les étudiants reproduisent l'identification des vulnérabilités à partir des sorties d'outils (résultats de scan fournis en amont, sans qu'ils aient à lancer eux-mêmes le scan complet). Cette étape vise à habituer les étudiants à lire et interpréter des rapports bruts.

Évaluation : pour chaque vulnérabilité identifiée, les étudiants remplissent une fiche d'évaluation comprenant le score CVSS, l'impact potentiel sur le système de test et la disponibilité d'un correctif officiel.

Test en pré-production : avant tout déploiement, un correctif doit être testé dans un environnement qui reproduit la configuration de production. Les étudiants appliquent les mises à jour dans un environnement de test isolé et documentent les impacts observés (comportement du service, redémarrage nécessaire, dépendances affectées).

Déploiement : simulation du déploiement du correctif sur l'environnement de test principal, avec documentation des commandes utilisées et du résultat.

Vérification : confirmation que la vulnérabilité a bien été corrigée, idéalement en vérifiant la version du paquet installé ou en relançant un scan ciblé sur le composant corrigé.

Outils utilisés

• apt changelog <paquet> et apt-get changelog <paquet> : pour consulter les notes de version d'un paquet Debian/Ubuntu et comprendre ce que corrige un correctif avant de l'appliquer.
• yum check-update et dnf updateinfo list : équivalents sur les distributions Red Hat/CentOS/Rocky Linux, pour lister les mises à jour disponibles avec les CVEs associés.
• Trivy : outil open source de scan de vulnérabilités pour les images Docker. Commande de base : trivy image <nom-image>. Trivy produit un rapport listant les CVEs détectés, leur score CVSS, la version affectée et la version corrigée. Son intégration dans un pipeline CI/CD peut également être présentée aux étudiants les plus avancés.

Critères d'évaluation du rapport de patch

Le livrable final est un rapport de patch management structuré, évalué selon les critères suivants :

• Exhaustivité : toutes les vulnérabilités identifiées sont documentées, même celles dont le correctif n'est pas encore disponible.
• Justification de la priorisation : l'ordre de traitement des vulnérabilités est argumenté (score CVSS, criticité du système, disponibilité du correctif).
• Documentation des actions : les commandes utilisées, les résultats obtenus et les éventuels problèmes rencontrés sont consignés.
• Vérification : le rapport inclut une preuve que la correction a été appliquée (version du paquet, capture d'un scan post-correctif).
• Clarté et structure : le rapport est lisible par un responsable technique non spécialiste de la vulnérabilité traitée.

Outils pour les labs

Un des atouts pédagogiques de ce module est la richesse des outils open source disponibles, qui permettent de monter des labs complets sans coût de licence.

OpenVAS / Greenbone Community Edition

OpenVAS, maintenant intégré dans la suite Greenbone Community Edition, est l'outil de référence pour les scans de vulnérabilités réseau en environnement pédagogique. Il permet de scanner une plage d'adresses IP, d'identifier les services exposés et de les croiser avec une base de données de vulnérabilités connues. Le format de rapport généré (HTML ou XML) habitue les étudiants à la lecture de résultats de scan professionnels. L'installation via Docker simplifie considérablement la mise en place du lab.

Trivy

Trivy, développé par Aqua Security et distribué sous licence Apache 2.0, est devenu un standard pour le scan de vulnérabilités dans les images de conteneurs. Sa simplicité d'utilisation (trivy image ubuntu:22.04) en fait un outil idéal pour initier les étudiants à la sécurité des chaînes de build. Il supporte également le scan de systèmes de fichiers, de dépôts Git et de fichiers de configuration Infrastructure-as-Code.

NVD NIST et CVE.org

La National Vulnerability Database (nvd.nist.gov) et CVE.org sont les deux sources de référence pour consulter les fiches officielles des vulnérabilités. Apprendre à lire une fiche CVE — description, références, scores CVSS, liens vers les correctifs — est une compétence de base que chaque étudiant doit maîtriser. Un exercice simple consiste à demander aux étudiants de retrouver eux-mêmes la fiche d'un CVE connu et d'en extraire les informations clés.

EPSS : le complément indispensable à CVSS

L'Exploit Prediction Scoring System (EPSS), maintenu par le FIRST, est un système de scoring complémentaire à CVSS. Là où CVSS mesure la sévérité d'une vulnérabilité, EPSS prédit la probabilité qu'elle soit exploitée dans les 30 prochains jours, sur la base de données de menaces réelles. Un score EPSS élevé sur une vulnérabilité de score CVSS modéré peut justifier une correction prioritaire.

Introduire EPSS dans le module permet d'enseigner une approche de priorisation basée sur le risque réel plutôt que sur la sévérité théorique, ce qui est de plus en plus attendu dans les équipes de sécurité matures. Les données EPSS sont disponibles gratuitement via l'API du FIRST et via le NVD.

Évaluation du module

Grille de rubrique

L'évaluation finale du module repose sur une grille critériée permettant d'apprécier le niveau de maîtrise de chaque compétence :

Oral de 15 minutes sur un cas réel

En complément des travaux pratiques, un oral individuel de 15 minutes permet d'évaluer la capacité de l'étudiant à raisonner en situation. Le format consiste à présenter un cas réel (CVE public bien documenté) que l'étudiant a préparé à l'avance, suivi de questions de l'examinateur portant sur les choix de priorisation, les outils utilisés et les mesures de remédiation envisageables.

Cet oral prépare également les étudiants aux entretiens techniques dans lesquels il leur sera demandé d'expliquer comment ils géreraient une vulnérabilité critique dans un contexte donné.

Liens avec les certifications professionnelles

Les compétences développées dans ce module sont directement valorisées dans plusieurs certifications professionnelles reconnues sur le marché du travail. Parmi les plus pertinentes : la certification CompTIA Security+ aborde la gestion des vulnérabilités et le patch management comme domaines examinables. La certification eJPT et les parcours GIAC (notamment GCIA et GCIH) intègrent également la lecture de rapports de vulnérabilités. Pour les étudiants souhaitant se spécialiser, la certification GEVA (GIAC Enterprise Vulnerability Assessor) est entièrement dédiée à ce domaine.

Ce qu'il faut retenir

La gestion des vulnérabilités est une discipline structurante qui demande à la fois une rigueur méthodologique, une maîtrise des outils et une capacité à prendre des décisions dans un contexte d'incertitude. Enseigner ce module efficacement, c'est transmettre :

• La compréhension du cycle de vie complet d'une vulnérabilité, de la découverte à la vérification du correctif.
• La maîtrise de la lecture et du calcul du score CVSS, en particulier le groupe Environmental qui permet la priorisation contextuelle.
• La capacité à utiliser des outils professionnels — OpenVAS, Trivy, NVD — et à en interpréter les résultats de manière critique.
• La production de livrables professionnels : tableaux de priorisation argumentés, rapports de patch management structurés.

Ces compétences sont directement opérationnelles à l'issue de la formation et correspondent aux attentes des postes d'analyste en vulnérabilités et d'ingénieur CSIRT.

Pour aller plus loin dans la conception de votre programme, explorez les ressources pédagogiques disponibles sur cyberteachers.org et découvrez comment les intervenants spécialisés en gestion des vulnérabilités peuvent enrichir vos formations avec des retours d'expérience terrain.