01
Une liste ne donne pas un ordre
Un inventaire de vulnérabilités décrit un état. Il ne dit pas à lui seul quel service doit être corrigé en premier. La même faiblesse peut concerner un composant exposé sur Internet, une machine isolée ou une dépendance non utilisée. La priorité commence donc par la relation entre le composant, son usage, son exposition et le service métier qu’il soutient.
02
Ajouter le signal d’exploitation
La CISA publie le catalogue KEV des vulnérabilités dont l’exploitation est connue. Son dépôt officiel fournit les données en JSON et CSV avec un historique de modifications. Ce signal peut enrichir le tri, mais il ne remplace pas l’inventaire local : la présence du produit et de la version concernés doit être vérifiée. L’absence d’une CVE du catalogue n’est pas une preuve d’innocuité.
03
Rendre l’arbitrage explicite
Un ticket utile précise l’actif, la version, les voies d’accès, l’impact, l’action envisagée et l’équipe responsable. Si la correction crée un risque de rupture, la discussion porte aussi sur une mesure temporaire et sur sa durée de validité. Documenter le choix permet de distinguer une acceptation de risque d’un simple oubli. Le score reste un signal parmi d’autres.
04
Fermer avec une preuve
La clôture doit reposer sur ce qui a changé : version corrigée, configuration vérifiée, nouveau contrôle ou exposition supprimée. Une capture non datée ou un ticket marqué terminé ne suffit pas toujours à retrouver cette information. Conserver le lien entre constat initial, changement et validation transforme le backlog en mémoire opérationnelle utile au MCS et à l’homologation.
Sources et portée
Note de méthode, rédigée à partir des références ci-dessous et de l’approche d’ingénierie présentée sur ce site. Les propositions d’application sont une synthèse éditoriale, pas une certification par les organismes cités.
CISA — Known Exploited Vulnerabilities, données officielles ↗