VEX : ce que dit un document Vulnerability Exploitability eXchange

Qu'est-ce que VEX ?

VEX, abréviation de Vulnerability Exploitability eXchange, est une déclaration lisible par machine indiquant si un produit est concerné par une vulnérabilité connue précise. Un fournisseur la publie pour que les utilisateurs du produit sachent quelles vulnérabilités exigent une action et lesquelles n'en exigent pas. Dans la plupart des organisations, ce travail du fournisseur revient à l'équipe de réponse aux incidents de sécurité produit (PSIRT).

Les Minimum Requirements for VEX de la CISA (avril 2023) le définissent indépendamment de tout format de fichier : un document VEX est un conteneur pour une ou plusieurs déclarations VEX, et chaque déclaration donne un statut pour une vulnérabilité dans un ou plusieurs produits. VEX est conçu pour fonctionner avec les SBOM, les bases de vulnérabilités et les avis de sécurité, mais n'a besoin d'aucun d'eux.

Pourquoi VEX existe : le bruit des SBOM

Une SBOM liste chaque composant d'un produit, y compris les dépendances transitives. Un scanner compare ces composants aux avis de sécurité et signale chaque CVE de chaque version qu'il trouve. Beaucoup de ces résultats ne s'appliquent pas : la fonction vulnérable n'est jamais appelée, une option de build l'exclut de la compilation, ou la configuration du produit bloque l'attaque. Sans VEX, chaque client doit le déterminer seul, ou ouvrir un ticket de support auprès du fournisseur.

VEX confie cette analyse à la partie qui peut la faire une seule fois, pour tout le monde : le fournisseur. Le scanner du client lit le document VEX et supprime les résultats que le fournisseur a marqués comme n'affectant pas le produit.

Les quatre statuts VEX

Chaque déclaration VEX porte exactement l'un des quatre statuts suivants :

Statut	Signification	Également requis
not_affected	Aucune remédiation ni atténuation n'est nécessaire. La vulnérabilité n'affecte pas les produits listés.	Une justification, ou une déclaration d'impact expliquant pourquoi
affected	La vulnérabilité affecte les produits listés, et l'auteur recommande d'agir.	Une déclaration d'action : ce que les utilisateurs doivent faire
fixed	Les versions de produit listées contiennent un correctif.	Rien de plus
under_investigation	L'auteur enquête et n'a pas encore tranché.	Rien de plus ; le statut est appelé à changer

Les justifications VEX pour not_affected

Une déclaration not_affected doit dire pourquoi. Selon les exigences de la CISA, elle DEVRAIT utiliser l'une des cinq justifications, et DOIT donner une déclaration d'impact en texte libre si elle ne le fait pas. OpenVEX et CSAF utilisent les cinq mêmes :

• component_not_present : le composant vulnérable n'est pas inclus dans le produit.
• vulnerable_code_not_present : le composant est inclus, mais pas le code vulnérable, généralement en raison de la façon dont il a été configuré ou construit.
• vulnerable_code_not_in_execute_path : le code vulnérable est présent, mais le produit ne l'appelle jamais.
• vulnerable_code_cannot_be_controlled_by_adversary : le code est présent et utilisé, mais un attaquant ne peut pas le contrôler pour exploiter la vulnérabilité.
• inline_mitigations_already_exist : des protections intégrées que les utilisateurs ne peuvent pas désactiver empêchent l'exploitation.

Les justifications diffèrent par les preuves qu'elles exigent. component_not_present nécessite un enregistrement exact de ce que contient le produit. Les trois du milieu nécessitent une analyse du code, comme une analyse d'atteignabilité ou une revue manuelle, et ce sont celles que les clients remettent le plus souvent en question.

Ce que contient une déclaration VEX

Les exigences minimales de la CISA listent ces éléments :

• Métadonnées du document : un identifiant de document, une version qui augmente à chaque modification, l'auteur (une personne ou une organisation, pas un outil), et les dates de première publication et de dernière mise à jour.
• Détails du produit : un ou plusieurs identifiants de produit, idéalement les mêmes que ceux de la SBOM du produit, comme une package URL (purl). Une déclaration peut aussi nommer le sous-composant qui porte la vulnérabilité.
• Détails de la vulnérabilité : un identifiant de vulnérabilité par déclaration, généralement une CVE, et une description ou un lien vers celle-ci.
• Le statut, avec la justification, la déclaration d'impact ou la déclaration d'action qu'il exige.
• Métadonnées de la déclaration : un identifiant, une version et des horodatages pour la déclaration elle-même.

Un exemple de document VEX

Ce document OpenVEX indique qu'un produit, example-api 3.2.0, livre une version vulnérable de log4j-core mais n'est pas concerné par Log4Shell, car la classe vulnérable est retirée pendant le build :

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

Le produit et son sous-composant sont identifiés par des package URLs : un scanner peut donc les faire correspondre aux composants de la SBOM du produit. La même déclaration en CycloneDX ou CSAF porte les mêmes faits dans une structure différente.

Les formats VEX : OpenVEX, CycloneDX VEX et CSAF VEX

VEX est un ensemble d'exigences, pas un format de fichier. La CISA nomme trois formats capables de le porter, et ils ne sont pas interchangeables :

	OpenVEX	CycloneDX VEX	CSAF VEX
Ce que c'est	Un petit format JSON conçu uniquement pour VEX	La section vulnerabilities d'un document CycloneDX	Le profil csaf_vex de la norme d'avis de sécurité CSAF
Norme	Spécification ouverte, v0.2.0	ECMA-424 (CycloneDX 1.6 et ultérieur)	OASIS Standard (CSAF 2.0, 2022)
Statuts	Les quatre statuts VEX	Ses propres états d'analyse : not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Des listes de statuts de produit : known_not_affected, known_affected, fixed, under_investigation
Justifications	Les cinq justifications de la CISA	Neuf qui lui sont propres, comme code_not_reachable et requires_configuration	Les cinq justifications de la CISA, sous forme de flags
Convient aux équipes qui	Veulent le fichier VEX le plus petit possible	Livrent déjà des SBOM CycloneDX	Publient déjà des avis de sécurité CSAF
Lu par Trivy	Oui	Oui, pour les scans de SBOM	Oui
Lu par Grype	Oui	Non indiqué	Oui

OpenVEX est le plus léger : un document avec un auteur, un horodatage, une version et une liste de déclarations. Sa spécification traite VEX comme une suite de déclarations, chacune remplaçant ou complétant les précédentes.

CycloneDX VEX utilise la même structure vulnerabilities que CycloneDX emploie pour tout le reste, avec un objet analysis qui contient un état, une justification, des valeurs de réponse telles que update ou will_not_fix, et un détail en texte libre. Les données VEX peuvent se trouver dans la SBOM ou dans un document CycloneDX distinct qui pointe vers la SBOM avec BOM-Link. Notez que son vocabulaire de justifications n'est pas celui de la CISA : la conversion depuis ou vers OpenVEX ou CSAF nécessite donc une table de correspondance. Voir CycloneDX vs SPDX pour le volet SBOM.

CSAF VEX est un document CSAF complet de catégorie csaf_vex. Il exige une arborescence de produits, une CVE ou un autre identifiant, des notes et, pour chaque produit, une déclaration d'impact (s'il n'est pas concerné) ou une remédiation (s'il est concerné). Il est plus lourd qu'OpenVEX, mais il convient aux organisations qui distribuent déjà des avis CSAF via un fournisseur CSAF.

VEX vs VDR

Un Vulnerability Disclosure Report (VDR) liste les vulnérabilités qui affectent bel et bien un produit, avec leur analyse et leur remédiation. NIST SP 800-161 recommande les VDR comme pratique de la chaîne d'approvisionnement, et CycloneDX prend en charge les deux. La différence, selon les exemples CycloneDX :

• Le VDR dit quelles vulnérabilités affectent le produit. Il peut couvrir des vulnérabilités trouvées dans votre propre code et jamais publiées ailleurs.
• VEX est surtout une déclaration négative : quelles vulnérabilités connues n'affectent pas le produit, et pourquoi. Il ne couvre que les vulnérabilités connues.

De nombreux fournisseurs publient les deux : le VDR répond à « que dois-je corriger », le VEX à « que puis-je ignorer ».

Comment les scanners utilisent VEX

Un document VEX ne fait gagner du temps que si les outils du client le lisent. C'est le cas de deux scanners open source largement utilisés :

• Trivy accepte VEX via son option --vex (marquée expérimentale) depuis un fichier local, un dépôt VEX, une attestation OCI ou une référence dans la SBOM. Il lit OpenVEX, CycloneDX VEX pour les scans de SBOM et CSAF VEX, et cesse de signaler les vulnérabilités marquées not_affected.
• Grype accepte OpenVEX et CSAF VEX via --vex. Il déplace les correspondances not_affected et fixed vers une liste ignorée, affichée avec --show-suppressed, et peut en option ajouter aux résultats les déclarations affected et under_investigation.

La correspondance dépend des identifiants. Si le VEX nomme le produit avec un identifiant différent de celui de la SBOM, le scanner ne peut pas les relier et le résultat reste.

Qui publie VEX

VEX vient généralement du fournisseur : l'éditeur, la distribution open source ou le fabricant d'appareils qui livre le produit. Chez le fournisseur, c'est une tâche du PSIRT, qui s'inscrit dans le même cycle de vie de la gestion des vulnérabilités que celui qui produit les avis et les correctifs. Red Hat, par exemple, publie des documents CSAF VEX dans un répertoire dédié de son flux CSAF, à côté de ses avis. Pour le travail quotidien des ingénieurs PSIRT, voir le rôle PSIRT.

Les clients écrivent aussi des VEX pour leur propre usage, afin de consigner leurs décisions de tri sur le produit d'un fournisseur pour que leur scanner cesse de les remonter. Des réglementations telles que le Cyber Resilience Act de l'UE demandent aux fabricants de gérer les vulnérabilités des composants qu'ils livrent, et VEX est un moyen d'indiquer aux utilisateurs lesquelles s'appliquent.

Tenir VEX à jour

• Les statuts évoluent. Une déclaration commence généralement par under_investigation et finit par not_affected, ou par affected puis fixed. Publiez chaque changement ; la CISA exige que la version augmente à chaque fois.
• Les nouvelles releases exigent de nouvelles déclarations. Un verdict not_affected pour la 3.2.0 ne dit rien de la 3.3.0. Revérifiez-le chaque fois que le composant, sa version ou la configuration du build change.
• Gardez VEX séparé de la SBOM. La SBOM décrit une release et reste figée. VEX continue d'évoluer après la release : le publier comme document distinct évite de rééditer les SBOM.
• Publiez là où les outils regardent. À côté de la SBOM, sous forme d'attestation sur l'image de conteneur ou dans votre flux d'avis, et indiquez l'emplacement dans votre politique de divulgation. Voir la divulgation coordonnée des vulnérabilités.

Les limites de VEX

• C'est une affirmation, pas une preuve. Une déclaration not_affected est l'évaluation de son auteur. La CISA recommande de lier cryptographiquement l'identité de l'auteur au document, mais la plupart des consommateurs font encore confiance à VEX parce qu'ils font confiance au fournisseur.
• Le silence ne signifie rien. VEX n'implique aucun statut par défaut. Pour une vulnérabilité sans déclaration, le statut est inconnu, pas « non concerné ».
• Les formats ne se correspondent pas point par point. CycloneDX utilise des états et des justifications différents d'OpenVEX et de CSAF : les conversions perdent donc des détails.
• Il ne vaut que ce que vaut l'inventaire. Affirmer qu'un composant est absent exige de savoir exactement ce que contient le produit, y compris les dépendances transitives et tout ce que le build a téléchargé en dehors du gestionnaire de paquets.

VEX commence par une SBOM exacte

Chaque déclaration VEX pointe vers des composants, et la justification la plus facile à défendre, component_not_present, n'est vraie que si l'inventaire est complet. Une SBOM générée en scannant des lockfiles après coup peut lister des dépendances de développement qui ne sont jamais livrées et rater des paquets que le build a récupérés autrement.

CRACI exécute les builds GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches et les dépendances qu'aucun lockfile ne liste. Chaque SBOM porte un état de complétude et s'exporte en CycloneDX ou SPDX. Les SBOM surveillées sont réévaluées en continu, l'historique des builds montre quels builds passés contenaient une dépendance vulnérable, et CRACI prend en charge VEX. Voir la génération de SBOM et le suivi des vulnérabilités.

VEX : questions fréquentes

Que signifie VEX ?

VEX signifie Vulnerability Exploitability eXchange. C'est une déclaration lisible par machine indiquant si un produit est concerné par une vulnérabilité connue précise, publiée pour que les utilisateurs sachent quelles vulnérabilités signalées exigent une action.

Quelle est la différence entre une SBOM et VEX ?

Une SBOM liste les composants d'un produit. VEX indique, pour une vulnérabilité donnée, si ce produit est concerné. La SBOM change rarement après une release ; les déclarations VEX évoluent à mesure que le fournisseur enquête et corrige. C'est pourquoi VEX est généralement publié comme document distinct qui se réfère au produit, plutôt qu'intégré à la SBOM.

Quels sont les quatre statuts VEX ?

not_affected, affected, fixed et under_investigation. Une déclaration not_affected nécessite une justification ou une déclaration d'impact, et une déclaration affected nécessite une déclaration d'action indiquant ce que les utilisateurs doivent faire.

Quel format VEX utiliser ?

Utilisez celui que lisent vos destinataires et vos outils. OpenVEX est le plus petit et fonctionne avec Trivy et Grype. CycloneDX VEX convient aux équipes qui livrent déjà des SBOM CycloneDX. CSAF VEX convient aux organisations qui publient déjà des avis de sécurité CSAF, ce qui est courant dans les logiciels industriels et d'entreprise. De nombreux fournisseurs finissent par convertir de l'un à l'autre.

VEX est-il la même chose qu'un avis de sécurité ?

Non. Un avis de sécurité explique une vulnérabilité, qui est concerné et comment la corriger, surtout à destination des personnes. VEX est un statut ciblé et lisible par machine, par produit et par vulnérabilité, surtout à destination des outils. Les deux vont souvent de pair : la norme CSAF comporte à la fois un profil d'avis de sécurité et un profil VEX.

Qui écrit les documents VEX ?

Généralement le fournisseur du produit, souvent son équipe de réponse aux incidents de sécurité produit (PSIRT), car elle sait comment le produit est construit et configuré. Les exigences minimales de la CISA autorisent aussi des tiers à rédiger des VEX, et chaque document doit nommer son auteur.

Les scanners de vulnérabilités lisent-ils VEX ?

Plusieurs le font. Trivy accepte OpenVEX, CycloneDX VEX et CSAF VEX via son option --vex et écarte les résultats marqués not_affected. Grype accepte OpenVEX et CSAF VEX via --vex et déplace les résultats not_affected et fixed vers une liste ignorée.