Vulnérabilité en clair

Qu’est-ce qu’une vulnérabilité ?

On appelle Vulnérabilité une faille isolée, techniquement exploitable : un dépassement de tampon, une désérialisation non sécurisée ou une dépendance vulnérable dans une bibliothèque logicielle. Cette page prend le point de vue technique : comment une faille est identifiée, évaluée et corrigée tout au long de son cycle de vie. La vue d’ensemble organisationnelle — processus, responsabilité, preuve d’audit — est traitée dans la page consacrée à la Gestion des vulnérabilités. Les failles connues reçoivent un identifiant CVE unique (Common Vulnerabilities and Exposures) et sont classées selon leur gravité par un score CVSS de 0 à 10. En complément, le score EPSS estime la probabilité qu’une faille soit effectivement exploitée — un signal précieux pour fixer les priorités.

Notation : CVE, CVSS et EPSS

Le score CVSS décrit le potentiel de dommage théorique, mais ne dit rien de l’exploitation effective d’une faille. C’est là qu’intervient l’EPSS : il pronostique la probabilité d’exploitation dans les 30 jours à venir. Si la faille figure en outre au catalogue KEV (Known Exploited Vulnerabilities), elle est démontrablement utilisée et passe tout en haut de la pile. Seule la combinaison de la gravité (CVSS), de la probabilité (EPSS) et de l’exposition du système donne une priorisation technique solide.

Failles connues et zero-days

Pour la plupart des CVE répertoriées, un correctif existe déjà : elles ne restent dangereuses que parce que la mise à jour n’est pas installée. Il en va autrement des « zero-days » : ils sont exploités avant que l’éditeur ne livre un correctif. Tant qu’aucun correctif n’est disponible, seules comptent les mesures compensatoires — correctif virtuel par règle de pare-feu applicatif, filtrage réseau supplémentaire, durcissement de la configuration ou arrêt temporaire du service concerné.

Le processus technique de traitement

L’outillage automatise le cycle de vie : scanners de vulnérabilités et outils d’analyse de composition logicielle confrontent en continu systèmes, conteneurs et dépendances aux bases CVE ; un SBOM (nomenclature logicielle) est ce qui rend les composants vulnérables visibles. Du constat découle un délai de correction contraignant, calé sur la criticité. Les signes d’une exploitation déjà en cours, eux, viennent des Indicateurs de compromission.

• Identification : passage du scanner, rapprochement SBOM et import des flux (NVD, KEV, avis des éditeurs).
• Évaluation : pondérer la gravité CVSS, la probabilité EPSS et l’exposition réelle du système.
• Traitement : appliquer le correctif dans le délai fixé ; à défaut, durcissement ou correctif virtuel en contournement.
• Vérification : relancer un scan, qui ne doit plus signaler la faille refermée.
• Documentation : consigner l’horodatage, la mesure prise et la preuve du nouveau scan.

Les délais de correction en pratique

Des délais échelonnés ont fait leurs preuves : failles critiques (CVSS 9.0–10.0) sous 24 à 72 heures, élevées sous sept jours, moyennes sous 30 jours. Exemple : un scanner signale CVE-2026-XXXX, CVSS 9.8 et EPSS élevé, dans une bibliothèque du portail client accessible publiquement. Gravité, probabilité et exposition se rejoignant, le délai de 24 heures s’applique : l’équipe installe une mise à jour d’urgence, cherche dans les journaux les indicateurs de compromission et confirme par un nouveau scan que la faille est refermée. Ainsi ne naît aucun incident important à déclarer. Cette discipline technique relève de la gestion des risques et de la Cyberhygiène que l’article 21 de la directive exige. En France, la loi de transposition n’est pas promulguée : ces exigences n’y sont pas encore opposables, mais la discipline technique, elle, ne dépend d’aucun calendrier.

Pour aller plus loin : ENISA – Agence de l’Union européenne pour la cybersécurité