VEX (Vulnerability Exploitability eXchange)

devsecops

Définition

VEX (Vulnerability Exploitability eXchange) est un standard d'échange de documents qui permet aux fournisseurs de logiciels de communiquer à leurs clients si et comment les vulnérabilités CVE répertoriées dans un SBOM affectent réellement leurs produits. VEX est une réponse pratique au problème de la "CVE fatigue" : un SBOM peut lister des centaines de CVEs dans les dépendances d'un logiciel, mais la grande majorité ne sont pas exploitables dans le contexte spécifique du produit. Le problème que VEX résout est fondamental dans l'ère du SBOM : savoir qu'un composant présente une CVE ne suffit pas — il faut savoir si le code vulnérable est réellement utilisé, si la fonctionnalité vulnérable est exposée, si des contrôles compensatoires atténuent le risque. Sans cette information, les équipes de sécurité des clients sont submergées de milliers d'alertes CVE dont seule une fraction représente un risque réel. Un document VEX accompagne le SBOM d'un produit et exprime pour chaque CVE pertinente l'un des quatre statuts suivants : "Affected" (le produit est affecté et une action est requise), "Not Affected" (le produit n'est pas affecté, avec justification : code non accessible, fonctionnalité désactivée, vulnérabilité mitigée), "Fixed" (le problème a été corrigé dans la version X), et "Under Investigation" (le fournisseur analyse l'impact). VEX s'intègre aux formats de SBOM existants : CycloneDX supporte VEX nativement dans son schéma, et des formats VEX autonomes comme OpenVEX ou CSAF VEX permettent des mises à jour séparées du SBOM. L'automatisation de la génération de documents VEX basée sur l'analyse du code (via SAST et SCA) est un domaine actif de développement dans l'écosystème DevSecOps. L'adoption de VEX est encouragée par les réglementations de cybersécurité : la CISA (Cybersecurity and Infrastructure Security Agency) américaine a publié des guides sur VEX dans le cadre du programme SBOM, et des régulateurs européens dans le contexte du Cyber Resilience Act examinent VEX pour la communication de vulnérabilités dans les produits IoT et logiciels.

Les quatre statuts VEX et leur signification

VEX définit quatre statuts pour chaque CVE dans le contexte d'un produit : "Affected" (action requise avec justification d'impact), "Not Affected" (avec l'une des justifications formelles : Component Not Present, Vulnerable Code Not Present, Vulnerable Code Cannot Be Controlled By Adversary, Vulnerable Code Not in Execute Path), "Fixed" (avec référence à la version corrigeant le problème), et "Under Investigation" (évaluation en cours avec date de mise à jour attendue).

Formats VEX : CycloneDX, OpenVEX, CSAF

CycloneDX intègre VEX nativement dans son format SBOM (champ vulnerabilities[]). OpenVEX est un format JSON-LD autonome spécifié par Sigstore/Chainguard, conçu pour être signé cryptographiquement et versionné. CSAF (Common Security Advisory Format) de l'OASIS, utilisé par les CVSSv4 advisories, inclut un profil "VEX" pour les avis de sécurité structurés. Les outils vexctl (Chainguard) et CycloneDX CLI permettent de générer et valider des documents VEX.

Intégration VEX dans les pipelines de gestion de vulnérabilités

Les équipes DevSecOps peuvent consommer les documents VEX des fournisseurs pour filtrer automatiquement les alertes SCA : si un fournisseur déclare "Not Affected" pour une CVE spécifique avec justification valide, cette alerte peut être supprimée automatiquement dans les outils de gestion de vulnérabilités (DefectDojo, Snyk, JFrog Xray). Cette automatisation réduit le bruit et permet aux équipes de se concentrer sur les vulnérabilités réellement exploitables.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis