VEX per la Conformità CRA: Guida Vulnerability Exploitability eXchange

Come utilizzare i documenti VEX per la conformità CRA. Copre i formati VEX, i tipi di stato, l'integrazione con SBOM e esempi pratici per comunicare l'applicabilità delle vulnerabilità.

Team CRA Evidence
Autore
14 gennaio 2026
Aggiornato 25 febbraio 2026 00:00:00 UTC
12 min di lettura
VEX per la Conformità CRA: Guida Vulnerability Exploitability eXchange
In this article

Non tutte le vulnerabilità nel vostro SBOM influenzano il vostro prodotto. VEX (Vulnerability Exploitability eXchange) vi permette di comunicare quali vulnerabilità si applicano effettivamente al vostro prodotto e contesto specifico. Per la conformità CRA, VEX aiuta a dimostrare che avete valutato le vulnerabilità e affrontato quelle che contano.

Questa guida spiega come utilizzare VEX efficacemente.

Info: VEX (Vulnerability Exploitability eXchange) vi permette di comunicare quali vulnerabilità nel vostro SBOM influenzano realmente il vostro prodotto -- e quali no. È essenziale per soddisfare il requisito CRA di "nessuna vulnerabilità sfruttabile nota".

Sintesi

  • VEX = dichiarazione leggibile da macchina sull'applicabilità delle vulnerabilità
  • Risponde a: "CVE-XXXX influenza IL MIO prodotto?"
  • Quattro stati: Non Affetto, Affetto, Corretto, Sotto Investigazione
  • Complementa lo SBOM, lo SBOM elenca i componenti, VEX valuta le vulnerabilità
  • CycloneDX VEX e CSAF VEX sono i formati principali
  • Essenziale per il requisito CRA "nessuna vulnerabilità sfruttabile nota"

Flusso degli stati VEX — Non interessato, In indagine, Interessato, Corretto

Cos'è VEX?

Il Problema che VEX Risolve

Quando scansionate uno SBOM, ottenete una lista di vulnerabilità nei componenti:

RISULTATI SCANSIONE SBOM (Tipici):

Componente: openssl 1.1.1k
  - CVE-2021-3711 (Critica)
  - CVE-2021-3712 (Alta)
  - CVE-2022-0778 (Alta)

Componente: zlib 1.2.11
  - CVE-2018-25032 (Alta)

Componente: libxml2 2.9.10
  - CVE-2021-3517 (Alta)
  - CVE-2021-3518 (Alta)
  - CVE-2022-23308 (Media)

TOTALE: 8 vulnerabilità trovate

MA ASPETTA...
- Tutte queste influenzano davvero il vostro prodotto?
- Il percorso di codice vulnerabile è usato?
- Avete già mitigato alcune?
- Alcune non sono sfruttabili nel vostro contesto?

VEX risponde a queste domande.

Definizione di VEX

VEX (Vulnerability Exploitability eXchange) è un formato standardizzato per comunicare:

  • Se una vulnerabilità influenza un prodotto specifico
  • Perché sì o perché no
  • Quali azioni (se presenti) sono necessarie
  • Stato attuale della valutazione

Tipi di Stato VEX

OPZIONI DI STATO VEX

NON AFFETTO:
"Questa vulnerabilità non influenza il nostro prodotto"
- Codice vulnerabile non presente
- Funzione vulnerabile non chiamata
- Piattaforma non applicabile
- Mitigato dalla configurazione

AFFETTO:
"Questa vulnerabilità influenza il nostro prodotto"
- Richiede azione
- Può includere mitigazioni raccomandate
- Indica la severità nel contesto

CORRETTO:
"Questa vulnerabilità è stata corretta"
- In una versione specifica
- Dettagli della correzione forniti
- Raccomandazione di aggiornamento

SOTTO INVESTIGAZIONE:
"Stiamo ancora valutando questo"
- Stato non ancora determinato
- Investigazione in corso
- Stato temporaneo

VEX e Requisiti CRA

Requisiti CRA sulle Vulnerabilità

Il CRA richiede ai produttori di:

  1. Nessuna vulnerabilità sfruttabile nota (all'immissione sul mercato)
  2. Gestire le vulnerabilità durante tutto il periodo di supporto
  3. Fornire aggiornamenti di sicurezza per correggere le vulnerabilità
  4. Segnalare vulnerabilità attivamente sfruttate a ENISA (24h)
  5. Segnalare vulnerabilità severe a ENISA (72h)

Come VEX Supporta il CRA

VEX PER LA CONFORMITÀ CRA

REQUISITO: Nessuna vulnerabilità sfruttabile nota

RUOLO DI VEX:
- Documentare la valutazione delle vulnerabilità
- Mostrare quali CVE sono stati valutati
- Dimostrare le determinazioni "non affetto"
- Evidenza per il fascicolo tecnico

REQUISITO: Gestire le vulnerabilità

RUOLO DI VEX:
- Tracciare i cambiamenti di stato delle vulnerabilità
- Documentare la progressione "affetto" → "corretto"
- Comunicare con i clienti
- Mantenere una traccia di audit

REQUISITO: Aggiornamenti di sicurezza

RUOLO DI VEX:
- Documentare cosa è corretto in ogni aggiornamento
- Fornire informazioni "corretto nella versione X"
- Strumento di comunicazione con il cliente

REQUISITO: Segnalazione ENISA

RUOLO DI VEX:
- La pre-valutazione aiuta a determinare la segnalabilità
- "Affetto" + "attivamente sfruttato" = segnalare
- Documentazione per l'accuratezza del report

Suggerimento: CycloneDX ha supporto VEX nativo. Se state già generando SBOM CycloneDX, aggiungere dati VEX è semplice.

Formati VEX

CycloneDX VEX

CycloneDX include la capacità VEX come parte del formato SBOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2021-3711",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_present",
        "detail": "Il nostro prodotto usa OpenSSL ma non usa la funzionalità SM2 dove esiste questa vulnerabilità. SM2 non è compilato nella nostra build."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ]
    },
    {
      "id": "CVE-2022-0778",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "affected",
        "detail": "Il prodotto è affetto quando analizza certificati non affidabili. Corretto nella versione 2.1.0."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ],
      "recommendation": "Aggiornare alla versione prodotto 2.1.0 o successiva"
    }
  ]
}

CSAF VEX

CSAF (Common Security Advisory Framework) fornisce un formato di documento VEX autonomo:

{
  "document": {
    "category": "csaf_vex",
    "title": "Valutazione Sicurezza Prodotto per 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 funzionalità SM2 non è inclusa nella nostra build OpenSSL."
        }
      ]
    }
  ]
}

OpenVEX

OpenVEX è un formato VEX più semplice e mirato:

{
  "@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 funzionalità crittografica SM2 non è compilata nella build OpenSSL del nostro prodotto."
    }
  ]
}

Creazione di Dichiarazioni VEX

Processo di Valutazione

WORKFLOW DI VALUTAZIONE VEX

PASSO 1: IDENTIFICARE LA VULNERABILITÀ
- Dai risultati della scansione SBOM
- Da un avviso di sicurezza
- Da una segnalazione cliente
- Da una notifica ENISA

PASSO 2: ANALIZZARE L'APPLICABILITÀ
Domande a cui rispondere:
- Il componente vulnerabile è nel nostro prodotto?
- La versione vulnerabile è presente?
- Il percorso di codice vulnerabile è usato?
- La vulnerabilità è sfruttabile nel nostro contesto?
- Ci sono mitigazioni già in atto?

PASSO 3: DETERMINARE LO STATO
Basato sull'analisi:
- NOT_AFFECTED: La vulnerabilità non si applica
- AFFECTED: La vulnerabilità si applica, azione necessaria
- FIXED: Era affetto, ora rimediato
- UNDER_INVESTIGATION: Valutazione in corso

PASSO 4: DOCUMENTARE LA GIUSTIFICAZIONE
Per NOT_AFFECTED, specificare perché:
- vulnerable_code_not_present
- vulnerable_code_cannot_be_controlled_by_adversary
- vulnerable_code_not_in_execute_path
- inline_mitigations_already_exist

PASSO 5: CREARE IL DOCUMENTO VEX
- Usare il formato scelto
- Includere tutti i campi richiesti
- Versionare e datare il documento
- Firmare se possibile

Tipi di Giustificazione

GIUSTIFICAZIONI NON_AFFETTO

VULNERABLE_CODE_NOT_PRESENT:
"Il codice vulnerabile non è incluso nella nostra build"
Esempio: OpenSSL compilato senza supporto SM2

VULNERABLE_CODE_CANNOT_BE_CONTROLLED_BY_ADVERSARY:
"Un attaccante non può raggiungere il codice vulnerabile"
Esempio: Funzione chiamata solo con dati interni affidabili

VULNERABLE_CODE_NOT_IN_EXECUTE_PATH:
"La funzione vulnerabile non viene mai chiamata"
Esempio: Libreria inclusa ma funzione specifica non usata

INLINE_MITIGATIONS_ALREADY_EXIST:
"Altri controlli prevengono lo sfruttamento"
Esempio: WAF blocca il vettore di attacco, sandboxing limita l'impatto

Esempi di Valutazioni

ESEMPIO 1: Non Affetto (Codice Non Presente)

Vulnerabilità: CVE-2021-3711 (OpenSSL SM2 buffer overflow)
Componente: openssl 1.1.1k
Valutazione: Il nostro prodotto usa OpenSSL solo per TLS.
            SM2 è uno standard crittografico cinese che non usiamo.
            La nostra build disabilita esplicitamente SM2: ./config no-sm2
Stato: NOT_AFFECTED
Giustificazione: vulnerable_code_not_present

ESEMPIO 2: Non Affetto (Non nel Percorso di Esecuzione)

Vulnerabilità: CVE-2022-23308 (libxml2 use-after-free)
Componente: libxml2 2.9.10
Valutazione: Vulnerabilità nella valutazione XPath con namespace.
            Il nostro prodotto usa libxml2 solo per parsing XML semplice.
            Non usiamo mai la funzionalità XPath.
Stato: NOT_AFFECTED
Giustificazione: vulnerable_code_not_in_execute_path

ESEMPIO 3: Affetto

Vulnerabilità: CVE-2022-0778 (OpenSSL infinite loop)
Componente: openssl 1.1.1k
Valutazione: Il nostro prodotto processa certificati TLS da
            fonti potenzialmente non affidabili. La vulnerabilità
            permette DoS tramite certificato malevolo.
Stato: AFFECTED
Raccomandazione: Aggiornare alla versione prodotto 2.1.0 (OpenSSL 1.1.1n)

ESEMPIO 4: Corretto

Vulnerabilità: CVE-2022-0778 (OpenSSL infinite loop)
Componente: openssl (era 1.1.1k, ora 1.1.1n)
Valutazione: Corretto nella versione prodotto 2.1.0
Stato: FIXED
Versione Corretta: 2.1.0

Workflow VEX per il CRA

Valutazione Continua

PROCESSO VEX CONTINUO

GIORNALIERO/SETTIMANALE:
1. Scansionare lo SBOM per nuove vulnerabilità
2. Prioritizzare per severità
3. Iniziare la valutazione delle critiche/alte

PER OGNI VULNERABILITÀ:
1. Analisi tecnica
2. Determinare lo stato
3. Creare/aggiornare la dichiarazione VEX
4. Se AFFECTED: pianificare la remediation

QUANDO CORRETTO:
1. Aggiornare lo stato VEX a FIXED
2. Riferire la versione della correzione
3. Notificare i clienti
4. Aggiornare il fascicolo tecnico

PER LA SEGNALAZIONE ENISA:
1. AFFECTED + attivamente sfruttato  Segnalare 24h
2. AFFECTED + severo  Segnalare 72h
3. Includere VEX nel contesto del report

Integrazione con lo SBOM

INTEGRAZIONE SBOM + VEX

OPZIONE 1: VEX Incorporato (CycloneDX)
- Dati VEX dentro il documento SBOM
- Singolo file per componenti + vulnerabilità
- Aggiornare lo SBOM quando VEX cambia

OPZIONE 2: VEX Collegato
- Documento VEX separato
- Riferisce i componenti SBOM
- Può essere aggiornato indipendentemente

OPZIONE 3: Avvisi CSAF
- Avvisi di sicurezza autonomi
- Pubblicati sulla pagina sicurezza
- Leggibili da macchina per automazione

RACCOMANDAZIONE PER CRA:
- Usare VEX incorporato per il fascicolo tecnico (record completo)
- Pubblicare avvisi CSAF per comunicazione cliente
- Mantenere entrambi, tenere sincronizzati

Comunicazione con il Cliente

VEX PER LA COMUNICAZIONE CON IL CLIENTE

SCENARIO: Il cliente chiede "CVE-XXXX influenza il vostro prodotto?"

CON VEX:
1. Controllare il database VEX per la vulnerabilità
2. Fornire lo stato immediatamente
3. Se NOT_AFFECTED: condividere la giustificazione
4. Se AFFECTED: fornire guida alla remediation
5. Se UNDER_INVESTIGATION: fornire una timeline

VANTAGGI:
- Risposte consistenti nel team di supporto
- Giustificazioni pre-preparate
- Tempo di risposta più veloce
- Diligenza dimostrabile

VEX nel Fascicolo Tecnico

Approccio alla Documentazione

SEZIONE VEX DEL FASCICOLO TECNICO

SEZIONE: Valutazione delle Vulnerabilità (VEX)

CONTENUTI:
1. Descrizione della metodologia VEX
2. Documento VEX attuale (tutti i prodotti)
3. Aggiornamenti VEX storici (traccia di audit)
4. Evidenze di giustificazione non-affetto

ESEMPIO DI VOCE:
"Alla data del [data], le seguenti vulnerabilità sono state
valutate per [Nome Prodotto] versione [X.Y.Z]:

Totale CVE nelle dipendenze dei componenti: 47
- Non Affetto: 41
- Corretto: 4
- Sotto Investigazione: 2
- Affetto (con mitigazione): 0

Documento VEX: [link/allegato]
Ultimo aggiornamento: [data]"

Evidenza per "Nessuna Vulnerabilità Sfruttabile Nota"

EVIDENZA DI CONFORMITÀ CRA

AFFERMAZIONE: Il prodotto non ha vulnerabilità sfruttabili note

EVIDENZA (basata su VEX):
1. Risultati scansione SBOM (datati)
2. Valutazione VEX che copre tutti i risultati
3. Per ogni "Non Affetto": giustificazione
4. Per ogni "Corretto": informazione versione
5. Per "Sotto Investigazione": timeline/stato

TRACCIA DI AUDIT:
- Quando è stato valutato ogni CVE?
- Chi ha eseguito la valutazione?
- Qual era la giustificazione?
- Quando è stato aggiornato lo stato?

Strumenti e Automazione

Strumenti di Generazione VEX

OPZIONI DI STRUMENTI VEX

MATCHING SBOM + VULNERABILITÀ:
- Grype (Anchore) - genera VEX
- Trivy - scansione vulnerabilità con output VEX
- OWASP Dependency-Track - supporto VEX

AUTHORING VEX:
- CycloneDX CLI - creare/validare VEX
- Strumenti CSAF - creare documenti CSAF VEX
- Strumenti OpenVEX - creazione VEX semplice

AUTOMAZIONE:
- Integrazione CI/CD per scansione
- Stato "sotto investigazione" automatico
- Revisione manuale per stato finale

Strategia di Automazione

APPROCCIO DI AUTOMAZIONE VEX

AUTOMATIZZATO:
- Scansione SBOM per nuovi CVE
- Stato "sotto investigazione" iniziale
- Notifica al team sicurezza
- Controlli di applicabilità base

SEMI-AUTOMATIZZATO:
- Suggerimenti analisi percorso di codice
- Matching pattern storici
- Ricerca stato prodotti simili

MANUALE (Richiesto):
- Determinazione stato finale
- Scrittura giustificazioni
- Comunicazioni destinate ai clienti
- Decisioni di segnalazione ENISA

Sfide Comuni

Sfida: Volume di CVE

Problema: Le scansioni SBOM restituiscono centinaia di CVE.

Soluzioni:

  • Prioritizzare per severità (Critica/Alta prima)
  • Usare automazione per il triage iniziale
  • Costruire template di giustificazione per pattern comuni
  • Concentrarsi sui componenti che controllate

Sfida: Difficoltà dell'Analisi Tecnica

Problema: Difficile determinare se il codice vulnerabile è usato.

Soluzioni:

  • Lavorare con il team di sviluppo
  • Usare strumenti di analisi statica
  • Documentare l'incertezza appropriatamente
  • Approccio conservativo: nel dubbio, trattare come affetto

Sfida: Mantenere VEX Aggiornato

Problema: Lo stato delle vulnerabilità cambia nel tempo.

Soluzioni:

  • Automatizzare la ri-scansione dello SBOM
  • Revisioni VEX programmate
  • Aggiornamenti basati su trigger (nuovo CVE, nuova versione)
  • Versionare i vostri documenti VEX

Checklist VEX

CHECKLIST IMPLEMENTAZIONE VEX

CONFIGURAZIONE:
[ ] Scegliere il formato VEX (CycloneDX VEX raccomandato)
[ ] Definire il processo di valutazione
[ ] Assegnare responsabilità
[ ] Configurare gli strumenti

VALUTAZIONE INIZIALE:
[ ] Scansionare lo SBOM per vulnerabilità
[ ] Prioritizzare per severità
[ ] Valutare ogni vulnerabilità
[ ] Documentare le giustificazioni

PROCESSO CONTINUO:
[ ] Programma di ri-scansione SBOM regolare
[ ] Monitoraggio nuovi CVE
[ ] SLA di valutazione (es. Critico: 24h)
[ ] Aggiornamenti documenti VEX

DOCUMENTAZIONE:
[ ] VEX incluso nel fascicolo tecnico
[ ] Storico versioni mantenuto
[ ] Giustificazioni dettagliate
[ ] Pubblicazione destinata ai clienti

INTEGRAZIONE:
[ ] Collegato allo SBOM
[ ] Processo di comunicazione cliente
[ ] Workflow segnalazione ENISA
[ ] Note di rilascio aggiornate

Risorse Chiave

RISORSE VEX

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

GUIDA:
CISA VEX Status Justifications
NTIA VEX Minimum Elements

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

Come Aiuta CRA Evidence

CRA Evidence fornisce supporto VEX completo:

  • VEX Integrato: Gestire VEX insieme allo SBOM
  • Workflow di valutazione: Analisi strutturata delle vulnerabilità
  • Tracciamento stato: Tracciare i cambiamenti nel tempo
  • Template di giustificazione: Pattern comuni pre-costruiti
  • Integrazione fascicolo tecnico: VEX nella documentazione di conformità
  • Portale cliente: Condividere lo stato VEX con i clienti

Inizia la tua conformità CRA su app.craevidence.com.

Articoli Correlati


Questo articolo è solo a scopo informativo e non costituisce consulenza legale. Per indicazioni specifiche sulla conformità, consultare un consulente legale qualificato.

Argomenti trattati in questo articolo

Condividi questo articolo

Articoli correlati

Does the CRA apply to your product?

Rispondi a 6 semplici domande per scoprire se il tuo prodotto rientra nell’ambito del Cyber Resilience Act dell’UE. Ottieni il risultato in meno di 2 minuti.

Pronto a raggiungere la conformità CRA?

Inizia a gestire i tuoi SBOM e la documentazione di conformità con CRA Evidence.