VEX e CSAF: evidenze sulle vulnerabilità verificabili in audit

L’avviso delle 07:40 che trasforma un SBOM in un tema da consiglio di amministrazione

Alle 07:40 di un martedì mattina, all’inizio del 2026, Anya, CISO di una piattaforma FinTech in rapida crescita, riceve da un fornitore un avviso critico in formato CSAF. È stata individuata una vulnerabilità di esecuzione di codice da remoto in una libreria open source ampiamente utilizzata. Il suo Software Bill of Materials conferma che la libreria è incorporata nell’applicazione principale di elaborazione dei pagamenti, in due servizi interni e in un componente di analisi esternalizzato.

Alle 08:10, il telefono inizia a vibrare. Il team di ingegneria vuole sapere se la funzione vulnerabile è raggiungibile. La funzione Compliance vuole capire se la questione riguarda ISO/IEC 27001:2022, NIS2 o DORA. La funzione Legale chiede se il Cyber Resilience Act possa richiedere una comunicazione ai clienti o alle autorità. Un membro del consiglio di amministrazione, appena formato sulla responsabilità degli organi di gestione prevista da NIS2, pone la domanda che tutti hanno in mente:

Siamo affected?

La prima risposta tecnica è onesta: il pacchetto esiste, ma la funzione vulnerabile potrebbe non essere richiamata in produzione. Nel 2026 questa risposta non è sufficiente.

Il consiglio di amministrazione vuole evidenze. I clienti vogliono una risposta chiara. La funzione Acquisti vuole sapere se il fornitore ha rispettato gli obblighi contrattuali di divulgazione. Il DPO vuole capire se dati personali potrebbero essere esposti. Un auditor ISO 27001 non accetterà “lo ha detto lo sviluppatore” come evidenza conservata. Un auditor DORA si aspetterà che la vulnerabilità sia collegata ad asset ICT, funzioni critiche e dipendenze da terze parti.

È qui che VEX e CSAF smettono di essere formati tecnici e diventano infrastruttura di governance.

CSAF, il Common Security Advisory Framework, struttura gli avvisi sulle vulnerabilità in modo che persone e sistemi possano trattare prodotti interessati, versioni, indicazioni di remediation, riferimenti e informazioni di stato. VEX, Vulnerability Exploitability eXchange, fornisce il livello decisionale. Indica agli stakeholder se una vulnerabilità nota è effettivamente sfruttabile in uno specifico prodotto, servizio o ambiente.

Gli esiti pratici dello stato VEX sono semplici: affected, not affected, fixed e under investigation. La governance sottostante non lo è. Ogni stato richiede evidenze, un titolare, una motivazione, un’approvazione e un criterio di riesame.

La lacuna di conformità non è più l’assenza di SBOM. Molte organizzazioni oggi dispongono di SBOM. La lacuna consiste nel dimostrare come ogni avviso di vulnerabilità sia stato sottoposto a triage, chi abbia approvato la decisione sullo stato, quali evidenze abbiano supportato una conclusione “not affected”, come sia stata prioritizzata la remediation quando il prodotto era “affected” e come l’organizzazione abbia conservato questa traccia per auditor, autorità di regolamentazione, clienti e direzione.

Clarysec tratta VEX e CSAF come parte del modello operativo del SGSI. In Zenith Blueprint: roadmap in 30 passaggi per l’auditor, questo tema rientra nelle fasi di gestione del rischio, sicurezza dei fornitori, controlli tecnologici ed evidenze. In Zenith Controls: guida alla conformità incrociata, lo stesso tema collega i controlli ISO/IEC 27001:2022 con sicurezza della catena di fornitura ICT, gestione delle vulnerabilità, gestione delle evidenze, NIS2, DORA, GDPR e aspettative NIST.

Perché gli SBOM generano segnali, mentre VEX genera evidenze

Un SBOM è un elenco degli ingredienti. Indica che cosa è presente in un prodotto o servizio. Quando una CVE compare in uno di questi ingredienti, l’SBOM segnala che potresti essere affected.

Questo segnale è prezioso, ma non è una conclusione.

Un ambiente software maturo può generare migliaia di corrispondenze tra SBOM e vulnerabilità. Molte rappresentano rischi reali. Molte non sono sfruttabili perché il codice vulnerabile non viene distribuito, importato, raggiunto, configurato o esposto a input non attendibili, oppure perché è mitigato da controlli compensativi. Senza un processo formale per registrare l’indagine, i team di solito ricadono in uno di due modelli negativi.

Il primo è l’esaurimento da triage. Gli ingegneri rincorrono ogni corrispondenza di vulnerabilità con la stessa urgenza, anche quando il componente è una dipendenza di build, un percorso di codice inattivo o una funzionalità esclusivamente interna protetta da controlli stratificati.

Il secondo è l’accettazione del rischio non documentata. I team chiudono i ticket con brevi commenti come “non applicabile” o “falso positivo”. Può sembrare efficiente, ma per un auditor è una decisione non controllata. Per un’autorità di regolamentazione può apparire come una vulnerabilità non gestita.

VEX e CSAF risolvono questo problema trasformando il rumore sulle vulnerabilità in evidenze strutturate e verificabili in audit.

Un processo di governance VEX e CSAF difendibile risponde a cinque domande:

1. Abbiamo ricevuto o identificato l’avviso?
2. Lo abbiamo mappato a prodotti, asset, fornitori, clienti e flussi di dati personali?
3. Abbiamo determinato lo stato della vulnerabilità utilizzando criteri definiti?
4. Abbiamo documentato decisione, evidenze, titolare, approvazione e criterio di riesame?
5. Abbiamo eseguito remediation, divulgazione, monitoraggio o conservazione delle evidenze in base al rischio?

La differenza tra “not affected” e “ignorato” è l’evidenza.

Uno stato VEX “not affected” deve essere supportato da una motivazione, ad esempio: il componente vulnerabile non è presente, la versione vulnerabile non è distribuita, il percorso di codice vulnerabile non viene eseguito, la configurazione vulnerabile è disabilitata oppure un controllo compensativo impedisce lo sfruttamento. “Under investigation” deve prevedere un follow-up con scadenza definita, non diventare un cimitero del backlog. “Fixed” deve rimandare a patch, mitigazione, aggiornamento di versione, risultato di test e registrazione di deployment. “Affected” deve confluire nei flussi di lavoro di trattamento del rischio, pianificazione della remediation, notifica al fornitore, comunicazione al cliente e, ove rilevante, valutazione dell’incidente o della violazione.

Il modello di governance Clarysec per le decisioni sullo stato VEX

Ogni avviso CSAF e ogni dichiarazione VEX devono essere trattati come una registrazione controllata all’interno del SGSI, non come un artefatto tecnico isolato. Il flusso di lavoro può risiedere in una piattaforma GRC, in uno strumento di gestione delle vulnerabilità, in un sistema di ticketing, in un flusso di controllo del codice sorgente o in una cartella di lavoro Clarysec per le evidenze. Il punto essenziale è che stato, evidenze, approvazione e trattamento del rischio restino collegati.

Questa tabella sembra semplice, ma cambia l’ambiente di controllo. Una dichiarazione “not affected” diventa una mini-decisione di rischio per uno specifico prodotto e ambiente. Uno stato “fixed” collega la gestione delle vulnerabilità alla gestione delle modifiche e ai test. Uno stato “affected” attiva trattamento, escalation e possibile divulgazione. Uno stato “under investigation” offre alla direzione un rischio visibile e limitato nel tempo.

Zenith Blueprint rafforza questo approccio nello Step 13 sulla pianificazione del trattamento del rischio e sulla Dichiarazione di Applicabilità. Spiega che le decisioni sui controlli devono essere giustificate dal trattamento del rischio, da requisiti legali o contrattuali, dalla rilevanza per l’ambito di applicazione e dal contesto organizzativo:

“Nel foglio SoA, contrassegnare ogni controllo come ‘Sì’ (applicabile) o ‘No’ (non applicabile). Fornire una Giustificazione/Note.”

Per VEX, “not affected” segue la stessa disciplina. Non è la chiusura informale di un ticket. È una decisione motivata che deve resistere al riesame.

Lo Step 19 di Zenith Blueprint affronta la gestione delle vulnerabilità tecniche:

“Restare informati sui nuovi bug di sicurezza (tramite avvisi dei fornitori, feed CVE, ecc.) relativi al software e all’hardware in uso. Valutare quali siano rilevanti (usiamo questo software? quanto è critico il bug?) e applicare tempestivamente correzioni o mitigazioni.”

CSAF aiuta a ricevere avvisi strutturati. Gli SBOM aiutano a determinare la presenza dei componenti. VEX aiuta a documentare sfruttabilità e stato. Il SGSI governa la decisione.

Evidenze di policy prima dell’arrivo dell’avviso critico

Un programma VEX fallisce quando il primo avviso critico arriva prima che esistano ruoli, criteri e requisiti di evidenza. Le policy devono già definire ricezione delle vulnerabilità, escalation, registrazione, obblighi dei fornitori, gestione delle eccezioni e conservazione delle evidenze.

Per le PMI, la Politica di gestione delle vulnerabilità e delle patch - PMI stabilisce l’obbligo di monitoraggio:

“Monitora i sistemi per individuare vulnerabilità e patch disponibili utilizzando avvisi dei fornitori, avvisi di threat intelligence e notifiche del sistema operativo”

Questa clausola, tratta da Ruoli e responsabilità, clausola di policy 4.2.1, si applica direttamente alla ricezione CSAF. Gli avvisi CSAF sono avvisi sulle vulnerabilità provenienti da fornitori o ecosistemi che devono essere monitorati, correlati e sottoposti a triage.

La stessa policy per PMI definisce le aspettative sulla capacità di dimostrare la conformità in sede di audit:

“Mantenere registrazioni accurate delle patch applicate, delle problematiche aperte e delle eccezioni per garantire la preparazione agli audit”

Da Obiettivi, clausola di policy 3.4, questo è il punto in cui VEX diventa più di un file tecnico. Se un team non applica una patch perché un prodotto è “not affected”, tale eccezione richiede evidenze, approvazione e tracciabilità.

Per gli ambienti enterprise, la Politica di gestione delle vulnerabilità e delle patch è esplicita:

“Monitorare gli avvisi sulle minacce (ad es. CVE, CISA KEV, bollettini dei fornitori) e sottoporre a escalation le vulnerabilità critiche.”

Da Ruoli e responsabilità, clausola di policy 4.5.1, questa clausola supporta un canale strutturato di ricezione per CSAF, CVE, bollettini dei fornitori e informazioni sugli exploit. Richiede inoltre l’escalation quando uno stato VEX è “affected” o “under investigation” per un prodotto critico.

La policy enterprise stabilisce inoltre:

“Tutte le vulnerabilità critiche e ad alto rischio devono essere registrate nel Registro dei rischi del SGSI e monitorate fino alla remediation o fino alla copertura mediante un’eccezione approvata.”

Questa clausola, tratta da Requisiti di governance, clausola di policy 5.3, è l’ancoraggio di conformità. Una dichiarazione VEX “not affected” per una CVE critica è difendibile solo quando è trattata come un’eccezione approvata e supportata da evidenze. Una dichiarazione VEX “fixed” chiude il ciclo solo quando la remediation è verificata.

Anche il punteggio di rischio richiede contesto. La stessa policy fa riferimento a:

“Valutazione del rischio (basata su CVSS, criticità dell’asset, informazioni sulle minacce)”

Da Trattamento del rischio ed eccezioni, clausola di policy 7.2.2, questo supporta un modello di triage combinato. Il solo CVSS non basta. Una vulnerabilità di gravità media sfruttata attivamente in un componente critico di identità può essere più urgente di un problema con CVSS critico in codice non raggiungibile.

Le policy sulla sicurezza delle applicazioni e sullo sviluppo sicuro estendono la stessa disciplina all’ingegneria e ai fornitori. La Politica sui requisiti di sicurezza delle applicazioni - PMI richiede ai team di tracciare:

“vulnerabilità note e stato della remediation.”

Da Requisiti di applicazione della policy, clausola di policy 6.4.2.3, questo si mappa in modo naturale sugli stati VEX. La stessa policy richiede che gli accordi:

“specifichino gli obblighi di divulgazione delle vulnerabilità, i tempi di risposta e l’applicazione delle patch.”

Da Requisiti di governance, clausola di policy 5.3.2, questo diventa una clausola pratica per i fornitori: fornire avvisi tempestivi, identificare le versioni interessate, emettere uno stato VEX ove possibile, definire le tempistiche di remediation e supportare la divulgazione al cliente.

Per lo sviluppo sicuro in ambito enterprise, la Politica di sviluppo sicuro richiede:

“Scansione delle vulnerabilità note (CVE, OSS Index, ecc.)”

Da Requisiti di governance, clausola di policy 5.4.3, questo offre all’ingegneria un meccanismo definito per associare gli avvisi ai componenti e attivare l’analisi VEX.

Quando una vulnerabilità diventa un incidente o una potenziale questione legale, la disciplina sulle evidenze diventa essenziale. La Politica per la raccolta delle evidenze e l’analisi forense - PMI stabilisce:

“Per ogni incidente deve essere mantenuto un semplice registro della catena di custodia (ad es. file Excel o modello di documento).”

Da Requisiti di governance, clausola di policy 5.3.1, questo è il confine tra il triage VEX ordinario e la gestione delle evidenze di livello incident. Se si sospetta uno sfruttamento, log, registrazioni degli avvisi, note di analisi, comunicazioni e artefatti forensi richiedono tracciabilità.

Mappatura di VEX e CSAF a ISO 27001, NIS2, DORA, GDPR e CRA

I programmi VEX più solidi non sono progetti isolati di security engineering. Sono mappati nel sistema di controllo già utilizzato dall’organizzazione.

Ai sensi di ISO/IEC 27001:2022, il SGSI deve tenere conto delle parti interessate, degli obblighi legali e contrattuali, delle interfacce e delle dipendenze con altre organizzazioni. Questa logica di ambito è essenziale per VEX, perché avvisi dei fornitori, impegni verso i clienti, componenti open source e servizi esternalizzati incidono tutti sulle decisioni relative alle vulnerabilità.

I controlli dell’Allegato A più rilevanti includono 5.19 Sicurezza delle informazioni nei rapporti con i fornitori, 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori, 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT, 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, 5.28 Raccolta delle evidenze e 8.8 Gestione delle vulnerabilità tecniche. Anche i controlli di sviluppo sicuro da 8.25 a 8.29 sono rilevanti quando l’organizzazione sviluppa software o prodotti digitali.

NIS2 aumenta la pressione sulla governance. Article 21 richiede misure tecniche, operative e organizzative adeguate, incluse analisi del rischio, trattamento dell’incidente, continuità operativa, sicurezza della catena di fornitura, acquisizione, sviluppo e manutenzione sicuri, gestione e divulgazione delle vulnerabilità, efficacia dei controlli, igiene informatica, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e autenticazione. Article 20 richiede agli organi di gestione di approvare e supervisionare le misure di gestione del rischio di cibersicurezza. Ciò rende le metriche VEX adatte alla reportistica al consiglio di amministrazione.

DORA si applica dal 17 gennaio 2025 agli enti finanziari rientranti nel suo ambito. Richiede un quadro di riferimento per la gestione del rischio ICT, identificazione e classificazione di asset ICT, vulnerabilità, dipendenze e servizi ICT di terze parti, gestione degli incidenti, test di resilienza, gestione del rischio di terze parti e supervisione della direzione. Per gli enti finanziari, le registrazioni VEX sono particolarmente utili quando un avviso del fornitore deve essere collegato a funzioni critiche o importanti, obblighi contrattuali e classificazione dell’incidente.

GDPR entra in gioco quando lo sfruttamento potrebbe incidere sui dati personali. Un’API, una libreria o un servizio vulnerabile che potrebbe esporre registrazioni dei clienti richiede una valutazione rispetto a riservatezza, integrità, disponibilità e criteri di notifica della violazione. Una conclusione VEX “not affected” può supportare la decisione di non notificare, ma solo se l’organizzazione può dimostrare perché non si è verificata alcuna violazione dei dati personali.

Il Cyber Resilience Act aggiunge la governance di prodotto. Con l’entrata progressiva in vigore degli obblighi CRA, produttori e altri operatori economici hanno bisogno di processi ripetibili per gestione delle vulnerabilità, aggiornamenti di sicurezza, divulgazione coordinata ed evidenze. CSAF può strutturare gli avvisi. VEX può chiarire quali prodotti e versioni sono affected, fixed o not affected.

Che cosa aggiunge la guida Clarysec alla conformità incrociata

Zenith Controls è utile perché mappa il lavoro tecnico alle aspettative di audit e ai quadri di riferimento sovrapposti. Per VEX e CSAF, le tre aree più rilevanti sono sicurezza della catena di fornitura ICT, gestione delle vulnerabilità tecniche e raccolta delle evidenze.

Per la sicurezza della catena di fornitura ICT, Zenith Controls identifica il controllo 5.21 di ISO/IEC 27002:2022 come “Gestione della sicurezza delle informazioni nella catena di fornitura ICT”. Spiega che 5.21 estende i controlli sui rapporti con i fornitori 5.19 e 5.20 ai rischi specifici ICT, inclusi componenti software non sicuri e librerie di terze parti o open source. Lo collega a ingegneria sicura, programmazione sicura, test di sicurezza, controllo degli accessi, raccolta delle evidenze, ciclo di vita sicuro dello sviluppo e sviluppo esternalizzato.

È esattamente qui che operano CSAF e VEX. Un avviso del fornitore non è solo un messaggio di un fornitore. È evidenza della pratica di cibersicurezza del fornitore. Una dichiarazione VEX del fornitore non è solo una comodità. Può supportare approvvigionamento, due diligence, monitoraggio e decisioni di rischio del cliente.

Per la gestione delle vulnerabilità tecniche, Zenith Controls identifica il controllo 8.8 come “Gestione delle vulnerabilità tecniche”. Classifica il controllo come preventivo, a supporto di riservatezza, integrità e disponibilità, e collegato alla gestione di minacce e vulnerabilità. Rileva inoltre che la gestione delle vulnerabilità si collega a protezione antimalware, gestione della configurazione, gestione delle modifiche, informazioni sulle minacce e monitoraggio.

Un passaggio particolarmente utile di Zenith Controls per la governance VEX è:

“Una gestione efficace delle vulnerabilità stabilisce le priorità in base alle minacce reali. Le informazioni sulle minacce indicano quali vulnerabilità sono sfruttate attivamente, guidando la prioritizzazione delle patch.”

Questa è la differenza tra una semplice corrispondenza SBOM e un triage VEX basato sul rischio. La presenza da sola non basta. Sfruttabilità, criticità dell’asset, esposizione e attività della minaccia devono orientare la decisione.

Per le evidenze, Zenith Controls identifica il controllo 5.28, “Raccolta delle evidenze”, come correttivo e collegato a rilevazione e risposta. Collega 5.28 a risposta agli incidenti, logging, monitoraggio e segnalazione degli eventi. Mappa inoltre la gestione delle evidenze a ISO/IEC 27037:2012 per identificazione, raccolta, acquisizione e conservazione delle evidenze digitali.

Quando una vulnerabilità è solo teorica, le registrazioni VEX ordinarie possono essere sufficienti. Quando si sospetta uno sfruttamento, l’organizzazione deve passare alla gestione delle evidenze di incidente. Log, comunicazioni dei fornitori, avvisi ai clienti, registrazioni delle patch e artefatti forensi richiedono integrità, conservazione e tracciabilità.

Un pacchetto pratico di evidenze VEX dall’allerta alla chiusura

Torniamo alla piattaforma FinTech di Anya. Arriva un avviso CSAF per una vulnerabilità critica in lib-common-utils, presente nell’SBOM del gateway di pagamento. Una risposta disciplinata creerebbe un unico pacchetto di evidenze, non messaggi Slack e screenshot dispersi.

Step 1: creare la registrazione di ricezione dell’avviso

Apri un caso di vulnerabilità nel tracciatore delle evidenze del SGSI. Allega l’avviso CSAF, il riferimento CVE, il bollettino del fornitore, la corrispondenza SBOM e l’elenco degli asset interessati. Assegna un titolare della vulnerabilità e un titolare del sistema di business. Collega il servizio di pagamento a impatto sui clienti, dati personali, elaborazione finanziaria e criticità operativa.

Base di policy: la Politica di gestione delle vulnerabilità e delle patch richiede il monitoraggio degli avvisi e l’escalation delle vulnerabilità critiche. Base ISO: controllo Allegato A 8.8. Base NIS2: gestione delle vulnerabilità e manutenzione sicura. Base DORA: identificazione delle vulnerabilità ICT e preparazione agli incidenti.

Step 2: impostare lo stato preliminare su under investigation

Lo stato iniziale deve spesso essere “under investigation”, soprattutto per gli avvisi critici. Definisci una scadenza decisionale, ad esempio 24 ore per servizi critici o esposti all’esterno. Registra i controlli provvisori, come monitoraggio rafforzato, restrizioni temporanee di funzionalità o regole WAF. Questo impedisce che un avviso critico scompaia in un backlog non gestito.

Step 3: eseguire l’analisi di sfruttabilità

Il team di ingegneria deve rispondere a domande pratiche:

• La versione vulnerabile è presente in produzione?
• La funzione vulnerabile è importata, richiamata o raggiungibile?
• La configurazione vulnerabile è abilitata?
• Il componente è esposto a input non attendibili?
• È richiesta l’autenticazione prima che il percorso vulnerabile possa essere raggiunto?
• I controlli compensativi sono efficaci?
• Esiste uno sfruttamento attivo o informazioni sulle minacce credibili?
• Lo sfruttamento potrebbe incidere su dati personali, transazioni finanziarie o disponibilità del servizio?

Nel caso di Anya, l’analisi statica conferma che il componente è presente, ma la funzione vulnerabile non viene invocata dal gateway di pagamento. In produzione non esiste alcun percorso di esecuzione. Il team prepara una dichiarazione VEX “not affected” con evidenze a supporto.

Se l’analisi avesse mostrato che un job amministrativo autenticato poteva raggiungere la funzione vulnerabile, lo stato corretto sarebbe stato “affected”, non “not affected”. Il team avrebbe quindi creato un piano di trattamento del rischio, aperto un ticket di modifica, applicato una patch o una mitigazione e aggiornato lo stato a “fixed” solo dopo la verifica.

Step 4: collegare il caso al Registro dei rischi e alla registrazione del fornitore

I casi critici e ad alto rischio devono essere inseriti nel Registro dei rischi del SGSI, salvo chiusura tramite un’eccezione approvata e supportata da evidenze. Gli avvisi dei fornitori devono essere collegati anche al Registro dei fornitori, agli obblighi contrattuali e alle registrazioni di monitoraggio.

Questo supporta lo Step 23 di Zenith Blueprint, che indica alle organizzazioni di compilare l’elenco dei fornitori, classificarli in base ad accesso e controllo operativo, incorporare nei contratti le aspettative di sicurezza e definire procedure di monitoraggio per le modifiche dei fornitori.

Step 5: convalidare la correzione o approvare l’eccezione

Per “fixed”, allega versione della patch, registrazione della modifica, risultato della pipeline CI/CD, scansione delle dipendenze, digest dell’immagine container, evidenza di deployment e test di regressione. Per “not affected”, allega analisi del percorso di codice, evidenze di configurazione, evidenze di versione, evidenze dei controlli compensativi e approvazione.

Se i clienti utilizzano versioni installate presso il cliente o la vulnerabilità potrebbe interessare utenti esterni, coordina la comunicazione. La Politica di divulgazione coordinata delle vulnerabilità fornisce il modello:

“Quando una vulnerabilità confermata potrebbe interessare clienti o utenti del servizio, il team Comunicazioni, sotto la direzione del VRT, deve preparare un avviso di sicurezza. L’avviso deve includere una panoramica del problema, senza divulgare dettagli di exploit, i prodotti o le versioni interessati, le indicazioni di mitigazione o le istruzioni per il download della patch, e le informazioni di contatto per il supporto.”

Da Requisiti di attuazione, clausola di policy 6.8, questo si mappa direttamente sulla disciplina di pubblicazione CSAF.

Step 6: conservare le evidenze se si sospetta uno sfruttamento

Se i log mostrano tentativi di sfruttamento, passa dalla gestione delle vulnerabilità alla risposta agli incidenti e alla raccolta delle evidenze. Avvia un registro della catena di custodia, conserva i log, registra le query SIEM, esporta gli eventi rilevanti, acquisisci snapshot dei sistemi interessati se necessario e documenta chi ha gestito ogni artefatto. Collega il caso di incidente alla registrazione VEX.

Che cosa chiederanno auditor e autorità di regolamentazione

Non tutti gli auditor verificano la governance VEX e CSAF nello stesso modo. Un singolo pacchetto di evidenze deve soddisfare più prospettive.

Zenith Controls include indicazioni metodologiche di audit coerenti con questa tabella. Per la sicurezza della catena di fornitura ICT, gli auditor che utilizzano ISO/IEC 19011 e ISO/IEC 27007 esamineranno policy di approvvigionamento, modelli RFP e processi di gestione dei fornitori per verificare i requisiti di sicurezza specifici ICT. Effettueranno campionamenti sui contratti per clausole relative a sviluppo sicuro, divulgazione delle vulnerabilità e autenticità del software.

Per la gestione delle vulnerabilità tecniche, gli auditor riesaminano la policy di gestione delle vulnerabilità, la frequenza delle scansioni, la copertura degli asset, la prioritizzazione basata sul rischio, le tempistiche di remediation e le responsabilità. Per la raccolta delle evidenze, verificano se catena di custodia, archiviazione sicura e conservazione siano state seguite in incidenti reali.

Ecco perché la governance VEX non deve mai fermarsi all’etichetta di stato. L’etichetta è la sintesi. La traccia delle evidenze è il controllo.

Metriche di gestione che rendono VEX adatto al consiglio di amministrazione

ISO/IEC 27001:2022 richiede valutazione delle prestazioni, audit interno e Riesame della direzione. NIS2 richiede supervisione della direzione. DORA richiede governance del rischio ICT. VEX e CSAF creano metriche che traducono il lavoro di ingegneria in visibilità del rischio per l’alta direzione.

Le metriche utili per il Riesame della direzione includono:

• Numero di avvisi CSAF critici ricevuti nel trimestre
• Percentuale associata a componenti SBOM
• Numero ed età degli stati VEX per affected, not affected, fixed e under investigation
• Casi “under investigation” scaduti
• Avvisi dei fornitori privi di dati sufficienti sulle versioni interessate
• Vulnerabilità critiche accettate come eccezioni approvate
• Tempo dalla ricezione dell’avviso alla decisione VEX
• Tempo dalla decisione affected alla remediation
• Numero di casi con potenziale impatto sui dati personali
• Numero di avvisi ai clienti emessi

Queste metriche aiutano la direzione a porre domande migliori. Quali fornitori non forniscono dati azionabili sulle vulnerabilità? Quali prodotti hanno i tempi di remediation più lunghi? Quali team lasciano aperte le indagini? Quali vulnerabilità possono incidere su dati personali o funzioni critiche?

Schemi di fallimento comuni da eliminare

Il primo fallimento è trattare la corrispondenza SBOM come analisi di sfruttabilità. Una corrispondenza del componente è un segnale, non una conclusione.

Il secondo fallimento è usare “not affected” senza una motivazione. Gli auditor chiederanno perché. Il percorso di codice era irraggiungibile? La funzionalità vulnerabile era disabilitata? La versione era diversa? Il componente era usato solo in fase di build? La conclusione è stata approvata dalla sicurezza di prodotto?

Il terzo fallimento è lasciare “under investigation” aperto. Questo stato è utile solo con un titolare, una scadenza e controlli provvisori.

Il quarto fallimento è separare la governance dei fornitori dalla governance delle vulnerabilità. I contratti con i fornitori devono richiedere divulgazione tempestiva delle vulnerabilità, tempi di risposta, obblighi di applicazione delle patch, contenuto degli avvisi e supporto alle evidenze.

Il quinto fallimento è ignorare dati personali e comunicazione ai clienti. Una vulnerabilità che potrebbe esporre dati personali richiede una valutazione GDPR. Una vulnerabilità di prodotto confermata che potrebbe interessare i clienti richiede disciplina di divulgazione coordinata. Una dipendenza di un servizio finanziario può richiedere un’analisi dell’incidente ai fini DORA.

Il sesto fallimento è una conservazione debole delle evidenze. Zenith Blueprint avverte nello Step 23, controllo 5.28, che le evidenze sono spesso trascurate:

“ciò che puoi dimostrare conta tanto quanto ciò che è effettivamente accaduto”

Questa frase coglie la realtà del 2026. I team di sicurezza non si limitano a correggere vulnerabilità. Dimostrano che le decisioni sono state tempestive, basate sul rischio e controllate.

Prossimi passi per evidenze sulle vulnerabilità verificabili in audit

Se la tua organizzazione dispone già di SBOM, il passo successivo di maturità non è un altro foglio di calcolo di inventario. È la governance dello stato delle vulnerabilità, degli avvisi dei fornitori e delle evidenze di divulgazione.

Inizia con quattro azioni:

1. Aggiungi la ricezione CSAF e VEX alla procedura di gestione delle vulnerabilità.
2. Definisci criteri di approvazione per affected, not affected, fixed e under investigation.
3. Collega le registrazioni VEX al Registro dei rischi del SGSI, al Registro dei fornitori, all’inventario degli asset, al repository SBOM e al processo di gestione degli incidenti.
4. Testa il processo con un recente avviso critico e produci un pacchetto di evidenze pronto per l’audit.

Clarysec può aiutarti ad applicarlo rapidamente utilizzando Zenith Blueprint, Zenith Controls e il set di policy pertinente, tra cui la Politica di gestione delle vulnerabilità e delle patch, la Politica di gestione delle vulnerabilità e delle patch - PMI, la Politica sui requisiti di sicurezza delle applicazioni - PMI, la Politica di sviluppo sicuro, la Politica per la raccolta delle evidenze e l’analisi forense - PMI e la Politica di divulgazione coordinata delle vulnerabilità.

La domanda vincente nel 2026 non è “Abbiamo un SBOM?”. È “Possiamo dimostrare, per ogni avviso grave, esattamente come abbiamo determinato lo stato della vulnerabilità, trattato il rischio e comunicato il risultato?”

Prenota una valutazione Clarysec o richiedi il toolkit di policy pertinente per trasformare VEX e CSAF in evidenze sulle vulnerabilità pronte per l’audit prima che il prossimo avviso critico arrivi al tuo consiglio di amministrazione.