Le Vulnerability Exploitability eXchange (VEX) est un format de données structuré qui permet aux éditeurs de logiciels d’indiquer à leurs clients quelles vulnérabilités connues affectant les composants de leurs logiciels sont réellement exploitables dans le contexte de leur produit. Les outils SBOM et SCA identifient chaque composant et signalent chaque CVE connue associée à ces composants, ce qui produit des listes de vulnérabilités techniquement exactes mais ingérables sur le plan opérationnel. Un produit logiciel qui utilise 500 composants open source sera associé à des centaines, voire des milliers de CVE. La majorité de ces CVE concerneront des chemins de code que le produit n’exécute jamais, des fonctions de bibliothèque qu’il n’appelle jamais ou des configurations qu’il n’utilise pas. Le VEX fournit au fournisseur le mécanisme pour communiquer ce contexte, en distinguant les vulnérabilités qui exigent une action du client de celles qui sont présentes dans le code mais non exploitables dans le produit.
La structure d’une déclaration VEX définit quatre statuts pour toute vulnérabilité connue d’un produit : « Non affecté » (le produit n’est pas touché par la vulnérabilité), « Affecté » (le produit est touché et une action est requise), « Corrigé » (la vulnérabilité a été corrigée dans une version précise) ou « En cours d’analyse » (le fournisseur détermine l’impact). Ces statuts transforment un nombre brut de vulnérabilités en un tableau de correction exploitable. Un produit présentant 312 CVE signalées, avec des déclarations VEX indiquant 289 « Non affecté » et 23 « Affecté », exige un effort de tri fondamentalement différent de 312 vulnérabilités indifférenciées.
Le modèle de confiance entre producteur et consommateur est la limite dans laquelle le VEX doit être évalué. Les déclarations VEX sont produites par l’éditeur du logiciel, c’est-à-dire la partie même dont le logiciel contient les vulnérabilités. Un fournisseur qui affirme que 289 de ses 312 CVE signalées sont « Non affecté » peut avoir raison, ou peut sous-estimer l’exploitabilité pour réduire sa charge de correction. Les déclarations VEX doivent être accompagnées d’une justification, c’est-à-dire la raison précise pour laquelle la vulnérabilité est jugée non exploitable, qui permet au consommateur d’évaluer l’analyse plutôt que de simplement lui faire confiance.
Pourquoi c’est important
Le VEX est important pour la TPRM, car sans lui, les entreprises doivent soit trier manuellement de longues listes de vulnérabilités, un processus coûteux et lent, soit appliquer une acceptation des risques en bloc à des vulnérabilités non signalées qui peuvent être exploitables ou non. Le VEX fournit le contexte du fournisseur qui permet un tri proportionné au risque, en concentrant l’effort de correction sur les vulnérabilités réellement exploitables dans le contexte de déploiement du produit.
- Les résultats SCA sans VEX exigent un tri manuel de toutes les vulnérabilités signalées
- Vulnérabilités exploitables et non exploitables non distinguées en l’absence de VEX
- Évaluation de l’exploitabilité par le fournisseur non fournie avec la SBOM
- VEX non demandé lors de l’évaluation de la sécurité des logiciels du fournisseur
- Acceptation des risques appliquée en bloc à des vulnérabilités non triées
À quoi ressemblent les bonnes pratiques
Les programmes VEX matures demandent des documents VEX en plus des SBOM pour les logiciels critiques, valident les déclarations VEX « Non affecté » en examinant leurs justifications et s’appuient sur un tri éclairé par le VEX pour prioriser la correction des statuts « Affecté » et « En cours d’analyse ».
- Demandez un document VEX en plus de la SBOM aux fournisseurs de logiciels critiques
- Examinez les justifications « Non affecté », sans vous contenter d’accepter le statut
- Donnez la priorité aux statuts « Affecté » et « En cours d’analyse » pour les actions de correction
- Suivez les mises à jour du VEX à mesure que les corrections progressent chez le fournisseur
- Intégrez le VEX aux exigences d’évaluation de la chaîne d’approvisionnement logicielle
Outils
VEX : spécification OpenVEX ; CycloneDX VEX ; orientations du groupe de travail VEX de la CISA
Le VEX est actuellement mis en œuvre dans deux formats principaux : OpenVEX (un format VEX autonome) et CycloneDX VEX (VEX intégré à une SBOM CycloneDX ou lié à celle-ci). Dependency-Track et d’autres outils de gestion de SBOM peuvent ingérer les deux formats et appliquer les statuts VEX pour filtrer les résultats de vulnérabilités. Pour les praticiens de la TPRM, demander aux fournisseurs un VEX au format CycloneDX correspond à la norme la plus largement mise en œuvre.
Enjeux de gouvernance
Le défi de gouvernance du VEX est le problème de la qualité des documents produits. Les fournisseurs qui génèrent des documents VEX sans analyse suffisante, en déclarant « Non affecté » toutes les CVE non signalées sans avoir réellement validé leur exploitabilité, produisent un VEX qui donne une fausse assurance. La solution de gouvernance consiste à exiger des justifications avec les déclarations VEX et à contrôler un échantillon des évaluations « Non affecté » pour vérifier le raisonnement du fournisseur.
- Exigez un VEX assorti de justifications, et pas seulement de statuts
- Prélevez un échantillon de déclarations « Non affecté » pour les valider au regard du raisonnement du fournisseur
- Demandez le rythme de mise à jour du VEX : à quelle fréquence le VEX est mis à jour à mesure que de nouvelles CVE sont publiées
- Suivez les statuts « Affecté » pour mesurer l’avancement des corrections du fournisseur
- Intégrez le VEX aux exigences de SBOM pour les fournisseurs de logiciels critiques
Si vous êtes une petite équipe
Pour votre fournisseur de logiciels le plus à risque, demandez son document VEX pour la version actuelle, en plus de la SBOM. S’il ne fournit pas de VEX, demandez-lui d’indiquer lesquelles des vulnérabilités signalées par l’SCA dans sa SBOM sont réellement exploitables dans le produit tel qu’il est déployé, et lesquelles ne le sont pas en raison des chemins de code, des configurations ou des fonctions de bibliothèque précis que le produit utilise. Cette question, même sans format VEX formel, recueille l’essentiel des informations d’un VEX et révèle si le fournisseur a mené l’analyse d’exploitabilité.
- Demandez un document VEX en plus de la SBOM à votre fournisseur de logiciels le plus à risque
- En l’absence de VEX, demandez au fournisseur d’indiquer quelles CVE sont exploitables et lesquelles ne le sont pas
- Examinez les justifications « Non affecté » d’un échantillon de déclarations
- Suivez les statuts « Affecté » pour mesurer l’avancement des corrections
Ce qu’il faut exiger
Demandez directement :
« Pouvez-vous fournir une documentation VEX en plus de votre SBOM, en indiquant précisément lesquelles des CVE signalées sont réellement exploitables dans votre produit tel qu’il est déployé, avec une justification pour les évaluations « Non affecté » ? »
Preuves attendues
- Document VEX au format OpenVEX ou CycloneDX VEX
- Justifications des statuts « Non affecté »
- Liste des statuts « Affecté » avec calendrier de correction
- Engagement sur le rythme de mise à jour du VEX
Il convient de demander à un fournisseur qui fournit une SBOM de fournir également un document VEX. La SBOM indique ce qui est présent. Le VEX indique ce qui exige une action. Les deux sont nécessaires à une gestion des vulnérabilités exploitable.
Comment le prouver
- Registres de demande et de réception des documents VEX
- Revue des justifications « Non affecté »
- Suivi de la correction des statuts « Affecté »
- Suivi des mises à jour du VEX
À retenir
312 résultats SCA. VEX : non disponible. Tri : 3 semaines pour identifier 23 vulnérabilités exploitables et 289 non exploitables dans le contexte. Le VEX aurait apporté la réponse en quelques minutes. L’SCA identifie chaque composant et chaque CVE qui lui est associée : c’est techniquement exact, mais ingérable sur le plan opérationnel. Le VEX fournit le contexte d’exploitabilité du fournisseur, en distinguant ce qui exige une action de ce qui est présent mais inatteignable. La SBOM recense les composants. Le VEX identifie les vulnérabilités qui exigent une action parmi eux. Les deux sont nécessaires pour gérer à grande échelle les vulnérabilités de la chaîne d’approvisionnement.