SÉCURITÉ · SAAS · REMÉDIATION
Pour prioriser les vulnérabilités selon l’exposition réelle, regarde d’abord si le service est accessible, ce qu’il protège et comment vérifier le correctif.
Une faille accessible depuis Internet demande plus d’attention qu’un composant isolé.
Une API client, un serveur d’identité et un environnement de test n’ont pas le même impact.
Un ticket n’est pas terminé tant que la nouvelle version et le service n’ont pas été contrôlés.
Les outils de scan trouvent beaucoup de vulnérabilités. C’est utile, mais la liste ne dit pas quoi faire en premier.
Le bon réflexe est simple : ne pas trier uniquement par score. Il faut regarder le service touché et la façon dont un attaquant pourrait l’atteindre.
Le score CVSS ne suffit pas
CVSS donne une gravité théorique. Il ne connaît pas ton réseau, tes règles de pare-feu, tes comptes ni les données de tes clients.
Une faille avec un score élevé dans une machine de test arrêtée peut attendre. Une faille moyenne sur une API publique qui traite des données clients peut être urgente.
Note le service, le chemin d’accès, l’impact, les protections en place, l’action à faire et la preuve attendue. Tout le monde comprend alors pourquoi le sujet passe en premier.
Cette revue doit être répétée. Un changement de DNS, de proxy ou de droits peut rendre un service plus exposé du jour au lendemain.
Les cinq questions à poser
Pour chaque alerte, pose les mêmes questions. Elles évitent de perdre du temps sur une alerte peu importante et de rater un vrai risque.
Internet, VPN, réseau interne, réseau d’administration ou aucun accès connu.
Production, identité, sauvegarde, données clients ou test.
Le composant est-il vraiment utilisé ? Existe-t-il un chemin réaliste pour l’attaquer ?
MFA, filtrage réseau, droits limités, segmentation ou surveillance.
Patch, mise à jour, restriction d’accès ou changement planifié avec retour arrière.
Un VPN ou un WAF peut réduire le risque. Il faut tout de même nommer le responsable, fixer une date et vérifier que la protection couvre bien le bon accès.
Choisir P1, P2 ou P3
Le niveau doit être facile à expliquer. Si la décision demande dix minutes d’explication, elle n’est pas assez claire.
| Priorité | Cas typique | Action |
|---|---|---|
| P1 | Service critique accessible et attaque plausible. | Réduire le risque tout de suite, tester puis corriger. |
| P2 | Service important, accès limité et protection vérifiée. | Planifier vite, nommer un responsable et une date. |
| P3 | Composant non accessible ou peu important, situation documentée. | Traiter dans le cycle normal et revoir si le contexte change. |
Vérifie les routes, les règles de pare-feu, le DNS et les droits. Ne te fie pas seulement au nom donné à la machine ou au service.
Pour un correctif NGINX déployé proprement, le guide sur les CVE NGINX avec Ansible montre une méthode concrète.
Corriger et vérifier
Un correctif ne vaut que s’il est réellement en place et que le service continue de fonctionner.
Garde dans le ticket la version installée, le résultat du scan après correction, le contrôle de santé du service et la vérification de l’accès. Cela suffit dans la plupart des cas.
Une exception doit aussi être simple : le service concerné, la personne responsable, la protection utilisée et la date de fin. Sans date, l’exception sera oubliée.
Suis le temps de correction des P1, les alertes sans responsable, les exceptions arrivées à leur date et les correctifs vérifiés. C’est plus utile qu’un simple total de CVE.
Test rapide sur une image de préproduction
Fais le test sur une image de préproduction ou une VM non critique. Le but est de prendre une décision claire, pas de modifier la production.
Un résultat de scan récent, le nom du service, ses accès, une sauvegarde ou un snapshot, et une façon de revenir en arrière.
Exporte les alertes et regroupe-les par service réellement déployé. Une même bibliothèque peut apparaître dans plusieurs images, mais elle n’a pas la même urgence partout.
trivy image --severity HIGH,CRITICAL --format json mon-registry/app:staging > trivy-staging.json
jq '.Results[]? | .Vulnerabilities[]? | {id:.VulnerabilityID,package:.PkgName,severity:.Severity}' trivy-staging.jsonAvant de corriger, vérifie ce qui est exposé. Si tu ne connais pas le chemin d’accès, commence par le documenter. C’est souvent la première action utile.
Erreurs à éviter
Ajoute toujours l’accès réel et l’importance du service.
Un paquet installé n’est pas forcément utilisé. Mais un service accessible mérite une vérification rapide.
Sans version constatée, scan de contrôle et test du service, le risque peut encore être présent.
FAQ
▶ Faut-il corriger toutes les vulnérabilités critiques immédiatement ?
Commence par celles qui sont accessibles et touchent un service important. Les autres doivent avoir un responsable et une date.
▶ Un WAF permet-il de reporter un patch ?
Il peut réduire le risque pour un temps. Vérifie qu’il protège le bon accès et garde une date de correction.
▶ Comment éviter une panne après une mise à jour ?
Teste sur staging ou canari, surveille le service et prépare un retour arrière avant le changement.
▶ Que garder comme preuve ?
La version installée, le scan après correction et le résultat du contrôle de santé du service.
Une méthode simple à refaire chaque semaine
Le but n’est pas de tout corriger dans la journée. Le but est de corriger d’abord ce qui peut vraiment causer un problème.
Linux-Man peut t’aider à suivre les vulnérabilités, préparer les changements et vérifier les résultats.