Hiérarchisation et correction des vulnérabilités CVE

Votre outil de scan des vulnérabilités vient de recenser 4 000 CVE non corrigées sur l'ensemble de votre parc informatique. Vous disposez d'une équipe de trois personnes. Savoir lesquelles corriger en priorité, et comment les corriger efficacement, fait toute la différence entre une gestion maîtrisée des risques et une faille de sécurité inévitable.

Ce guide explique comment les équipes informatiques et de sécurité expérimentées abordent concrètement la hiérarchisation et la correction des CVE : à quels systèmes de notation se fier, comment intégrer le contexte métier et comment mettre en place un workflow reproductible qui ne cède pas sous le poids du volume actuel de divulgations de vulnérabilités.

Que signifie réellement la hiérarchisation des CVE ?

Un CVE (Common Vulnerabilities and Exposures) est un identifiant standardisé désignant une vulnérabilité de sécurité rendue publique. La National Vulnerability Database (NVD) attribue à chacune d’elles un score à l’aide du Common Vulnerability Scoring System (CVSS), qui évalue la gravité sur une échelle de 0 à 10.

La hiérarchisation consiste à déterminer quelles CVE votre équipe doit corriger en priorité, et lesquelles vous acceptez, reportez ou atténuez à l’aide de contrôles compensatoires. Cela semble simple. Le problème est que le score CVSS brut n’a jamais été conçu pour refléter le risque spécifique de votre organisation, et le considérer comme le seul critère de décision conduit à un gaspillage d’efforts.

Une vulnérabilité notée 9,8 selon le CVSS dans un logiciel qui n’est installé nulle part dans votre environnement n’a aucune incidence pratique. Une vulnérabilité notée 5,4 selon le CVSS dans un service accessible au public qui traite des données de paiement est urgente. La hiérarchisation consiste à mettre en adéquation la gravité avec la réalité.

Pourquoi les scores CVSS ne suffisent pas à eux seuls

Le CVSS mesure la gravité intrinsèque d’une vulnérabilité dans des conditions d’exploitation idéales. Il ne tient pas compte :

• L'exploitabilité en conditions réelles. Il s'agit de savoir si un exploit fonctionnel existe réellement, s'il est accessible au public et s'il est activement utilisé par des acteurs malveillants.
• L’exposition de l’actif. Le système vulnérable est-il connecté à Internet, isolé ou en « air gap » ?
• La criticité pour l’entreprise. L’actif affecté héberge-t-il votre produit phare, stocke-t-il des données réglementées ou s’agit-il d’une machine de test dans un environnement de développement ?
• Les contrôles existants. Le fait que des contrôles compensatoires (segmentation du réseau, EDR, liste blanche des applications) réduisent déjà l’exploitabilité.

C’est pourquoi la communauté de la cybersécurité s’est largement orientée vers des cadres de gestion des vulnérabilités basés sur les risques, qui viennent s’ajouter au CVSS plutôt que de le remplacer.

Cadres de notation qui ajoutent un contexte concret

EPSS (Exploit Prediction Scoring System)

Géré par le Forum of Incident Response and Security Teams (FIRST), l’Exploit Prediction Scoring System (EPSS) utilise l’apprentissage automatique pour estimer la probabilité qu’une vulnérabilité CVE soit exploitée en conditions réelles au cours des 30 prochains jours. Les scores EPSS vont de 0 à 1 (probabilité de 0 % à 100 %).

La combinaison d’un niveau de gravité CVSS élevé et d’un score EPSS élevé indique clairement qu’une vulnérabilité CVE mérite une attention immédiate. Un CVSS de 7,5 associé à un score EPSS de 0,94 est bien plus urgent qu’un CVSS de 9,1 associé à un score EPSS de 0,003.

CISA KEV (Catalogue des vulnérabilités connues pour être exploitées)

Le catalogue des vulnérabilités connues et exploitées de la CISA est une liste sélectionnée de CVE dont la CISA a confirmé qu’elles sont activement exploitées dans la nature. Les agences fédérales sont tenues de corriger les entrées du KEV dans un délai défini. Pour les organisations non fédérales, la présence sur la liste KEV doit déclencher une procédure de correction accélérée, quel que soit votre SLA standard.

Référentiels CIS et NIST SP 800-40

La publication spéciale 800-40 du NIST fournit des recommandations en matière de gestion des correctifs pour les entreprises, notamment des critères de priorisation basés sur les risques. Les contrôles de sécurité critiques du CIS (en particulier le contrôle n° 7, « Gestion continue des vulnérabilités ») recommandent de hiérarchiser les mesures correctives en fonction du score CVSS, de la criticité des actifs et des renseignements sur les menaces, dans cet ordre.

Mise en place d’un workflow de hiérarchisation des CVE

Un processus de hiérarchisation reproductible suit généralement les étapes suivantes :

1. Dressez l’inventaire de vos actifs. Vous ne pouvez pas hiérarchiser ce que vous ne voyez pas. Un inventaire matériel complet et à jour est la condition préalable à tout programme de gestion des vulnérabilités. Chaque appareil non géré constitue un angle mort.

2. Effectuez des analyses de vulnérabilité en continu. Les analyses programmées ne couvrent pas la période comprise entre la divulgation d’un CVE et votre prochain cycle d’analyse. Une analyse continue ou en temps quasi réel comble cette lacune. Consultez le détail complet dans « Analyse des vulnérabilités : guide pratique ».

3. Filtrez d’abord selon la liste KEV de la CISA. Tout CVE figurant sur la liste KEV et affectant votre environnement passe en tête de file. Sans exception.

4. Évaluez les CVE restants en fonction d’un risque combiné. Utilisez le CVSS + l’EPSS + la criticité de l’actif + le niveau d’exposition. Certaines équipes établissent un simple score pondéré dans un tableur ; d’autres utilisent une plateforme dédiée à la gestion des vulnérabilités.

5. Attribuez des niveaux de SLA. Voici une structure courante :

- Critique (CVSS ≥ 9,0 ou figurant sur la liste KEV) : correction dans un délai de 24 à 72 heures

- Élevé (CVSS 7,0-8,9, EPSS élevé) : remédier dans un délai de 7 à 14 jours

- Moyen (CVSS 4,0 à 6,9) : correction dans un délai de 30 à 60 jours

- Faible (CVSS inférieur à 4,0) : remédier lors du prochain cycle de correctifs prévu ou accepter en justifiant formellement la décision

6. Documenter formellement les exceptions. Si vous ne pouvez pas corriger le problème dans les délais prévus par le SLA, documentez le contrôle compensatoire, la justification métier et la date de révision. Ce point est non négociable pour tout référentiel de conformité (SOC 2, ISO 27001, FedRAMP).

Correction des CVE : l’application de correctifs est une option, mais pas la seule

La correction consiste à réduire le risque présenté par une vulnérabilité CVE à un niveau acceptable. L’application d’un correctif est l’approche la plus courante, mais les options disponibles sont les suivantes :

• Appliquer le correctif du fournisseur. C’est la solution privilégiée dès lors qu’un correctif existe et peut être déployé sans perturber les systèmes dépendants.
• Modification de la configuration. Certains CVE ne sont exploitables que dans des configurations spécifiques. Le renforcement de la configuration élimine la possibilité d’exploitation sans avoir recours à un correctif.
• Contrôle compensatoire. La segmentation du réseau, les règles WAF ou la désactivation d’une fonctionnalité affectée peuvent réduire la vulnérabilité lorsqu’aucun correctif n’est disponible ou qu’il n’est pas sûr de le déployer immédiatement.
• Accepter le risque. Pour les CVE de faible gravité affectant des ressources isolées et non critiques, l’acceptation formelle du risque, accompagnée d’une documentation, constitue un choix légitime.

Les workflows de correction doivent également tenir compte des tests. Déployer un correctif du système d’exploitation sur 3 000 terminaux sans déploiement progressif, c’est s’assurer de se retrouver avec un parc informatique hors service un mardi matin. Un déploiement par étapes standard : groupe « canary » (1 à 5 % du parc), groupe pilote (10 à 15 %), déploiement à grande échelle.

Hiérarchisation des CVE dans les environnements Apple

Les parcs d’appareils Apple impliquent des considérations spécifiques. Apple corrige les vulnérabilités de macOS, iOS et iPadOS via des mises à jour du système d’exploitation et des « Rapid Security Responses » (RSR). Contrairement aux logiciels tiers, il n’est pas possible d’appliquer un correctif CVE à un composant du système d’exploitation Apple sans appliquer la mise à jour complète du système d’exploitation ou la RSR correspondante.

Cela signifie que la fréquence de vos correctifs pour les appareils Apple est liée à votre stratégie de déploiement MDM. Les mises à jour du système d’exploitation retardées entraînent une accumulation croissante de CVE non corrigées. Une visibilité à l’échelle du parc sur les versions du système d’exploitation et des logiciels installés constitue le point de départ. Si vous n’êtes pas à jour sur les principes fondamentaux de la gestion des appareils Apple, l’écart entre la divulgation d’une vulnérabilité et son déploiement se creusera plus vite que votre équipe ne pourra le suivre manuellement.

Apple publie des notes de sécurité pour chaque mise à jour, avec des références croisées aux identifiants CVE. En comparant ces notes à la répartition actuelle des versions du système d’exploitation au sein de votre parc, vous pouvez déterminer précisément le retard de chaque appareil.

Comment Iru aborde la hiérarchisation et la correction des CVE

Iru est spécialement conçu pour les parcs Apple, ce qui signifie que l’exposition aux CVE sur macOS, iOS, iPadOS et tvOS est une priorité absolue de la plateforme, et non une considération secondaire.

Iru surveille en permanence les versions des systèmes d’exploitation et les logiciels installés sur l’ensemble de votre parc. Lorsqu’Apple publie une mise à jour de sécurité, Iru identifie les appareils exécutant des versions vulnérables du système d’exploitation et établit une correspondance avec les CVE corrigées dans cette mise à jour. Vous visualisez votre exposition en termes concrets : pas seulement « mise à jour disponible », mais « X appareils exécutent des versions de macOS affectées par la faille CVE-2025-XXXX, qui figure sur la liste KEV de la CISA ».

La mise en œuvre des mesures correctives s’effectue via le moteur de conformité d’Iru. Vous pouvez définir une version minimale du système d’exploitation, fixer une date limite pour la mise en conformité et configurer des alertes progressives destinées aux utilisateurs finaux avant que la mise en application stricte ne soit déclenchée. Les déploiements par étapes sont intégrés au workflow de déploiement ; vous pouvez ainsi commencer par un groupe de test, valider, puis déployer à grande échelle sans avoir à écrire de scripts personnalisés.

Côté logiciel, la bibliothèque de configurations d’applications gérées d’Iru vous permet de mettre à jour les applications tierces vulnérables sur l’ensemble de votre parc sans intervention manuelle au niveau des appareils. Associée aux intégrations d’Iru en matière de gestion des appareils et de sécurité, cette fonctionnalité vous offre une vue d’ensemble des vulnérabilités ainsi que les outils de mise en conformité nécessaires pour y remédier, le tout depuis une seule et même plateforme.

Choisir le bon rythme de correction pour votre parc

Le rythme approprié dépend de la tolérance au risque de votre organisation, de ses obligations de conformité et de sa capacité opérationnelle. Voici quelques repères pratiques :

• Les organisations soumises à la norme SOC 2 Type II s’engagent généralement à corriger les vulnérabilités critiques dans un délai de 30 jours, de nombreux auditeurs exigeant désormais un délai de 14 jours, voire moins, pour les CVE répertoriées dans la liste KEV.
• La norme FedRAMP High exige la correction des CVE critiques dans un délai de 30 jours et celle des CVE à haut niveau de gravité dans un délai de 90 jours.
• La norme CIS Control 7.4 recommande le déploiement automatisé des correctifs dans la mesure du possible afin de réduire les retards humains dans le processus de correction.

La véritable contrainte réside dans la capacité de l’équipe. Une équipe informatique de deux personnes gérant 500 terminaux ne peut pas suivre et corriger manuellement chaque CVE chaque semaine. L’automatisation, des niveaux de SLA clairs et des outils mettant en évidence les actions prioritaires permettent aux petites équipes de maintenir une posture de défense solide.

Si vous mettez en place ou affinez votre programme, commencez par la liste KEV de la CISA, intégrez une solution EPSS pour la hiérarchisation des priorités, puis automatisez l’application des correctifs du système d’exploitation pour votre parc Apple. Cette combinaison permet de traiter les vulnérabilités présentant la probabilité et l’impact les plus élevés avec un minimum d’intervention manuelle.

Prêt à combler le fossé entre la divulgation des CVE et leur correction sur votre parc Apple ? Découvrez comment la conformité continue et l’application automatisée des correctifs d’Iru fonctionnent dans la pratique en demandant une démonstration.