# Vulnérabilités : prioriser les correctifs par exposition et risque métier

Adrien Murillo — Murillo Consulting

Méthode pour trier les vulnérabilités : exploitation connue, exposition Internet, actif critique, compensations, fenêtre de patch et acceptation de risque.

Le CVSS aide à qualifier une faille, mais il ne suffit pas à décider quoi corriger en premier. Une vulnérabilité devient prioritaire quand elle rencontre un actif exposé, un service critique, une exploitation connue, une absence de compensation ou une contrainte métier mal maîtrisée.

Version : Mai 2026

## À retenir

- Croiser score technique, exploitation réelle, exposition et criticité métier.
- Traiter vite les failles exploitées sur actifs exposés ou services critiques.
- Documenter les exceptions de patch comme des risques temporaires, pas comme des oublis.
- Mesurer la réduction du risque après correction ou compensation.

## Construire une matrice simple

Une matrice utile tient en quelques colonnes : CVE, actif, exposition, criticité métier, exploitation connue, correctif disponible, compensation, décision, date de revue. Elle force la discussion sur le risque réel plutôt que sur une longue liste de scores.

Le but est de décider vite ce qui doit être traité cette semaine, ce qui doit être compensé et ce qui peut attendre une fenêtre normale.

- CVE
- actif
- exposition
- criticité
- exploitation
- décision

## Traiter les exceptions comme des décisions

Certaines corrections ne peuvent pas être appliquées immédiatement : dépendance éditeur, application legacy, période de production, indisponibilité métier. L'exception doit alors être datée, justifiée, compensée et revue.

Sans cette discipline, le patch management se transforme en backlog permanent où les risques les plus anciens deviennent invisibles.



## Prouver la réduction du risque

La clôture d'une vulnérabilité ne doit pas reposer uniquement sur le ticket. Il faut une preuve : scan de contrôle, version corrigée, configuration modifiée, règle de filtrage testée ou retrait de l'actif exposé.

Cette preuve protège l'équipe en cas d'audit ou d'incident ultérieur.

- scan de contrôle
- version
- configuration
- filtrage
- retrait

## À décider

- Cette vulnérabilité est-elle exploitée dans la nature ?
- L'actif est-il accessible depuis Internet ou depuis un tiers ?
- Quel processus métier tombe si le patch provoque une indisponibilité ?
- Quelle compensation réduit réellement le risque en attendant le patch ?
- Qui accepte le risque si la correction est repoussée ?

## À vérifier techniquement

- CVE présente dans le catalogue CISA KEV ou activement exploitée
- Actif vulnérable exposé Internet, VPN, messagerie, portail client ou accès admin
- Service critique sans fenêtre de maintenance réaliste
- Correctif non appliqué mais compensation réseau, EDR ou configuration non vérifiée
- Vulnérabilités récurrentes sur même famille d'actifs ou même processus de patch

## Preuves à conserver

- Liste des actifs vulnérables avec exposition et propriétaire
- Source de priorisation : KEV, éditeur, scanner, EDR, renseignement ou incident
- Décision : patch, mitigation, isolement, acceptation temporaire ou retrait du service
- Preuve de correction ou de compensation testée
- Date de revue des exceptions et risque résiduel accepté

## Erreurs fréquentes

- Trier uniquement par CVSS sans regarder l'exposition réelle.
- Repousser un patch critique sans écrire l'acceptation de risque.
- Considérer une règle firewall comme compensation sans test.
- Ne pas vérifier que la vulnérabilité a disparu après correction.

## Le CVSS est-il inutile ?

Non. Il reste un indicateur important, mais il doit être croisé avec l'exploitation connue, l'exposition et le contexte métier.

## Sources

- [CISA - Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [CISA - Cybersecurity Incident & Vulnerability Response Playbooks](https://www.cisa.gov/sites/default/files/publications/Cybersecurity_Incident_Vulnerability_Response_Playbooks_508C.pdf)
- [NIST - Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)



## Navigation
- [Consultant DevOps et DevSecOps Cloud.](/profil)
- [Missions d’ingénierie.](/services)
- [Réalisations.](/realisations)
- [Projets open source.](/projets)
- [Des guides pour passer à l’action.](/ressources)
- [Parlons de votre projet.](/contact)
- [Du cadrage aux livrables.](/approche)
- [Des contextes. Des contraintes réelles.](/secteurs)
- [Apprendre en prenant des décisions.](/lab)
- [Mentions légales](/mentions-legales)
- [Confidentialité](/confidentialite)
- [Conditions générales d’utilisation](/conditions-utilisation)
- [Former vos équipes. Avec de la pratique.](/formation)

[Contact](mailto:contact@adrien-murillo.com)