VEX : quand accepter un statut not_affected ?

Un statut VEX not_affected affirme qu’une vulnérabilité ne touche pas les produits désignés par l’avis. Avant de fermer l’alerte CVE, vérifiez que le produit déployé correspond bien à ce périmètre et que la justification décrit votre situation.

La question n’est pas seulement « le fournisseur a-t-il publié un VEX ? ». Elle devient : « cet avis, dans cette version, explique-t-il pourquoi cette instance de notre produit n’est pas affectée ? ». Cette formulation évite de transformer une déclaration précise en exception permanente pour tout un catalogue logiciel.

Commencer par le produit, pas par le statut

Relevez le produit, sa version, son mode de distribution et son artefact déployé. Un nom commercial ne suffit pas toujours à distinguer un service hébergé, une appliance et une image de conteneur construite localement.

Rapprochez ces éléments du SBOM disponible et de l’inventaire réel. Si le SBOM décrit une autre construction, corrigez d’abord le rapprochement. Une analyse technique solide appliquée au mauvais produit peut aboutir à une clôture incorrecte.

Pour chaque décision, conservez l’avis reçu, sa provenance, son auteur et sa date. Un lien vers une page qui changera ne permet pas toujours de reconstruire ce qui avait été annoncé. Gardez aussi le numéro ou identifiant de version du document lorsqu’il existe.

Les exigences minimales VEX publiées par la CISA distinguent notamment les statuts affecté, non affecté, corrigé et en cours d’investigation. Elles prévoient une justification ou une explication d’impact pour not_affected. Ce cadre décrit l’information échangée ; la procédure ci-dessous porte sur sa vérification technique dans votre environnement.

Traduire la justification en question vérifiable

Une justification devient utile lorsque l’équipe sait quelle preuve demander. « Le composant est absent » invite à examiner l’artefact. « Le code vulnérable n’est pas utilisé » demande une analyse des chemins d’exécution. Ces deux affirmations ne se vérifient pas avec le même document.

Ce tableau propose une méthode de revue. Il ne remplace pas les valeurs exactes du format utilisé par votre fournisseur. Les champs et les vocabulaires doivent être validés avant leur ingestion.

Ne remplacez pas une preuve manquante par une préférence opérationnelle. « Le correctif est difficile à déployer » explique un problème de planification. Cela ne démontre pas que la vulnérabilité ne s’applique pas.

Un exemple fictif : la dépendance est présente, la fonction absente

Imaginons une application interne appelée Atelier, distribuée en deux variantes. La variante serveur inclut une bibliothèque dont un module optionnel est concerné par une CVE. La variante minimale utilise une construction qui exclut ce module. Cet exemple est fictif et ne décrit aucune vulnérabilité réelle.

Le fournisseur publie un avis not_affected pour la variante minimale. Le scanner de dépendances continue à reconnaître la bibliothèque et signale la CVE. Les deux résultats peuvent coexister : l’un identifie un composant, l’autre apporte une analyse de son contenu dans un produit précis.

L’analyste vérifie l’artefact installé et constate qu’il s’agit bien de la variante minimale couverte par l’avis. Il conserve la référence de construction et la preuve d’exclusion du module. La clôture mentionne ces éléments ainsi que la CVE concernée. Elle ne retire pas toutes les alertes liées à cette bibliothèque.

Si l’environnement utilise la variante serveur, l’avis ne répond pas au problème. Si la variante installée reste inconnue, le dossier reste à instruire. La ressemblance des numéros de version ne doit pas suffire à appliquer l’exception.

Respecter les différences entre formats

OpenVEX emploie notamment not_affected et des justifications telles que vulnerable_code_not_present. Sa spécification relie les déclarations à des produits et à des vulnérabilités identifiés. Elle distingue également une protection intégrée au produit d’une simple hypothèse sur son environnement.

Cela compte lorsqu’une équipe invoque son pare-feu pour expliquer une absence d’exposition. Une mesure externe, modifiable, mérite une analyse de risque et un suivi local. Elle ne doit pas être transformée automatiquement en déclaration fournisseur affirmant que le produit est intrinsèquement non affecté.

CycloneDX dispose de son propre modèle d’analyse, avec des champs comme state, justification et response. Son guide de l’exploitabilité des vulnérabilités décrit leurs rôles. Une conversion entre formats doit préserver le sens, sans supposer que tous les libellés se correspondent un pour un.

Faites tester au connecteur un avis reconnu, un avis incomplet et une valeur qu’il ne comprend pas. Dans ce dernier cas, l’outil doit laisser la décision visible à l’analyste. Un champ inconnu supprimé silencieusement peut transformer une condition limitée en exemption générale.

Mettre une borne à la décision de clôture

Associez la clôture à la CVE, au produit, à sa version ou son artefact et à la version de l’avis. Ajoutez la personne ou l’équipe qui a accepté le raisonnement et la date du contrôle.

Définissez ensuite les événements de réouverture : nouvelle version du produit, changement de configuration, avis révisé ou nouvelle information qui contredit la justification. Un statut accepté aujourd’hui n’autorise pas automatiquement la prochaine mise à jour.

Conservez le finding du scanner et son explication au lieu de l’effacer. Lors d’un audit technique ou d’un changement de responsable, le dossier doit montrer pourquoi une alerte connue n’exigeait pas la même action qu’une autre. Cette traçabilité sert aussi à repérer les exceptions qui ne sont plus applicables.

Le guide SBOM pour les équipes sécurité aide à établir l’inventaire de départ. Le processus de réponse aux CVE de la chaîne d’approvisionnement replace ensuite l’avis dans le suivi des dépendances et des correctifs.

Sur votre prochaine alerte accompagnée d’un VEX, demandez quatre pièces concrètes : l’artefact déployé, l’avis applicable, la preuve de sa justification et la condition de réexamen. Si l’une manque, attribuez la recherche à un responsable et gardez la limite explicite. Vous pourrez fermer le dossier lorsque la conclusion sera démontrée pour le produit concerné.