Gestion des vulnérabilités CVE : du triage au patch

Une CVE critique publiée un vendredi soir. Votre scanner d’images remonte 47 vulnérabilités dans le pipeline. Un développeur reçoit une alerte Dependabot sans savoir quoi en faire. Ces situations arrivent toutes les semaines dans les équipes qui n’ont pas de workflow CVE structuré — et elles paralysent.

Ce guide vous donne un processus concret pour gérer les vulnérabilités de la détection au patch : comment les prioriser selon leur risque réel, comment définir des SLA internes, comment utiliser SBOM et VEX pour aller vite, et quels outils brancher à chaque étape. À la fin, votre équipe saura quoi faire dans les 24 heures qui suivent une alerte de sécurité.

Qu’est-ce qu’une vulnérabilité CVE ?

Une CVE (Common Vulnerabilities and Exposures — “Vulnérabilités et Expositions Communes”) est un identifiant unique attribué à une faille de sécurité découverte dans un logiciel. Exemple : CVE-2021-44228 désigne la fameuse faille Log4Shell dans la bibliothèque Java Log4j.

Pensez à une CVE comme à un numéro de dossier médical : elle identifie précisément la maladie, sa gravité, et les traitements connus.

Les métriques de sévérité

Une CVE seule ne dit pas tout. Ce qui compte, c’est son score de risque :

Métrique	Ce que c’est	Interprétation
CVSS (Common Vulnerability Scoring System)	Score de gravité théorique, de 0 à 10	Mesure l’impact potentiel maximal. Un score de 9.8 = critique.
EPSS (Exploit Prediction Scoring System)	Probabilité d’exploitation dans les 30 prochains jours	Un score EPSS de 0.8 = 80 % de chance que cette faille soit exploitée prochainement.
KEV (Known Exploited Vulnerabilities)	Liste CISA des CVE déjà exploitées dans des attaques réelles	Si une CVE est dans la KEV, elle est exploitée maintenant. Traitez-la en urgence.

Le cycle de vie d’une vulnérabilité

Découverte → Publication CVE → Score CVSS/EPSS → Détection dans votre SI → Triage → SLA → Patch → Vérification → Reporting

L’étape souvent oubliée : la détection dans votre SI. Une CVE publiée ne vous affecte que si vous utilisez le composant vulnérable. D’où l’importance du SBOM.

Prérequis

Comprendre les bases de DevSecOps : DevSecOps fondamentaux
Notions de supply chain sécurité : Supply Chain Security
Connaître les principes de tests de sécurité : Tests de sécurité
Avoir un pipeline CI/CD en place

Concepts clés avant de commencer

Le SBOM : votre inventaire de dépendances

Un SBOM (Software Bill of Materials — “liste des composants logiciels”) est l’inventaire complet de tout ce que contient votre application : bibliothèques, versions, licences, dépendances transitives.

Analogie : c’est la liste d’ingrédients d’un produit alimentaire. Sans elle, impossible de savoir si votre application contient un composant vulnérable.

Formats standard : SPDX (Linux Foundation) et CycloneDX (OWASP).

Le VEX : dire ce qui n’est pas exploitable

Un VEX (Vulnerability Exploitability eXchange — “échange d’exploitabilité de vulnérabilité”) est un document qui atteste :

“Cette CVE est présente dans notre composant, mais elle n’est pas exploitable dans notre contexte, pour cette raison précise.”

Exemple : une CVE dans une fonction réseau d’une bibliothèque, alors que votre application n’utilise jamais cette fonction. Le VEX permet d’éliminer les faux positifs documentés et auditables.

SCA : le scan automatisé de dépendances

Une analyse SCA (Software Composition Analysis — “analyse de composition logicielle”) est l’outil qui compare vos dépendances avec les bases de CVE connues (NVD, OSV, GitHub Advisory Database). C’est votre premier outil de détection.

Workflow opérationnel en 5 étapes

Étape 1 — Détecter : brancher les outils de scan

La détection doit être automatique et couvrir tous vos assets :

Images Docker : scanner lors du build et à intervalles réguliers (même les images en production)
Dépendances applicatives : scanner à chaque push et à chaque merge request
Infrastructure : scanner les packages système des serveurs et VMs

Outils courants à cette étape :

Outil	Ce qu’il scanne	Intégration CI
Trivy	Images, filesystem, Git repos, IaC	Natif GitHub/GitLab
Grype	Images, SBOM	GitHub Actions, GitLab CI
Dependabot	Dépendances GitHub	Nativement intégré
Renovate	Dépendances + PRs automatiques	Multi-plateformes
Snyk	Code, containers, IaC	SaaS + CI

Générez un SBOM à chaque build pour accélérer l’analyse d’impact lors d’une alerte :

# Générer un SBOM au format CycloneDX avec Syft
syft your-image:tag -o cyclonedx-json > sbom.json

# Scanner ce SBOM directement
grype sbom:sbom.json

Vérification : votre pipeline doit produire un artefact SBOM versionnié pour chaque image publiée.

Étape 2 — Trier : évaluer l’impact réel

Toutes les CVE remontées ne sont pas urgentes. Le triage consiste à répondre à 3 questions :

Suis-je affecté ? Le composant vulnérable est-il vraiment utilisé dans mon code et dans son code path affecté ?
Quelle est la probabilité d’exploitation ? (EPSS + présence dans la liste KEV de la CISA)
Quel est l’impact métier si exploitée ? Accès aux données, indisponibilité, escalade de privilèges ?

Matrice de priorisation :

CVSS	EPSS	Dans KEV	Priorité
≥ 9.0	> 0.5	Oui	🔴 Critique — traiter sous 24h
≥ 7.0	> 0.3	Non	🟠 Élevé — traiter sous 72h
4.0–6.9	< 0.2	Non	🟡 Moyen — traiter dans le sprint
< 4.0	< 0.05	Non	⚪ Faible — accepter ou reporter

Étape 3 — Appliquer les SLA

Un SLA (Service Level Agreement) de sécurité est un engagement interne sur le délai maximum de correction par sévérité. Sans SLA, les CVE s’accumulent et les discussions sur les priorités sont sans fin.

Exemple de SLA internes (à adapter à votre contexte) :

Sévérité	Délai maximum	Escalade automatique si dépassé
Critique	24 heures	RSSI + CTO notifiés
Élevé	72 heures	Manager sécurité + Lead Dev
Moyen	Prochain sprint (≤ 2 semaines)	Ticket créé, suivi sprint review
Faible	Trimestre courant	Backlog sécurité

Étape 4 — Corriger : patch, mitigation ou exception

Trois options s’offrent à vous, dans cet ordre de préférence :

Option A — Patcher (préféré) : mettre à jour la dépendance ou l’image vers une version corrigée. Passez par votre pipeline CI pour éviter de déployer manuellement.

Option B — Mitiger : si aucun patch n’est disponible, appliquer une mesure compensatoire (désactiver la fonctionnalité vulnérable, ajouter une règle WAF, isoler le composant).

Option C — Accepter formellement : si la vulnérabilité n’est pas exploitable dans votre contexte, produire un document VEX qui le justifie. Ceci élimine le faux positif de manière auditable.

# Exemple : vérifier si un patch est disponible avec Trivy
trivy image --severity CRITICAL,HIGH your-image:tag --exit-code 1

# Lister les vulnérabilités avec fix disponible uniquement
trivy image --ignore-unfixed your-image:tag

Étape 5 — Vérifier et reporter

Après correction, vérifiez que la CVE a disparu du scan suivant. C’est trivial mais souvent oublié.

Créez un rapport de sécurité mensuel ou par sprint qui couvre :

Nombre de CVE détectées / triées / corrigées
Respect des SLA (taux de conformité)
CVE en exception avec justification
Tendance (le nombre monte ou baisse ?)

Ces métriques alimentent vos KPIs Sécurité.

Intégrer SBOM et VEX dans votre pipeline

Un pipeline mature intègre SBOM et VEX comme artefacts de première classe :

Build → Test → Génération SBOM → Scan CVE → Enrichissement VEX → Signature image → Push registre → Attestation SLSA

Exemple de flux GitLab CI complet :

stages:
  - build
  - scan
  - publish

generate-sbom:
  stage: scan
  image: anchore/syft:latest
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json > sbom.json
  artifacts:
    paths: [sbom.json]

scan-vulnerabilities:
  stage: scan
  image: aquasec/grype:latest
  needs: [generate-sbom]
  script:
    # Fail le pipeline si des CVE critiques sont trouvées sans fix connu
    - grype sbom:sbom.json --fail-on critical
  allow_failure: false

Dépannage

Symptôme	Cause probable	Solution
Trop de faux positifs, équipe démotivée	Pas de VEX, pas de filtrage contextuel	Créer un catalogue VEX pour les faux positifs récurrents. Utiliser `--ignore-unfixed` pour filtrer les CVE sans patch.
SLA non respectés systématiquement	SLA trop courts pour la capacité de l’équipe	Recalibrer les SLA en atelier. Commencer par ne traiter que les Critiques + KEV.
Scanner trop lent dans le pipeline	Scan complet à chaque commit	Scanner uniquement les couches modifiées. Utiliser les caches Trivy (`--cache-dir`).
CVE corrigée revient après déploiement	Image de base pas mise à jour	Automatiser la mise à jour de l’image de base (Renovate ou Dependabot pour Dockerfiles).
Aucun patch disponible (CVE 0-day)	Fournisseur n’a pas encore corrigé	Documenter l’exception VEX, appliquer une mitigation réseau ou WAF, surveiller le flux d’advisories du fournisseur.

À retenir

Une CVE identifie une faille. Le CVSS mesure sa gravité théorique. L’EPSS mesure sa probabilité d’exploitation réelle. Combinez les deux pour prioriser.
La liste KEV de la CISA signale les CVE déjà exploitées : traitez-les en urgence.
Le SBOM est votre inventaire de dépendances. Sans lui, vous ne savez pas si vous êtes affecté.
Le VEX documente ce qui n’est pas exploitable. Il transforme un faux positif en preuve d’analyse.
Les SLA internes éliminent les discussions infinies sur les priorités. Définissez-les en atelier.
Un workflow CVE sans reporting est incomplet. Les métriques montrent si vous progressez.

Prochaines étapes

Supply Chain Security Comprendre comment les vulnérabilités entrent dans la chaîne d'approvisionnement logicielle.

KPIs Sécurité Mesurer l'efficacité de votre programme de gestion des vulnérabilités avec les bonnes métriques.

Tests de sécurité SAST, DAST, SCA : intégrer les tests de sécurité dans votre pipeline CI/CD.

Pipeline sécurisé Sécuriser l'ensemble de votre pipeline CI/CD de bout en bout.