Les vulnérabilités, risque permanent mais gérable
Chaque jour, des milliers de vulnérabilités sont publiées : failles dans des systèmes d’exploitation, bibliothèques open source, applications métier, équipements réseau. La majorité des compromissions exploitent des vulnérabilités connues depuis des mois, voire des années, mais non corrigées chez la victime. Une gestion structurée des vulnérabilités est donc une discipline de base pour toute organisation, y compris les PME. Ce tutoriel propose un processus simple et progressif.
Comprendre le cycle des vulnérabilités
Une vulnérabilité suit un parcours type : découverte (par le fournisseur, un chercheur, un attaquant), divulgation (souvent avec publication d’un identifiant CVE), disponibilité d’un correctif, déploiement du correctif chez les utilisateurs. Entre la divulgation et le déploiement, la fenêtre d’exposition est critique : les attaquants développent rapidement des exploits et scannent internet pour trouver des cibles vulnérables.
Le score CVSS, de 0 à 10, indique la gravité théorique. Le score EPSS estime la probabilité d’exploitation. Ces métriques guident la priorisation.
Étape 1 : cartographier les actifs
On ne peut corriger que ce qu’on connaît. Listez les actifs logiciels : systèmes d’exploitation (postes et serveurs), navigateurs, suites bureautiques, applications métier, équipements réseau, applications web développées en interne, plugins WordPress, bibliothèques utilisées dans les développements.
Pour chaque actif : version installée, fournisseur, criticité, date de dernière mise à jour. Un tableur structuré suffit pour une PME, complété par un outil de découverte si le parc est étendu.
Les dépendances des développements
Le code développé en interne utilise des bibliothèques open source tierces. Ces bibliothèques ont elles-mêmes des dépendances. Un projet moderne peut facilement utiliser plusieurs centaines de dépendances transitives, chacune pouvant contenir une vulnérabilité. Les outils SBOM (Software Bill of Materials) et SCA (Software Composition Analysis) listent ces composants et identifient les vulnérabilités connues.
Étape 2 : détecter les vulnérabilités
Plusieurs sources d’information se complètent. Les alertes des fournisseurs (Microsoft, Apple, Adobe, fabricants réseau) annoncent les nouvelles failles. Les scanners de vulnérabilités (Nessus Essentials gratuit pour 16 IP, OpenVAS open source, Qualys, Rapid7) examinent systématiquement les actifs et produisent des rapports.
Pour les applications web, OWASP ZAP, Burp Suite, Nuclei identifient les faiblesses spécifiques au web. Pour les containers et infrastructures cloud, Trivy, Snyk, Wiz couvrent ces environnements.
S’abonner aux flux d’alerte
Abonnez-vous aux flux officiels : CVE (cve.mitre.org), NVD (nvd.nist.gov), alertes de l’autorité nationale de cybersécurité. Filtrez selon vos technologies. Des plateformes comme vulners, CERT-FR permettent des recherches ciblées.
Étape 3 : prioriser
Toutes les vulnérabilités ne méritent pas le même traitement. Priorisez selon plusieurs critères : score CVSS, probabilité d’exploitation (EPSS), exposition de l’actif concerné (public ou interne), criticité métier de l’actif, disponibilité d’un exploit public, présence dans les catalogues d’exploitations actives (KEV de la CISA).
Une vulnérabilité critique sur un serveur exposé sur internet avec exploit public active et donnée sensible traitée : action immédiate. Une vulnérabilité moyenne sur un poste isolé sans exploit public : planification normale.
Étape 4 : corriger
Le correctif est la réponse préférée, mais pas toujours immédiatement applicable : incompatibilité avec l’application métier, fenêtre de maintenance indisponible, dépendance à valider. Dans ces cas, mettez en place des contrôles compensatoires : règles de filtrage au pare-feu, désactivation temporaire du service, surveillance renforcée.
Définissez des SLA internes : critique corrigé sous 7 jours, élevé sous 30 jours, moyen sous 90 jours, faible sous 6 mois. Documentez les exceptions justifiées.
Automatiser ce qui peut l’être
Les mises à jour automatiques sur les postes de travail (Windows Update, Microsoft 365, navigateurs) réduisent drastiquement la charge. Sur les serveurs, la prudence est requise : un correctif peut casser un service. Des environnements de test permettent de valider avant déploiement en production.
Les outils de gestion de parc (Microsoft Intune, Jamf, PDQ, Chocolatey pour Windows) déploient les mises à jour à l’échelle du parc avec reporting.
Étape 5 : vérifier
Un correctif est supposé installé, mais l’est-il réellement ? Relancez le scanner de vulnérabilités après déploiement pour confirmer. Documentez les réussites et les échecs. Un correctif incomplètement déployé laisse des angles morts.
Gérer les vulnérabilités zero-day
Une vulnérabilité zero-day est exploitée avant qu’un correctif ne soit disponible. Ces situations, bien que rares, appellent une posture particulière : surveiller l’actualité sécurité, appliquer les mesures d’atténuation proposées par le fournisseur, renforcer temporairement la surveillance, limiter l’exposition.
Les vulnérabilités dans les développements internes
Les équipes de développement doivent intégrer la sécurité : revues de code, analyse statique automatisée (SAST) à chaque commit, tests dynamiques (DAST) sur les environnements de pré-production, scan des dépendances (Dependabot, Snyk). Les chaînes CI/CD modernes intègrent ces contrôles de manière transparente.
La gestion des vulnérabilités dans les contrats
Si vous utilisez des logiciels développés par des prestataires, intégrez des clauses : engagement de correction dans un délai défini, possibilité de test de sécurité, responsabilité en cas de vulnérabilité exploitée. Ces clauses sont rarement négociées par les PME mais mériteraient de l’être.
Communiquer et documenter
Tenez un registre des vulnérabilités identifiées, corrigées, acceptées (risque résiduel conscient). Ce registre sert à la direction (vision du risque), aux auditeurs (traçabilité), aux équipes (priorisation). Rapport mensuel à la direction : top 5 des vulnérabilités critiques, taux de correction dans les SLA, tendance.
Gérer les équipements en fin de vie
Un système d’exploitation ou un équipement qui n’est plus maintenu par son fournisseur ne reçoit plus de correctifs. Il devient une dette technique dangereuse. Planifiez les remplacements avant la fin de support. Pour les cas où le remplacement n’est pas immédiatement possible, isolez le système dans un segment réseau limité.
Mesurer la progression
Indicateurs utiles : nombre de vulnérabilités critiques en cours, âge moyen des vulnérabilités non corrigées, pourcentage d’actifs scannés, taux de correction dans les SLA, réduction des vulnérabilités au fil des mois. Ces mesures objectivent les progrès.
Conclusion : la discipline plus que la sophistication
La gestion des vulnérabilités n’est pas un domaine glamour, mais c’est l’un des plus rentables en matière de sécurité. Corriger rapidement ce qui est connu élimine la majorité des risques. Pour une PME, mettre en place un processus simple mais régulier (scan mensuel, priorisation claire, correctifs dans les SLA, vérification) transforme la posture de sécurité. Commencez modestement : inventaire sur tableur, scanner gratuit sur le périmètre externe, réunion mensuelle de revue. Ces bases, suivies dans la durée, font la différence.