Cosa si intende per Vulnerability Assessment? La guida definitiva per le aziende

Il Vulnerability Assessment è una delle attività fondamentali della cybersecurity aziendale moderna, ma anche una delle più fraintese. Molti la confondono con il Penetration Test, altri pensano che basti uno scanner automatico per fare un’analisi seria, altri ancora ne sottovalutano la frequenza necessaria per restare al sicuro.

In questa guida tecnica trovi tutto ciò che serve per capire davvero cos’è un Vulnerability Assessment, come si svolge, quali tipologie esistono e perché oggi è un’attività essenziale — non solo per la sicurezza, ma anche per la conformità a normative come NIS2, GDPR e ISO 27001.

1. Cos’è il Vulnerability Assessment
2. Vulnerability Assessment vs Penetration Test
3. Le tipologie di Vulnerability Assessment
4. Le fasi di un VA professionale
5. Gli strumenti più usati
6. CVE, CVSS e CWE: come si leggono le vulnerabilità
7. Quando eseguire un Vulnerability Assessment
8. Vulnerability Assessment e compliance normativa
9. I 5 errori più comuni

Cos’è il Vulnerability Assessment

Il Vulnerability Assessment (VA) è un processo sistematico di identificazione, classificazione e prioritizzazione delle vulnerabilità di sicurezza presenti in un sistema informatico, una rete aziendale o un’applicazione.
A differenza di un attacco simulato, il VA non sfrutta le vulnerabilità trovate: si limita a rilevarle, documentarle e assegnare loro un livello di rischio. È un’attività ad ampio spettro, automatizzata nella fase di scansione ma validata e interpretata da specialisti.

Cosa fa concretamente un Vulnerability Assessment:

• Mappa tutti gli asset esposti (server, endpoint, applicazioni, dispositivi di rete)
• Confronta configurazioni e versioni software con database aggiornati di vulnerabilità note
• Identifica patch mancanti, configurazioni insicure e servizi esposti
• Classifica ogni vulnerabilità in base alla gravità tramite metriche standard

Cosa il Vulnerability Assessment NON fa:

• Non sfrutta le vulnerabilità per dimostrarne l’impatto reale
• Non rileva, di norma, vulnerabilità zero-day o errori complessi di logica applicativa
• Non sostituisce un Penetration Test
• Non verifica l’efficacia operativa delle difese contro attacchi mirati

Il VA è quindi il primo livello di analisi della superficie d’attacco aziendale, e la base su cui costruire una strategia di sicurezza più ampia.

Vulnerability Assessment vs Penetration Test

Confondere VA e Penetration Test è uno degli errori più diffusi tra le aziende che si avvicinano alla cybersecurity. Sono attività complementari, ma profondamente diverse.
Il Vulnerability Assessment è ampio, automatizzato nella scansione, mira a una visione d’insieme della superficie d’attacco. Il Penetration Test è profondo, prevalentemente manuale, mira a dimostrare l’impatto reale di una o più vulnerabilità simulando il comportamento di un attaccante.

Le due attività possono e dovrebbero coesistere.
Si parla in questi casi di VAPT (Vulnerability Assessment + Penetration Test): un approccio combinato in cui il VA fornisce la mappa delle vulnerabilità e il PT verifica quali sono effettivamente sfruttabili e con quale impatto sul business.
In sintesi: il VA risponde alla domanda “quali sono i punti deboli?”, il Penetration Test risponde a “cosa può fare davvero un attaccante con quei punti deboli?”.

Le tipologie di Vulnerability Assessment

Non esiste un solo tipo di Vulnerability Assessment.
A seconda dell’asset analizzato si parla di tipologie differenti, ognuna con strumenti e metodologie specifiche.

Il Network-based Vulnerability Assessment è la tipologia più diffusa e analizza i dispositivi connessi alla rete — server, firewall, switch, router — per individuare porte aperte, servizi vulnerabili, configurazioni errate e patch mancanti. Si concentra quindi sul perimetro infrastrutturale.

L’Host-based Vulnerability Assessment sposta invece il focus sui singoli host, ovvero workstation e server, analizzando sistema operativo, software installato, configurazioni locali e politiche di sicurezza. Per risultare efficace richiede credenziali di accesso ai sistemi target.

Quando l’oggetto dell’analisi sono le applicazioni web entra in gioco il Web Application Vulnerability Assessment, che identifica vulnerabilità tipiche dell’ambiente applicativo come SQL Injection, Cross-Site Scripting e meccanismi di autenticazione deboli. Lo standard di riferimento è l’OWASP Top 10.

Esistono poi tipologie più verticali: il Database Vulnerability Assessment verifica permessi, configurazioni, patch e crittografia dei database, oltre alla sicurezza delle credenziali e dei meccanismi di backup. Il Wireless Vulnerability Assessment analizza le reti Wi-Fi aziendali alla ricerca di access point non autorizzati, configurazioni di crittografia deboli (WPA, WEP) e reti guest mal segmentate.

Negli ambienti moderni sono sempre più rilevanti il Cloud Vulnerability Assessment — specifico per AWS, Azure e GCP, valuta configurazioni IAM, bucket di storage esposti, security group e API mal configurate — e il Container Vulnerability Assessment, per ambienti Docker e Kubernetes, che identifica immagini con vulnerabilità note, configurazioni non sicure dei cluster e secret esposti.

Completa il quadro il Mobile Vulnerability Assessment, che analizza app iOS e Android dal lato client e server, gestione dei dati locali e permessi richiesti. Un programma di security maturo combina più tipologie, calibrate sulla specifica superficie d’attacco aziendale.

Le fasi di un Vulnerability Assessment professionale

Un Vulnerability Assessment condotto in modo serio segue una metodologia precisa, suddivisa in fasi consecutive che vanno dalla preparazione alla verifica finale delle correzioni.

Tutto inizia con la pianificazione e lo scoping: si definisce il perimetro dell’assessment, cioè quali asset rientrano nell’analisi, quali tipologie di VA verranno eseguite, in quali finestre temporali. È in questa fase che si concordano le regole d’ingaggio tra fornitore e cliente, e si stabilisce cosa è incluso e cosa è esplicitamente escluso.
Segue l’asset discovery o asset inventory, una fase apparentemente banale ma quasi sempre rivelatrice: si identifica e cataloga tutto ciò che esiste nel perimetro — indirizzi IP attivi, host raggiungibili, servizi in ascolto, applicazioni esposte. Quasi sempre emergono asset dimenticati o non documentati, e questo è già di per sé un risultato di valore.

Si passa poi alla fase tecnica vera e propria, la scansione delle vulnerabilità: strumenti automatizzati confrontano gli asset rilevati con database aggiornati di vulnerabilità note (CVE). È la fase che produce il maggior volume di dati. I dati grezzi però non bastano: serve la validazione manuale, in cui un analista verifica i risultati per scartare i falsi positivi, validare le vulnerabilità reali e identificare correlazioni tra debolezze.
Questa fase è ciò che distingue un Vulnerability Assessment professionale da un report grezzo di scanner.

Ogni vulnerabilità validata viene quindi sottoposta a risk scoring, attribuendo un punteggio di gravità tramite metriche standard come il CVSS (Common Vulnerability Scoring System), su una scala da 0 a 10. Il reporting finale documenta tutte le vulnerabilità rilevate, le classifica per priorità e include raccomandazioni di mitigazione, con un executive summary destinato al management e un dettaglio tecnico per il team IT.

A questo punto inizia la parte operativa lato cliente: il remediation planning, in cui si definiscono tempi e responsabilità per la correzione delle vulnerabilità più gravi, prioritizzandole in base al rischio reale per il business. Il ciclo si chiude infine con il re-test, una verifica successiva che conferma se le correzioni siano state effettivamente implementate. È la fase che molti fornitori dimenticano di includere, ma senza la quale il VA resta un esercizio incompleto.

Gli strumenti del Vulnerability Assessment

Il mercato degli strumenti di Vulnerability Assessment è ampio e si è andato consolidando negli ultimi anni.
A grandi linee la classificazione più utile è quella che distingue tra soluzioni commerciali e soluzioni open source, perché rispondono a logiche d’uso, modelli di pricing e profili di utenza differenti.

Le soluzioni commerciali offrono potenza, supporto strutturato, aggiornamenti tempestivi del database CVE e integrazione nativa con il resto dell’ecosistema di sicurezza aziendale (SIEM, SOAR, sistemi di ticketing).
Sono pensate per ambienti enterprise dove la scansione è continua e va integrata con processi di vulnerability management più ampi. Tra i nomi più consolidati nel panorama internazionale ci sono Tenable Nessus, Qualys VMDR, Rapid7 InsightVM e Acunetix per il segmento Web Application.
Sono soluzioni potenti ma con costi di licenza che possono essere significativi, soprattutto per le PMI.

Le soluzioni open source rappresentano un’alternativa flessibile, sostenuta da comunità tecniche attive.
Tra le più note ci sono OpenVAS — affiancato dalla versione enterprise Greenbone —, OWASP ZAP mantenuto dalla fondazione OWASP per il segmento web, Nikto per assessment rapidi su asset esposti e, più recentemente, Nuclei, un framework moderno basato su template YAML particolarmente apprezzato nei team offensive. Le soluzioni open source non hanno il supporto strutturato dei prodotti commerciali, ma in mani esperte producono risultati di qualità equivalente.

Va sottolineato un punto spesso trascurato: lo strumento, da solo, non basta.

Qualunque sia lo scanner utilizzato, il vero valore di un Vulnerability Assessment professionale risiede nella competenza dell’analista che interpreta i risultati, scarta i falsi positivi, contestualizza le vulnerabilità rispetto al business del cliente e definisce le priorità di intervento. Affidarsi al solo output di uno strumento, per quanto evoluto, è uno degli errori più diffusi — e ne parliamo più avanti in questa guida.

CVE, CVSS e CWE: come si leggono le vulnerabilità

Tre acronimi ricorrono in ogni report di Vulnerability Assessment ed è essenziale conoscerli per interpretare correttamente i risultati.
Il CVE (Common Vulnerabilities and Exposures) è un identificatore univoco assegnato a ogni vulnerabilità nota pubblicata. Quando si legge un riferimento del tipo “CVE-2024-1234”, quello è il codice che identifica una specifica vulnerabilità a livello globale. Il database CVE è gestito da MITRE ed è il riferimento universale del settore.

Il CVSS (Common Vulnerability Scoring System) è invece il sistema di punteggio che misura quanto è grave una vulnerabilità, su una scala da 0 (nessun impatto) a 10 (critico). Si compone di metriche su exploitability (quanto è facile sfruttare la vulnerabilità) e impact (cosa succede se viene sfruttata). Le vulnerabilità con CVSS superiore o uguale a 9.0 sono considerate critiche e richiedono correzione urgente, idealmente entro pochi giorni dalla scoperta.

Il CWE (Common Weakness Enumeration) ha invece una funzione diversa: classifica le categorie di debolezza software, non le singole vulnerabilità. Ad esempio CWE-79 identifica la categoria “Cross-Site Scripting”, CWE-89 identifica “SQL Injection”. Mentre la CVE punta a una vulnerabilità specifica e contestualizzata, la CWE descrive il tipo di problema in astratto.

Va segnalato un ultimo riferimento sempre più rilevante: il KEV catalog (Known Exploited Vulnerabilities) gestito dalla CISA statunitense, che elenca le vulnerabilità note attivamente sfruttate da attaccanti reali. Indipendentemente dal punteggio CVSS, le vulnerabilità presenti nel KEV vanno trattate come priorità assoluta.

Quando eseguire un Vulnerability Assessment

Un Vulnerability Assessment può essere eseguito secondo due logiche distinte, in base al profilo dell’azienda e agli obiettivi che si vogliono raggiungere.
La prima logica è quella del VA una tantum, ovvero un’analisi puntuale eseguita in un momento specifico.
È la modalità più adatta quando l’azienda ha un obiettivo circoscritto: fotografare lo stato di sicurezza prima di un audit, validare un nuovo deployment, supportare la preparazione di un Penetration Test o rispondere a una richiesta specifica dei clienti o degli auditor. È anche la modalità più comune per chi si avvicina per la prima volta a questo tipo di servizio e vuole capire da dove partire.

La seconda logica è quella del VA continuativo a cadenza mensile, pensato per le aziende che vogliono mantenere sotto controllo costante la propria superficie d’attacco. Gli ambienti IT cambiano rapidamente — nuovi sistemi vengono installati, software vengono aggiornati, asset entrano ed escono dall’inventario — e una scansione mensile garantisce che le vulnerabilità emergenti vengano intercettate tempestivamente, prima che possano essere sfruttate. È la modalità più indicata per organizzazioni con superficie d’attacco ampia, requisiti di compliance stringenti o operatività critica.

Indipendentemente dalla modalità scelta, esistono eventi specifici che richiedono comunque un Vulnerability Assessment dedicato: l’introduzione di nuovi sistemi o software, le migrazioni infrastrutturali — come il passaggio al cloud —, le modifiche significative al perimetro di rete, l’esito di un incidente di sicurezza e la preparazione di audit o certificazioni come ISO 27001 o SOC 2.

In tutti questi casi un VA puntuale serve a fotografare lo stato di sicurezza prima e dopo un cambiamento rilevante.
La scelta tra modalità una tantum e modalità continuativa dipende da diversi fattori: dimensione e complessità dell’infrastruttura, criticità dei dati gestiti, requisiti normativi applicabili, maturità del programma di security interno. In linea generale, le aziende con sistemi sempre più esposti a Internet e con dati sensibili trovano nel VA mensile uno strumento più efficace, mentre le realtà con perimetro più contenuto e modifiche infrastrutturali poco frequenti possono trovare nel VA una tantum una soluzione adeguata, ripetuta periodicamente in base alle esigenze.

Vulnerability Assessment e compliance normativa

Il Vulnerability Assessment non è solo una pratica di sicurezza: in molti casi è anche un obbligo normativo o un requisito esplicito per ottenere certificazioni.

In ambito GDPR, il Regolamento UE 2016/679 stabilisce all’art. 32 l’obbligo di adottare misure tecniche e organizzative adeguate per garantire la sicurezza dei dati personali. Il Vulnerability Assessment è una delle misure tipiche riconosciute dalle autorità di controllo per dimostrare diligenza nella tutela dei dati.

La direttiva NIS2 e la sua trasposizione italiana nel Decreto Legislativo 138/2024 richiedono ai soggetti essenziali e importanti l’adozione di misure di gestione dei rischi di cybersecurity, tra cui rientrano esplicitamente le valutazioni periodiche delle vulnerabilità. Le sanzioni in caso di non conformità sono significative e applicabili anche al management aziendale.

Lo standard internazionale ISO/IEC 27001 include controlli specifici nell’Annex A.12 e A.18 che richiedono valutazioni periodiche delle vulnerabilità tecniche. Per le aziende del settore finanziario è inoltre rilevante il DORA (Digital Operational Resilience Act), in vigore dal 2025, che impone test di resilienza ICT periodici comprensivi di Vulnerability Assessment e Penetration Test. Infine, le aziende incluse nel Perimetro di Sicurezza Nazionale Cibernetica hanno obblighi specifici di valutazione e di segnalazione delle vulnerabilità all’Agenzia per la Cybersicurezza Nazionale.

In tutti questi contesti, il Vulnerability Assessment fornisce evidenze documentali che testimoniano la diligenza dell’organizzazione e che possono essere esaminate dagli auditor.

I 5 errori più comuni nei Vulnerability Assessment

1. Confondere VA con Penetration Test. Il Vulnerability Assessment non simula attacchi: chi pensa che basti per testare le difese in profondità si espone a brutte sorprese.
2. Affidarsi solo allo scanner automatico. Un report di scanner senza validazione umana contiene falsi positivi (vulnerabilità segnalate ma inesistenti) e falsi negativi (vulnerabilità reali non rilevate).
3. Non gestire i falsi positivi. Un report grezzo da scanner può segnalare centinaia di “vulnerabilità” inesistenti. Se il team IT le tratta tutte, perde tempo prezioso e finisce per ignorare anche quelle reali.
4. Mancare di un piano di remediation. Identificare le vulnerabilità senza un piano operativo per correggerle è inutile. Ogni VA serio termina con priorità, responsabili e tempistiche.
5. Saltare il re-test. Senza una verifica finale, non c’è certezza che le correzioni siano state implementate correttamente. Il re-test chiude il ciclo.