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 de gestion des vulnérabilités CVE, 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 comment adapter votre chaîne de détection aux changements survenus en 2026 sur le NVD. À la fin, votre équipe saura quoi faire dans les 24 heures qui suivent une alerte de sécurité.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer CVE, CVSS, EPSS et KEV pour prioriser correctement
- Mettre en place un workflow de triage en 5 étapes reproductibles
- Définir des SLA de correction réalistes par niveau de sévérité
- Utiliser SBOM et VEX pour accélérer l'analyse d'impact
- Adapter votre chaîne de détection aux changements 2026 du NVD
- Protéger vos propres outils de scan contre la compromission
Qu'est-ce qu'une vulnérabilité CVE ?
Section intitulée « 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. En juillet 2026, plus de 345 000 CVE sont recensées et scorées par le modèle EPSS (données FIRST.org), un volume qui ne cesse de croître et qui rend le tri automatique indispensable.
Les métriques de sévérité
Section intitulée « 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. Le NVD publie désormais un score CVSS v4.0 en plus du v3.1 pour les nouvelles CVE, sans réévaluer rétroactivement l'historique. |
| EPSS (Exploit Prediction Scoring System) | Probabilité d'exploitation dans les 30 prochains jours | Modèle v4 depuis mars 2025, entraîné sur des milliers de variables. Un score de 0.8 signifie 80 % de chance d'exploitation prochaine. |
| 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é
Section intitulée « 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 → ReportingL'étape souvent oubliée : la détection dans votre SI (système d'information). Une CVE publiée ne vous affecte que si vous utilisez le composant vulnérable, dans le chemin de code réellement atteint. D'où l'importance du SBOM, qui vous dit ce que vous utilisez vraiment.
Le NVD ralentit : ce qu'il faut changer dans votre détection
Section intitulée « Le NVD ralentit : ce qu'il faut changer dans votre détection »Depuis le 15 avril 2026, le NVD (National Vulnerability Database, la base américaine de référence gérée par le NIST) a changé sa politique d'enrichissement. Les soumissions de CVE ont augmenté de 263 % entre 2020 et 2025 ; malgré 42 000 CVE enrichies en 2025 (+45 % par rapport à l'année précédente), le NIST ne peut plus suivre le volume.
Désormais, seules trois catégories de CVE sont prioritaires pour l'enrichissement (ajout de score CVSS, de CWE, de CPE) : celles présentes dans la liste KEV de la CISA, celles touchant un logiciel utilisé par le gouvernement américain, et celles concernant un logiciel critique au sens du décret exécutif 14028. Toute CVE publiée avant le 1er mars 2026 et non concernée est reclassée "Not Scheduled" : elle reste listée, mais sans score ni détail officiel du NVD, potentiellement pour longtemps.
Conséquence concrète pour votre équipe : un scanner qui ne s'appuie que sur le champ CVSS du NVD peut remonter une CVE sans aucune information exploitable. Deux sources complètent désormais ce vide : le programme Vulnrichment de la CISA, qui enrichit manuellement les CVE non couvertes par le NVD, et OSV.dev, une base ouverte maintenue par Google qui agrège les advisories GitHub, les données par écosystème (npm, PyPI, Go, Maven) et les CVE elles-mêmes. Configurez votre outil de scan pour croiser plusieurs sources plutôt que de dépendre du seul NVD.
Prérequis
Section intitulée « 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é
- Distinguer menace, risque et vulnérabilité : Menace, risque, vulnérabilité, attaque
- Avoir un pipeline CI/CD en place
Concepts clés avant de commencer
Section intitulée « Concepts clés avant de commencer »Le SBOM : votre inventaire de dépendances
Section intitulée « 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, version 3.0.1 stable, avec un profil sécurité qui intègre nativement vulnérabilités et VEX) et CycloneDX (OWASP, version 1.7 depuis octobre 2025, dernière révision de la branche 1.x avant une refonte 2.0). La plupart des outils du marché produisent encore du CycloneDX 1.5/1.6 ou du SPDX 2.3 : vérifiez la version supportée par votre chaîne avant de choisir un format cible.
Le VEX : dire ce qui n'est pas exploitable
Section intitulée « 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, ce qui évite à l'équipe de re-analyser la même CVE à chaque scan.
SCA : le scan automatisé de dépendances
Section intitulée « 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.dev, GitHub Advisory Database). C'est votre premier outil de détection, mais depuis le ralentissement du NVD en 2026, aucune de ces bases ne suffit seule : privilégiez un outil qui agrège plusieurs sources.
Le workflow de gestion des vulnérabilités CVE, en 5 étapes
Section intitulée « Le workflow de gestion des vulnérabilités CVE, en 5 étapes »Étape 1, Détecter : brancher les outils de scan
Section intitulée « É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 |
| OSV-Scanner | Dépendances multi-écosystèmes via OSV.dev | GitHub Actions, CLI |
| 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 avec Syft, le générateur de SBOM open source d'Anchore, pour accélérer l'analyse d'impact lors d'une alerte :
# Générer un SBOM au format CycloneDX avec Syftsyft your-image:tag -o cyclonedx-json > sbom.json
# Scanner ce SBOM directementgrype sbom:sbom.jsonVérification : votre pipeline doit produire un artefact SBOM versionnié pour chaque image publiée.
Étape 2, Trier : évaluer l'impact réel
Section intitulé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 chemin de code affecté ?
- Quelle est la probabilité d'exploitation ? (score 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 (les seuils ci-dessous sont des repères pratiques courants, pas une norme officielle FIRST.org : adaptez-les à votre contexte) :
| 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
Section intitulée « É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 maximum) | Ticket créé, suivi sprint review |
| Faible | Trimestre courant | Backlog sécurité |
Étape 4, Corriger : patch, mitigation ou exception
Section intitulée « É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, un pare-feu applicatif qui filtre les requêtes malveillantes avant qu'elles n'atteignent le code vulnérable, ou 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 Trivytrivy image --severity CRITICAL,HIGH your-image:tag --exit-code 1
# Lister les vulnérabilités avec fix disponible uniquementtrivy image --ignore-unfixed your-image:tagÉtape 5, Vérifier et reporter
Section intitulée « É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é, qui donnent une vue d'ensemble sur la maturité de votre programme de gestion des vulnérabilités.
Intégrer SBOM et VEX dans votre pipeline
Section intitulée « 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 SLSACette intégration transforme un contrôle ponctuel en automatisme reproductible : chaque build produit ses propres preuves de conformité, sans intervention manuelle. C'est ce qui permet de répondre en quelques minutes, plutôt qu'en plusieurs jours, à la question "sommes-nous affectés par cette nouvelle CVE ?".
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: falseDépannage
Section intitulée « Dépannage »Un workflow CVE qui grince révèle presque toujours l'un de ces cinq symptômes. Le tableau ci-dessous relie chaque signal à sa cause probable et à l'action corrective, pour éviter de bricoler une solution qui ne traite que le symptôme.
| 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). |
| CVE sans score CVSS ni détail | CVE classée "Not Scheduled" par le NVD depuis avril 2026 | Croiser avec Vulnrichment (CISA) et OSV.dev avant de conclure à une absence de risque. |
À retenir
Section intitulée « À retenir »- Une CVE identifie une faille. Le CVSS mesure sa gravité théorique. L'EPSS (modèle v4) 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.
- Depuis avril 2026, le NVD n'enrichit plus systématiquement toutes les CVE : croisez-le avec Vulnrichment et OSV.dev pour ne pas perdre en visibilité.
- Le SBOM est votre inventaire de dépendances (SPDX 3.0.1 ou CycloneDX 1.7). 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.
- Vos outils de scan font partie de la supply chain à protéger : épinglez-les par SHA, pas par tag mobile.
- Un workflow CVE sans reporting est incomplet. Les métriques montrent si vous progressez.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »CVE-2021-44228 pour la fameuse faille Log4Shell. Elle sert de numéro de dossier : elle identifie la faille, mais ne dit rien seule sur son urgence. C'est le CVSS et l'EPSS qui évaluent ensuite la gravité et la probabilité réelle d'exploitation.cosign attest.