Qu'est-ce que le VEX ?
Dire si une CVE affecte vraiment votre produit.
Le VEX (Vulnerability Exploitability eXchange) est un document lisible par machine qui indique si une vulnérabilité connue est réellement exploitable dans un produit donné — et si non, pourquoi. Il transforme le bruit d'un scan en une information utile pour vos clients et vos auditeurs.
Le VEX en une phrase
VEX = Vulnerability Exploitability eXchange. Une affirmation structurée, émise par le fabricant, qui indique si une CVE connue est exploitable dans un produit précis, et fournit une justification lorsque ce n'est pas le cas.
Un scan de composants (SBOM) signale toutes les vulnérabilités connues des bibliothèques présentes dans un produit. Mais une vulnérabilité présente dans un composant n'est pas toujours exploitable dans le produit final : le code vulnérable peut être absent du build, désactivé, ou inaccessible. Le VEX sert exactement à documenter cette distinction.
Exemple concret. Quand la vulnérabilité Log4Shell est publiée, un VEX permet d'affirmer : « notre produit utilise Log4j, mais la fonctionnalité vulnérable est désactivée — risque non exploitable ». Le client peut alors écarter l'alerte, avec une justification vérifiable, sans que vous ayez à divulguer votre architecture interne.
Les quatre statuts VEX
Un énoncé VEX attribue à chaque vulnérabilité l'un de quatre statuts d'exploitabilité. Le statut « non affecté » exige toujours une justification lisible par machine, afin que le consommateur puisse auditer l'affirmation.
| Statut | Signification | Ce qui suit |
|---|---|---|
| Non affecté | La vulnérabilité n'est pas exploitable dans ce produit | Une justification est requise ; le client peut écarter l'alerte |
| Affecté | La vulnérabilité est exploitable, le produit est impacté | Doit inclure une remédiation ou une mesure d'atténuation |
| Corrigé | La vulnérabilité a été traitée dans la version référencée | Le client met à jour |
| Sous investigation | L'analyse est en cours | Statut provisoire, mis à jour une fois l'analyse conclue |
CycloneDX, OpenVEX ou CSAF ?
Trois formats lisibles par machine coexistent. Ils portent tous la même information de fond — un produit, une vulnérabilité, un statut, une justification — et sont interopérables. Le choix dépend surtout de votre écosystème et de la demande de vos clients.
CycloneDX VEX
Le VEX peut vivre dans le même document que le SBOM. Idéal si vous générez déjà des SBOM CycloneDX : inventaire et exploitabilité voyagent ensemble.
OpenVEX
Un énoncé autonome, minimal et facile à signer. Adapté quand vous voulez publier des affirmations VEX simples et vérifiables, indépendamment du SBOM.
CSAF VEX
Un profil du standard CSAF, sous forme d'avis de sécurité structuré. Attendu par les grands comptes et le secteur public qui publient des advisories lisibles par machine.
VEX et SBOM : deux documents complémentaires
Le SBOM (Software Bill of Materials) est l'inventaire des composants d'un produit : il dit ce que le produit contient. Le VEX dit si les vulnérabilités de ces composants sont exploitables dans le produit. L'un ne remplace pas l'autre.
Concrètement : le SBOM sert de base à l'analyse. En le croisant avec les CVE connues, on obtient une liste de vulnérabilités potentielles — souvent longue et bruitée. Le VEX est la couche qui transforme ce bruit en une liste courte de ce qui compte vraiment : ce qui est réellement exploitable, et ce qui ne l'est pas, avec une justification.
De la CVE à la décision
Une CVE est une vulnérabilité publiée. Elle devient exploitable — ou non — selon le contexte du produit. Le VEX est le document qui porte cette décision de triage, de façon lisible par machine et auditable.
Produire un VEX ancré dans le produit réel
Un VEX n'a de valeur que s'il est relié au bon produit, à la bonne version et au bon composant. VAST structure cette connaissance : Projects, Assets, inventaire, versions et dépendances. Lorsqu'une CVE apparaît, le contexte nécessaire pour décider — et pour justifier — est déjà en place.
VAST aide à générer des énoncés VEX reliés à cette connaissance produit, avec la traçabilité des décisions dans le temps. La décision d'exploitabilité, elle, reste explicite et sous contrôle de vos équipes : VAST structure l'information, il ne se substitue pas au jugement de sécurité.
Questions fréquentes sur le VEX
Le SBOM liste les composants d'un produit ; le VEX indique si les vulnérabilités de ces composants sont exploitables dans le produit. Le SBOM est l'inventaire, le VEX est l'analyse d'exploitabilité qui s'appuie dessus.
Quatre statuts : non affecté, affecté, corrigé et sous investigation. Le statut « non affecté » nécessite une justification lisible par machine pour que le client puisse auditer l'affirmation.
C'est la raison, tirée d'un vocabulaire contrôlé, pour laquelle une vulnérabilité n'est pas exploitable — par exemple « code non présent dans le build » ou « code vulnérable non atteignable ». Elle rend l'affirmation « non affecté » vérifiable.
Les trois formats (CycloneDX VEX, OpenVEX, CSAF) portent la même information et sont interopérables. Si vous produisez déjà des SBOM CycloneDX, CycloneDX VEX est naturel. Si vos clients sont des grands comptes ou le secteur public, CSAF est souvent attendu. Le format est une décision d'export, pas d'analyse.
Le VEX est un outil utile dans une démarche CRA : il aide à documenter l'exploitabilité des vulnérabilités d'un produit et à communiquer cette information de façon structurée. Il ne constitue pas à lui seul une preuve de conformité : la conformité dépend de l'ensemble de la démarche du fabricant.
Reliez vos VEX à la connaissance de vos produits.
À partir d'un Asset et de ses versions, VAST rassemble le contexte nécessaire pour décider de l'exploitabilité d'une CVE — puis pour la documenter.