Présentez-moi le cycle de vie de la gestion des vulnérabilités.
Réponse courte
La gestion des vulnérabilités est une boucle continue : découvrir les actifs et vulnérabilités (scan, inventaire d'actifs), prioriser selon le risque réel (CVSS plus exploitabilité, exposition et criticité des actifs — des frameworks comme EPSS et SSVC aident), remédier ou atténuer, vérifier la correction et rapporter sur les tendances et les SLA. Le scan est la partie facile ; la discipline est de prioriser et de boucler la boucle pour que le risque baisse réellement avec le temps.
La gestion des vulnérabilités n'est pas « lancer Nessus ». C'est un programme continu qui maintient un risque mesurable orienté à la baisse, et les recruteurs interrogent dessus pour voir si vous comprenez que le scan est la partie triviale — prioriser et boucler la boucle est le travail.
Le cycle de vie
- Découvrir. On ne peut protéger ce qu'on ne voit pas, donc cela commence par un inventaire d'actifs précis. Ensuite, des scans authentifiés et non authentifiés, des contrôles de posture cloud et de l'analyse de composition logicielle font remonter les vulnérabilités à travers cet inventaire.
- Prioriser. C'est l'étape difficile qui apporte de la valeur. Le score de base CVSS brut est nécessaire mais pas suffisant — un 9,8 sur une machine interne isolée compte moins qu'un 7,5 sur une application précieuse exposée à Internet avec du code d'exploit public. Ajoutez l'exploitabilité (EPSS, CISA KEV), l'exposition et la criticité des actifs. Des frameworks de décision comme SSVC formalisent cela.
- Remédier ou atténuer. Patcher quand vous le pouvez ; là où vous ne pouvez pas, appliquer des contrôles compensatoires — segmentation, règles WAF, désactivation d'une fonctionnalité — et suivre le risque résiduel.
- Vérifier. Re-scanner ou re-tester pour confirmer que la correction a réellement été appliquée et n'a pas régressé. Un « on l'a patché » non suivi n'est pas une clôture.
- Rapporter. Suivre des métriques — délai moyen de remédiation, conformité aux SLA, nombre de critiques ouverts — pour que la direction voie le risque baisser et dote le programme en conséquence.
Pourquoi la priorisation domine
Un grand parc génère des milliers de constats ; seule une petite fraction est réalistement exploitable. Traiter les CVSS 10 comme l'unique priorité gaspille à la fois l'effort et passe à côté du bug de gravité moyenne, activement exploité, exposé à Internet, qui vous fait réellement compromettre.
Ce que recherchent les recruteurs
Ils veulent vous entendre parler de priorisation fondée sur le risque (pas uniquement la gravité), de l'appui sur un inventaire d'actifs, de l'étape de vérification que beaucoup d'équipes sautent, et de la gestion pragmatique des vulnérabilités sans correctif disponible.
Questions de suivi probables
- Pourquoi le score de base CVSS seul est-il une mauvaise façon de prioriser le patching ?
- Comment EPSS ou CISA KEV changent-ils votre ordre de remédiation ?
- Que faites-vous d'une vulnérabilité critique sans correctif disponible ?