La présence n’est que le début de l’analyse

Un scanner peut signaler une dépendance vulnérable parce qu’elle apparaît dans un fichier de verrouillage, une image de conteneur ou une machine. C’est un signal utile. Mais la présence ne suffit pas à conclure que le défaut peut être déclenché dans l’application.

Il faut ensuite vérifier la version réellement déployée, le composant qui la charge, la fonction concernée et le chemin d’exécution. La version déclarée dans le dépôt peut différer de l’image publiée; une dépendance peut être présente sans être appelée; une configuration peut désactiver le code concerné. Ces vérifications réduisent les faux positifs, sans prouver à elles seules qu’un risque est nul.

Le réseau change la priorité

Un service accessible publiquement ne présente pas le même chemin d’attaque qu’un composant réservé à un réseau privé. Cartographier les routes exposées, les ports, les règles de pare-feu, les reverse proxies et les autorisations aide à comprendre qui peut atteindre le composant vulnérable.

La question utile n’est pas seulement « quelle est la note CVSS ? », mais aussi : « cette version est-elle active ? le chemin vulnérable est-il utilisé ? qui peut l’atteindre ? quelle donnée ou opération pourrait être affectée ? » Une CVE exploitée et exposée publiquement mérite une attention rapide, même si l’évaluation doit encore confirmer les versions et conditions d’exploitation.

Rendre la décision traçable

Pour chaque alerte, consigner la source, l’actif, la version, l’exposition, les preuves vérifiées, la décision et son propriétaire. Si l’équipe choisit de ne pas corriger immédiatement, documenter le motif et la date de réexamen. Une décision non écrite a tendance à être rejouée à chaque nouveau scan.

Ce processus ne remplace pas les correctifs, la segmentation ou les tests. Il aide à diriger l’effort vers les vulnérabilités présentes et atteignables, plutôt qu’à traiter toutes les lignes d’un rapport comme équivalentes.

Sources

À lire aussi