Sécuriser la chaîne d’approvisionnement logicielle

VEX et SBOM : vérifier la portée de la déclaration fournisseur

Une SBOM décrit des composants ; VEX exprime un statut d’impact pour une vulnérabilité et des produits identifiés. Cette fiche utilise les libellés d’OpenVEX v0.2.0. Elle ne propose pas de conversion automatique vers CSAF ou CycloneDX, dont les structures doivent être lues dans leur propre version.

L’émetteur, l’identification du produit et le temps sont indispensables à l’interprétation. Les informations produit ou temporelles peuvent être héritées selon les règles OpenVEX ; un champ absent dans un statement n’est donc pas nécessairement une information absente du document complet. Vérifier les valeurs résolues avant de conclure.

Quatre statuts OpenVEX, avec leur portée

Pour not_affected, la structure OpenVEX exige une justification ou un impact_statement ; le format recommande la justification exploitable par une machine, éventuellement enrichie d’un texte. Pour affected, un action_statement est requis. Ces champs documentent une déclaration ; ils ne rendent pas son auteur automatiquement fiable.

Cinq justifications : des preuves différentes à rechercher

Exemple JSON fictif : une déclaration pour le build 2.4.0

Exemple pédagogique rédigé pour cette fiche, avec identifiant de vulnérabilité TRAINING-VULN-01 et domaine .example. Il ne décrit aucun produit ou défaut réel, n’est pas signé et n’a pas été validé par un moteur de conformité OpenVEX. La date du document est héritée par son unique déclaration.

{
    "@context": "https://openvex.dev/ns/v0.2.0",
    "@id": "https://vendor.example/vex/training-01",
    "author": "Fictional training publisher",
    "timestamp": "2026-10-22T10:00:00Z",
    "version": 1,
    "statements": [
        {
            "vulnerability": {
                "name": "TRAINING-VULN-01"
            },
            "products": [
                {
                    "@id": "https://vendor.example/products/gateway/2.4.0"
                }
            ],
            "status": "not_affected",
            "justification": "vulnerable_code_not_present",
            "impact_statement": "Fictional training statement: the affected code was excluded from this exact product build."
        }
    ]
}

Cette déclaration ne concerne que le produit identifié en version 2.4.0. Elle ne couvre pas automatiquement une version 2.3.0, une autre distribution ou une configuration différente. L’assertion d’exclusion du code reste à rapprocher des preuves et de la confiance accordée à l’émetteur.

Six contrôles avant d’utiliser un VEX pour réduire des alertes

• Identifier l’émetteur et la manière dont le document a été obtenu ; distinguer provenance, signature éventuelle et confiance.
• Résoudre le produit, les sous-composants et les identifiants jusqu’au build effectivement déployé.
• Vérifier l’identifiant de vulnérabilité et ses alias ; ne pas rapprocher des défauts par une simple ressemblance de titre.
• Lire le statut, les justifications ou actions requises et les conditions propres au produit.
• Résoudre les dates héritées et conserver la version du document ; une évolution du produit peut invalider une ancienne hypothèse.
• Enregistrer la décision de prise en compte, le responsable et les conditions qui déclenchent une nouvelle revue.

Revenir aux signaux de priorisation et aux preuves de remédiation →

Sources primaires et périmètre

• OpenVEX · Specification v0.2.0 · OpenVEX v0.2.0 · reviewed 2026-10-22
  Statement Data Structure · Status Labels · Status Justifications · Data Inheritance

Sources vérifiées le 2026-10-22