Une liste de vuln\u00e9rabilit\u00e9s peut contenir des centaines de lignes. Les traiter uniquement dans l\u2019ordre de leur score technique risque de laisser de c\u00f4t\u00e9 une ressource r\u00e9ellement expos\u00e9e ou indispensable \u00e0 l\u2019activit\u00e9.<\/p>\n\n\n
Pour chaque vuln\u00e9rabilit\u00e9 importante, identifiez le syst\u00e8me concern\u00e9, son responsable, son exposition et le service m\u00e9tier associ\u00e9. V\u00e9rifiez les recommandations de l\u2019\u00e9diteur et les informations de veille disponibles. Une version pr\u00e9sente dans un inventaire ancien ne prouve pas que le syst\u00e8me est encore utilis\u00e9.<\/p>\n\n\n
Le r\u00e9f\u00e9rentiel ANSSI souligne l\u2019importance des correctifs sans d\u00e9lai injustifi\u00e9 et de mesures d\u2019att\u00e9nuation lorsque leur installation est impossible. Une restriction d\u2019acc\u00e8s peut r\u00e9duire temporairement le risque, mais elle doit avoir un responsable et une \u00e9ch\u00e9ance de r\u00e9examen.<\/p>\n\n\n
Une mise \u00e0 jour annonc\u00e9e n\u2019est pas n\u00e9cessairement appliqu\u00e9e partout. V\u00e9rifiez la version effective et le retour au fonctionnement normal. Documentez les exceptions, plut\u00f4t que de les faire dispara\u00eetre du tableau de suivi.<\/p>\n\n\n
Exemple fictif : une application interne et un \u00e9quipement expos\u00e9 pr\u00e9sentent des failles comparables. La discussion doit porter sur les chemins d\u2019attaque et les cons\u00e9quences possibles, puis aboutir \u00e0 une s\u00e9quence d\u2019intervention justifi\u00e9e.<\/p>\n\n\n
Le tableau de bord peut rester simple : actif, risque, traitement choisi, responsable, \u00e9ch\u00e9ance et preuve de correction. L\u2019objectif est de rendre les retards visibles et les arbitrages v\u00e9rifiables.<\/p>\n\n\n