Gérer les vulnérabilités logicielles : processus pour PME

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.

Étape 1 : cadrer la gestion des vulnérabilités pour une PME ouest-africaine

Une PME à Dakar, Lomé ou Douala n’a souvent ni RSSI ni budget pour un produit de gestion de vulnérabilités à six chiffres. Pourtant, négliger ce processus expose à des rançongiciels qui peuvent paralyser la facturation, le paiement Wave ou Mixx by Yas, et la relation client pendant plusieurs jours. Le coût d’arrêt moyen pour une PME locale (estimation interne, équipe de 30 personnes, marge de 10 % sur un CA mensuel de 30 millions FCFA soit environ 45 731 EUR au taux fixe 1 EUR = 655,957 FCFA) avoisine 1 000 000 FCFA par jour de panne.

L’objectif de ce tutoriel : poser un processus simple, exécutable par un binôme IT (un responsable et un technicien), reposant uniquement sur des outils gratuits ou peu coûteux, et qui couvre l’ensemble du cycle — inventaire, scan, priorisation, remédiation, vérification, documentation. Vous saurez à la fin de la lecture quelle commande lancer chaque lundi, quelle décision prendre face à une CVE critique, et comment prouver à votre direction que les correctifs ont bien été appliqués.

Étape 2 : construire l’inventaire des actifs en 90 minutes

On ne corrige pas ce qu’on ne connaît pas. Ouvrez une feuille Google Sheets ou Excel et créez un tableau avec sept colonnes : nom de l’actif, type (serveur, poste, équipement réseau, application web), OS et version, propriétaire métier, criticité (1=vitale, 2=importante, 3=secondaire), exposition (interne, DMZ, internet), date du dernier patch.

# Sur Linux/macOS, lister rapidement les machines actives sur le réseau local 192.168.1.0/24
sudo nmap -sn 192.168.1.0/24 -oG inventaire-$(date +%F).txt

# Côté Windows, exporter la liste des packages installés sur un poste
Get-Package | Select-Object Name, Version | Export-Csv -Path inventaire-poste.csv -NoTypeInformation

Une fois l’inventaire complet, vous saurez combien de Windows 10 22H2 vous avez encore (Microsoft a arrêté le support en octobre 2025, donc tout poste resté sur cette version est désormais à risque), combien de serveurs Ubuntu LTS, combien d’imprimantes mal sécurisées. Le test concluant : aucune ligne vide dans la colonne « version ».

Étape 3 : scanner les vulnérabilités avec OpenVAS et Nuclei

Pour les serveurs et postes, OpenVAS (devenu Greenbone Community Edition) reste la référence open source. Pour les applications web, Nuclei de ProjectDiscovery couvre des milliers de templates CVE en une commande. Installez Greenbone via Docker sur un VPS dédié à 5-10 EUR par mois.

# Lancer Greenbone Community Edition en Docker
mkdir greenbone && cd greenbone
curl -fsSL https://greenbone.github.io/docs/latest/_static/setup-and-start-greenbone-community-edition.sh -o gce.sh
sudo bash gce.sh
# Accédez ensuite à https://localhost:9392 dans le navigateur

# Scanner une application web avec Nuclei
nuclei -u https://app.votre-pme.sn -severity critical,high -o resultats-nuclei.txt

Le scan complet d’un parc de 30 machines prend en moyenne 4 à 6 heures. Lancez-le un dimanche soir. Indicateur que tout est en place : un rapport HTML listant les CVE, classées par sévérité CVSS.

Étape 4 : prioriser avec EPSS et CISA KEV plutôt que par CVSS seul

Une CVE critique CVSS 9.8 qui n’est exploitée nulle part dans le monde est moins urgente qu’une CVE de score 7.5 activement exploitée. Deux référentiels publics permettent cette priorisation : EPSS (Exploit Prediction Scoring System) qui donne une probabilité d’exploitation à 30 jours, et le catalogue CISA KEV (Known Exploited Vulnerabilities) qui liste les CVE prouvées en attaque réelle.

# Récupérer le catalogue CISA KEV en JSON
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
jq '.vulnerabilities | length' kev.json
# Vérifier si une CVE détectée est dans KEV
jq '.vulnerabilities[] | select(.cveID=="CVE-2024-1234")' kev.json

Règle simple à appliquer : toute CVE présente dans CISA KEV → SLA de remédiation 72 heures. Toute CVE avec EPSS > 0,5 → SLA 14 jours. Le reste → cycle mensuel.

Étape 5 : appliquer les correctifs avec une fenêtre de maintenance

Annoncez la fenêtre 48 heures à l’avance par e-mail interne et message WhatsApp Business. Choisissez un créneau de faible activité (vendredi soir 21h-23h ou dimanche matin pour les zones rurales). Avant tout patch, prenez un snapshot complet (VMware, Proxmox) ou un backup vérifié.

# Sur Ubuntu/Debian — patcher uniquement les paquets de sécurité
sudo apt-get update
sudo unattended-upgrade --dry-run -d
sudo unattended-upgrade -d

# Sur Windows Server — utiliser PSWindowsUpdate
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -Category 'Security Updates'
Install-WindowsUpdate -Category 'Security Updates' -AcceptAll -AutoReboot

Vérifiez après reboot que les services métier remontent (ERP, messagerie, site web). Comment vérifier le bon fonctionnement : un test de bout en bout passé (ex. créer une facture, envoyer un mail, charger la page d’accueil).

Étape 6 : vérifier la remédiation par re-scan

Un correctif appliqué ne signifie pas une CVE corrigée — il arrive qu’un service redémarre avec l’ancienne version (cache, conteneur Docker pinné, etc.). Relancez Nuclei ou Greenbone sur le périmètre patché et comparez avec le scan précédent.

# Comparer deux rapports Nuclei
diff <(sort resultats-avant.txt) <(sort resultats-apres.txt)
# Lignes commençant par "<" = vulnérabilités corrigées (bon signe)
# Lignes commençant par ">" = nouvelles vulnérabilités (à investiguer)

Si une CVE persiste, documentez la raison : exception métier (logiciel non patché par l’éditeur), workaround appliqué (règle WAF, désactivation d’un module), ou simple oubli à reprogrammer.

Étape 7 : documenter et reporter à la direction

Sans reporting, le processus s’éteint au bout de deux mois. Préparez un tableau de bord mensuel d’une seule page avec quatre indicateurs : nombre de CVE critiques ouvertes, délai moyen de remédiation, taux de respect du SLA KEV (objectif > 90 %), nombre de scans réalisés. Présentez-le en comité de direction tous les premiers lundis du mois, en moins de 10 minutes.

# Générer un PDF synthétique avec pandoc à partir d'un Markdown
pandoc rapport-vulnerabilites-2026-04.md -o rapport-vulnerabilites-2026-04.pdf \
  --pdf-engine=xelatex -V geometry:margin=2cm

Conservez tous les rapports dans un dossier versionné Git ou un drive partagé avec contrôle d’accès. En cas d’audit (banque, partenaire international, certification ISO), vous prouverez la régularité du processus.

Étape 8 : automatiser progressivement

Une fois le rythme installé pendant trois mois, automatisez ce qui peut l’être : lancement hebdomadaire de Nuclei via cron, ingestion du catalogue KEV chaque matin, alerte WhatsApp via API officielle Meta v25.0 si une CVE critique apparaît. N’automatisez jamais l’application des correctifs en production sans validation humaine — un patch qui casse l’ERP un vendredi soir vaut autant qu’une attaque réussie.

Pour approfondir sur la sécurité applicative en amont, consultez notre tutoriel sur la mise en place d’un SDLC sécurisé pour PME, et pour la dimension réseau le durcissement d’un VPS Linux exposé sur internet.