CompTIA SY0-701: Gestion des vulnérabilités et gestion des correctifs — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

La gestion des vulnérabilités est le processus continu d’identification, de classification, de remédiation et de vérification des faiblesses de sécurité dans l’ensemble du parc technologique d’une organisation. Il ne s’agit pas d’un projet avec une date de fin, mais d’une discipline opérationnelle qui doit suivre le rythme d’un paysage de menaces qui produit des centaines de nouvelles CVE chaque semaine.

Le cycle de vie de la gestion des vulnérabilités

Le cycle de vie commence par la découverte des actifs — on ne peut pas protéger ce dont on ignore l’existence. L’analyse active (Nessus, Qualys, Rapid7) sonde le réseau à la recherche d’hôtes actifs et de services ouverts. La découverte passive (analyse du trafic réseau, journaux DHCP, intégration CMDB) détecte les actifs que les analyses actives manquent. Les environnements cloud nécessitent une découverte basée sur les API, car l’analyse réseau traditionnelle ne répertorie pas les fonctions serverless, les services gérés ou les conteneurs éphémères.

L’analyse suit la découverte. Les analyses authentifiées offrent une visibilité complète sur les logiciels installés, les niveaux de correctifs et les faiblesses de configuration. Les analyses non authentifiées sont utiles pour l’évaluation de la surface d’attaque externe mais manquent la majorité des vulnérabilités. La fréquence des analyses doit correspondre au risque : hebdomadaire pour les actifs exposés à Internet, mensuelle pour les serveurs internes, mensuelle pour les postes de travail avec une surveillance continue basée sur des agents.

La priorisation utilise le CVSS comme base de référence mais doit intégrer le contexte. Une vulnérabilité CVSS 9.8 sur un serveur de développement isolé physiquement est moins urgente qu’une vulnérabilité CVSS 7.5 sur un point de terminaison d’authentification public. Les scores EPSS, l’appartenance au catalogue KEV, la criticité des actifs et les contrôles compensatoires ajustent tous la priorité effective. L’objectif n’est pas de tout corriger — c’est de corriger les bonnes choses en premier.

Les options de remédiation incluent l’application de correctifs (privilégiée), la modification de la configuration (désactivation d’une fonctionnalité vulnérable), l’application de correctifs virtuels (règle WAF bloquant l’exploitation), l’isolement réseau ou l’acceptation formelle avec une justification documentée. Les SLA de remédiation doivent être définis et suivis ; les exceptions nécessitent une approbation et un contrôle compensatoire.

La vérification confirme que la remédiation a été efficace. Une nouvelle analyse après l’application du correctif confirme que la vulnérabilité n’est plus présente. La vérification est souvent négligée par manque de temps, ce qui conduit à des situations où un correctif a été déployé mais pas appliqué correctement, ou où la vulnérabilité a été corrigée sur une instance mais pas sur d’autres du même niveau.

Opérations de gestion des correctifs

La gestion des correctifs opérationnalise la phase de remédiation. Un programme mature inclut un pipeline de test des correctifs : les correctifs sont d’abord appliqués à un environnement de non-production, validés pour leur compatibilité et leur fonctionnalité, puis promus en production via un processus de gestion des changements. Les correctifs d’urgence pour les vulnérabilités activement exploitées peuvent contourner le cycle de test complet avec une approbation de changement accélérée.

Windows Server Update Services (WSUS) et Microsoft Endpoint Configuration Manager (MECM/SCCM) sont des outils courants pour gérer les correctifs Windows à grande échelle. Les environnements Linux utilisent des gestionnaires de paquets (apt, yum, dnf) combinés à des outils d’automatisation (Ansible, Puppet, Chef) pour appliquer l’état des correctifs. Les environnements natifs du cloud utilisent AWS Systems Manager Patch Manager, Azure Update Management ou des services équivalents.

Les rapports de conformité des correctifs suivent le pourcentage d’actifs respectant les SLA pour chaque niveau de gravité. Un tableau de bord affichant une conformité de 94 % pour les correctifs critiques semble acceptable jusqu’à ce que vous réalisiez que 6 % de 10 000 points de terminaison représentent 600 systèmes non corrigés — chacun étant un point d’entrée potentiel. Les chiffres absolus comptent autant que les pourcentages.

Gestion de la configuration et bases de référence

La gestion de la configuration maintient les systèmes dans un état connu et sécurisé. Les bases de référence de configuration définissent l’état approuvé pour chaque type de système ; la détection de dérive identifie les écarts par rapport à cette base de référence. Des outils comme CIS-CAT Pro, OpenSCAP et des services natifs du cloud (AWS Config, Azure Policy) évaluent en continu la conformité de la configuration et alertent en cas de dérive.

La gestion des changements régit les modifications apportées aux systèmes de production. Chaque changement doit avoir une justification documentée, une évaluation des risques, un plan de retour en arrière et l’approbation des parties prenantes appropriées. Les changements d’urgence — requis en dehors de la fenêtre de changement normale — suivent un processus accéléré avec une revue post-implémentation. Les changements non autorisés détectés par les outils de gestion de la configuration sont traités comme des événements de sécurité jusqu’à preuve du contraire.

Scénario pratique : Réponse à Log4Shell sous pression

Lorsque la CVE-2021-44228 (Log4Shell) a été divulguée le 9 décembre 2021, avec un score CVSS de 10.0 et une exploitation active dans les heures qui ont suivi sa divulgation, les organisations ont fait face à une crise qui a mis à l’épreuve chaque aspect de leurs programmes de gestion des vulnérabilités. Une entreprise technologique dotée d’un programme mature a réagi comme suit : en deux heures, l’équipe de sécurité a interrogé son inventaire d’actifs pour toutes les applications Java et a identifié 847 systèmes potentiellement affectés. En six heures, elle avait confirmé que 312 systèmes exécutaient des versions vulnérables de Log4j grâce à une analyse authentifiée. En 24 heures, elle avait déployé des règles WAF bloquant le modèle de chaîne ${jndi: comme contrôle compensatoire temporaire sur tous les systèmes exposés à Internet. En 72 heures, 89 % des systèmes critiques étaient corrigés. Les 11 % restants ont été isolés sur des segments réseau restreints en attendant l’approbation des propriétaires d’applications pour les fenêtres d’application des correctifs. Le succès du programme dépendait de trois prérequis qui manquaient à de nombreuses organisations : un inventaire d’actifs complet et précis ; une capacité d’analyse authentifiée ; et des procédures de changement d’urgence pré-approuvées qui pouvaient être invoquées sans un cycle d’approbation d’une semaine.

← Sécurité des terminaux · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →