Points clés
- Les vulnérabilités s'accumulent principalement dans les angles morts du patrimoine applicatif : applications legacy, composants tiers non inventoriés, assets oubliés.
- Un CMDB incomplet ou non maintenu est le premier facteur d'accumulation : on ne corrige pas ce qu'on ne sait pas posséder.
- La dette technique non traitée est une dette de sécurité : chaque report de mise à niveau d'un composant déprécié élargit la surface vulnérable.
- La direction doit exiger un inventaire des actifs numériques à jour comme prérequis à tout programme de gestion des vulnérabilités.
La gestion des vulnérabilités échoue rarement sur les systèmes que l'organisation surveille activement. Elle échoue sur ceux qu'elle ignore, sous-estime ou a oubliés. Ce paradoxe — l'accumulation des failles là où le regard ne porte pas — est l'une des causes structurelles les plus fréquemment citées dans les analyses post-incident.
Pour comprendre pourquoi les vulnérabilités s'accumulent, il faut examiner les mécanismes organisationnels et techniques qui créent ces angles morts : inventaires insuffisants, dépendances logicielles non tracées, obsolescence acceptée par défaut, et fragmentation des responsabilités entre équipes IT.
L'inventaire des actifs : fondation défaillante du patch management
Un programme de gestion des vulnérabilités ne peut couvrir que les actifs connus. Or, dans la grande majorité des organisations de taille intermédiaire ou supérieure, le CMDB (Configuration Management Database) est incomplet, périmé ou mal alimenté. Des serveurs provisoirement déployés deviennent permanents sans être enregistrés. Des applications métier développées en interne sont déployées sans passer par le processus de mise en production formel. Des composants open source sont intégrés sans être inventoriés.
Le résultat est une surface d'attaque réelle significativement plus étendue que la surface connue. Les outils de découverte automatique des actifs — scanners de réseau, agents de collecte, solutions CSPM pour les environnements cloud — permettent de réduire cet écart, mais leur déploiement et leur maintenance requièrent une gouvernance active.
La dette technique comme vecteur d'accumulation silencieuse
Les composants logiciels dépassent leur cycle de support selon un calendrier connu. Un système d'exploitation en fin de vie, une bibliothèque dont la maintenance a cessé, un middleware dont le fournisseur n'émet plus de correctifs : ces situations génèrent des failles permanentes pour lesquelles aucun patch n'existera jamais. La seule résolution est la migration ou le remplacement — opérations coûteuses que les équipes IT tendent à reporter.
Chaque trimestre de report est un trimestre pendant lequel de nouvelles CVE peuvent affecter ces composants sans possibilité de correction. Le NIST SP 800-53 et le CIS Controls v8 identifient explicitement la gestion du cycle de vie des composants comme un contrôle fondamental, distinct du patch management classique.
La fragmentation des responsabilités comme facteur aggravant
Dans les organisations où l'IT est structurée par silos — infrastructure, applicatif, sécurité, cloud — la responsabilité du patch management peut être fragmentée ou ambiguë. Un composant applicatif peut relever de l'équipe applicative pour son déploiement mais de l'équipe infrastructure pour sa mise à jour système, avec un tiers — un prestataire — responsable de la couche intermédiaire. Cette fragmentation produit des zones grises où personne ne prend l'initiative de corriger.
La violation de données de Capital One a exposé les informations de plus de 100 millions de clients. L'exploitation a porté sur une mauvaise configuration d'un service cloud AWS non correctement inventorié dans le programme de gestion des risques de l'entreprise. L'enquête a révélé que l'actif vulnérable n'était pas couvert par les processus de revue de sécurité habituels — il était dans un angle mort de l'inventaire. L'amende OCC a atteint 80 millions de dollars.
Le rapport annuel de l'ENISA sur le panorama des menaces en Europe a documenté que dans une majorité d'incidents analysés impliquant des entités NIS, le vecteur d'entrée initial était un composant externe ou un asset périphérique non inclus dans le périmètre de patch management officiel. L'ENISA a recommandé l'adoption systématique d'outils de découverte automatique des actifs comme prérequis aux programmes de gestion des vulnérabilités.
Le MAS a publié des conclusions d'audit révélant que plusieurs institutions financières supervisées présentaient des lacunes significatives dans l'inventaire de leurs actifs IT, notamment pour les systèmes legacy et les composants applicatifs de tiers. Le MAS Technology Risk Management Guidelines impose désormais que l'inventaire des actifs soit maintenu en temps réel et couvre l'ensemble du patrimoine numérique, y compris les dépendances open source.