Une grande CVE est publiée — disons une faille critique dans OpenSSL ou dans une bibliothèque JSON très utilisée. En quelques heures, vos clients RSSI et vos équipes achats vont vous envoyer le même message : « Est-ce que votre produit est affecté ? » Sans processus en place, vous passez les 48h suivantes à fouiller votre code, à essayer de comprendre si cette version est celle que vous utilisez, et à rédiger une réponse manuelle à chaque client. C’est là que VEX entre en jeu.
1. VEX, c’est quoi exactement
VEX signifie Vulnerability Exploitability eXchange. C’est un format standardisé pour communiquer si une vulnérabilité connue (une CVE) est réellement exploitable dans un produit spécifique — et si oui, dans quelles conditions.
En résumé : une CVE dit « ce composant a une faille ». Un VEX dit « dans mon produit, cette faille est exploitable / non exploitable / corrigée / en cours d’analyse — et voilà pourquoi ».
VEX est complémentaire du SBOM. Le SBOM liste les ingrédients. Le VEX qualifie l’impact d’une vulnérabilité sur un produit précis qui utilise ces ingrédients.
Analogie simple : une CVE annonce qu’un type de verre de voiture peut se briser sous certaines conditions. Un VEX dit « mon modèle de voiture utilise ce verre, mais il est protégé par un film de sécurité — la CVE ne s’applique pas dans notre configuration ». Sans VEX, vos clients ne savent pas s’ils doivent s’inquiéter ou non.
2. Les 4 statuts VEX
Un document VEX attribue l’un de ces quatre statuts à chaque CVE concernant votre produit :
| Statut | Signification | Ce que vos clients comprennent |
|---|---|---|
| Not affected | Le composant est présent dans le produit mais la CVE n’est pas exploitable dans cette configuration. | Pas d’action requise de leur côté. |
| Affected | Le produit est vulnérable. Le correctif est disponible ou en cours. | Mise à jour à planifier selon la criticité. |
| Fixed | La vulnérabilité a été corrigée dans une version précise du produit. | Mettre à jour vers la version mentionnée. |
| Under investigation | L’analyse est en cours — vous n’avez pas encore de conclusion définitive. | En attente de votre analyse — délai à communiquer. |
3. Pourquoi le CRA rend le VEX incontournable
Le CRA impose deux obligations qui rendent VEX structurellement nécessaire :
- Obligation de notification d’incidents (dès sept. 2026) : en cas de vulnérabilité activement exploitée, vous devez notifier l’ENISA en 24h. Pour produire cette notification, il faut avoir analysé l’exploitabilité dans vos produits — c’est exactement ce que formalise le VEX.
- Obligation d’information des utilisateurs : le CRA impose d’informer vos clients des vulnérabilités affectant vos produits et des correctifs disponibles. Le VEX est le format standard pour structurer cette communication.
La pression viendra aussi de vos clients avant les autorités : les grands comptes industriels, les opérateurs d’infrastructures critiques et les organismes publics exigent déjà des SBOM et commenceront à exiger des VEX dès que leurs propres obligations NIS 2 et CRA seront actives. C’est un avantage commercial autant qu’une obligation réglementaire.
4. VEX et SBOM : le duo indissociable
Sans SBOM, le VEX est impossible à produire de façon fiable. Voici pourquoi les deux sont indissociables :
- Le SBOM indique que votre produit utilise log4j-core 2.14.1
- Une CVE critique (ex : CVE-2021-44228) est publiée sur log4j-core < 2.15.0
- La corrélation SBOM → CVE confirme que votre version est dans la plage affectée
- Vous analysez si le vecteur d’attaque est accessible dans votre configuration spécifique
- Vous émettez un VEX « Affected » ou « Not affected » avec justification
Ce flux — SBOM → corrélation CVE → analyse → VEX — doit être automatisé. Avec des dizaines de composants et des centaines de CVE publiées chaque mois, il est impossible de le faire manuellement.
5. Le format VEX en pratique
VEX n’est pas un format unique — il s’intègre dans les standards existants :
- CycloneDX VEX — le format le plus adopté dans l’écosystème CRA. Le VEX est intégré directement dans le document CycloneDX, ce qui simplifie la distribution.
- CSAF VEX (Common Security Advisory Framework) — standard OASIS, utilisé notamment par les PSIRT d’éditeurs majeurs (Microsoft, Red Hat, Siemens). Format JSON plus verbeux mais très complet.
- OpenVEX — format minimaliste proposé par la CISA, utile pour des communications simples et rapides.
6. Comment mettre en place un processus VEX
Un processus VEX opérationnel repose sur quatre éléments :
- Un SBOM à jour par produit — prérequis absolu. Sans inventaire précis des composants et versions, l’analyse d’impact CVE est impossible.
- Une veille CVE corrélée — les nouvelles CVE doivent être automatiquement croisées avec vos SBOM. Toute CVE affectant un composant présent dans un produit doit déclencher une alerte.
- Un processus d’analyse d’exploitabilité — pour chaque alerte, une personne qualifiée doit analyser si le vecteur d’attaque est accessible dans votre configuration (réseau exposé ? paramètre activé ? version exacte ?). Cette analyse doit être documentée.
- Un canal de communication client — les VEX doivent être publiés de façon accessible : portail sécurité, flux CSAF, email aux clients concernés selon la criticité.
Le statut « Under investigation » n’est pas une échappatoire : le CRA impose des délais. Utiliser systématiquement ce statut sans communiquer de délai de résolution est une pratique qui sera scrutée par les autorités. Définissez des SLA internes : 48h maximum pour passer à un statut définitif sur les CVE critiques.