Gestion des vulnérabilités IT : comment bâtir un programme proactif en 2026

En bref : 48 185 CVE ont été publiées en 2025 — une hausse de 263 % depuis 2020. Le délai médian d'exploitation est passé de 45 jours à moins de 5 jours. Depuis avril 2026, le NIST ne peut plus enrichir l'ensemble des entrées de la NVD. Pour les équipes de sécurité et équipes informatiques, la gestion des vulnérabilités IT n'est plus un processus trimestriel : c'est une boucle continue qui conditionne directement la posture de sécurité de l'organisation.

Avant d'aborder le cycle opérationnel, il faut maîtriser le vocabulaire de l'écosystème. Ces acronymes reviennent dans chaque outil de gestion des vulnérabilités, chaque rapport, chaque échange avec les régulateurs.

Un point souvent mal compris : Heartbleed (CVE-2014-0160) avait un score CVSS de 5.0 malgré un impact mondial. Spectre (CVE-2017-5753) était scoré 4.7. Le score seul ne suffit pas à identifier les problèmes de sécurité réellement critiques pour votre infrastructure informatique.

Un programme réactif attend qu'une alerte déclenche l'action. Il s'appuie sur des scans ponctuels et mesure son activité par le nombre de tickets fermés.

Un programme proactif anticipe : il détecte les vulnérabilités avant que les attaquants ne les exploitent, priorise selon le risque réel, et produit des métriques de réduction des risques mesurables.

Trois réalités rendent l'approche réactive insuffisante en 2026.

• Le volume dépasse la capacité. Les équipes informatiques ne corrigent que 10 à 15 % de leur backlog mensuel. Sans priorisation rigoureuse, les équipes de sécurité passent l'essentiel de leur temps sur des vulnérabilités que les attaquants n'utiliseront jamais.

• La fenêtre d'exploitation s'est effondrée. Le délai médian entre la publication d'une CVE critique et son exploitation active est passé de 45 jours en 2020 à moins de 5 jours en 2025. Des agents IA offensifs génèrent des exploits fonctionnels en 10 à 15 minutes pour environ 1 dollar par tentative (Cloud Security Alliance, 2026).

• La NVD n'est plus exhaustive. Depuis le 15 avril 2026, le NIST priorise l'enrichissement des CVE KEV, des logiciels fédéraux américains et des logiciels critiques. Les autres CVE ne sont plus enrichies systématiquement — sans score CVSS ni description d'impact disponible immédiatement. Les équipes de sécurité qui s'appuient uniquement sur la NVD travaillent désormais avec une information incomplète.

Pendant longtemps, la maturité d'un programme de gestion des vulnérabilités était associée à sa capacité à identifier toujours plus de failles. L'évolution des scanners, des outils SAST, SCA et désormais de l'intelligence artificielle a profondément changé cette réalité.

Aujourd'hui, les organisations génèrent des milliers, voire des dizaines de milliers de findings chaque mois. Pourtant, seule une fraction de ces résultats aboutit à une action de remédiation concrète.

Le défi n'est donc plus de produire davantage d'alertes, mais de distinguer :

• les vulnérabilités réellement exploitables ;

• les actifs effectivement exposés ;

• les risques susceptibles d'impacter l'activité ;

• les actions capables de réduire significativement l'exposition de l'organisation.

Dans ce contexte, la valeur d'un programme de gestion des vulnérabilités ne se mesure plus au volume de findings détectés, mais à sa capacité à transformer des milliers de signaux en quelques actions prioritaires.

1 — Identifier les vulnérabilités : découverte et inventaire

Aucun programme ne peut identifier les vulnérabilités sur des actifs qu'il ne connaît pas. La première étape est un inventaire vivant : systèmes d'exploitation, applications, cloud, conteneurs, APIs, équipements réseau. L'inventaire doit couvrir non seulement les actifs connus (CMDB, SBOM) mais aussi le shadow IT — sous-domaines oubliés, SaaS non déclarés, nouvelles instances cloud déployées sans validation sécurité.

La distinction fondamentale : un scanner de vulnérabilités analyse le périmètre que vous lui fournissez. L'EASM (External Attack Surface Management) découvre ce que vous ignorez et l'intègre automatiquement dans la boucle de surveillance.

2 — Analyse des vulnérabilités : évaluer et scorer

L'analyse des vulnérabilités croise trois signaux complémentaires. Aucun ne suffit seul.

• CVSS — point de départ standardisé. La limite principale : seules 2,3 % des CVE scorées CVSS 7 ou plus sont réellement exploitées sur un mois donné (FIRST, EPSS User Guide). S'appuyer uniquement sur le CVSS revient à générer 97,7 % de faux positifs urgents. En Q1 2025, 28 % des vulnérabilités exploitées portaient seulement un score CVSS "medium" (Picus Security, 2026).

• CVSS v4.0 — publié en novembre 2023 par le FIRST, CVSS v4.0 introduit des améliorations structurelles : granularité accrue sur les métriques d'impact, distinction entre l'exploitabilité théorique et l'exploitation confirmée, et meilleure prise en compte des systèmes OT/ICS. Pour les équipes qui migrent depuis v3.1, l'impact immédiat est une redistribution notable des scores — certaines vulnérabilités "critiques" descendent, d'autres "hautes" montent. La migration doit être pilotée avec attention avant de modifier les SLA existants.

• EPSS — probabilité d'exploitation dans les 30 jours, mise à jour quotidiennement par le FIRST à partir de données d'exploitation réelles. Un percentile de 0,98 signifie que la CVE est plus susceptible d'être exploitée que 98 % des CVE connues.

• CISA KEV — exploitation active confirmée. 1 484 entrées en 2025, dont 24 liées directement à des campagnes ransomware. Toute CVE KEV passe en tête de file, indépendamment du CVSS.

3 — Priorisation : vulnérabilité × menace × actif

La priorisation efficace croise trois dimensions — pas seulement le score de la vulnérabilité.

• Vulnérabilité — sévérité CVSS, âge, disponibilité d'un correctif de sécurité, maturité de l'exploit

• Menace — disponibilité et facilité d'exploitation, renseignements sur les menaces (EPSS, KEV, groupes d'attaquants actifs)

• Actif — criticité métier, exposition internet, systèmes d'exploitation concernés, nombre d'instances affectées

Un cas concret : face à trois vulnérabilités, avec des ressources pour en corriger une seule, quelle est la bonne réponse ?

Les outils modernes de sécurité produisent un volume considérable de résultats issus de scanners, analyses de code, contrôles de dépendances ou mécanismes de détection automatisés.

Prenons un exemple simplifié :

Ces chiffres ne signifient pas que les outils génèrent principalement des faux positifs. Ils illustrent surtout le travail nécessaire pour qualifier, contextualiser et prioriser les résultats avant de mobiliser les équipes opérationnelles.

Chaque finding détecté ne représente pas nécessairement un risque exploitable. Certaines vulnérabilités concernent des actifs non exposés, d'autres ne disposent d'aucun exploit connu, tandis que certaines peuvent être compensées par des contrôles de sécurité déjà en place.

Les équipes les plus performantes concentrent leurs efforts sur :

• les actifs exposés sur Internet ;

• les vulnérabilités exploitables ;

• les actifs critiques pour l'activité ;

• les vulnérabilités déjà exploitées dans la nature ;

• les actions offrant la plus forte réduction du risque.

L'objectif n'est plus de traiter l'ensemble des findings détectés, mais d'identifier les quelques dizaines d'expositions qui concentrent l'essentiel du risque.

La réponse intuitive est la #1 (CVSS 10.0). La réponse correcte est la #2 : exposée sur internet, exploit public disponible, patch applicable immédiatement. La #3 est KEV mais sans correctif disponible — elle nécessite une mitigation compensatoire (règle WAF, segmentation réseau). La #1, malgré son CVSS maximal, est interne sans exploit : urgente, mais moins prioritaire.

4 — Gestion des correctifs et remédiation

La gestion des correctifs de vulnérabilités ne se résume pas à l'application de patches. Trois approches coexistent selon le contexte.

• Application de correctifs (patch) — la remédiation définitive. Elle nécessite des fenêtres de maintenance, des tests de régression et une coordination entre équipes informatiques et équipes de sécurité. La règle opérationnelle fondamentale : No owner = No fix. Sans propriétaire identifié, aucun déploiement des correctifs n'est possible.

• Mitigation — réduire les risques sans corriger la faille : désactivation d'un service vulnérable, ajout d'une règle WAF, segmentation réseau, restriction d'accès. Utilisée quand aucun patch n'est disponible ou applicable immédiatement.

• Acceptation du risque — décision formelle et documentée de ne pas remédier, basée sur les niveaux de risque réels et les contrôles compensatoires en place. Elle doit être validée par le RSSI et tracée.

  Les SLA de remédiation recommandés :

5 — Validation, reporting et métriques

La remédiation sans validation n'est pas une remédiation. Les applications de correctifs peuvent être partielles ou introduire des régressions. Un retest automatisé post-patch est la norme minimale. Pour les findings critiques, un retest manuel par un pentester est recommandé.

Les métriques clés pour mesurer la maturité du programme : MTTD et MTTR par sévérité, taux de couverture de la surface d'attaque, pourcentage de CVE KEV remédiées dans les délais, conformité aux SLA par équipe. Ces données constituent également les preuves auditables exigées par NIS2 (Art. 21), DORA (Ch. II et IV) et ISO 27001 (Annex A 8.8).

Le nombre de vulnérabilités détectées ou le volume de tickets créés mesurent une activité. Ils ne démontrent pas nécessairement une réduction du risque.

Les organisations les plus matures complètent désormais leurs indicateurs traditionnels avec des métriques orientées exposition :

• nombre d'actifs exposés sur Internet ;

• vulnérabilités KEV corrigées dans les délais ;

• réduction du backlog critique ;

• couverture réelle de la surface d'attaque ;

• expositions critiques éliminées chaque trimestre.

L'objectif n'est plus uniquement de mesurer ce qui a été détecté, mais de démontrer ce qui a été réellement sécurisé.

Aucun outil de gestion des vulnérabilités ne couvre à lui seul l'ensemble des besoins. La stack efficace combine plusieurs familles complémentaires.

• Scanners de vulnérabilités — Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, Cyberwatch. Ils constituent le socle de l'analyse des vulnérabilités sur périmètre connu. Chaque finding est mappé à un CVE ID enrichi avec CVSS, CPE, et renseignements sur les menaces disponibles.

• SAST (Static Application Security Testing) — SonarQube, Checkmarx, Fortify. Ils analysent le code source pour détecter les vulnérabilités avant mise en production. Indispensables pour les équipes DevSecOps qui veulent identifier les problèmes de sécurité dès la phase de développement.

• SCA (Software Composition Analysis) — Snyk, Dependabot, Black Duck. Ils analysent les dépendances open-source et mappent les versions de bibliothèques aux CVE de la NVD. Essentiels pour les organisations qui veulent gérer les risques de sécurité dans leur chaîne d'approvisionnement logicielle. À noter : le format VEX (Vulnerability Exploitability eXchange) s'impose progressivement comme standard complémentaire au SBOM — il permet aux éditeurs de déclarer formellement si une CVE est exploitable dans leur contexte précis, réduisant significativement le bruit pour les équipes qui consomment ces données.

• EDR (Endpoint Detection and Response) — CrowdStrike, SentinelOne, HarfangLab. Ils détectent les tentatives d'exploitation actives associées à des CVE spécifiques sur les endpoints et systèmes d'exploitation.

• RBVM (Risk-Based Vulnerability Management) — Hackuity, Vulcan Cyber, Qualys TruRisk. Ils agrègent les données de scanners et corrèlent CVE, renseignements sur les menaces et criticité métier pour fournir une priorisation basée sur les niveaux de risque réels plutôt que sur le seul CVSS.

• CTI (Cyber Threat Intelligence) — MISP, Recorded Future, Sekoia, Filigran OpenBAS. Ils enrichissent les CVE avec le contexte d'exploitation réel : acteurs de menace, groupes ransomware, campagnes actives. Exemple : CVE-2023-34362 (MOVEit) exploitée par CL0P — ce signal change radicalement la priorisation.

• EASM (External Attack Surface Management) — adresse l'angle mort de toutes les catégories précédentes : la découverte des actifs de l'infrastructure informatique non inventoriés exposés sur internet.

Cinq critères pour évaluer une solution de gestion des vulnérabilités :

• Couverture — cloud, on-premise, conteneurs, APIs, actifs externes non inventoriés

• Qualité de priorisation — scoring CVSS × EPSS × KEV × contexte actif, pas un CVSS brut

• Taux de faux positifs — un volume élevé d'alertes non qualifiées épuise les équipes informatiques

• Intégration ITSM — connecteurs Jira, ServiceNow pour assigner les propriétaires et déclencher le déploiement des correctifs

• Preuves d'audit — exports structurés pour NIS2, DORA, ISO 27001

Patrowl est une solution française combinant EASM et tests de sécurité en continu (PTaaS). Elle adresse les deux angles morts structurels des scanners traditionnels : la surface non inventoriée et le volume d'alertes non qualifiées qui épuise les équipes.

Ce que ça change concrètement : une équipe sécurité qui gère 3 000 CVE dans son backlog scanner reçoit avec Patrowl une liste de findings actionnables, requalifiés manuellement par les analystes du CERT interne avant transmission. Pas de noise, pas de ticket ouvert sur une vulnérabilité interne sans exploit. Seulement ce qui est réellement exposé, réellement exploitable — avec le contexte pour décider et agir.

Patrowl permet de :

• Découvrir en continu les actifs exposés non inventoriés (shadow IT, sous-domaines, APIs, prestataires) avec log horodaté

• Détecter les vulnérabilités exploitables — chaque finding requalifié manuellement par le CERT avant transmission

• Prioriser par exploitabilité réelle — scoring CVSS × EPSS × KEV × contexte d'exposition

• Tester en continu (PTaaS) — pentests automatisés basés sur l'exposition réelle, avec retest documenté post-remédiation

• Surveiller les prestataires — monitoring de l'exposition externe des fournisseurs, conformément à NIS2 Art. 21 et DORA Ch. V

• Produire des rapports audit-ready — exports mappés aux exigences NIS2 et DORA

FAQ

Sources

1. NIST — NVD Operations Update, avril 2026 — nist.gov

2. Cloud Security Alliance — The Collapsing Exploit Window, avril 2026 — cloudsecurityalliance.org

3. Verizon — Data Breach Investigations Report 2025 — verizon.com

4. FIRST — EPSS User Guide — first.org

5. Picus Security — Vulnerability Prioritization in 2026: Why CVSS Isn't Enough — picussecurity.com

6. CISA — Known Exploited Vulnerabilities Catalog — cisa.gov

7. ANSSI / CERT-FR — Bulletins de sécurité — cert.ssi.gouv.fr

8. Patrowl Tech — Vulnerability Management 102, novembre 2025 — formation interne