Chaque correctif logiciel non installé laisse ouverte une porte que des attaquants connaissent parfois mieux que l’éditeur lui-même. Les failles de sécurité exploitées lors d’intrusions concernent, dans une large part des cas documentés, des vulnérabilités pour lesquelles un correctif existait déjà au moment de l’attaque. La mise à jour des logiciels reste le levier de réduction du risque le plus direct, mais aussi celui dont l’application réelle pose le plus de difficultés opérationnelles.
Failles non corrigées et ré-intrusion : ce que montrent les retours d’incident
Les analyses post-incident révèlent un schéma récurrent. Une entreprise subit une attaque, mobilise des ressources pour y répondre, puis reprend son activité sans appliquer l’ensemble des correctifs liés à la compromission initiale. Quelques mois plus tard, la même faille, ou une faille voisine restée ouverte, sert de vecteur à une nouvelle intrusion.
Lire également : ODT en DOCX en toute sécurité : protéger vos documents sensibles
L’absence de mise à jour reste un facteur majeur de ré-intrusion, y compris lorsque l’organisation pense avoir traité le problème. Ce constat, documenté par des bulletins de réponse à incident, met en lumière un angle rarement abordé par les guides pédagogiques : corriger la faille exploitée ne suffit pas si le reste du parc logiciel accumule un retard de correctifs.
Le cas de systèmes de gestion de contenu (CMS) non patchés illustre bien cette dynamique. Des failles connues dans des versions obsolètes de certains CMS ont permis des exfiltrations de données sensibles sur des périodes prolongées, parce que les correctifs disponibles n’avaient jamais été déployés.
A lire également : Les failles dans les objets connectés menacent la vie privée
Directive NIS2 et responsabilité des dirigeants face aux correctifs de sécurité
Le cadre réglementaire européen a changé la donne depuis octobre 2024. La directive (UE) 2022/2555, dite NIS2, est applicable via les lois nationales depuis le 18 octobre 2024. Elle couvre 18 secteurs considérés comme critiques et impose aux entités concernées des mesures explicites de gestion des vulnérabilités.
Parmi ces mesures, la directive vise directement la gestion des mises à jour et des failles de sécurité dans l’acquisition, le développement et la maintenance des systèmes. L’approche retenue est celle du « tous risques » : il ne s’agit pas de corriger uniquement les failles jugées critiques, mais d’intégrer la maintenance logicielle dans un processus global.
Un point rarement relayé dans les contenus grand public : la direction de l’organisation est personnellement responsable de la mise en œuvre de ces mesures. Les amendes prévues peuvent atteindre plusieurs millions d’euros. Le défaut de gestion des correctifs n’est plus seulement un risque technique, c’est un risque juridique pour les dirigeants eux-mêmes.
Cyber Resilience Act : la pression se déplace aussi vers les éditeurs
En parallèle de NIS2, le Cyber Resilience Act (CRA) européen introduit une obligation pour les fabricants et éditeurs de produits comportant des éléments numériques. Ils devront fournir des mises à jour de sécurité pendant toute la durée de vie attendue du produit, ou au minimum cinq ans.
Le CRA prévoit également l’obligation de publier un SBOM (Software Bill of Materials), un inventaire des composants logiciels utilisés. L’objectif est de permettre aux utilisateurs et aux régulateurs d’identifier rapidement si un composant vulnérable est présent dans un produit donné. Les premières obligations entreront en vigueur progressivement d’ici 2027.
Vulnérabilités activement exploitées : le délai entre publication et attaque
Les agences de cybersécurité publient régulièrement des alertes sur des failles déjà utilisées dans des attaques au moment même où le correctif est rendu disponible. Des éditeurs majeurs, notamment dans les domaines de la virtualisation et des systèmes d’exploitation, ont publié des correctifs pour des vulnérabilités dont l’exploitation active était confirmée.
Ce phénomène réduit considérablement la fenêtre de réaction. Lorsqu’une faille est divulguée avec un correctif, le délai entre publication du patch et tentative d’exploitation se compte parfois en heures. Repousser l’installation d’un correctif de quelques semaines, dans ce contexte, revient à laisser une vulnérabilité documentée et connue des attaquants ouverte sur le réseau.
Les données disponibles ne permettent pas de fixer un délai moyen universel entre publication et exploitation. Les retours terrain divergent selon le type de faille, le logiciel concerné et la visibilité de la cible. En revanche, les bulletins d’alerte montrent une tendance nette : les failles les plus critiques sont exploitées de plus en plus vite.
Gestion des correctifs en entreprise : les obstacles concrets
Si le principe est simple (appliquer les mises à jour dès qu’elles sont disponibles), la réalité opérationnelle complique la mise en œuvre. Plusieurs facteurs ralentissent le déploiement des correctifs dans les organisations :
- La compatibilité applicative : un correctif système peut provoquer des régressions sur des applications métier anciennes, ce qui pousse les équipes à retarder l’installation le temps de tester
- La dette technique : des systèmes en fin de vie, qui ne reçoivent plus de mises à jour de la part de l’éditeur, restent en production faute de budget ou de plan de migration
- La fragmentation du parc : serveurs physiques, machines virtuelles, conteneurs, postes de travail, objets connectés – chaque catégorie suit un cycle de mise à jour différent, avec des outils et des responsabilités éclatés
- Les fenêtres de maintenance réduites : certaines infrastructures critiques ne tolèrent que quelques heures d’interruption par mois, ce qui limite le nombre de correctifs déployables à chaque cycle
Ces contraintes expliquent pourquoi le retard de correctifs (patch backlog) constitue un indicateur suivi par les équipes de sécurité. Réduire ce retard demande autant d’organisation que de technique, avec des processus de priorisation fondés sur la criticité réelle des failles et l’exposition des systèmes concernés.
Prioriser par le risque, pas par la date de publication
Toutes les mises à jour ne se valent pas. Un correctif pour une faille activement exploitée sur un serveur exposé à internet n’a pas la même urgence qu’une mise à jour fonctionnelle sur un poste isolé du réseau. Les organisations qui parviennent à maintenir un niveau de correctifs acceptable s’appuient généralement sur une classification des actifs par niveau d’exposition et sur les alertes des agences nationales de cybersécurité (ANSSI, CISA) pour ajuster leurs priorités.
La gestion des mises à jour logicielles se situe à la croisée de la technique, de la réglementation et de la gouvernance. Avec NIS2 et le Cyber Resilience Act, le non-respect des cycles de correctifs expose désormais à des sanctions financières et juridiques, en plus du risque d’intrusion lui-même. Pour les organisations concernées, la question n’est plus de savoir s’il faut mettre à jour, mais comment structurer un processus qui tient dans la durée.
