Les failles à réparer : trouver, trier, corriger

La gestion des vulnerabilites rate rarement faute de scanners. Elle rate parce qu'il y a trop de findings, personne ne sait quoi prioriser, et les exceptions deviennent permanentes.

Tu te retrouves avec un PDF de 400 pages "Critical" et zero patch deploye. Familier ?

L'objectif n'est pas d'atteindre le score parfait. C'est de reduire le risque sans paralyser la prod - surtout si tu es une TPE sans equipe secu dediee, ou un SaaS qui ship chaque semaine.

CVE ≠ risque (et CVSS ne suffit pas)

Une CVE, c'est un numero officiel pour une faille connue. Elle a souvent un score CVSS. Utile comme signal. Insuffisant comme boussole.

Le risque reel depend de :

• l'exposition (Internet ? reseau interne ?)
• l'actif (poste user vs serveur prod vs bastion)
• l'exploitabilite (preuve publique, attaque deja vue "dans la nature")
• les controles deja en place (EDR, segmentation, auth forte)

Une CVE 9.8 sur un outil interne non expose, derriere double authentification et sans chemin d'attaque realiste, peut attendre. Une CVE 7.5 sur un service public avec exploit actif, c'est aujourd'hui. Priorise par contexte, pas par couleur du dashboard.

Chez un SaaS, une lib utilisee sur l'API publique, ca monte vite. Chez une TPE, un vieux NAS expose en VPN foireux peut etre plus urgent qu'une CVE "media" sur un navigateur deja patche via Windows Update. Les bases cyber aident a raisonner menace / faiblesse / risque.

Le pipeline qui tient la route

Un cycle sain ressemble a ca :

1. Decouverte : scanner l'infra, les dependances, les images conteneurs
2. Triage : faux positifs, doublons, "pas applicable"
3. Priorisation : exposition / actif / exploit
4. Remediation : patch, config, mitigation
5. Verification : re-scan
6. Exceptions controlees avec date d'expiration

Si tu t'arretes a la decouverte, tu fais du reporting, pas de la securite. Le scanner n'a jamais patche quoi que ce soit tout seul.

Patching : la vraie discipline

Le bon patching, c'est une fenetre reguliere (hebdo ou mensuelle), des environnements (dev / staging / prod), des rollbacks possibles, et des delais simples par criticite.

Patcher un peu tout le temps est souvent plus facile que "tout d'un coup" un dimanche magique qui n'arrive jamais.

Pour une TPE : Windows Update + mises a jour des apps critiques + plugins du site, avec un creneau fixe. Pour un SaaS : pipeline CI qui bloque les deps critiques connues, images de base rebuildées regulierement, patch OS, et un process clair pour les zero-day exposes. Ca colle bien au DevSecOps.

Le frein classique, c'est la peur de casser la prod. Legitime. La reponse n'est pas "on ne patch jamais". C'est staging, canary, rollback, et accepter qu'un patch rate gere vaut mieux qu'un exploit reussi.

Documente les applis fragiles. Donne-leur un traitement special. Ne transforme pas toute ton infra en zone d'exception.

Exceptions : oui, mais avec une date de fin

Parfois tu acceptes un risque. Vieille appli metier, editeur lent, contrainte client. OK.

Alors documente pourquoi, mets une date de fin, et definis une mitigation temporaire (segmentation, regle WAF, monitoring cible, droits reduits).

Sinon les exceptions deviennent la norme, et ton registre de risques ressemble a un cimetiere de "on verra plus tard". Une exception sans owner et sans expiration, ce n'est pas une exception. C'est un trou permanent avec un tampon administratif.

Dependances et chaine d'outils : la ou ca se joue aussi

Ne regarde pas que l'OS. Analyse des dependances applicatives, scan des images Docker, inventaire SBOM si tes clients le demandent, revue des plugins et des GitHub Actions.

Beaucoup d'incidents SaaS modernes passent par une lib ou une action CI, pas par un Windows oublie.

Un reflexe utile : surveiller les alertes d'exploitation active et croiser avec ton inventaire. Tu n'as pas besoin de paniquer pour chaque CVE du fil Twitter secu. Tu as besoin de savoir vite si toi tu es touche.

Priorisation pragmatique pour petites equipes

Si tu as deux heures par semaine, ne commence pas par le backlog de 2000 medium. Prends :

• tout ce qui est expose Internet avec exploit connu
• les actifs admin / identite / sauvegardes
• les deps critiques de ton applicatif principal

Trois buckets. Le reste attend. C'est frustrant pour les perfectionnistes. C'est efficace pour les gens qui ont une boite a faire tourner.

Mesure aussi le delai de remediation sur les criticites hautes, pas seulement le nombre de findings ouverts. Un backlog qui baisse de 10 % avec les vrais risques encore ouverts, ce n'est pas une victoire. Un P1 expose ferme en 72h, si.

Faire vivre le process

Assigne des owners. Infra pour l'OS, dev pour les deps, produit pour les arbitrages "on casse ou on attend". Sans owner, le finding flotte.

Fais une revue courte chaque semaine ou chaque sprint : top risques, exceptions qui expirent, fenetre de patch a venir.

Et sois honnete avec les questionnaires clients. Mieux vaut expliquer ton process reel (meme imparfait) que promettre un delai de 24h que tu ne tiens jamais. Les clients B2B sentent le bluff.

Au fond, la gestion des vulnerabilites c'est du triage de risque applique a des bugs publics. Scanner pour savoir. Prioriser pour choisir. Patcher pour reduire. Verifier pour fermer la boucle. Le reste, c'est du bruit autour.