VEX pour la Conformité CRA : Guide Vulnerability Exploitability eXchange

Toutes les vulnérabilités de votre SBOM n'affectent pas votre produit. VEX (Vulnerability Exploitability eXchange) vous permet de communiquer quelles vulnérabilités s'appliquent réellement à votre produit et contexte spécifique. Pour la conformité CRA, VEX aide à démontrer que vous avez évalué les vulnérabilités et traité celles qui comptent.

Ce guide explique comment utiliser VEX efficacement.

Info : VEX (Vulnerability Exploitability eXchange) vous permet de communiquer quelles vulnérabilités dans votre SBOM affectent réellement votre produit -- et lesquelles non. C'est essentiel pour satisfaire l'exigence CRA de "pas de vulnérabilités exploitables connues".

Qu'est-ce que VEX ?

Le Problème que VEX Résout

Quand vous scannez un SBOM, vous obtenez une liste de vulnérabilités dans les composants :

RÉSULTATS SCAN SBOM (Typique) :

Composant : openssl 1.1.1k
  - CVE-2021-3711 (Critique)
  - CVE-2021-3712 (Haute)
  - CVE-2022-0778 (Haute)

Composant : zlib 1.2.11
  - CVE-2018-25032 (Haute)

Composant : libxml2 2.9.10
  - CVE-2021-3517 (Haute)
  - CVE-2021-3518 (Haute)
  - CVE-2022-23308 (Moyenne)

TOTAL : 8 vulnérabilités trouvées

MAIS ATTENDEZ...
- Toutes ces vulnérabilités affectent-elles vraiment votre produit ?
- Le chemin de code vulnérable est-il utilisé ?
- Avez-vous déjà atténué certaines ?
- Certaines ne sont-elles pas exploitables dans votre contexte ?

VEX répond à ces questions.

Définition de VEX

VEX (Vulnerability Exploitability eXchange) est un format standardisé pour communiquer :

• Si une vulnérabilité affecte un produit spécifique
• Pourquoi ou pourquoi pas
• Quelles actions (le cas échéant) sont nécessaires
• Statut actuel de l'évaluation

Types de Statut VEX

OPTIONS DE STATUT VEX

NON AFFECTÉ :
« Cette vulnérabilité n'affecte pas notre produit »
- Code vulnérable non présent
- Fonction vulnérable non appelée
- Plateforme non applicable
- Atténué par la configuration

AFFECTÉ :
« Cette vulnérabilité affecte notre produit »
- Nécessite une action
- Peut inclure des atténuations recommandées
- Indique la sévérité en contexte

CORRIGÉ :
« Cette vulnérabilité a été corrigée »
- Dans une version spécifique
- Détails du correctif fournis
- Recommandation de mise à jour

EN COURS D'INVESTIGATION :
« Nous évaluons encore ceci »
- Statut pas encore déterminé
- Investigation en cours
- Statut temporaire

VEX et Exigences CRA

Exigences CRA sur les Vulnérabilités

Le CRA exige des fabricants de :

1. Aucune vulnérabilité exploitable connue (à la mise sur le marché)
2. Gérer les vulnérabilités tout au long de la période de support
3. Fournir des mises à jour de sécurité pour corriger les vulnérabilités
4. Signaler les vulnérabilités activement exploitées à ENISA (24h)
5. Signaler les vulnérabilités sévères à ENISA (72h)

Comment VEX Soutient le CRA

VEX POUR LA CONFORMITÉ CRA

EXIGENCE : Aucune vulnérabilité exploitable connue

RÔLE DE VEX :
- Documenter l'évaluation des vulnérabilités
- Montrer quels CVE ont été évalués
- Démontrer les déterminations « non affecté »
- Preuve pour le dossier technique

EXIGENCE : Gérer les vulnérabilités

RÔLE DE VEX :
- Suivre les changements de statut des vulnérabilités
- Documenter la progression « affecté » → « corrigé »
- Communiquer avec les clients
- Maintenir une piste d'audit

EXIGENCE : Mises à jour de sécurité

RÔLE DE VEX :
- Documenter ce qui est corrigé dans chaque mise à jour
- Fournir l'information « corrigé dans la version X »
- Outil de communication client

EXIGENCE : Signalement ENISA

RÔLE DE VEX :
- La pré-évaluation aide à déterminer la nécessité de signalement
- « Affecté » + « activement exploité » = signaler
- Documentation pour la précision du rapport

Conseil : CycloneDX dispose d'un support VEX natif. Si vous générez déjà des SBOMs CycloneDX, l'ajout de données VEX est simple.

Formats VEX

CycloneDX VEX

CycloneDX inclut la capacité VEX comme partie du format SBOM :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2021-3711",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_present",
        "detail": "Notre produit utilise OpenSSL mais n'utilise pas la fonctionnalité SM2 où existe cette vulnérabilité. SM2 n'est pas compilé dans notre build."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ]
    },
    {
      "id": "CVE-2022-0778",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "affected",
        "detail": "Le produit est affecté lors de l'analyse de certificats non fiables. Corrigé dans la version 2.1.0."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ],
      "recommendation": "Mettre à jour vers la version produit 2.1.0 ou ultérieure"
    }
  ]
}

CSAF VEX

CSAF (Common Security Advisory Framework) fournit un format de document VEX autonome :

{
  "document": {
    "category": "csaf_vex",
    "title": "Évaluation Sécurité Produit pour CVE-2021-3711",
    "publisher": {
      "category": "vendor",
      "name": "Example Corp"
    },
    "tracking": {
      "id": "EX-2024-001",
      "status": "final",
      "version": "1.0.0",
      "current_release_date": "2024-01-15T10:00:00Z"
    }
  },
  "product_tree": {
    "branches": [
      {
        "category": "product_name",
        "name": "Smart Sensor Pro",
        "product": {
          "product_id": "SSP-2.0",
          "name": "Smart Sensor Pro 2.0"
        }
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2021-3711",
      "product_status": {
        "known_not_affected": ["SSP-2.0"]
      },
      "flags": [
        {
          "label": "vulnerable_code_not_present",
          "product_ids": ["SSP-2.0"]
        }
      ],
      "notes": [
        {
          "category": "description",
          "text": "La fonctionnalité SM2 n'est pas incluse dans notre build OpenSSL."
        }
      ]
    }
  ]
}

OpenVEX

OpenVEX est un format VEX plus simple et ciblé :

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2024-001",
  "author": "Example Corp Security Team",
  "timestamp": "2024-01-15T10:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "CVE-2021-3711"
      },
      "products": [
        {
          "@id": "pkg:generic/smart-sensor-pro@2.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "La fonctionnalité cryptographique SM2 n'est pas compilée dans le build OpenSSL de notre produit."
    }
  ]
}

Création de Déclarations VEX

Processus d'Évaluation

WORKFLOW D'ÉVALUATION VEX

ÉTAPE 1 : IDENTIFIER LA VULNÉRABILITÉ
- Depuis les résultats de scan SBOM
- Depuis un avis de sécurité
- Depuis un signalement client
- Depuis une notification ENISA

ÉTAPE 2 : ANALYSER L'APPLICABILITÉ
Questions à répondre :
- Le composant vulnérable est-il dans notre produit ?
- La version vulnérable est-elle présente ?
- Le chemin de code vulnérable est-il utilisé ?
- La vulnérabilité est-elle exploitable dans notre contexte ?
- Des atténuations sont-elles déjà en place ?

ÉTAPE 3 : DÉTERMINER LE STATUT
Basé sur l'analyse :
- NOT_AFFECTED : La vulnérabilité ne s'applique pas
- AFFECTED : La vulnérabilité s'applique, action nécessaire
- FIXED : Était affecté, maintenant corrigé
- UNDER_INVESTIGATION : Évaluation en cours

ÉTAPE 4 : DOCUMENTER LA JUSTIFICATION
Pour NOT_AFFECTED, spécifier pourquoi :
- vulnerable_code_not_present
- vulnerable_code_cannot_be_controlled_by_adversary
- vulnerable_code_not_in_execute_path
- inline_mitigations_already_exist

ÉTAPE 5 : CRÉER LE DOCUMENT VEX
- Utiliser le format choisi
- Inclure tous les champs requis
- Versionner et dater le document
- Signer si possible

Types de Justification

JUSTIFICATIONS NON_AFFECTÉ

VULNERABLE_CODE_NOT_PRESENT :
« Le code vulnérable n'est pas inclus dans notre build »
Exemple : OpenSSL compilé sans support SM2

VULNERABLE_CODE_CANNOT_BE_CONTROLLED_BY_ADVERSARY :
« Un attaquant ne peut pas atteindre le code vulnérable »
Exemple : Fonction appelée uniquement avec des données internes de confiance

VULNERABLE_CODE_NOT_IN_EXECUTE_PATH :
« La fonction vulnérable n'est jamais appelée »
Exemple : Bibliothèque incluse mais fonction spécifique non utilisée

INLINE_MITIGATIONS_ALREADY_EXIST :
« D'autres contrôles empêchent l'exploitation »
Exemple : WAF bloque le vecteur d'attaque, sandboxing limite l'impact

Exemples d'Évaluations

EXEMPLE 1 : Non Affecté (Code Non Présent)

Vulnérabilité : CVE-2021-3711 (OpenSSL SM2 buffer overflow)
Composant : openssl 1.1.1k
Évaluation : Notre produit utilise OpenSSL pour TLS uniquement.
            SM2 est un standard cryptographique chinois que nous n'utilisons pas.
            Notre build désactive explicitement SM2 : ./config no-sm2
Statut : NOT_AFFECTED
Justification : vulnerable_code_not_present

EXEMPLE 2 : Non Affecté (Pas dans le Chemin d'Exécution)

Vulnérabilité : CVE-2022-23308 (libxml2 use-after-free)
Composant : libxml2 2.9.10
Évaluation : Vulnérabilité dans l'évaluation XPath avec namespaces.
            Notre produit utilise libxml2 uniquement pour le parsing XML simple.
            Nous n'utilisons jamais la fonctionnalité XPath.
Statut : NOT_AFFECTED
Justification : vulnerable_code_not_in_execute_path

EXEMPLE 3 : Affecté

Vulnérabilité : CVE-2022-0778 (OpenSSL infinite loop)
Composant : openssl 1.1.1k
Évaluation : Notre produit traite des certificats TLS depuis
            des sources potentiellement non fiables. La vulnérabilité
            permet un DoS via certificat malveillant.
Statut : AFFECTED
Recommandation : Mettre à jour vers la version produit 2.1.0 (OpenSSL 1.1.1n)

EXEMPLE 4 : Corrigé

Vulnérabilité : CVE-2022-0778 (OpenSSL infinite loop)
Composant : openssl (était 1.1.1k, maintenant 1.1.1n)
Évaluation : Corrigé dans la version produit 2.1.0
Statut : FIXED
Version Corrigée : 2.1.0

Workflow VEX pour le CRA

Évaluation Continue

PROCESSUS VEX EN CONTINU

QUOTIDIEN/HEBDOMADAIRE :
1. Scanner le SBOM pour nouvelles vulnérabilités
2. Prioriser par sévérité
3. Commencer l'évaluation des critiques/hautes

POUR CHAQUE VULNÉRABILITÉ :
1. Analyse technique
2. Déterminer le statut
3. Créer/mettre à jour la déclaration VEX
4. Si AFFECTED : planifier la correction

QUAND CORRIGÉ :
1. Mettre à jour le statut VEX à FIXED
2. Référencer la version du correctif
3. Notifier les clients
4. Mettre à jour le dossier technique

POUR LE SIGNALEMENT ENISA :
1. AFFECTED + activement exploité → Signaler 24h
2. AFFECTED + sévère → Signaler 72h
3. Inclure VEX dans le contexte du rapport

Intégration avec le SBOM

INTÉGRATION SBOM + VEX

OPTION 1 : VEX Embarqué (CycloneDX)
- Données VEX dans le document SBOM
- Fichier unique pour composants + vulnérabilités
- Mettre à jour le SBOM quand VEX change

OPTION 2 : VEX Lié
- Document VEX séparé
- Référence les composants SBOM
- Peut être mis à jour indépendamment

OPTION 3 : Avis CSAF
- Avis de sécurité autonomes
- Publiés sur la page sécurité
- Lisibles par machine pour l'automatisation

RECOMMANDATION POUR LE CRA :
- Utiliser VEX embarqué pour le dossier technique (enregistrement complet)
- Publier des avis CSAF pour la communication client
- Maintenir les deux, garder synchronisés

Communication Client

VEX POUR LA COMMUNICATION CLIENT

SCÉNARIO : Le client demande « CVE-XXXX affecte-t-il votre produit ? »

AVEC VEX :
1. Vérifier la base de données VEX pour la vulnérabilité
2. Fournir le statut immédiatement
3. Si NOT_AFFECTED : partager la justification
4. Si AFFECTED : fournir les conseils de correction
5. Si UNDER_INVESTIGATION : fournir un calendrier

AVANTAGES :
- Réponses cohérentes dans l'équipe support
- Justifications pré-préparées
- Temps de réponse plus rapide
- Diligence raisonnable démontrable

VEX dans le Dossier Technique

Approche de Documentation

SECTION VEX DU DOSSIER TECHNIQUE

SECTION : Évaluation des Vulnérabilités (VEX)

CONTENU :
1. Description de la méthodologie VEX
2. Document VEX actuel (tous produits)
3. Mises à jour VEX historiques (piste d'audit)
4. Preuves de justification non-affecté

EXEMPLE D'ENTRÉE :
« À la date du [date], les vulnérabilités suivantes ont été
évaluées pour [Nom du Produit] version [X.Y.Z] :

Total CVE dans les dépendances de composants : 47
- Non Affecté : 41
- Corrigé : 4
- En Investigation : 2
- Affecté (avec atténuation) : 0

Document VEX : [lien/pièce jointe]
Dernière mise à jour : [date] »

Preuve pour « Aucune Vulnérabilité Exploitable Connue »

PREUVE DE CONFORMITÉ CRA

AFFIRMATION : Le produit n'a pas de vulnérabilités exploitables connues

PREUVE (basée sur VEX) :
1. Résultats de scan SBOM (datés)
2. Évaluation VEX couvrant tous les résultats
3. Pour chaque « Non Affecté » : justification
4. Pour chaque « Corrigé » : information de version
5. Pour « En Investigation » : calendrier/statut

PISTE D'AUDIT :
- Quand chaque CVE a-t-il été évalué ?
- Qui a effectué l'évaluation ?
- Quelle était la justification ?
- Quand le statut a-t-il été mis à jour ?

Outils et Automatisation

Outils de Génération VEX

OPTIONS D'OUTILLAGE VEX

CORRESPONDANCE SBOM + VULNÉRABILITÉS :
- Grype (Anchore) - génère VEX
- Trivy - scan de vulnérabilités avec sortie VEX
- OWASP Dependency-Track - support VEX

RÉDACTION VEX :
- CycloneDX CLI - créer/valider VEX
- Outils CSAF - créer des documents CSAF VEX
- Outils OpenVEX - création VEX simple

AUTOMATISATION :
- Intégration CI/CD pour le scan
- Statut « en investigation » automatique
- Revue manuelle pour le statut final

Stratégie d'Automatisation

APPROCHE D'AUTOMATISATION VEX

AUTOMATISÉ :
- Scan SBOM pour nouveaux CVE
- Statut « en investigation » initial
- Notification à l'équipe sécurité
- Vérifications d'applicabilité de base

SEMI-AUTOMATISÉ :
- Suggestions d'analyse de chemin de code
- Correspondance de patterns historiques
- Recherche de statut de produits similaires

MANUEL (Requis) :
- Détermination finale du statut
- Rédaction des justifications
- Communications destinées aux clients
- Décisions de signalement ENISA

Défis Courants

Défi : Volume de CVE

Problème : Les scans SBOM retournent des centaines de CVE.

Solutions :

• Prioriser par sévérité (Critique/Haute d'abord)
• Utiliser l'automatisation pour le triage initial
• Construire des templates de justification pour les patterns courants
• Se concentrer sur les composants que vous contrôlez

Défi : Difficulté de l'Analyse Technique

Problème : Difficile de déterminer si le code vulnérable est utilisé.

Solutions :

• Travailler avec l'équipe de développement
• Utiliser des outils d'analyse statique
• Documenter l'incertitude de manière appropriée
• Approche conservatrice : en cas de doute, traiter comme affecté

Défi : Maintenir VEX à Jour

Problème : Le statut des vulnérabilités change avec le temps.

Solutions :

• Automatiser le re-scan du SBOM
• Revues VEX planifiées
• Mises à jour basées sur des déclencheurs (nouveau CVE, nouvelle version)
• Versionner vos documents VEX

Checklist VEX

CHECKLIST D'IMPLÉMENTATION VEX

CONFIGURATION :
[ ] Choisir le format VEX (CycloneDX VEX recommandé)
[ ] Définir le processus d'évaluation
[ ] Assigner les responsabilités
[ ] Configurer l'outillage

ÉVALUATION INITIALE :
[ ] Scanner le SBOM pour les vulnérabilités
[ ] Prioriser par sévérité
[ ] Évaluer chaque vulnérabilité
[ ] Documenter les justifications

PROCESSUS EN CONTINU :
[ ] Calendrier de re-scan SBOM régulier
[ ] Surveillance des nouveaux CVE
[ ] SLA d'évaluation (ex. Critique : 24h)
[ ] Mises à jour des documents VEX

DOCUMENTATION :
[ ] VEX inclus dans le dossier technique
[ ] Historique des versions maintenu
[ ] Justifications détaillées
[ ] Publication destinée aux clients

INTÉGRATION :
[ ] Lié au SBOM
[ ] Processus de communication client
[ ] Workflow de signalement ENISA
[ ] Notes de version mises à jour

Ressources Clés

RESSOURCES VEX

STANDARDS :
CycloneDX VEX : https://cyclonedx.org/capabilities/vex/
CSAF : https://docs.oasis-open.org/csaf/
OpenVEX : https://openvex.dev

CONSEILS :
CISA VEX Status Justifications
NTIA VEX Minimum Elements

OUTILS :
Grype : https://github.com/anchore/grype
Trivy : https://aquasecurity.github.io/trivy/
CycloneDX CLI : https://github.com/CycloneDX/cyclonedx-cli

Comment CRA Evidence Aide

CRA Evidence fournit un support VEX complet :

• VEX Intégré : Gérer VEX aux côtés du SBOM
• Workflow d'évaluation : Analyse structurée des vulnérabilités
• Suivi de statut : Suivre les changements dans le temps
• Templates de justification : Patterns courants pré-construits
• Intégration dossier technique : VEX dans la documentation de conformité
• Portail client : Partager le statut VEX avec les clients

Commencez votre conformité CRA sur app.craevidence.com.

Articles Connexes

• SBOM pour la Conformité CRA : Guide Complet du Software Bill of Materials -- VEX complète le SBOM -- apprenez à construire la base d'abord.
• Signalement des Vulnérabilités CRA : Exigences de Notification ENISA -- Comprenez les obligations de signalement 24h/72h pour les vulnérabilités classées "Affecté".
• Génération SBOM CRA : Guide des Outils et de l'Automatisation -- Automatisez la génération de SBOM et VEX dans votre pipeline CI/CD.

Cet article est à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils spécifiques sur la conformité, consultez un conseiller juridique qualifié.