Che differenza c'è tra vulnerability assessment e penetration test?

Vulnerability assessment e penetration test sono due attività distinte che vengono vendute come se fossero la stessa. Il vulnerability assessment è una verifica in larga parte automatica: uno strumento interroga sistemi, servizi e applicazioni, confronta versioni e configurazioni con basi dati di vulnerabilità note e restituisce un elenco con una classificazione di gravità. È ampio, ripetibile e poco costoso, e produce un inventario, non una prova. Il penetration test è un'attività manuale condotta da persone che, dentro un perimetro autorizzato per iscritto, provano a sfruttare quello che trovano e a concatenare più debolezze fino a un impatto reale: leggere dati che non dovrebbero vedere, diventare amministratori, arrivare da un servizio esposto a un archivio interno. Il primo dice cosa potrebbe essere sfruttabile, il secondo dimostra cosa lo è. Sulla sovrapposizione fra i due nomi si regge buona parte dell'offerta di sicurezza a basso prezzo rivolta alle imprese italiane, e distinguerli è il modo più rapido per capire cosa si sta comprando.

Chiamare pentest una scansione

È la scorrettezza commerciale più diffusa del settore, e funziona perché il cliente non ha modo di distinguere i due esiti. Si lancia uno scanner, si esporta il rapporto con la copertina del fornitore e si fattura come test di intrusione. Il segnale è quasi sempre riconoscibile: il documento elenca centinaia di voci ordinate per punteggio, ogni voce ha una descrizione generica identica a quella della base dati pubblica, e non c'è una sola pagina che racconti un percorso. Un test vero documenta i percorsi tentati e l'esito di ognuno: sono partito da qui, ho ottenuto questo, l'ho usato per arrivare là; e quest'altra strada l'ho provata senza riuscirci, per un motivo che scrivo. Il criterio non è trovare una catena sfruttabile: su un perimetro tenuto bene un test onesto può chiudersi senza trovarne nessuna. Ma se nel documento non ci sono né catene né tentativi falliti, allora nessuno ha davvero attaccato.

Cosa serve davvero per un pentest formale

Non basta una persona capace. Serve una società con un metodo dichiarato e verificabile, riferito a uno standard pubblico come la NIST SP 800-115 o le guide di test OWASP, un mandato scritto che definisca perimetro, finestre temporali e azioni vietate, e una copertura assicurativa professionale, perché l'attività può interrompere un servizio in produzione e la responsabilità va allocata prima e non dopo. Servono inoltre le competenze individuali documentate del gruppo che opera, la gestione cifrata delle prove raccolte, e un retest incluso: senza la verifica delle correzioni il rapporto è una fotografia di una giornata.

Quando l'uno è spreco e l'altro è teatro

Un penetration test su un'infrastruttura che non ha mai fatto un assessment è denaro speso male: i professionisti passeranno i primi giorni a trovare aggiornamenti mancanti che uno strumento avrebbe elencato in due ore, e il rapporto finale confermerà l'ovvio. All'opposto, un assessment ripetuto ogni trimestre per anni su un'applicazione che gestisce pagamenti, senza nessuno che provi la logica applicativa, lascia scoperta l'intera classe di difetti che gli scanner non vedono, quelli di autorizzazione e di processo. Il pentest diventa teatro quando il perimetro è ridotto a ciò che si sa già sicuro, quando il fornitore riceve un ambiente di prova ripulito e non rappresentativo, o quando l'obiettivo dichiarato è l'attestato da allegare a un questionario.

Il caso di un fornitore industriale

Un'azienda che produce componenti per l'automotive riceve dal cliente finale la richiesta di un penetration test annuale. Il primo anno acquista al prezzo più basso e ottiene ottanta pagine di scansione. Il secondo anno cambia impostazione: assessment continuo sull'intera superficie con correzione tracciata, e un test manuale limitato a due obiettivi, il portale di scambio documenti con i clienti e il percorso dalla rete d'ufficio verso quella di stabilimento. Il secondo esercizio costa meno del primo e produce due catene di attacco reali, una delle quali porta a rivedere la segmentazione di rete.

Perché conta per chi decide

La sequenza corretta è assessment ricorrente dentro il ciclo di sviluppo e di gestione, quindi in logica DevSecOps e non come evento annuale, e test manuale mirato sui pochi percorsi che, se sfruttati, fermano l'azienda. Sulle richieste che arrivano dalla catena di fornitura o dal perimetro NIS2, la domanda da porre a un fornitore non è il prezzo della giornata ma tre cose: quale standard di metodo segue, cosa contiene il mandato, e se il retest è compreso.