In breve:
Il vulnerability assessment è l’attività sistematica di identificazione, classificazione e prioritizzazione delle vulnerabilità presenti su sistemi, applicazioni e dispositivi di rete di un’organizzazione. A differenza del penetration test, non tenta di sfruttare le falle: le censisce in modo esteso e ripetibile, producendo una fotografia della superficie di attacco. La sua rilevanza è misurabile: secondo l’ENISA Threat Landscape 2025, lo sfruttamento di vulnerabilità note rappresenta il 21,3% dei vettori di accesso iniziale, secondo solo al phishing, e nello stesso periodo sono state divulgate 42.595 nuove vulnerabilità (+27%). Senza un processo strutturato di rilevazione, il divario tra ciò che è esposto e ciò che è noto cresce ogni settimana.
Cos'è il vulnerability assessment
Il vulnerability assessment è un processo di analisi che individua le debolezze note di configurazione, versione e architettura sui sistemi di un’organizzazione, le associa a un livello di gravità e restituisce un elenco ordinato di ciò che va corretto e in quale sequenza. Si appoggia a database pubblici di vulnerabilità e a scanner che confrontano lo stato rilevato con le vulnerabilità documentate per quel software e quella versione.
L’obiettivo non è dimostrare che un attacco sia possibile, quello è il compito del penetration test, ma coprire in ampiezza l’intero perimetro, con una frequenza tale da mantenere la fotografia aggiornata. È un’attività di igiene, più simile a un inventario periodico che a un’indagine.
Il problema dei numeri
La ragione per cui il tema è diventato ingestibile senza automazione è quantitativa. L’ENISA Threat Landscape 2025 riporta 42.595 vulnerabilità divulgate, in crescita del 27% sull’anno precedente, di cui il 64% sfruttabile via rete — quindi da remoto, senza accesso fisico né credenziali preesistenti. Nessun team può valutare manualmente questo volume e correlarlo al proprio parco applicativo.
Perché la finestra di esposizione si è ristretta
Il secondo dato è più insidioso del primo. ENISA rileva che le campagne di sfruttamento di massa si attivano entro pochi giorni, talvolta poche ore, dalla divulgazione della vulnerabilità, con particolare accanimento su applicazioni esposte su internet: sistemi di collaborazione, mail server, appliance VPN e bilanciatori. Il tempo utile tra “la falla è pubblica” e “la falla è sfruttata su larga scala” si è compresso al punto che una scansione trimestrale non è più una misura di sicurezza: è una misura di conformità documentale.
Differenza tra vulnerability assessment e penetration test
La differenza vulnerability assessment penetration test è la domanda più frequente e la più fraintesa in fase di acquisto. I due servizi rispondono a domande diverse e non sono sostituibili.
Il vulnerability assessment risponde a "cosa è esposto"
Copre l’intero perimetro, è largamente automatizzato, è ripetibile con frequenza elevata e produce un elenco esaustivo di debolezze potenziali. Il suo limite è la profondità: segnala che una condizione vulnerabile esiste, non dimostra che sia realmente sfruttabile nel contesto specifico. Genera per costruzione un certo numero di falsi positivi, che vanno filtrati.
Il penetration test risponde a "cosa succede davvero"
Un penetration test seleziona un perimetro ristretto e verifica manualmente se le vulnerabilità sono concatenabili in un attacco reale, misurando l’impatto effettivo. Richiede competenza umana specialistica, costa sensibilmente di più per unità di perimetro e per questo si esegue con frequenza minore, tipicamente annuale o legata a rilasci significativi.
Il red teaming risponde a "ci accorgeremmo di un attacco"
Un livello ulteriore è l’esercizio di red teaming, che simula un avversario reale su obiettivi di business senza preavviso ai team difensivi, mettendo alla prova non solo la tecnologia ma i processi di rilevazione e risposta. Ha senso solo quando i due livelli precedenti sono già a regime: testare la capacità di risposta di un’organizzazione che non ha ancora un processo di patching è un esercizio con esito prevedibile.
Confronto tra vulnerability assessment, penetration test e red teaming
| Criterio | Vulnerability assessment | Penetration test | Red teaming |
|---|---|---|---|
| Domanda a cui risponde | Cosa è esposto e potenzialmente vulnerabile | Cosa è realmente sfruttabile e con quale impatto | Saremmo in grado di rilevare e reagire |
| Ampiezza del perimetro | Estesa, tendenzialmente completa | Circoscritta, definita in scope | Definita per obiettivi di business |
| Profondità dell'analisi | Superficiale, per definizione | Alta, con verifica manuale | Alta, con simulazione di avversario |
| Grado di automazione | Elevato | Misto, prevalenza di lavoro manuale | Prevalentemente manuale |
| Frequenza tipica | Continuativa o mensile | Annuale o a fronte di rilasci rilevanti | Occasionale, su maturità già acquisita |
| Falsi positivi | Presenti, richiedono triage | Ridotti, per verifica diretta | Non applicabile |
| Team difensivi informati | Sì | Di norma sì | No, è parte dell'esercizio |
| Output principale | Inventario prioritizzato di vulnerabilità | Catene di attacco dimostrate e impatto | Valutazione di rilevazione e risposta |
| Prerequisito | Inventario asset aggiornato | Assessment già a regime | Processi di risposta già maturi |
I tre livelli non si escludono: si stratificano. Il vulnerability assessment fornisce la base continua, il penetration test valida in profondità i punti critici, il red teaming misura la maturità complessiva dell’organizzazione.
Come funziona una scansione vulnerabilità aziendale
Una scansione vulnerabilità aziendale efficace non è l’esecuzione di uno strumento: è un processo con quattro momenti distinti, e il valore si concentra negli ultimi due.
Discovery e inventario degli asset
Non si può analizzare ciò che non si sa di avere. La prima causa di assessment inefficaci è un inventario incompleto: ambienti di test dimenticati, macchine virtuali orfane, dispositivi di rete periferici, servizi cloud attivati fuori dai canali IT. È lo stesso presupposto che rende difficili molti progetti di sicurezza, e vale a maggior ragione quando il perimetro include ambienti non produttivi con copie di dati reali.
Scansione autenticata e non autenticata
La scansione non autenticata osserva il sistema dall’esterno, come farebbe un attaccante privo di credenziali: utile per misurare l’esposizione, cieca su tutto ciò che non è visibile dalla rete. La scansione autenticata accede al sistema con credenziali dedicate e ispeziona versioni, patch e configurazioni: molto più accurata, ma richiede gestione sicura delle credenziali di scansione, che diventano a loro volta un asset critico.
Triage e prioritizzazione
È la fase che distingue un servizio da un report. Un punteggio di gravità tecnico elevato su un sistema isolato e non raggiungibile conta meno di un punteggio medio su un sistema esposto su internet che tratta dati personali. La prioritizzazione deve combinare gravità tecnica, esposizione effettiva, esistenza di exploit pubblici e criticità di business dell’asset. Senza questa correlazione, il team riceve migliaia di righe e non sa da dove iniziare — esito peggiore del non avere il report.
Remediation e verifica di chiusura
Ogni vulnerabilità prioritizzata deve avere un responsabile, una scadenza e una verifica di avvenuta chiusura tramite ri-scansione. Le eccezioni — casi in cui la correzione non è applicabile — vanno formalizzate con misure compensative e riesaminate periodicamente, non lasciate implicite.
Dalla scansione alla gestione delle vulnerabilità
La differenza tra un’organizzazione che subisce e una che regge non sta nel numero di scansioni, ma nell’esistenza di un ciclo continuo. La gestione delle vulnerabilità è il processo che trasforma il dato in riduzione effettiva del rischio.
Perché il ciclo deve essere continuo
Con decine di migliaia di nuove vulnerabilità l’anno e finestre di sfruttamento di pochi giorni, una fotografia periodica descrive uno stato già superato al momento della consegna. Il modello sostenibile è la scansione continua con triage a cadenza breve, integrata con le informazioni sulle minacce attivamente sfruttate — perché la priorità non è la vulnerabilità più grave in astratto, ma quella che gli attaccanti stanno usando adesso.
Il raccordo con il monitoraggio e la risposta
La gestione delle vulnerabilità e il monitoraggio degli eventi sono due facce dello stesso presidio: la prima riduce la superficie, il secondo rileva ciò che passa comunque. L’integrazione tra le due funzioni è ciò che consente di dare priorità in modo informato, ed è il motivo per cui in molte organizzazioni il processo converge verso il presidio continuo di un SOC as a Service. Il contesto delle minacce, del resto, è cambiato rapidamente, come emerge guardando a come l’AI sta modificando le tecniche offensive.
L'obbligo normativo: NIS2 e non solo
Per le organizzazioni che ricadono nel perimetro della direttiva NIS2, la gestione delle vulnerabilità non è una buona pratica ma un requisito esplicito tra le misure di gestione del rischio, insieme alla gestione degli incidenti e alla sicurezza della catena di fornitura. Abbiamo trattato il quadro complessivo degli adempimenti nella guida pratica alla compliance NIS2. Analoghi requisiti compaiono, con formulazioni diverse, in DORA per il settore finanziario.
Il contesto italiano
Il volume di attività ostile rende il tema tutt’altro che teorico per le aziende italiane: il Rapporto Clusit 2026 rileva 507 attacchi gravi in Italia nel 2025 contro 357 nel 2024, con un incremento del 42%, e segnala che il manifatturiero italiano assorbe da solo il 16% degli attacchi globali al settore.
Il ruolo del system integrator nel vulnerability assessment
Il mercato degli strumenti di scansione è maturo e le differenze tecniche tra le soluzioni principali sono meno rilevanti di quanto si creda. La variabile decisiva è il processo che ci si costruisce intorno: chi definisce le priorità, chi assegna le remediation, chi verifica la chiusura, chi decide quando un’eccezione è accettabile.
Nella pratica il fallimento più comune di un programma di vulnerability assessment non è tecnico. È l’accumulo: il report arriva, nessuno ha mandato per imporre le correzioni alle funzioni proprietarie dei sistemi, il backlog cresce e dopo qualche ciclo la scansione diventa un adempimento formale. Evitarlo richiede una governance concordata prima di avviare il servizio, non dopo il primo report.
In AD Consulting queste attività si collocano tra i servizi di vulnerability management e di penetration testing, che coprono rispettivamente il ciclo continuo di rilevazione e prioritizzazione e la verifica in profondità dei perimetri critici, con il complemento delle attività di ethical hacking e red teaming per le organizzazioni con processi di risposta già maturi.
Sai quali dei tuoi sistemi esposti presentano vulnerabilità note sfruttabili oggi?
Il team Security di AD Consulting affianca aziende di banking, GDO, manufacturing, PA e automotive nella costruzione di un processo continuo di vulnerability assessment e remediation.
Scopri i servizi di Vulnerability Management.
FAQ: domande frequenti sul vulnerability assessment
Cos'è il vulnerability assessment?
Il vulnerability assessment è il processo sistematico di identificazione, classificazione e prioritizzazione delle vulnerabilità note presenti su sistemi, applicazioni, dispositivi di rete e servizi cloud di un’organizzazione. Si basa su scansioni automatizzate confrontate con database pubblici di vulnerabilità e produce un inventario ordinato di ciò che deve essere corretto, con quale urgenza e su quale asset.
Qual è la differenza tra vulnerability assessment e penetration test?
Il vulnerability assessment copre l’intero perimetro in ampiezza, è automatizzato, ripetibile con alta frequenza e identifica vulnerabilità potenziali senza sfruttarle. Il penetration test agisce su un perimetro ristretto, è prevalentemente manuale e verifica se e come le vulnerabilità siano concatenabili in un attacco reale, misurandone l’impatto. Il primo dice cosa è esposto, il secondo cosa è realmente sfruttabile. Non sono alternativi: si completano.
Ogni quanto va eseguito un vulnerability assessment?
Considerando che le campagne di sfruttamento si attivano entro giorni dalla divulgazione di una vulnerabilità, la scansione trimestrale ha valore di conformità documentale ma scarso valore difensivo. Il modello raccomandato è una scansione continua o almeno mensile sui sistemi esposti su internet, con triage a cadenza breve e ri-scansione di verifica dopo ogni intervento di remediation.
Il vulnerability assessment è obbligatorio?
Non esiste un obbligo generalizzato, ma per le organizzazioni nel perimetro della direttiva NIS2 la gestione delle vulnerabilità rientra tra le misure di gestione del rischio richieste, e requisiti equivalenti compaiono in DORA per il settore finanziario e in vari standard di settore. In pratica, per un numero crescente di aziende italiane si tratta di un requisito e non di una scelta.
Quante vulnerabilità si trovano tipicamente alla prima scansione?
Il numero assoluto non è un indicatore utile: dipende dall’ampiezza del perimetro, dall’età dei sistemi e dal tipo di scansione. Ciò che conta è la distribuzione per criticità reale — cioè quante riguardano sistemi esposti su internet, con exploit pubblicamente disponibili e rilevanti per il business. È normale che una prima scansione produca un volume elevato di rilevazioni; l’indicatore di maturità è la velocità con cui il backlog critico si riduce nei cicli successivi.
Fonti e riferimenti
- ENISA — Threat Landscape 2025 (ottobre 2025). Lo sfruttamento di vulnerabilità rappresenta il 21,3% dei vettori di accesso iniziale, secondo solo al phishing (60%); 42.595 nuove vulnerabilità divulgate (+27%), di cui il 64% con vettore di attacco di rete; campagne di sfruttamento di massa entro giorni dalla divulgazione.
- Clusit — Rapporto Clusit 2026 sulla sicurezza ICT in Italia (marzo 2026). 507 attacchi gravi rilevati in Italia nel 2025 contro 357 nel 2024 (+42%); il manifatturiero italiano assorbe il 16% degli attacchi globali al settore.
- NIST — National Vulnerability Database (NVD). Repository di riferimento per la classificazione e l’arricchimento delle vulnerabilità note, base dei principali strumenti di scansione.
- Direttiva (UE) 2022/2555 (NIS2) — art. 21, misure di gestione dei rischi di cybersicurezza, che includono la gestione delle vulnerabilità e la loro divulgazione.