Votre pipeline CI vient de passer au rouge : Dependabot signale une CVE « critique » sur une librairie transitive. L'équipe panique, quelqu'un propose un hotfix en fin de journée — puis on découvre que le module incriminé n'est jamais chargé en production, qu'il vit dans un outil de build, et que la version réellement installée n'est pas celle du bulletin. Résultat : une nuit blanche pour un risque théorique, pendant qu'une faille XSS exposée sur l'API publique attend encore son tour.
Le problème n'est pas l'absence d'alertes. C'est l'absence de tri : traiter chaque CVE comme urgente revient à ne prioriser aucune.
Ce qu'une alerte ne dit pas
Un scanner de dépendances compare des versions de paquets à une base de vulnérabilités connues. Il ne connaît pas votre architecture, vos pare-feu, ni si le code vulnérable est reachable depuis Internet.
Trois filtres séparent le bruit du risque réel :
| Signal | Ce qu'il indique | Limite |
|---|---|---|
| Score CVSS | Gravité théorique | Ignore l'exposition locale |
| Reachability (Snyk, Grype…) | Chemin d'appel dans votre code | Dépend de l'analyse statique |
| Surface réseau | Port ouvert, auth, WAF | À cartographier vous-même |
Une CVE « 9,8 » dans une dépendance de devDependencies n'a pas la même urgence qu'une « 6,5 » sur votre endpoint d'authentification public.
Cartographier l'exposition avant de patcher
Avant d'ouvrir une pull request, répondez à quatre questions dans cet ordre.
1. Où tourne le composant ? Production, staging, CI, poste de dev — chaque environnement a son propre SLA. Une faille dans une image Docker de test ne justifie pas un déploiement d'urgence le vendredi soir.
2. Est-il reachable depuis l'extérieur ? Un serveur derrière un VPN, sans port public, et sans proxy inverse exposé réduit fortement la probabilité d'exploitation opportuniste.
3. Quels privilèges l'attaquant obtiendrait-il ? RCE en root sur un pod isolé sans accès aux données sensibles ≠ RCE sur la base PostgreSQL principale.
4. Existe-t-il une exploitation active (KEV, bulletins CERT) ? Les vulnérabilités cataloguées comme activement exploitées passent en tête de file, même avec un score CVSS moyen.
Grille de priorisation opérationnelle
Voici une grille pragmatique pour une équipe web hébergée sur VPS ou cloud :
| Niveau | Critères | Délai cible |
|---|---|---|
| P0 | Exploitation active + surface publique | Correctif ou contournement < 24 h |
| P1 | RCE/LFI sur service exposé, pas d'exploit connu | < 7 jours |
| P2 | Dépendance prod, non exposée directement | Prochain cycle de release |
| P3 | Dev/test, outillage interne | Backlog mensuel |
Les mesures compensatoires comptent : bloquer un endpoint, restreindre une plage IP, activer une règle WAF ou retirer temporairement une fonctionnalité peuvent tenir le temps d'un patch propre.
SBOM, lockfiles et continuité
Sans inventaire fiable, vous ne savez pas ce qui tourne réellement. Les lockfiles (package-lock.json, composer.lock, poetry.lock) et les images Docker figées sont votre source de vérité — pas le package.json déclaratif seul.
Générez un SBOM (Software Bill of Materials) à chaque build, stockez-le avec l'artefact déployé, et rescanez les images déjà en production quand de nouvelles CVE apparaissent. C'est la seule façon de répondre honnêtement à la question « sommes-nous affectés ? » sans relancer un audit manuel.
Le sommet : le patch rate ne mesure pas la sécurité
Voici ce que les tableaux de bord « 100 % des CVE corrigées en 48 h » eludent.
Les équipes qui trient par exposition corrigent moins de tickets — et prennent moins de risques.
Décider et avancer sans angle mort
- Fixez une grille P0–P3 et partagez-la avec le produit et l'hébergement.
- Branchez le scan sur le CI avec blocage uniquement sur les alertes reachable en prod.
- Revoyez les contournements chaque semaine : un WAF temporaire ne doit pas devenir permanent.
- Testez la restauration après un patch majeur de dépendance — surtout sur PHP, Node ou Python où les breaking changes sont fréquents.
Pour choisir un hébergeur capable de supporter vos cycles de patch (snapshots, staging miroir, rollback), parcourez notre annuaire ou le comparateur.
Questions fréquentes
Faut-il corriger toutes les alertes Dependabot ou Snyk immédiatement ?
Non. Corrigez d'abord ce qui est exposé au réseau ou exécuté avec des privilèges élevés. Une CVE critique dans une dépendance de test peut attendre un cycle planifié.
Comment savoir si une vulnérabilité est réellement exploitable chez moi ?
Croisez le chemin d'appel, la version exacte installée, la configuration réseau et les preuves d'exploitation active. Un score CVSS seul ne suffit pas.
Que faire quand la mise à jour casse la compatibilité ?
Documentez un contournement temporaire avec une date d'expiration. Une vulnérabilité non patchée sans mesure compensatoire est une dette assumée.
SBOM et scan automatique, par où commencer ?
Générez un inventaire des dépendances en production, branchez un scanner sur le CI, puis classez les alertes par exposition avant de fixer des SLA.
La prochaine alerte rouge ne demande pas « patchons tout » — elle demande où est l'exposition réelle ?