Lab de gestion des vulnérabilités avec OpenVAS et Trivy : guide pédagogique complet
Pourquoi la gestion des vulnérabilités mérite un lab dédié
La gestion des vulnérabilités figure parmi les compétences les plus demandées sur le marché, et parmi les plus mal enseignées dans les cursus. Elle se réduit souvent à quelques diapositives sur le score CVSS et une démonstration rapide d'un outil de scan. Les étudiants quittent la salle sans avoir produit un rapport de vulnérabilités ni articulé une décision de priorisation face à un interlocuteur technique.
Un lab dédié change la situation. Confrontés à un environnement réel — même simplifié — les apprenants développent des réflexes que la théorie ne transmet pas : distinguer un faux positif d'une vulnérabilité exploitable, peser l'impact d'un patch sur un service de production, documenter leurs conclusions de façon actionnable.
Ce guide propose quatre séances progressives, du premier scan au cycle de remédiation complet, en s'appuyant sur deux outils open source complémentaires : OpenVAS dans sa distribution Greenbone Community Edition pour le périmètre réseau et infrastructure, et Trivy pour le périmètre conteneurs. Pour les fondements théoriques préalables — cycle de vie d'une CVE, métriques CVSS — l'article sur l'enseignement du CVSS couvre l'ensemble du parcours conceptuel.
Trois lacunes que le lab doit combler
Avant même de choisir les outils, il est utile d'inventorier ce que les étudiants ne savent pas faire. Dans la plupart des groupes sans TP de scan, trois angles morts ressortent : lire un rapport sans se fier uniquement au score brut, distinguer une vulnérabilité dans un package système d'une vulnérabilité dans une dépendance applicative, et vérifier qu'une correction a réellement été appliquée. Le lab décrit ici adresse ces trois lacunes, séance après séance. Les formateurs qui souhaitent ancrer ce travail dans un programme plus large trouveront le cadre conceptuel dans le cours de gestion des vulnérabilités.
Architecture du lab
Le lab repose sur une séparation claire de deux périmètres : l'infrastructure réseau et système, scannée avec OpenVAS, et la chaîne conteneurs, analysée avec Trivy. Cette séparation n'est pas artificielle — elle reflète la réalité opérationnelle d'une équipe sécurité qui gère à la fois des serveurs traditionnels et une stack DevSecOps basée sur Kubernetes ou Docker.
L'environnement minimal se compose de quatre éléments :
| Composant | Rôle | Spécifications minimales | Remarque |
|---|---|---|---|
| Serveur GCE | Héberge Greenbone Community Edition via Docker Compose | 4 Go RAM, 2 vCPU, 20 Go SSD | VPS ou VM locale |
| Cibles de scan | Machines Linux avec packages volontairement anciens | 1 Go RAM, 1 vCPU | Debian 11 ou Ubuntu 22.04 |
| Postes étudiants (Trivy) | Analyse locale des images Docker | 2 Go RAM, accès Docker | Linux ou macOS |
| Réseau isolé | Sépare le lab du réseau de l'établissement | VLAN ou réseau hôte-seulement | Évite toute propagation |
Un seul serveur GCE central suffit pour un groupe de 15 à 20 étudiants en binômes : ils se partagent l'interface web pour la phase OpenVAS et travaillent de façon autonome sur leurs postes pour la phase Trivy.
Séance 1 : installation et premier scan avec OpenVAS (Greenbone Community Edition)
Durée recommandée : 3 heures. Niveau : débutant avec accompagnement.
OpenVAS (Open Vulnerability Assessment System) est le moteur de scan au cœur de la suite Greenbone Community Edition (GCE). Il s'agit d'un projet open source distribué sous licence GPL, maintenu par Greenbone Networks. La Greenbone Community Edition est la version gratuite de la plateforme : elle inclut l'interface web (Greenbone Security Assistant, GSA), le démon de scan, et la base de données de tests de vulnérabilités (NVTs). Elle se distingue des éditions commerciales (Greenbone Enterprise) par l'absence de certaines sources de renseignement propriétaires et de fonctionnalités de gestion à grande échelle, mais elle couvre largement les besoins d'un lab pédagogique.
Installation via Docker Compose
La méthode recommandée est Docker Compose. Greenbone maintient un script d'initialisation officiel qui déploie l'intégralité de la stack :
mkdir -p /opt/greenbone && cd /opt/greenbone
curl -f -L https://greenbone.github.io/docs/latest/_static/setup-and-start-greenbone-community-edition.sh \
-o setup.sh && bash setup.sh
Le script télécharge les images et initialise la base de NVTs (plusieurs gigaoctets — prévoir 15 à 20 minutes au premier démarrage). L'interface GSA est ensuite accessible sur https://localhost:9392 avec les identifiants admin / admin à changer immédiatement. Point formateur : le certificat TLS auto-signé est une occasion naturelle d'aborder la gestion des certificats internes.
Lancer un premier scan
Dans l'interface GSA, les étudiants créent une tâche via Scans > Tasks > New Task, renseignent l'adresse IP de la cible et choisissent le profil Full and Fast — le profil pédagogique recommandé, large sans être agressif. La durée d'un scan varie de 5 à 20 minutes selon les services exposés. Cette attente est une opportunité : demander aux étudiants d'anticiper quels services apparaîtront dans les résultats, puis de confronter leurs hypothèses à la réalité.
Lire un rapport brut
À l'issue du scan, les résultats sont disponibles sous Scans > Results. Chaque entrée comporte : le nom de la vulnérabilité, le score CVSS, l'hôte et le port affectés, et une description technique. Le rapport peut être exporté en PDF ou en XML pour être intégré aux livrables des étudiants.
L'exercice demandé à ce stade est volontairement limité : identifier les cinq vulnérabilités au score le plus élevé et pour chacune, noter le port et le service concerné. L'interprétation approfondie est réservée à la séance suivante.
Séance 2 : interpréter les résultats CVSS et prioriser
Durée recommandée : 3 heures. Niveau : intermédiaire.
Cette séance est la plus dense sur le plan analytique. Les étudiants disposent du rapport généré en séance 1 et doivent passer de la liste brute à une décision de priorisation argumentée.
Comprendre le score affiché dans GCE
GCE affiche le score CVSS Base pour chaque vulnérabilité, issu des données NVD et des publications de l'équipe Greenbone. Les étudiants doivent comprendre deux points clés :
- Le score Base est un score "dans l'absolu" : il ne tient pas compte de l'exposition réelle du système dans leur réseau. Une vulnérabilité critique sur un serveur interne non exposé à Internet est moins urgente qu'une vulnérabilité moyenne sur un serveur web en DMZ.
- GCE peut générer des faux positifs : certaines détections reposent sur la version du logiciel plutôt que sur une vérification d'exploitation effective. Il est essentiel d'apprendre à croiser le rapport avec la fiche NVD officielle pour confirmer qu'un correctif existe et que le système est réellement affecté.
Exercice de priorisation en binôme
Chaque binôme reçoit le rapport de scan et une fiche de contexte (rôle de chaque machine, exposition réseau, mesures compensatoires en place). Leur travail : sélectionner les cinq vulnérabilités les plus prioritaires — pas forcément les cinq au score le plus élevé —, justifier chaque choix, identifier au moins un faux positif probable et le documenter, puis produire un tableau avec score Base, priorité assignée (P1 à P3) et justification.
Le débriefing collectif est la partie la plus formatrice. Plusieurs groupes arrivent inévitablement à des classements différents — ces divergences révèlent les hypothèses implicites de chaque binôme et ouvrent une discussion sur la prise de décision en situation d'incertitude, qui est exactement le quotidien de l'analyste en vulnérabilités.
Séance 3 : scanner des images Docker avec Trivy
Durée recommandée : 2 heures 30. Niveau : débutant à intermédiaire.
Trivy est un scanner de vulnérabilités open source développé par Aqua Security et distribué sous licence Apache 2.0. Il se distingue par sa polyvalence : il analyse les images Docker, les systèmes de fichiers, les dépôts Git, les fichiers de configuration Terraform et Kubernetes, ainsi que les manifestes de dépendances de nombreux langages (Python, Node.js, Go, Java, Ruby). C'est l'outil de référence pour intégrer la détection de vulnérabilités dans un pipeline CI/CD, et sa simplicité d'utilisation en fait un excellent choix pédagogique.
Installation
Trivy s'installe via les dépôts officiels Aqua Security sur Debian/Ubuntu ou via Homebrew sur macOS. La documentation d'installation est disponible sur le dépôt GitHub officiel du projet. L'outil est disponible en tant que binaire autonome, ce qui simplifie son déploiement dans des environnements sans gestionnaire de paquets.
Premier scan d'une image Docker
La commande de base est volontairement simple :
# Scanner une image publique connue pour comporter des vulnérabilités
trivy image python:3.9
# Filtrer sur les vulnérabilités de sévérité CRITICAL et HIGH uniquement
trivy image --severity CRITICAL,HIGH python:3.9
# Exporter le rapport en JSON pour un traitement ultérieur
trivy image --format json --output rapport-python.json python:3.9
Trivy interroge sa base de données locale (mise à jour automatiquement) et produit un rapport qui liste, pour chaque package détecté dans l'image, les CVEs associées, leur score CVSS, la version affectée et — point crucial pédagogiquement — la version corrigée lorsqu'elle existe. Cette colonne « Fixed Version » est celle que les étudiants doivent apprendre à regarder en premier.
Exercice : comparer deux versions d'une image
L'exercice de cette séance consiste à comparer le profil de vulnérabilités de deux versions d'une même image de base :
trivy image --severity HIGH,CRITICAL ubuntu:20.04
trivy image --severity HIGH,CRITICAL ubuntu:22.04
Les étudiants notent le nombre de vulnérabilités CRITICAL et HIGH pour chaque version, identifient les CVEs présentes dans les deux et les CVEs corrigées dans la version plus récente. Le livrable est un tableau comparatif et un paragraphe qui tire les conclusions opérationnelles : dans quel cas une mise à jour de l'image de base suffit-elle, et quand faut-il également mettre à jour les packages applicatifs ?
Lien avec la sécurité des chaînes de build
La deuxième partie de la séance ouvre sur la dimension DevSecOps. Trivy s'intègre directement dans un pipeline GitHub Actions ou GitLab CI pour bloquer la construction d'une image dépassant un seuil de vulnérabilités critiques. Un extrait de pipeline à montrer aux étudiants illustre concrètement comment la sécurité entre dans les workflows de développement modernes, même si le déploiement d'un pipeline CI complet dépasse le cadre d'un TP de 2h30.
Séance 4 : simuler un cycle de patch et vérifier la remédiation
Durée recommandée : 3 heures. Niveau : intermédiaire.
La séance 4 est celle qui ancre le cycle complet : identifier → prioriser → corriger → vérifier. C'est aussi la plus proche des conditions réelles de travail d'une équipe de sécurité opérationnelle.
Scénario
Les binômes reprennent la liste de vulnérabilités priorisées produite en séance 2. Leur mission est d'appliquer les correctifs pour les deux vulnérabilités de priorité P1 sur la machine cible, de documenter chaque étape et de re-scanner la cible pour vérifier que les vulnérabilités ont disparu du rapport.
Appliquer les correctifs sur la cible Linux
Pour les vulnérabilités liées à des packages système (cas le plus fréquent sur une cible Debian/Ubuntu), la remédiation passe par la mise à jour du package concerné avec apt-get install --only-upgrade <paquet>. L'étape préalable à ne pas sauter est apt-get changelog <paquet> : elle oblige l'étudiant à lire ce que le correctif modifie concrètement avant de l'appliquer, ce qui est souvent ignoré en pratique mais fondamental dans un processus de patch management rigoureux.
Vérifier la remédiation par un re-scan ciblé
Après application des correctifs, les étudiants relancent un scan OpenVAS ciblé sur le même hôte. Un scan de vérification dans GCE peut être paramétré pour ne tester que les vulnérabilités précédemment détectées, ce qui réduit le temps d'exécution. Les résultats doivent montrer que les vulnérabilités corrigées n'apparaissent plus — ou apparaissent avec une mention indiquant que le correctif est détecté.
Point d'attention formateur : il arrive qu'une vulnérabilité persiste dans le rapport après correction, parce que GCE détecte la version du package plutôt que l'exploit lui-même. C'est l'occasion d'expliquer la différence entre une détection version-based et une détection exploit-based, et pourquoi la première peut générer des faux positifs persistants après patch.
Livrable de la séance 4
Le livrable final est un rapport de remédiation structuré selon ce modèle :
- Identification de la vulnérabilité (CVE, score CVSS, service affecté)
- Action de remédiation réalisée (commande, version corrigée installée)
- Preuve de correction (sortie de
dpkg -l, capture du rapport de re-scan) - Vulnérabilités pour lesquelles aucun correctif n'était disponible et mesures compensatoires proposées
Ce format est directement inspiré des livrables attendus dans des missions réelles d'audit de remédiation.
Tableau récapitulatif des séances
| Séance | Durée | Objectif pédagogique | Livrable attendu | Outil principal |
|---|---|---|---|---|
| 1 – Installation et premier scan | 3 h | Déployer GCE, lancer un scan réseau, lire un rapport brut | Liste des 5 vulnérabilités les plus élevées avec port et service | OpenVAS / GCE |
| 2 – Interprétation CVSS et priorisation | 3 h | Ajuster les scores au contexte, identifier les faux positifs, argumenter un classement | Tableau de priorisation commenté (P1 à P3) | OpenVAS / GCE + NVD |
| 3 – Scan d'images Docker | 2 h 30 | Analyser deux versions d'une image, comprendre les vulnérabilités de dépendances | Tableau comparatif et paragraphe de conclusions opérationnelles | Trivy |
| 4 – Cycle de patch et vérification | 3 h | Appliquer des correctifs, re-scanner, documenter la remédiation | Rapport de remédiation structuré avec preuves | OpenVAS / GCE + apt |
Évaluation et grille de notation
L'évaluation du module repose sur deux livrables complémentaires : le rapport de remédiation produit en séance 4 et un oral individuel de 15 minutes.
Rapport de remédiation (60 % de la note)
| Critère | Insuffisant | Satisfaisant | Expert |
|---|---|---|---|
| Priorisation | Classement par score brut sans ajustement contextuel | Prend en compte le rôle du système et l'exposition réseau | Intègre la disponibilité du correctif et les mesures compensatoires dans l'argumentaire |
| Documentation des actions | Commandes manquantes ou résultats non consignés | Toutes les commandes et sorties documentées | Documentation lisible par un tiers, avec explications des choix |
| Vérification de la remédiation | Aucun re-scan ou re-scan non interprété | Re-scan réalisé, vulnérabilités corrigées confirmées | Différencie détection version-based et exploit-based, commente les persistances |
| Traitement des faux positifs | Faux positifs non identifiés | Un faux positif probable identifié et argumenté | Méthodologie de qualification systématique, sources croisées (NVD, Greenbone) |
| Clarté et structure | Rapport incomplet ou sans structure lisible | Structure cohérente, compréhensible par un responsable technique | Rapport actionnable, synthèse exécutive en tête de document |
Oral individuel (40 % de la note)
L'oral dure 15 minutes : 5 minutes de présentation par l'étudiant d'une vulnérabilité issue de son rapport, suivies de 10 minutes de questions sur trois axes : compréhension du mécanisme d'exploitation et du score CVSS, décision de priorisation (pourquoi ce choix, que faire sans correctif disponible), et communication vers un interlocuteur non technique. Ce format prépare directement aux entretiens techniques pour des postes d'analyste en vulnérabilités.
Ce qu'il faut retenir
Un lab de gestion des vulnérabilités bien construit change durablement la façon dont les étudiants abordent les rapports de scan. La pratique installe des réflexes que la théorie ne peut pas donner : le doute systématique face à un score brut, la recherche du contexte avant toute décision de priorisation, l'exigence de preuve avant de déclarer une vulnérabilité corrigée.
Les points clés pour mettre en place ce lab :
- OpenVAS / Greenbone Community Edition est gratuit et open source ; son déploiement via Docker Compose est reproductible en moins d'une heure.
- Trivy (Aqua Security, Apache 2.0) s'installe en un binaire ; sa colonne "Fixed Version" en fait l'outil pédagogique idéal pour la sécurité des images.
- Les deux outils couvrent des périmètres complémentaires : les associer sur quatre séances progressives donne une vision complète du cycle de gestion des vulnérabilités, de l'infrastructure au conteneur.
- L'évaluation la plus pertinente est un rapport de priorisation argumenté suivi d'un oral, pas un QCM sur le score CVSS.
- Les faux positifs ne sont pas un obstacle pédagogique : apprendre à les qualifier et à les documenter est une compétence à part entière.
Ce lab peut s'intégrer dans un cours de gestion des vulnérabilités dédié ou dans un parcours DevSecOps plus large. L'investissement en préparation — machines cibles et fiches de contexte — se rentabilise dès la première promotion.
Pour trouver un formateur spécialisé en gestion des vulnérabilités capable de concevoir et d'animer ce type de lab, ou pour accéder à des ressources pédagogiques complémentaires sur l'enseignement de la cybersécurité, rendez-vous sur cyberteachers.org.