Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Une déclaration VEX (Vulnerability Exploitability eXchange) indique un statut pour une vulnérabilité concernant un ou plusieurs produits.
- Une déclaration VEX correspond à l'affirmation de son auteur ; l'auditeur vérifie donc qui l'a émise, si elle a été modifiée et quelle analyse étaye cette situation.
- L'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) définit quatre statuts VEX ; toute déclaration indiquant le statut « non concerné » doit en préciser la raison, au moyen d'une justification ou d'une déclaration écrite sur l'impact.
- Plusieurs formats peuvent prendre en charge VEX, et CycloneDX utilise ses propres étiquettes d'état et de justification ; il peut donc être nécessaire de traduire ses documents en utilisant les noms définis par la CISA.
- En l'absence de correctif en amont, un fournisseur peut indiquer « non concerné » en fournissant une justification, « concerné » en précisant les mesures à prendre, ou « corrigé » dès qu'une version corrigée est intégrée à la version de développement.
Une liste des composants logiciels (SBOM) vous indique ce que contient une version, mais ne précise pas quelles vulnérabilités détectées par un scanner parmi celles associées à ces composants s'appliquent réellement à votre produit. VEX (Vulnerability Exploitability eXchange) comble cette lacune : il s'agit du moyen par lequel un fournisseur ou un tiers indique si une vulnérabilité connue affecte un produit logiciel.
Les recommandations VEX de la CISA considèrent chaque déclaration comme une affirmation de son auteur. Le degré de fiabilité qu’un lecteur peut en tirer dépend de l’émetteur, de la manière dont elle est signée et des éléments probants acceptés par le cadre de conformité de l’auditeur. Dans cet article, l’expression « élément probant vérifiable » désigne une affirmation qu’un auditeur peut vérifier par rapport à l’analyse qui la sous-tend. Une déclaration VEX ne constitue pas une preuve en soi.
Qu'est-ce que le « Vulnerability Exploitability eXchange » ?
Selon la définition de la CISA, le VEX est un moyen d’indiquer le statut d’un produit ou d’un composant logiciel au regard d’une vulnérabilité. Dans les « Exigences minimales pour le VEX » de la CISA, version 1.0.0 d’avril 2023, un document VEX regroupe une ou plusieurs déclarations. Chaque déclaration indique un statut unique pour une vulnérabilité donnée, concernant un ou plusieurs produits.
VEX est conçu pour s'intégrer aux SBOM, aux bases de données de vulnérabilités et aux avis de sécurité, mais la CISA précise qu'il n'en nécessite aucun. Le document de la CISA d'avril 2022 consacré aux cas d'utilisation décrit un document VEX comme constituant en soi une forme d'avis de sécurité.
VEX est un format de données. Il ne s'agit pas d'une loi, et les exigences minimales de la CISA précisent qu'elles ne constituent pas une politique officielle de la CISA et n'imposent aucune obligation de conformité. Les éléments minimaux de la SBOM pour 2026 définis par la CISA et ses partenaires n'incluent pas non plus VEX.
Un fournisseur ou un tiers peut rédiger un document VEX. L'auteur doit être identifié en tant que personne physique ou morale et est responsable du contenu.
Ce que VEX prouve et ne prouve pas à un auditeur
L’auteur étant responsable du contenu d’un document VEX, tout ce qu’il contient constitue une déclaration de sa part. Les recommandations de la CISA précisent que les documents et les déclarations doivent être signés, l’identité de l’auteur étant liée de manière cryptographique à la signature. Elles exigent également l’attribution d’un numéro de version plus élevé à chaque modification du contenu, ainsi que l’apposition d’horodatages indiquant la date de première publication et celle de la dernière mise à jour. Ces éléments permettent à un auditeur de déterminer qui a fait cette déclaration, à quel moment, et si elle a été modifiée depuis.
Extrait du document sur les cas d'utilisation de la CISA : la publication d'avril 2022 précise que les statuts VEX n'ont pas pour but de clore un débat. Ils ont pour objectif d'aider les consommateurs à prendre des décisions éclairées ; ainsi, un lecteur peut remettre en question un statut plutôt que de le considérer comme définitif.
La CISA et ses partenaires ont publié le 29 juillet 2026 les « Éléments minimaux pour une nomenclature logicielle (SBOM) 2026 ». La section intitulée « Mise en corrélation de la SBOM avec les avis de sécurité » traite du VEX et du Cadre commun d’avis de sécurité (CSAF). Elle indique qu’une mise à jour du statut permet d’éviter des efforts inutiles lorsqu’une source fiable estime qu’un risque potentiel ne se traduit pas par un risque réel. Cet avantage dépend de la confiance accordée à la source ; c’est donc l’identité de l’émetteur qui détermine si un lecteur peut donner suite à une mise à jour de statut.
L'association de VEX à une SBOM nécessite également une SBOM complète. L'élément « Coverage » du document de 2026 stipule qu'un destinataire devrait pouvoir conclure qu'une vulnérabilité nouvellement signalée ne le concerne pas si la SBOM ne mentionne pas le composant en question, et que cette conclusion n'est valable que si la SBOM répertorie l'ensemble des composants. Ce même document précise que la vérification de l’exactitude, de la couverture et de l’exhaustivité d’une SBOM ne relève pas de ses éléments minimaux ; par conséquent, une déclaration VEX s’appuyant sur une SBOM peut hériter de toute erreur contenue dans cette dernière.
De plus, une déclaration VEX ne fait état que des vulnérabilités présentes dans un composant ; elle ne permet donc pas de savoir si le paquet que vous avez récupéré a été altéré ou s'il est malveillant. Si votre produit repose sur des paquets open source, la fiabilité de vos déclarations VEX dépend entièrement de la précision de vos registres indiquant les éléments inclus dans chaque version.
Certains évaluateurs demandent également l’analyse qui sous-tend chaque constat. Pour les dispositifs médicaux, les recommandations non contraignantes de février 2026 de la Food and Drug Administration (FDA) américaine en matière de cybersécurité avant la mise sur le marché demandent aux fabricants de fournir une évaluation des risques de sûreté et de sécurité pour chaque vulnérabilité connue de leurs composants, ainsi que les mesures de contrôle des risques mises en place pour y remédier. Un état ne s’accompagnant d’aucune analyse ne donne guère d’éléments à tester à un tel évaluateur ; c’est pourquoi les champs qui présentent le raisonnement, abordés ci-après, revêtent une importance capitale.
Les quatre statuts et ce que doit préciser une déclaration de non-incidence
Les exigences minimales de la CISA, version 1.0.0, stipulent que chaque déclaration doit utiliser l'un des quatre statuts. Deux d'entre eux nécessitent des précisions, et le tableau indique lesquels.
| Statut | Ce que cela révèle au lecteur | Ce que la déclaration doit également contenir | Base |
|---|---|---|---|
| Non concerné | Aucune mesure corrective ou d'atténuation n'est nécessaire, car les produits mentionnés ne sont pas concernés. | Une justification, ou une déclaration écrite expliquant les conséquences en l'absence de justification | Recommandations de la CISA |
| concerné | Les produits mentionnés sont concernés, et l'auteur recommande de prendre certaines mesures | Une déclaration d'action, qui doit décrire comment remédier au problème ou en atténuer les effets | Recommandations de la CISA |
| Corrigé | Les produits mentionnés ci-dessous contiennent des correctifs pour cette vulnérabilité | Rien au-delà des champs que chaque déclaration véhicule | Recommandations de la CISA |
| Fait l'objet d'une enquête | L'auteur ou d'autres personnes mènent actuellement des recherches et n'ont pas encore déterminé le statut définitif. | Rien de plus, même si la CISA s'attend à ce que la situation évolue une fois l'enquête terminée | Recommandations de la CISA |
Le document sur les cas d'utilisation d'avril 2022 exige une déclaration d'impact pour chaque déclaration « non concernée ». Les exigences minimales d'avril 2023 permettent de la remplacer par une justification.
Les exigences minimales définissent cinq valeurs d'alignement, dont la dernière est plus stricte que son nom ne le laisse entendre :
- La mention « Composant absent » s'applique lorsque le sous-composant vulnérable n'est pas inclus dans le produit.
- L'expression « code vulnérable absent » désigne un composant qui est bien présent, alors que le code vulnérable ne l'est pas, généralement parce que la configuration de compilation l'exclut.
- Le code vulnérable qui ne se trouve pas sur le chemin d'exécution correspond à du code qui ne peut pas s'exécuter compte tenu de la manière dont le produit l'utilise.
- L'expression « code vulnérable non contrôlable par l'adversaire » désigne un code qui existe et qui est utilisé, mais qu'un attaquant ne peut pas manipuler pour exploiter la vulnérabilité.
- Les mesures d'atténuation intégrées doivent comporter des protections intégrées qu'un attaquant ne peut pas contourner, qu'un utilisateur ne peut ni configurer ni désactiver, et qui empêchent totalement toute exploitation par des vecteurs d'attaque connus.
Chaque valeur nécessite généralement un justificatif différent : une SBOM ou un autre document de composition, une configuration de compilation, une analyse du chemin d’appel, une analyse du traitement des entrées, ou la mesure d’atténuation elle-même. Les exigences de la CISA permettent d’ajouter à une déclaration des notes expliquant comment le statut a été déterminé ; veillez donc à consigner ce justificatif à cet endroit ou à côté de la déclaration. La valeur de justification à elle seule ne permettra pas à un évaluateur de comprendre pourquoi vous avez formulé cette affirmation.
Adaptez le statut à l'avancement de votre travail. Le statut « Affected » indique aux lecteurs que le produit est vulnérable et que l'auteur recommande des mesures. Ne l'utilisez pas pour une vulnérabilité que vous n'avez pas encore analysée : tant que l'analyse est en cours, indiquez que la vulnérabilité fait l'objet d'une enquête. La CISA s'attend à ce que ce statut évolue à l'issue de l'enquête ; par conséquent, le fait de le laisser inchangé sans mise à jour laisse entendre au réviseur que l'analyse est peut-être au point mort.
Formats et spécifications compatibles avec VEX
Les exigences minimales de la CISA pour 2023 mentionnent trois formats pouvant contenir ou servir à générer des documents VEX : CSAF, CycloneDX et OpenVEX. Ces exigences définissent leurs éléments de données indépendamment de tout format. Le Software Package Data Exchange (SPDX), qui n’est pas mentionné dans la liste de la CISA, peut également prendre en charge les quatre statuts : son profil de sécurité, dans sa version 3.0.1, comporte une classe de relation VEX pour chacun d’entre eux. La spécification VEX de chaque format définit ses propres champs, et les versions ainsi que le statut varient d’un format à l’autre.
| Format | Responsable de la maintenance | Version et état, vérifiés le 19 octobre 2026 | Base |
|---|---|---|---|
| CSAF (profil VEX) | Comité technique CSAF d'OASIS | La norme CSAF 2.0 est devenue une norme OASIS en novembre 2022 et a été publiée sous la référence ISO/IEC 20153:2025. La norme CSAF 2.1 en est actuellement au stade du projet de spécification du comité n° 03, daté du 11 septembre 2026. | Norme officielle (2.0), projet (2.1) |
| CycloneDX | Fondation OWASP et Ecma TC54 | CycloneDX 1.7 est défini par la norme ECMA-424, 2e édition, décembre 2025. | Norme formelle |
| OpenVEX | Communauté OpenVEX | Version 0.2.0. Le fichier README du projet qualifie toujours la spécification de « projet ». | Spécifications communautaires |
| SPDX (profil de sécurité) | Projet SPDX | SPDX 3.0.1 est la dernière version stable. La version 3.1 a été annoncée en tant que version candidate en janvier 2026. | Caractéristiques techniques |
Les formats n'utilisent pas tous les libellés de la CISA. La documentation du projet OpenVEX indique que CycloneDX VEX définit ses propres libellés d'état et de justification ; il peut donc être nécessaire de traduire les documents afin qu'ils correspondent aux noms de la CISA. Cet article utilise systématiquement les noms de la CISA. Choisissez le format que votre chaîne d'outils et vos clients prennent déjà en charge, car les éléments de données VEX n'en dépendent pas.
Lorsqu'il n'existe aucune solution en amont
Ce que vous devez prouver dépend de l’existence ou non d’un correctif. Si le développeur en amont en a publié un et que vous le diffusez, la déclaration peut indiquer « corrigé » et citer les versions du produit qui le contiennent. Une déclaration indiquant que le problème est « corrigé » ne nécessite généralement pas d’analyse visant à déterminer si le code vulnérable peut s’exécuter, car elle fait référence à une mesure corrective. Elle s’appuie généralement sur l’artefact corrigé et un enregistrement de version. La déclaration reste une affirmation de l’émetteur ; il est donc important de préciser les versions exactes. Le document de cas d’utilisation de la CISA recommande de lister explicitement les versions dans la mesure du possible, car les plages de versions complexes sont plus difficiles à analyser.
En l'absence de correctif, trois options s'offrent à vous. Vous pouvez analyser le résultat et indiquer « non affecté » en fournissant une justification, « affecté » en précisant les mesures à prendre, ou bien intégrer une version corrigée dans votre build et indiquer « corrigé ». La première option nécessite une analyse qui perd de sa pertinence à mesure que le code évolue. Le document de cas d'utilisation de la CISA met en garde contre le fait qu'une déclaration concernant toutes les versions s'applique également aux versions futures et peut inclure des versions déjà en fin de vie. L’exemple cité est l’affirmation selon laquelle un programme Rust ne peut pas être affecté par une vulnérabilité Java, ce qui devient trompeur si une version ultérieure adopte Java et que personne ne met à jour le document. La deuxième option comporte sa propre contrainte. Si l’analyse montre que votre produit est exposé, la déclaration d’action ne peut pas inviter les lecteurs à passer à une version corrigée qui n’existe pas. Elle doit décrire une mesure d’atténuation ou une autre démarche que les lecteurs peuvent entreprendre.
La troisième voie est celle que compliquent les composants non maintenus. Il se peut qu’aucun développeur en amont ne soit en train de travailler sur le correctif dont vous auriez besoin ; quelqu’un doit donc appliquer un correctif à la version que vous utilisez, puis vérifier qu’elle fonctionne toujours comme prévu par votre produit. L’alternative à l’application d’un correctif consiste à remplacer le composant, ce qui implique généralement de modifier toutes les parties de votre code où il est utilisé.
Un ordre qui fonctionne bien lorsque c'est vous qui formulez les phrases :
- Veillez à ce que la liste des composants (SBOM) corresponde exactement au contenu de l'expédition. Si un composant y figure par erreur, corrigez la SBOM au lieu de publier une déclaration indiquant que ce composant n'est pas concerné.
- Appliquez les correctifs disponibles, puis publiez des déclarations de correction précisant les versions qui les contiennent.
- Pour les composants pour lesquels aucun correctif n'est disponible, vous devez choisir entre intégrer une version corrigée dans votre build, vérifier s'il existe une mention indiquant que le composant n'est pas concerné, ou bien indiquer qu'il est concerné en précisant une action à entreprendre.
- Indiquez comme « en cours d'examen » tout élément dont l'analyse n'est pas encore terminée, et mettez à jour le document une fois le travail achevé. Toute modification entraîne une mise à jour de la version du document.
Chaque étape laisse une trace qu'un auditeur peut vérifier : la SBOM corrigée, les versions corrigées, l'analyse dans les notes de statut et l'historique des versions du document.
Contrôler ce qui est intégré à la version
Étant donné qu’un statut VEX ne permet pas de déterminer si un paquet a été altéré ou s’il correspond bien à la source publiée par son projet, l’intégrité de la compilation doit faire l’objet d’un contrôle spécifique.
SecureChain de TuxCare analyse le code source de chaque paquet à la recherche de logiciels malveillants et de motifs de code suspects, bloque tout paquet non conforme et recompile les autres à partir du code source dans des environnements renforcés et isolés. Tant que le fournisseur en amont continue de publier des correctifs, SecureChain applique ces correctifs à chaque paquet dans le cadre d’un SLA contractuel. Tous les paquets sont fournis avec une provenance de niveau 3 selon la norme SLSA (Supply-chain Levels for Software Artifacts), des SBOM et des déclarations VEX. Pour la troisième option mentionnée ci-dessus, lorsque le développeur en amont cesse de corriger un composant, SecureChain passe automatiquement le relais à Endless Lifecycle Support (ELS), qui continue à fournir des correctifs après la fin de la maintenance en amont. La couverture s’étend aux écosystèmes JavaScript, Python, Java, Go et PHP.
Si vous ne parvenez pas à déterminer ce qui a été intégré à une version, ou si vos analyses se heurtent sans cesse à des paquets pour lesquels le développeur en amont a cessé d'apporter des correctifs, demandez à notre équipe comment SecureChain gère ce genre de situation.
FAQ
L'utilisation de VEX est-elle obligatoire en vertu de la loi ?
Le format VEX (Vulnerability Exploitability eXchange) n’a pas force de loi. L’Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) précise que ses exigences minimales relatives au format VEX ne constituent pas une politique officielle et n’imposent pas de conformité, et que les éléments minimaux de la liste des composants logiciels (SBOM) pour 2026 ne mentionnent pas le format VEX comme champ obligatoire. Un contrat client peut toutefois l’exiger.
Qui peut rédiger une instruction VEX ?
Selon l'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA), une déclaration VEX (Vulnerability Exploitability eXchange) peut provenir du fournisseur du logiciel ou d'un tiers. L'auteur doit être identifié en tant que personne physique ou morale et est responsable du contenu. L'auteur peut également indiquer un rôle, tel que « fournisseur ».
Que contient un fichier VEX ?
Un fichier VEX (Vulnerability Exploitability eXchange), que l'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) désigne sous le nom de « document VEX », contient des métadonnées relatives au document et au moins une instruction. Chaque instruction attribue un statut à une vulnérabilité concernant un ou plusieurs produits, ainsi que tous les détails requis par ce statut, tels qu'une instruction d'action ou une justification.
Que signifie le fait qu'une vulnérabilité n'ait pas de statut VEX ?
On ne peut en tirer aucune conclusion. L'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) précise que le Vulnerability Exploitability eXchange (VEX) n'implique aucun statut par défaut au-delà de ce qu'indique explicitement une déclaration, et qu'un document peut être incomplet. Une vulnérabilité pour laquelle aucune déclaration n'a été publiée n'est pas pour autant considérée comme non affectée.
Un document VEX doit-il être signé ?
L'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) indique que les documents et déclarations du Vulnerability Exploitability eXchange (VEX) doivent être signés, ce qui fait de la signature une recommandation. L'identité de l'auteur doit être associée à la signature, et la signature d'un document doit couvrir l'ensemble de ses métadonnées et déclarations. Les implémentations doivent prendre en charge les mécanismes de signature couramment acceptés.
Peut-on utiliser VEX sans SBOM ?
Oui. L'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) précise que la plateforme Vulnerability Exploitability eXchange (VEX) est conçue pour s'intégrer à une nomenclature logicielle (SBOM), à des bases de données de vulnérabilités et à des avis de sécurité, mais qu'elle n'exige aucun de ces éléments. Lorsqu'une SBOM existe, les identifiants de produit VEX doivent faire référence à ses identifiants existants.
