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à.
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"
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:
- Nessuna vulnerabilità sfruttabile nota (all'immissione sul mercato)
- Gestire le vulnerabilità durante tutto il periodo di supporto
- Fornire aggiornamenti di sicurezza per correggere le vulnerabilità
- Segnalare vulnerabilità attivamente sfruttate a ENISA (24h)
- 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
- SBOM per la Conformità CRA: Guida Completa al Software Bill of Materials -- VEX complementa lo SBOM -- scoprite come costruire prima le basi.
- Segnalazione Vulnerabilità CRA: Requisiti di Notifica ENISA -- Comprendete gli obblighi di segnalazione 24h/72h per le vulnerabilità classificate come "Affetto".
- Generazione SBOM CRA: Guida a Strumenti e Automazione -- Automatizzate la generazione di SBOM e VEX nella vostra pipeline CI/CD.
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
Articoli correlati
Le telecamere intelligenti sono Prodotti Importanti ai...
Le telecamere di sicurezza connesse sono classificate come Prodotti...
11 minCybersecurity Act 2 dell'UE: Divieti sulla Supply Chain,...
Il 20 gennaio 2026, l'UE ha proposto di sostituire interamente il...
11 minClassificazione dei prodotti CRA: Il vostro prodotto è...
Guida pratica per determinare la categoria CRA del vostro prodotto. Include...
6 minDoes 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.