Prioriser les correctifs n’a jamais été aussi difficile : le dernier Patch Tuesday de Microsoft a corrigé un record de 974 vulnérabilités, dont deux failles déjà exploitées activement. Le même jour, Adobe publiait plus de 170 correctifs et SAP colmatait une faille notée CVSS 10.0. Pour une PME ou une ETI, la question n’est plus « avons-nous appliqué les mises à jour ? » mais « lesquelles d’abord, et avec quel délai acceptable ? ».
L’inflation des CVE change la nature du risque
Le volume publié par les éditeurs augmente plus vite que la capacité d’absorption des équipes. Une DSI de PME-ETI dispose rarement de plus de quelques jours-homme par mois pour le patch management, alors que le flux mensuel dépasse désormais le millier de références pour un seul éditeur. Mécaniquement, une part croissante du parc reste vulnérable en permanence.
Ce déséquilibre profite à l’attaquant, dont l’économie est inverse : il lui suffit d’une seule faille non corrigée sur un actif exposé. L’accélération de la découverte assistée par l’IA amplifie encore l’écart, comme nous l’évoquions dans notre analyse sur la réduction de la fenêtre de patch.
Le CVSS seul ne suffit plus
Trier par score CVSS produit des centaines de vulnérabilités « critiques » indifférenciées. Or la majorité d’entre elles ne seront jamais exploitées. Les données publiques d’exploitation montrent qu’une fraction très minoritaire des CVE publiées fait l’objet d’un exploit réel. Le score mesure la gravité théorique, pas la probabilité d’attaque.
Prioriser les correctifs par l’exposition réelle
Un modèle de priorisation exploitable en PME-ETI repose sur trois critères combinés, et non sur le seul CVSS :
- Exploitation observée : la vulnérabilité figure-t-elle au catalogue KEV de la CISA, ou un exploit public circule-t-il ? C’est le signal le plus fort.
- Exposition : l’actif est-il joignable depuis Internet, ou isolé derrière plusieurs segments réseau ? Un VPN, un serveur de messagerie ou une console d’administration exposée passent devant tout le reste.
- Criticité métier : la compromission de cet actif interrompt-elle la production, la facturation ou la paie ?
Une faille CVSS 7.5 sur un concentrateur VPN exposé mérite un traitement immédiat ; une CVSS 9.8 sur un composant interne jamais sollicité peut attendre le cycle mensuel. C’est exactement la logique qui s’imposait lors de l’exploitation de la faille critique sur les plateformes RMM : l’exposition primait sur le score.
Trois niveaux de délai à formaliser
- Sous 48 heures : faille exploitée activement sur un actif exposé (KEV, zero-day éditeur). Le correctif passe hors fenêtre de changement, avec validation a posteriori.
- Sous 7 jours : critique avec exploit public, ou exposé sans exploitation confirmée.
- Cycle mensuel : le reste, traité par lots automatisés avec redémarrage planifié.
Ces délais doivent être écrits, validés par la direction et mesurés. Un objectif non mesuré n’existe pas : le taux de respect du délai à 48 heures est l’indicateur le plus révélateur de la maturité réelle d’une organisation.
Ce qui rend la priorisation possible
Aucun tri n’est fiable sans inventaire à jour. Impossible de prioriser les correctifs sur un parc que l’on ne connaît qu’à 80 %. Les prérequis sont concrets :
- Un inventaire automatisé des actifs et des versions logicielles, alimenté en continu par les agents de supervision.
- Une cartographie de l’exposition Internet, revue au moins mensuellement : les actifs oubliés sont la première cause de compromission.
- L’automatisation des correctifs de bas risque, pour libérer le temps humain sur les décisions difficiles.
- Une capacité de mitigation temporaire quand le correctif n’existe pas encore : filtrage, désactivation de fonction, restriction d’accès.
Ce dernier point devient structurant. Les éditeurs publient de plus en plus d’avis avant la disponibilité d’un correctif complet, et le délai entre publication et exploitation se compte désormais en heures.
Le rôle de la détection quand le patch prend du retard
Prioriser les correctifs revient à accepter, de manière assumée, qu’une partie du parc reste vulnérable. Cette dette doit être compensée par la détection : journalisation centralisée, supervision des accès aux consoles d’administration, alerte sur les comportements post-exploitation plutôt que sur l’exploit lui-même. Un SOC qui détecte l’usage anormal d’un compte de service compense un correctif appliqué avec trois semaines de retard.
C’est la combinaison qui protège : un tri par exposition réelle, des délais formalisés, un inventaire fiable et une détection capable de couvrir le résiduel. À l’échelle actuelle de publication des vulnérabilités, prioriser les correctifs n’est plus une bonne pratique parmi d’autres, c’est la seule stratégie de patch management qui tienne dans la durée.