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

La gestion des vulnérabilités transforme une alerte en décision datée : détecter la CVE, juger son risque réel, fixer un délai de correction, corriger ou documenter, puis vérifier. Cette leçon s'adresse au DevOps qui reçoit des rapports de scanner et doit dire, dans les 24 heures, ce qu'on corrige d'abord et ce qu'on assume.

Tout est mesuré le 1er octobre 2026 sur l'image nginx:1.30.5-trixie : Trivy 0.74.0 y relève 390 vulnérabilités, Grype 0.119.0 classe 18 correspondances en Critical quand Trivy n'en compte qu'une, et la faille la plus probablement exploitée est notée Negligible. Un rapport brut ne se traite donc pas dans l'ordre où il s'affiche.

Ce que vous allez apprendre

• Distinguer CVE, CVSS, EPSS et KEV, et savoir lequel fait foi pour décider
• Dérouler un workflow de triage en cinq étapes reproductibles
• Fixer des délais de correction par criticité, et documenter les exceptions
• Répondre vite à « sommes-nous touchés ? » avec un SBOM et un document VEX
• Adapter sa détection au recul du NVD depuis avril 2026
• Protéger ses propres outils de scan, maillons de la chaîne comme les autres

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

Une CVE (Common Vulnerabilities and Exposures) est l'identifiant public attribué à une faille connue d'un logiciel : CVE-2021-44228 désigne Log4Shell, dans la bibliothèque Java Log4j. Cet identifiant est le point commun entre les scanners, les bulletins des éditeurs et les bases publiques : il permet de vérifier que deux outils parlent bien de la même faille.

Le volume rend le tri manuel impossible. Le 29 septembre 2026, l'API de FIRST attribuait un score EPSS à 380 526 CVE, et le catalogue KEV de la CISA en listait 1 730 dont l'exploitation est confirmée. La lecture détaillée de ces repères fait l'objet de la leçon CVE, CVSS et EPSS ; celle-ci en fait un processus, du rapport au correctif.

Les métriques de sévérité

Une CVE seule ne dit pas l'urgence. Trois repères publics la complètent, chacun répondant à une question différente, et un quatrième, l'exposition du composant chez vous, n'appartient qu'à vous. Le tableau résume ce que chaque repère mesure et ce qu'il ne dit pas.

Métrique	Ce qu'elle mesure	Ce qu'il faut savoir
CVSS (Common Vulnerability Scoring System)	La gravité si l'attaque réussit, de 0 à 10	La note varie selon la source : éditeur, distribution ou NVD
EPSS (Exploit Prediction Scoring System)	La probabilité d'exploitation dans les 30 jours	Modèle v4 publié depuis le 17 mars 2025, recalculé chaque jour : 0.73 se lit 73 %
KEV (Known Exploited Vulnerabilities)	L'exploitation confirmée, tenue par la CISA	Présence au catalogue = traitement en urgence

Glissez pour voir

Le CVSS et l'EPSS ne se remplacent pas. Sur l'image mesurée, la faille au plus fort EPSS est CVE-2011-3389 (BEAST, dans libgnutls30t64) : 73,3 %, 99e percentile, alors que Debian la note Negligible. À l'inverse, les 18 correspondances Critical de Grype ont toutes un EPSS inférieur à 1 % et portent le statut wont-fix. FIRST ne fixe d'ailleurs aucun seuil officiel : c'est à vous de combiner les repères.

Le cycle de vie d'une vulnérabilité

Une CVE publiée ne vous concerne que si le composant vulnérable est présent chez vous, et idéalement sur un chemin de code réellement atteint. L'étape la plus souvent oubliée est donc la détection dans votre SI (système d'information) : sans SBOM à jour, impossible de répondre vite. Le schéma suit une vulnérabilité de sa publication à la clôture, avec les trois issues possibles du traitement.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le NVD ralentit : ce qu'il faut changer dans votre détection

Le NVD (National Vulnerability Database), la base américaine gérée par le NIST, a changé sa politique le 15 avril 2026. Les soumissions de CVE ont augmenté de 263 % entre 2020 et 2025 ; le NIST en a enrichi près de 42 000 en 2025, 45 % de plus que toute année précédente, sans suivre le rythme.

Depuis, seules trois catégories sont enrichies en priorité (ajout de score CVSS, de CWE, de CPE) : les CVE du catalogue KEV, celles qui touchent un logiciel utilisé par l'administration fédérale américaine, et celles d'un logiciel critique au sens du décret 14028. Toute CVE non enrichie publiée avant le 1er mars 2026 passe en « Not Scheduled ». Le NIST ne calcule plus non plus de score propre quand la CNA (l'organisme qui a attribué la CVE) en fournit déjà un. Source : annonce du NIST.

La conséquence pratique est double. Un outil qui ne lit que le champ CVSS du NVD peut afficher une CVE sans score ; et la note affichée dépend de plus en plus de la source retenue. Deux bases comblent le vide : le programme Vulnrichment de la CISA et OSV.dev, base ouverte qui agrège les avis par écosystème (npm, PyPI, Go, Maven). Préférez un scanner qui croise plusieurs sources, et comparez-en deux sur vos images critiques.

Prérequis

Cette leçon suppose quelques notions déjà vues dans la formation, et un pipeline qui tourne. Les pages ci-dessous les reprennent si besoin.

• Les bases DevSecOps : DevSecOps fondamentaux
• La lecture des repères : CVE, CVSS et EPSS
• Le scan de dépendances : SCA
• Un pipeline CI/CD en place, avec accès au registre d'images

Concepts clés avant de commencer

Trois objets reviennent dans tout le workflow : l'inventaire de ce que vous livrez, la déclaration de ce qui n'est pas exploitable, et l'outil qui compare l'un aux bases de CVE. Les comprendre avant de commencer évite de les confondre dans le pipeline.

Le SBOM : votre inventaire de dépendances

Un SBOM (Software Bill of Materials) est l'inventaire de ce que contient un artefact : paquets, bibliothèques, versions, licences, dépendances transitives. Sans lui, répondre à « suis-je exposé à cette CVE ? » oblige à rescanner chaque application ; avec lui, la réponse tient en une requête sur les composants.

Deux formats dominent : CycloneDX (OWASP, version 1.7 publiée en octobre 2025) et SPDX (Linux Foundation, version 3.0.1). Mesuré : Syft 1.52.0 produit du CycloneDX 1.7 par défaut, et recense 152 paquets dans l'image nginx, plus 3 236 fichiers. Vérifiez la version que consomme le reste de votre chaîne avant d'en imposer une.

Le VEX : dire ce qui n'est pas exploitable

Un VEX (Vulnerability Exploitability eXchange) est un document qui déclare, pour une CVE et un produit donnés, un statut : not_affected, affected, fixed ou under_investigation. Un not_affected porte obligatoirement une justification, par exemple « le code vulnérable n'est pas sur un chemin exécuté ».

L'intérêt est mesurable : avec un document OpenVEX qui déclare CVE-2011-3389 non exploitable dans l'image nginx, trivy image --vex passe de 390 à 389 vulnérabilités. La décision est écrite une fois, versionnée, et le scanner l'applique à chaque passage au lieu de faire réanalyser la même alerte.

SCA : le scan automatisé de dépendances

La SCA (Software Composition Analysis) compare les composants d'un projet ou d'une image aux bases de CVE (NVD, OSV.dev, GitHub Advisory Database, avis des distributions). C'est le premier outil de détection. Depuis le recul du NVD, aucune base ne suffit seule, et les outils ne lisent pas les mêmes : c'est ce qui explique les écarts mesurés plus bas entre Trivy et Grype.

Le workflow de gestion des vulnérabilités CVE, en 5 étapes

Le workflow tient en cinq étapes, toujours dans le même ordre : détecter, trier, fixer le délai, traiter, vérifier. Chacune produit une trace (rapport, ticket, VEX), ce qui permet de prouver après coup qu'une alerte a bien été traitée.

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

La détection doit être automatique et couvrir trois familles d'actifs : les images au build et à intervalle régulier, y compris celles déjà en production ; les dépendances applicatives à chaque merge request ; les paquets système des serveurs. Une nouvelle CVE peut toucher une image publiée il y a trois mois : le scan programmé (cron) sur le registre est aussi important que le scan au build.

Outil	Ce qu'il scanne	Intégration
Trivy	Images, système de fichiers, dépôts, IaC	CLI, image, GitHub et GitLab
Grype	Images, SBOM	CLI, image
OSV-Scanner	Dépendances multi-écosystèmes via OSV.dev	CLI, GitHub Actions
Dependabot	Dépendances d'un dépôt GitHub	Natif GitHub
Renovate	Dépendances, avec merge requests automatiques	Multi-plateformes

Glissez pour voir

Le SBOM se génère au build, puis se rescanne sans reconstruire l'image. Les deux commandes suivantes ont été rejouées sur l'image nginx : Syft écrit l'inventaire, Grype le confronte à sa base, et --fail-on critical fait échouer la commande avec le code 2.

# Inventaire CycloneDX de l'image, figée par digest
syft nginx:1.30.5-trixie@sha256:b972f831f200b19ef0767938224f9711e74cd783718738cd7405d5cabf75c442 \
  -o cyclonedx-json=sbom.json

# Scan du SBOM, sans l'image
grype sbom:sbom.json --fail-on critical
echo $?
# 2

Votre scanner fait aussi partie de la supply chain

Le 27 février 2026, le dépôt aquasecurity/trivy a été vidé grâce à un jeton volé ; les 19 et 22 mars, l'avis GHSA-69fq-xp46-6x23 recensait les composants piégés pour voler les secrets des pipelines : binaire 0.69.4, images 0.69.5 et 0.69.6, trivy-action avant 0.35.0, setup-trivy avant 0.2.6. Retenez Trivy 0.72.0 au minimum, épinglé par digest, et abonnez-vous aux avis de sécurité de vos propres outils. Détail dans la leçon Trivy.

Étape 2, Trier : évaluer l'impact réel

Le triage répond à trois questions, dans cet ordre : le composant est-il exposé (internet, interne, test) ? Que disent les repères KEV, EPSS et CVSS, dans cet ordre de poids ? Quel serait l'impact métier d'une exploitation (fuite de données, indisponibilité, élévation de privilèges) ?

Le piège est de trier sur la seule sévérité affichée. Mesuré sur la même image, la même faille CVE-2026-19931 dans curl est notée MEDIUM par Trivy et Critical par Grype, qui retient la note du NVD. Le statut diverge aussi : affected chez Trivy, wont-fix chez Grype. Pour trier, Grype sait ordonner par probabilité d'exploitation :

grype sbom:sbom.json --sort-by epss

NAME             INSTALLED          FIXED IN  TYPE  VULNERABILITY   SEVERITY    EPSS          RISK
libgnutls30t64   3.8.9-3+deb13u4              deb   CVE-2011-3389   Negligible  73.3% (99th)  3.7
nginx            1.30.5-1~trixie              deb   CVE-2009-4487   Negligible  29.5% (98th)  1.5
libldap2         2.6.10+dfsg-1                deb   CVE-2017-17740  Negligible  7.0% (93rd)   0.4

Aucune de ces CVE n'est au catalogue KEV au 30 septembre 2026. La matrice suivante reprend la politique de départ de la leçon CVE, et lui associe un délai. Les seuils sont des repères courants, pas une norme de FIRST : adaptez-les à votre exposition.

Situation	Repères	Priorité
Exploitation confirmée	présente dans le KEV	Critique
Grave et probablement exploitée	CVSS ≥ 9 et EPSS élevé	Critique
Grave, peu exploitée	CVSS ≥ 9, EPSS faible	Élevée
Moyenne mais très exploitée	CVSS 4 à 6, EPSS élevé	Élevée
Faible et peu exploitée	CVSS < 4, EPSS faible	Faible : planifier ou accepter

Glissez pour voir

Étape 3, Appliquer les SLA

Un SLA (Service Level Agreement) de sécurité est un engagement interne sur le délai maximal de correction, par niveau de priorité. Sans lui, les CVE s'accumulent et chaque arbitrage se rejoue en réunion. Les valeurs ci-dessous sont un point de départ, le même que celui de la leçon sur les KPI de sécurité :

Priorité	Délai maximal	Escalade si dépassé
Critique	24 heures	RSSI et CTO notifiés
Élevée	7 jours	Responsable sécurité et lead dev
Moyenne	30 jours	Ticket suivi en revue de sprint
Faible	90 jours	Backlog sécurité, ou acceptation documentée

Glissez pour voir

Documenter les exceptions

Quand un délai ne peut pas être tenu (correctif inexistant, contrainte métier), ouvrez un ticket de risque accepté avec un responsable nommé et une date de réévaluation. Sans date, une exception temporaire devient une dette permanente.

Étape 4, Corriger : patch, mitigation ou exception

Trois issues existent, dans cet ordre de préférence. Corriger met à jour la dépendance ou l'image de base, via le pipeline et jamais à la main. Atténuer réduit l'exposition en attendant un correctif : désactiver la fonction, filtrer par un WAF (pare-feu applicatif), isoler le composant. Déclarer non exploitable passe par un document VEX justifié.

Les deux commandes Trivy suivantes séparent ce qui se corrige de ce qui attend. Mesuré sur l'image nginx : le scan bloquant remonte 80 vulnérabilités HIGH et CRITICAL ; avec --ignore-unfixed, il n'en reste que 13, toutes HIGH, qui ont un correctif publié. Le code de sortie reste 1 dans les deux cas.

# Bloquant : toute HIGH ou CRITICAL fait échouer
trivy image --severity CRITICAL,HIGH --exit-code 1 \
  nginx:1.30.5-trixie@sha256:b972f831f200b19ef0767938224f9711e74cd783718738cd7405d5cabf75c442
# Total: 80 (HIGH: 79, CRITICAL: 1)

# Seulement ce qui a un correctif publié
trivy image --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 \
  nginx:1.30.5-trixie@sha256:b972f831f200b19ef0767938224f9711e74cd783718738cd7405d5cabf75c442
# Total: 13 (HIGH: 13, CRITICAL: 0)

Côté Grype, l'équivalent est --only-fixed : avec lui, --fail-on critical sort en 0, car aucune des 18 CVE Critical n'a de correctif. Une CVE wont-fix ne disparaîtra pas d'elle-même : la seule issue est de changer d'image de base, ou de la documenter.

Étape 5, Vérifier et reporter

Après correction, rescannez l'artefact livré et vérifiez que la CVE a disparu : c'est trivial et souvent oublié. Un rapport mensuel ou par sprint donne ensuite la tendance. Il couvre le nombre de CVE détectées, triées et corrigées, le taux de respect des SLA, les exceptions et leur échéance.

Ces chiffres alimentent les KPI de sécurité, qui mesurent la posture dans la durée. Un workflow sans reporting fonctionne peut-être, mais personne ne peut le prouver.

Intégrer SBOM et VEX dans votre pipeline

Un pipeline mature produit le SBOM et le VEX comme des artefacts à part entière, à côté de l'image. Chaque build laisse ainsi sa propre preuve, et la question « sommes-nous touchés par cette nouvelle CVE ? » se règle en quelques minutes, par une requête sur les SBOM archivés, au lieu de plusieurs jours.

Un pipeline GitLab CI complet

Les images officielles de Syft et Grype ne contiennent pas de shell : GitLab ne peut pas y exécuter un script:. Mesuré : sh est introuvable dans anchore/syft:v1.52.0. Il faut leurs variantes -debug, qui embarquent BusyBox, avec entrypoint: [""] et le chemin absolu du binaire.

stages:
  - scan

generate-sbom:
  stage: scan
  image:
    name: anchore/syft:v1.52.0-debug@sha256:dd31bb351e28f958f2911dc2c53ef34340f3d61d5feb624e1ac061ccd0f87018
    entrypoint: [""]
  variables:
    SYFT_REGISTRY_AUTH_AUTHORITY: $CI_REGISTRY
    SYFT_REGISTRY_AUTH_USERNAME: $CI_REGISTRY_USER
    SYFT_REGISTRY_AUTH_PASSWORD: $CI_REGISTRY_PASSWORD
  script:
    - /syft "registry:$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" -o cyclonedx-json=sbom.json
  artifacts:
    paths: [sbom.json]

scan-vulnerabilities:
  stage: scan
  image:
    name: anchore/grype:v0.119.0-debug@sha256:166001ed93ae8463acad508c746586ced665abe9d817ae452ed9b781ddb6cebb
    entrypoint: [""]
  needs: [generate-sbom]
  script:
    # Échoue (code 2) sur toute CVE critique qui a un correctif publié
    - /grype sbom:sbom.json --only-fixed --fail-on critical

Les deux scripts ont été rejoués dans ces images, figées par digest, sur une image poussée dans un registre local : Syft écrit le SBOM, Grype sort en 0. L'analyse par plumber, qui exige l'API d'une instance GitLab, n'a pas pu être faite. Le commentaire du job dit exactement ce que bloque la règle : sans --only-fixed, des CVE critiques sans correctif bloqueraient le pipeline sans qu'aucune action ne soit possible.

Appliquer un VEX au scan

Le VEX se range dans le dépôt, à côté du code, ou s'attache à l'image en attestation avec cosign attest. Voici un document OpenVEX minimal : sa justification est un exemple, à établir par votre propre analyse du composant.

vex/nginx.openvex.json

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://exemple.fr/vex/nginx-2026-10-01",
  "author": "Equipe plateforme",
  "timestamp": "2026-10-01T10:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2011-3389" },
      "products": [
        {
          "@id": "pkg:oci/nginx@sha256%3Ab972f831f200b19ef0767938224f9711e74cd783718738cd7405d5cabf75c442",
          "subcomponents": [{ "@id": "pkg:deb/debian/libgnutls30t64" }]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

trivy image --vex vex/nginx.openvex.json \
  nginx:1.30.5-trixie@sha256:b972f831f200b19ef0767938224f9711e74cd783718738cd7405d5cabf75c442
# 389 vulnérabilités au lieu de 390 : CVE-2011-3389 n'apparaît plus

Le produit se désigne par le purl de l'image, digest compris : un VEX écrit pour une autre version de l'image ne s'applique pas. C'est voulu, puisque la justification ne vaut que pour l'artefact analysé.

Dépannage

Un workflow CVE qui grince révèle presque toujours l'un des symptômes suivants. Le tableau relie chaque signal à sa cause probable et à l'action corrective, pour éviter de traiter le symptôme au lieu de la cause.

Symptôme	Cause probable	Solution
Trop d'alertes, équipe démotivée	Tri sur la sévérité seule	Trier par exposition, KEV et EPSS ; écrire des VEX pour les cas récurrents
Le pipeline bloque sans action possible	CVE critiques wont-fix	--ignore-unfixed (Trivy) ou --only-fixed (Grype), et changer d'image de base
Deux scanners ne donnent pas la même sévérité	Sources de notation différentes (distribution, NVD)	Fixer la source de référence dans la politique, comparer sur les images critiques
Un job GitLab échoue sans exécuter le script	Image sans shell ou à ENTRYPOINT imposé	Variante -debug et entrypoint: [""]
CVE sans score CVSS ni détail	CVE « Not Scheduled » au NVD depuis avril 2026	Croiser avec Vulnrichment et OSV.dev
La CVE corrigée revient	Image de base non mise à jour	Automatiser la montée de version (Renovate, Dependabot)

Glissez pour voir

À retenir

• Une CVE identifie une faille ; le CVSS dit sa gravité, l'EPSS sa probabilité d'exploitation à 30 jours, le KEV l'exploitation confirmée.
• On trie par exposition, puis KEV, EPSS et CVSS : sur nginx, la faille au plus fort EPSS (73,3 %) est notée Negligible.
• La sévérité dépend de la source : la même CVE est MEDIUM chez Trivy et Critical chez Grype.
• Des délais par priorité (24 h, 7 j, 30 j, 90 j) évitent les arbitrages sans fin ; une exception porte une date de réévaluation.
• --ignore-unfixed et --only-fixed séparent ce qui se corrige de ce qui exige un changement d'image.
• Depuis le 15 avril 2026, le NVD n'enrichit plus tout : croisez avec Vulnrichment et OSV.dev.
• Le SBOM répond à « sommes-nous touchés ? », le VEX documente ce qui n'est pas exploitable, digest compris.
• Les scanners sont des dépendances : version minimale, digest, avis de sécurité suivis.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Les questions ci-dessous reprennent les doutes les plus courants sur la gestion des vulnérabilités : différence entre CVSS et EPSS, priorisation, rôle du SBOM et du VEX, et CVE restées sans score au NVD.

Qu'est-ce qu'une CVE ?

Quelle est la différence entre CVSS et EPSS ?

Comment prioriser les vulnérabilités à corriger en premier ?

Qu'est-ce qu'un SBOM et à quoi sert-il face aux CVE ?

Qu'est-ce qu'un document VEX et pourquoi l'utiliser ?

Pourquoi certaines CVE n'ont plus de score CVSS depuis 2026 ?

×

📖 Voir la documentation →