In breve
Il vulnerability assessment cerca in modo ampio le vulnerabilità note e le ordina per gravità; il penetration test prova a sfruttarle per dimostrare fin dove arriva un attaccante.
Gli scanner producono falsi positivi e non vedono gli errori di logica applicativa: i risultati vanno interpretati da chi conosce reti e sistemi.
Il NIST indica come modello scansioni regolari intervallate da penetration test periodici, con test aggiuntivi quando i sistemi cambiano.
La ISO 27001 (controllo 8.8) chiede di gestire le vulnerabilità tecniche; le specifiche ACN chiedono ai soggetti NIS2 essenziali vulnerability assessment e/o penetration test sui sistemi rilevanti.
Un test vale per le correzioni che produce: priorità, responsabili, retest e accettazione documentata del rischio residuo.
Uno ti dice quali porte potrebbero essere aperte, l'altro prova davvero a entrare. Ecco come scegliere tra vulnerability assessment e penetration test, e ogni quanto farli.
Le due espressioni vengono spesso usate come sinonimi, nei preventivi dei fornitori come nei questionari dei clienti. Non lo sono. Il vulnerability assessment cerca in modo ampio le debolezze note dei tuoi sistemi; il penetration test verifica fin dove un attaccante potrebbe spingersi sfruttandole. Scegliere quello sbagliato significa pagare per un risultato che non risponde alla tua domanda: un elenco di centinaia di avvisi quando ti serviva sapere se i dati dei clienti sono raggiungibili, oppure un test approfondito su un'applicazione quando la rete interna non è mai stata nemmeno censita.
In questa guida trovi le definizioni delle fonti di riferimento (NIST e OWASP), una tabella con le differenze, tre situazioni tipo per capire quale test ti serve, le indicazioni sulla frequenza e il legame con la ISO/IEC 27001, la NIS2 e le specifiche dell'ACN. Se vuoi approfondire il test sulle applicazioni web, le sue modalità e la OWASP Top 10, trovi tutto nella nostra guida al WAPT.
Cos'è un vulnerability assessment?
Il vulnerability assessment è una ricerca sistematica delle vulnerabilità note su sistemi, reti e applicazioni. Risponde alla domanda: "dove sono esposto, e quanto?".
Il riferimento più citato è la guida del NIST, l'istituto statunitense per gli standard e la tecnologia, dedicata ai test di sicurezza: la SP 800-115. Nella sezione sulla scansione delle vulnerabilità spiega che gli scanner identificano host, sistemi operativi, applicazioni e porte aperte, e li confrontano con un database di vulnerabilità conosciute. Così trovano versioni obsolete e patch mancanti, oltre a configurazioni errate, e spesso suggeriscono come porvi rimedio. La scansione può partire dalla rete oppure usare credenziali di accesso ai sistemi, che permettono di vedere molto più a fondo.
Cosa trova e cosa non trova
Un vulnerability assessment è ampio ma resta in superficie. Copre molti sistemi in poco tempo, ma si ferma alla possibile esistenza di una falla.
Lo stesso NIST è esplicito sui limiti. Gli scanner hanno un tasso elevato di falsi positivi, cioè segnalano vulnerabilità che non esistono. Si basano su firme e quindi non riconoscono ciò che non è ancora nel loro database. E non dicono quale sia il rischio complessivo della rete: valutano un sistema alla volta. Le guide OWASP aggiungono un limite specifico per le applicazioni web: gli strumenti automatici sono generici, mentre le applicazioni sono quasi sempre costruite su misura, per cui gli errori di logica sfuggono. Uno scanner non sa che un utente del portale clienti non dovrebbe vedere le fatture di un'altra azienda.
Scansione e assessment non sono la stessa cosa
Lanciare uno scanner non è ancora fare un vulnerability assessment. La differenza la fa l'interpretazione dei risultati da parte di qualcuno che conosce reti e sistemi, come raccomanda la stessa SP 800-115.
In pratica, un buon assessment elimina i falsi positivi, ricalcola la gravità in base al contesto (una vulnerabilità critica su un server isolato pesa meno di una media sul sito di e-commerce) e consegna un elenco ordinato per priorità. Il report di uno scanner con trecento righe in rosso, inoltrato così com'è al fornitore IT, quasi sempre finisce in un cassetto. Lo stesso elenco, ridotto a venti interventi con un responsabile e una data, diventa un piano di lavoro.
Cos'è un penetration test?
Il penetration test è un test in cui specialisti simulano un attacco reale, con autorizzazione e regole precise, per capire se e come le difese possono essere aggirate.
La SP 800-115 lo definisce come un test di sicurezza in cui chi valuta imita attacchi reali per individuare i modi di aggirare le protezioni di un'applicazione, di un sistema o di una rete. La parte che fa la differenza è lo sfruttamento: dove lo scanner si limita a dire che una vulnerabilità potrebbe esistere, il penetration test ne conferma l'esistenza provando a sfruttarla. Spesso combina più debolezze minori per ottenere un accesso che nessuna di esse, da sola, consentirebbe. Il risultato non è un elenco, ma un racconto: da dove si è entrati, cosa si è raggiunto, con quale impatto.
Le quattro fasi secondo il NIST
Il NIST descrive il penetration test in quattro fasi: pianificazione, scoperta, attacco e reporting. Nella pianificazione si fissano regole, obiettivi e approvazione della direzione.
La fase di scoperta raccoglie informazioni e individua i bersagli, spesso proprio con scanner di porte e vulnerabilità: per questo un vulnerability assessment è di solito parte del penetration test, non un'alternativa. L'attacco verifica le ipotesi e, quando ottiene nuovi accessi, torna alla scoperta per esplorare ciò che prima era invisibile. Il reporting descrive vulnerabilità, rischi e azioni di mitigazione. Le fasi del test applicativo, con le modalità black-box, grey-box e white-box, sono descritte nella guida al WAPT: qui ci interessa la logica generale.
Perimetro e regole di ingaggio
Un penetration test comporta rischi reali e va autorizzato per iscritto. Il NIST ricorda che usa attacchi veri su sistemi e dati di produzione e che il rischio di danni non è mai del tutto eliminabile.
Per questo la SP 800-115 include un modello di regole di ingaggio. In pratica, prima di iniziare servono almeno: l'elenco esatto di indirizzi, domini e applicazioni nel perimetro, le finestre orarie concordate, cosa è escluso (per esempio test che possono bloccare un servizio), un referente interno raggiungibile durante il test e un accordo su come trattare eventuali dati personali incontrati. Se l'applicazione è ospitata da un provider cloud o gestita da un fornitore, verifica anche che le sue condizioni consentano il test e informalo per tempo.
Penetration test e vulnerability assessment: le differenze in una tabella
La differenza essenziale è tra ampiezza e profondità. Il vulnerability assessment copre molto e scava poco; il penetration test copre meno e va fino in fondo.
Aspetto | Vulnerability assessment | Penetration test |
|---|---|---|
Domanda a cui risponde | Dove sono esposto? | Fin dove arriva un attaccante? |
Metodo | Prevalentemente automatico, con analisi dei risultati | Prevalentemente manuale, con strumenti a supporto |
Sfruttamento delle falle | No, si ferma alla possibile esistenza | Sì, in modo controllato |
Copertura | Ampia: molti sistemi e indirizzi | Mirata: un perimetro definito |
Falsi positivi | Frequenti, vanno filtrati | Rari, perché ogni falla viene verificata |
Errori di logica applicativa | Difficilmente rilevati | Rientrano nell'obiettivo del test |
Impatto sui sistemi | Basso, ma non nullo | Più alto, richiede regole di ingaggio |
Risultato | Elenco di vulnerabilità con gravità e rimedi | Scenari di attacco, impatto dimostrato, priorità |
Frequenza tipica | Regolare e ricorrente | Periodica e legata ai cambiamenti |
Nessuna delle due colonne è "migliore". Il NIST indica come modello un programma che alterna scansioni regolari e penetration test periodici: le prime tengono sotto controllo l'esposizione quotidiana, i secondi verificano che le difese reggano davvero.
Quale test ti serve? Tre situazioni tipo
La scelta dipende dalla domanda a cui devi rispondere, non dal nome del servizio. Ecco tre situazioni frequenti nelle PMI e la risposta più sensata per ciascuna.
Non sai cosa hai esposto: parti dal vulnerability assessment
Prendi un'azienda di distribuzione con 60 dipendenti, un gestionale in sede, un accesso VPN per gli agenti, il sito vetrina e una decina di server tra fisici e virtuali. Nessuno ha mai fatto un censimento completo. Qui un penetration test sarebbe prematuro: prima devi sapere cosa c'è.
Un vulnerability assessment esterno, sugli indirizzi pubblici, e uno interno, con credenziali, fanno emergere la VPN non aggiornata, la stampante di rete con la password di fabbrica, il vecchio server che nessuno ricordava. Il risultato alimenta l'inventario degli asset e il piano delle patch, che sono anche tra le misure minime di cybersecurity da cui ogni PMI dovrebbe partire. Il penetration test arriva dopo, quando le falle più evidenti sono chiuse e vale la pena capire cosa resta.
Hai un'applicazione con dati dei clienti: serve il penetration test
Ora pensa a una software house con un portale in cui i clienti caricano documenti e consultano contratti. Il rischio principale qui non è una patch mancante, ma un errore nei controlli di accesso: un utente che, cambiando un numero nell'indirizzo, apre il fascicolo di un altro.
Questo tipo di falla è proprio ciò che uno scanner non vede e che un penetration test applicativo cerca, soprattutto in modalità grey-box, con credenziali di utenti diversi. È il caso tipico per un WAPT. Un vulnerability assessment sull'infrastruttura che ospita il portale resta utile, ma non risponde alla domanda che conta per i clienti.
Un cliente o un bando ti chiede "un test di sicurezza"
Il terzo caso è il più comune: un cliente, nel suo questionario di sicurezza fornitori, chiede se fai test periodici e di allegare un'evidenza. Prima di comprare qualcosa, chiarisci cosa ti stanno chiedendo.
Leggi la domanda alla lettera. "L'azienda effettua scansioni periodiche delle vulnerabilità?" si soddisfa con un programma di vulnerability assessment documentato. "L'applicazione è stata sottoposta a penetration test da parte di terzi indipendenti?" richiede un penetration test vero, con un report. In entrambi i casi non serve consegnare il report completo: una lettera di sintesi con perimetro, data, metodo e stato delle correzioni basta quasi sempre. Come gestire queste richieste lo spieghiamo nella guida ai questionari di sicurezza dei clienti.
Ogni quanto fare vulnerability assessment e penetration test?
Non esiste una frequenza valida per tutti: la decide il rischio, insieme agli obblighi a cui sei soggetto e ai cambiamenti dei tuoi sistemi. Esistono però riferimenti solidi.
La SP 800-115 osserva che, dato il costo e l'impatto potenziale, un penetration test della rete su base annuale può essere sufficiente, a patto di affiancarlo con attività meno onerose svolte con regolarità, come le scansioni. Aggiunge che un test fotografa la sicurezza in un momento preciso: se i sistemi cambiano spesso, conviene testare più spesso. Le specifiche di base dell'ACN per i soggetti NIS2 essenziali, che vediamo più avanti, chiedono attività periodiche e comunque prima della messa in esercizio dei sistemi rilevanti.
In pratica, un calendario ragionevole per una PMI ha due livelli. Il primo è ricorrente: vulnerability assessment con una cadenza fissa, più frequente sui sistemi esposti su internet, e una scansione mirata ogni volta che esce un avviso di CSIRT Italia su un prodotto che usi. Il secondo è legato agli eventi: penetration test prima del rilascio di una nuova applicazione o di una modifica importante, dopo un incidente e con una periodicità definita per le applicazioni critiche. Qualunque frequenza tu scelga, scrivila nella procedura e rispettala: per un auditor conta che la cadenza sia motivata e mantenuta.
Cosa chiedono ISO 27001, NIS2 e le altre regole?
Nessuna di queste norme ti obbliga a scegliere un test specifico per nome, con un'eccezione importante per i soggetti NIS2 essenziali. Tutte però chiedono di gestire le vulnerabilità e di verificare che le misure funzionino.
ISO/IEC 27001: il controllo 8.8
Nell'Annex A della ISO/IEC 27001:2022 il controllo 8.8 riguarda la gestione delle vulnerabilità tecniche: ottenere informazioni sulle vulnerabilità dei sistemi in uso, valutare l'esposizione dell'organizzazione e prendere misure adeguate. Altri controlli dello stesso tema tecnologico trattano lo sviluppo sicuro e i test di sicurezza delle applicazioni.
La norma non impone né il vulnerability assessment né il penetration test. Lascia a te la scelta, purché coerente con l'analisi dei rischi e con la Dichiarazione di Applicabilità. In audit, quello che si verifica è il processo: da dove arrivano le informazioni sulle vulnerabilità, chi le valuta, con quali tempi si correggono, come si gestisce ciò che non si può correggere subito. Un report di vulnerability assessment con il relativo piano di rientro, o un penetration test con il retest, sono le evidenze più convincenti. Il quadro completo della norma è nella nostra guida alla ISO 27001.
NIS2 e le specifiche di base dell'ACN
La direttiva NIS2, recepita in Italia dal d.lgs. 138/2024, include tra le misure minime la gestione e divulgazione delle vulnerabilità e le procedure per valutare l'efficacia delle misure di sicurezza. Le specifiche di base adottate dall'ACN entrano nel dettaglio e distinguono tra soggetti importanti ed essenziali.
Per entrambi chiedono un piano di gestione delle vulnerabilità approvato dagli organi di amministrazione, il monitoraggio almeno dei canali di CSIRT Italia e la correzione tempestiva delle vulnerabilità, oppure l'accettazione documentata del rischio. Per i soggetti essenziali vanno oltre: sui sistemi rilevanti richiedono attività di identificazione delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test, svolte periodicamente e prima della messa in esercizio, documentate con relazioni che descrivono attività, esiti, vulnerabilità e impatto. È uno dei pochi testi che nomina espressamente i due test. Le specifiche possono essere aggiornate: verifica sempre la versione in vigore sul sito dell'ACN. Per capire se e come la NIS2 ti riguarda, trovi tutto nella pagina dedicata alla NIS2.
GDPR e, per il settore finanziario, DORA
Anche il GDPR entra in gioco. L'articolo 32 chiede a chi tratta dati personali una procedura per testare regolarmente l'efficacia delle misure di sicurezza. Un programma di test documentato è uno dei modi più diretti per dimostrarlo.
Per banche, assicurazioni e altri soggetti finanziari, il regolamento DORA prevede un programma di test che include, tra gli altri, valutazioni e scansioni delle vulnerabilità e penetration test, con test almeno annuali sui sistemi che supportano funzioni essenziali o importanti. Le entità individuate dalle autorità competenti devono inoltre svolgere almeno ogni tre anni test di penetrazione avanzati guidati dalla minaccia (TLPT). Se lavori come fornitore ICT di questi soggetti, aspettati che le loro richieste riflettano questi requisiti.
Dal report alle correzioni: come rendere utili i risultati
Un test vale quanto le correzioni che produce. Il NIST lo dice chiaramente: i risultati vanno presi sul serio, le vulnerabilità mitigate e gli esiti presentati alla direzione.
Il primo passo è la selezione. Ogni vulnerabilità riceve una priorità che tiene conto della gravità tecnica e del contesto: quanto è esposto il sistema, quali dati contiene, se esiste già uno sfruttamento noto. Poi si assegna ogni intervento a una persona con una data. Ciò che non puoi correggere, per esempio un software di macchina che il produttore non aggiorna più, va isolato e il rischio residuo va accettato in modo documentato, non dimenticato.
Il secondo passo è la verifica. Dopo le correzioni serve un retest, almeno sulle vulnerabilità più gravi, per confermare che la falla sia davvero chiusa e che la correzione non ne abbia aperte altre. Senza retest, il report racconta lo stato di un giorno passato.
Il terzo passo è la conservazione delle evidenze. Report, piano di rientro, esito del retest e decisioni di accettazione del rischio sono documenti che servono all'audit ISO, alla NIS2 e ai clienti. Conservali con data, versione e perimetro, e tieni separato il report tecnico completo, da condividere solo con chi deve correggere, dalla sintesi per l'esterno.
Gli errori più frequenti
Alcuni errori si ripetono in quasi tutte le aziende che iniziano. Riconoscerli ti fa risparmiare un giro di test.
Chiamare penetration test una scansione automatica: il report non resiste alla prima domanda di un cliente esperto o di un auditor.
Definire il perimetro in modo vago: il test copre il sito vetrina e lascia fuori l'area riservata, dove stanno i dati.
Testare una volta e mai più: un test di tre anni fa non dice nulla dei sistemi di oggi.
Non fare il retest: la correzione resta un'intenzione, non un fatto verificato.
Trattare il report come un obiettivo: lo scopo è ridurre il rischio, non archiviare un documento.
Come Complaion ti aiuta con vulnerability assessment e penetration test
Complaion ti aiuta a scegliere il test giusto e a farlo diventare parte del tuo sistema di gestione, non un documento isolato.
Il tuo Lead Auditor dedicato parte dall'analisi dei rischi e dagli obblighi che ti riguardano (ISO 27001, NIS2, richieste dei clienti) e ti propone il percorso più adatto: un programma di vulnerability assessment, un penetration test sulle applicazioni critiche o entrambi, con la frequenza motivata da scrivere nella procedura. Quando arriva il report, ti aiuta a collegare rilievi, piano di rientro e accettazione del rischio residuo al controllo 8.8 e alle misure NIS2, così in audit presenti un processo e non un allegato.
La piattaforma raccoglie report, piani di rientro ed esiti dei retest come evidenze, gestisce le procedure in versione controllata e tiene lo scadenziario dei test periodici, così sai quando tocca al prossimo assessment e cosa è ancora aperto. Quando si avvicina l'audit, trovi le evidenze già ordinate. Per le applicazioni web eseguiamo anche il WAPT, il penetration test applicativo, e se stai costruendo il sistema di gestione puoi farlo all'interno del percorso di certificazione ISO 27001. Lavoriamo così con oltre 1.000 clienti. Per capire quale test ti serve davvero, parla con un Lead Auditor.
Domande frequenti su penetration test e vulnerability assessment
Qual è la differenza tra vulnerability assessment e penetration test?
Il vulnerability assessment cerca in modo ampio e prevalentemente automatico le vulnerabilità note di sistemi e applicazioni, e le ordina per gravità. Il penetration test simula un attacco reale e prova a sfruttare le vulnerabilità per capire fin dove arriverebbe un attaccante. Il primo misura l'esposizione, il secondo dimostra l'impatto. Spesso il penetration test include una fase di scansione al suo interno.
Un vulnerability assessment può sostituire un penetration test?
No, perché non sfrutta le vulnerabilità e non rileva bene gli errori di logica delle applicazioni, come un controllo degli accessi sbagliato. Vale anche il contrario: un penetration test su un perimetro limitato non sostituisce scansioni regolari su tutti i sistemi. Le fonti di riferimento, come la guida NIST SP 800-115, suggeriscono di combinare i due approcci.
Ogni quanto va fatto un penetration test?
Dipende dal rischio, dagli obblighi e da quanto cambiano i tuoi sistemi. La guida NIST SP 800-115 osserva che un test annuale della rete può essere sufficiente se affiancato da scansioni regolari. In ogni caso conviene testare prima di mettere in produzione un'applicazione nuova o modificata in modo rilevante, e dopo un incidente. L'importante è che la frequenza sia scritta e rispettata.
Il penetration test è obbligatorio per la ISO 27001?
No, la ISO/IEC 27001 non impone un test specifico. Il controllo 8.8 chiede di gestire le vulnerabilità tecniche: raccogliere informazioni, valutare l'esposizione e intervenire. Il modo lo scegli tu in base all'analisi dei rischi. Un vulnerability assessment periodico o un penetration test con retest sono però evidenze molto efficaci in audit.
La NIS2 obbliga a fare vulnerability assessment o penetration test?
La NIS2 chiede la gestione delle vulnerabilità e la verifica dell'efficacia delle misure. In Italia, le specifiche di base dell'ACN chiedono a tutti i soggetti un piano di gestione delle vulnerabilità. Per i soggetti essenziali richiedono anche, sui sistemi rilevanti, attività che comprendano almeno vulnerability assessment e/o penetration test, periodiche e prima della messa in esercizio. Verifica sempre la versione in vigore delle specifiche sul sito dell'ACN.
Un penetration test può bloccare i sistemi?
Sì, il rischio esiste e non si può eliminare del tutto, come ricorda il NIST. Si riduce con regole di ingaggio scritte: perimetro preciso, finestre orarie, esclusione dei test più invasivi sui sistemi critici, un referente interno raggiungibile. Su applicazioni molto delicate si può testare un ambiente di collaudo identico alla produzione. Anche il vulnerability assessment ha un impatto basso, ma non nullo sulla rete.
Posso dare ai clienti il report del penetration test?
Meglio di no, almeno non quello completo: descrive le tue vulnerabilità in dettaglio ed è un documento utile a un attaccante. Ai clienti basta di solito una lettera di sintesi con perimetro, data, metodo e stato delle correzioni. Se il cliente ha un'esigenza particolare, valuta una condivisione protetta da un accordo di riservatezza o una verifica in videochiamata.
