Qu’est-ce que le VEX ? Dire qu’une faille ne vous touche pas

Passez n’importe quel analyseur sur un SBOM : il signalera des dizaines de vulnérabilités connues. La plupart ne comptent pas pour ce produit : la fonction vulnérable n’est jamais appelée, l’option est désactivée, le composant ne sert qu’à la compilation. Le VEX, pour Vulnerability Exploitability eXchange, est la façon standard de le dire, sous une forme que les outils et les clients savent lire.

Une déclaration VEX est une affirmation simple : ce produit, cette vulnérabilité, ce statut, avec la raison ou l’action qui va avec.

Pourquoi c’est utile

Sans VEX, chaque client qui analyse votre produit obtient la même longue liste et vous pose les mêmes questions, une par une. Avec le VEX, vous répondez une fois, dans un fichier que leurs outils appliquent tout seuls : les résultats que vous avez évalués comme sans effet sur le produit disparaissent de leurs rapports, avec votre justification.

Pour un fabricant soumis au Cyber Resilience Act, le VEX est aussi une preuve. L’annexe I demande de recenser et de traiter les vulnérabilités de vos produits, et de les livrer sans vulnérabilité exploitable connue. Une trace datée et signée de la raison pour laquelle chaque vulnérabilité restante n’est pas exploitable, c’est exactement ce que voudra voir un évaluateur ou une autorité de surveillance du marché. Cela évite aussi à votre équipe de refaire la même analyse à la version suivante.

Les quatre statuts

Le groupe de travail VEX réuni par la CISA américaine a défini quatre statuts, repris par tous les formats :

Statut	Signification	Ce qui doit l’accompagner
Non concerné	Le produit n’est pas touché par la vulnérabilité	Une justification, ou une explication de l’impact
Concerné	Le produit est touché	Une mesure : ce que les utilisateurs doivent faire
Corrigé	Ces versions contiennent le correctif	Rien de plus
En cours d’analyse	Le statut n’est pas encore connu	Rien de plus ; à mettre à jour dès que vous savez

Un document VEX ne suppose jamais de statut : une vulnérabilité qu’il ne cite pas n’est tout simplement pas couverte.

Les cinq justifications de « non concerné »

Le document de la CISA sur les justifications en liste cinq :

Composant absent : le composant vulnérable n’est pas du tout dans le produit (l’analyseur s’est trompé de paquet, ou ce n’est qu’un outil de build).
Code vulnérable absent : le composant est là, mais pas le code vulnérable, par exemple un module exclu à la compilation.
Code vulnérable hors de portée d’un attaquant : le code s’exécute, mais un attaquant ne peut pas l’atteindre avec l’entrée nécessaire.
Code vulnérable jamais exécuté : le code est présent mais le produit ne l’exécute jamais.
Mesures d’atténuation déjà en place : le produit contient des protections qui empêchent l’exploitation.

Les deux premières, et « jamais exécuté », sont en général les plus simples à prouver : un graphe de dépendances ou une analyse d’atteignabilité peut montrer que le code vulnérable est absent ou jamais appelé. Les deux autres demandent un raisonnement soigné et une explication avec vos mots ; la CISA rappelle qu’un attaquant peut parfois détourner l’exécution vers du code qu’on croyait inatteignable.

Les formats

Le VEX est un concept, avec plusieurs mises en œuvre. Toutes respectent les exigences minimales de la CISA :

CSAF VEX : un profil du Common Security Advisory Framework 2.0 de l’OASIS, aussi norme ISO (ISO/IEC 20153:2025). C’est le format de référence pour publier des avis de sécurité avec arbres de produits et mesures correctives ; beaucoup de grands éditeurs et de CERT nationaux l’utilisent.
CycloneDX VEX : la section des vulnérabilités d’un document CycloneDX, avec un bloc analysis par vulnérabilité. Il peut vivre dans le SBOM ou dans un fichier séparé qui y renvoie. CycloneDX a ses propres noms, plus fins, pour les états et les justifications, qui correspondent à peu près à ceux de la CISA.
OpenVEX : un format JSON-LD minimal tenu par l’OpenSSF, indépendant du format de SBOM, avec des outils comme vexctl pour créer et appliquer les documents. Des distributions comme Ubuntu publient leurs données VEX dans ce format.
SPDX 3.0 exprime le VEX par des relations dans son profil sécurité.

Un exemple

Voici un document OpenVEX qui dit que la version 4.2.0 d’une passerelle n’est pas concernée par une vulnérabilité d’une bibliothèque qu’elle embarque, parce que le code vulnérable n’est jamais généré :

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://acme.example/vex/gateway-4.2.0-2026-11-08",
  "author": "Acme Devices Security <security@acme.example>",
  "timestamp": "2026-11-08T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-45296" },
      "products": [
        {
          "@id": "pkg:generic/acme/gateway@4.2.0",
          "subcomponents": [{ "@id": "pkg:npm/path-to-regexp@0.1.7" }]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "No route of the gateway has two parameters in one path segment (such as /:a-:b), so the backtracking regular expression is never generated."
    }
  ]
}

Le document a un auteur, un horodatage et un numéro de version qui augmente à chaque modification d’une déclaration. Chaque déclaration nomme la vulnérabilité, le produit (et le composant qu’il contient), le statut et la raison. Les champs restent en anglais : ce sont les valeurs que lisent les outils.

Bonnes pratiques

Soyez précis sur le produit : une déclaration VEX couvre les versions qu’elle nomme, rien d’autre. Utilisez des URL de paquet.
Expliquez, ne vous contentez pas d’une étiquette : un code de justification seul ne convainc personne. Ajoutez une courte explication qu’un client comprend.
Tenez-le à jour : une nouvelle version peut changer la réponse. Réévaluez quand le code qui appelle un composant change, et publiez une nouvelle version du document.
Ne cachez pas un vrai risque : « non concerné » est une affirmation que vous devrez peut-être défendre. Dans le doute, dites « en cours d’analyse », ou « concerné » avec une mesure d’atténuation.
Publiez-le à côté de vos avis, et renvoyez-y depuis votre page de sécurité. Avis lisibles par machine (CSAF) et VEX aident ensemble à remplir l’obligation du CRA d’informer les utilisateurs sur les vulnérabilités corrigées.

Le VEX et l’horloge de signalement

Une déclaration VEX n’est pas un signalement aux autorités. Si une vulnérabilité de votre produit est activement exploitée, le délai de 24 heures du CRA s’applique, quoi que dise votre VEX sur d’autres versions. Mais le VEX aide à trancher vite : si vous savez déjà que le code vulnérable d’un composant n’est jamais exécuté, vous savez en quelques minutes que le produit n’est pas concerné. Voir l’horloge de signalement.

Ce que fait Provetry

Pour chaque vulnérabilité trouvée dans une version, vous enregistrez une évaluation VEX (statut, justification et explication) ; elle suit dans les versions suivantes qui contiennent le même composant, et Provetry la signale quand votre CI trouve ensuite un appel à la fonction vulnérable. Son étape de CI propose « non concerné » quand un paquet vulnérable n’est jamais chargé ou une fonction vulnérable jamais appelée, avec la preuve (niveau fonction pour npm, PyPI et Java avec les offres Pro et Consultant). Chaque version se télécharge avec un document OpenVEX et, avec les offres payantes, une page publique publie vos avis CSAF et un flux VEX des vulnérabilités closes (non concernées ou corrigées) dans les versions maintenues.