VEX : l'exploitabilité
Le problème que le VEX résout
Un SBOM confronté aux bases de vulnérabilités produit des centaines d’alertes par produit. Une large majorité d’entre elles n’est pas exploitable dans votre contexte : le code vulnérable n’est pas appelé, la fonction concernée n’est pas compilée, une mesure d’atténuation est en place.
Sans mécanisme pour l’exprimer, deux issues, toutes deux mauvaises : soit l’équipe traite tout et s’épuise, soit elle supprime les alertes et perd la trace de ses décisions. Le second cas est exactement ce qu’une autorité cherchera à détecter.
La définition
VEX — vulnerability exploitability exchange — est une assertion structurée du fournisseur sur le statut d’exploitabilité d’une vulnérabilité donnée dans un produit donné.
Ce n’est pas un format concurrent du SBOM : c’est un complément. Le SBOM dit ce qu’il y a dedans ; le VEX dit ce que cela implique.
Les quatre statuts
| Statut | Sens | Ce qui est attendu en plus |
|---|---|---|
not_affected |
Le produit n’est pas affecté | Une justification normalisée, obligatoire |
affected |
Le produit est affecté | Une recommandation d’action pour l’utilisateur |
fixed |
La vulnérabilité est corrigée dans cette version | La version corrigée |
under_investigation |
L’analyse est en cours | Un délai, et une reprise effective |
under_investigation est un statut temporaire. Un VEX resté en investigation pendant
six mois est un défaut de processus, pas une position.
Les justifications de not_affected
Elles sont normalisées, et c’est ce qui fait la valeur du mécanisme :
| Justification | Signification |
|---|---|
| component_not_present | Le composant réputé vulnérable n’est pas dans le produit |
| vulnerable_code_not_present | Le composant est présent, mais pas la portion de code vulnérable |
| vulnerable_code_not_in_execute_path | Le code vulnérable existe mais n’est jamais exécuté |
| vulnerable_code_cannot_be_controlled_by_adversary | Le code est exécuté mais l’attaquant ne peut pas en contrôler l’entrée |
| inline_mitigations_already_exist | Une contre-mesure interne neutralise l’exploitation |
Une justification hors de cette liste, ou une justification vide, n’est pas recevable.
Les implémentations
| Implémentation | Porteur | Usage typique |
|---|---|---|
| CycloneDX VEX | OWASP | Intégré au même écosystème que votre SBOM pivot |
| OpenVEX | Communauté | Format minimal, autonome, facile à générer et à signer |
| CSAF 2.0, profil VEX | OASIS | Publication d’avis de sécurité lisibles par machine aux clients |
Ces implémentations expriment les mêmes notions. Le choix se fait sur l’usage : interne et outillé pour CycloneDX ou OpenVEX, externe et normalisé pour CSAF.
La valeur juridique
C’est le point à faire comprendre au Juridique et à la Cyber en même temps.
L’annexe I, partie II, point 2, exige de traiter et corriger les vulnérabilités sans délai. Elle n’exige pas de corriger l’intégralité des identifiants remontés par un scanner. Une vulnérabilité analysée et déclarée non exploitable, avec une justification normalisée, a été traitée.
Le VEX est donc la forme documentaire d’une décision motivée de ne pas corriger. Il transforme un choix d’ingénierie en pièce défensive. Sans lui, la même décision est indiscernable d’une négligence.
Le processus interne
| Étape | Qui | Sortie |
|---|---|---|
| Détection | Plateforme de pilotage | Alerte sur un couple produit / vulnérabilité |
| Analyse d’exploitabilité | Ingénierie du produit | Statut proposé + justification |
| Revue | PSIRT | Statut validé ou renvoyé |
| Arbitrage en cas de désaccord | Comité, selon la matrice RACI | Décision tracée |
| Émission | Chaîne automatisée | Document VEX signé, horodaté |
| Publication éventuelle | PSIRT + Juridique | Avis client, format CSAF |
| Réexamen | PSIRT | À chaque nouvelle version du produit |
Un VEX est attaché à un produit et à une version. Il n’est pas transposable automatiquement à la version suivante : le réexamen fait partie du processus.
Le lien avec les avis de sécurité
L’annexe I, partie II, point 4, impose de publier des informations sur les vulnérabilités corrigées. Le format CSAF 2.0 permet de publier à la fois les avis de correction et les assertions VEX, sous une forme que vos clients peuvent traiter automatiquement — ce qui réduit leur charge et la nôtre.