Un penetration test è una verifica di sicurezza autorizzata in cui un professionista prova a superare le difese di un sistema, di un’applicazione o di un’infrastruttura entro un perimetro concordato.
La parte importante della definizione non è soltanto “simulare un attacco”. Un pentest serve a capire se una debolezza può trasformarsi in un percorso di compromissione concreto, quali conseguenze potrebbe produrre e quali correzioni meritano priorità.
Per questo non va confuso con una scansione automatica delle vulnerabilità e neppure considerato una certificazione assoluta della sicurezza. Il risultato descrive ciò che è stato verificato in uno scope, in un periodo e con determinate condizioni di test.
Cos’è un penetration test e qual è il suo vero obiettivo
Il National Cyber Security Centre britannico definisce il penetration testing come un metodo per ottenere assurance sulla sicurezza di un sistema tentando di superarne alcune o tutte le difese con strumenti e tecniche che potrebbe utilizzare anche un avversario.
La parola decisiva è assurance.
Un penetration test non cerca soltanto di costruire un elenco di configurazioni imperfette. Cerca di stabilire quali debolezze abbiano conseguenze realistiche quando vengono considerate nel contesto del sistema.
Una vulnerabilità che isolatamente sembra poco rilevante, per esempio, può diventare più seria se permette di raggiungere un secondo componente, aumentare i privilegi o accedere a informazioni che rendono possibile un’altra azione.
È qui che il pentest aggiunge qualcosa rispetto alla semplice individuazione di vulnerabilità.
Un attacco simulato, ma con autorizzazione e scope definiti
Alcune tecniche utilizzate durante un penetration test possono assomigliare a quelle impiegate in un attacco reale. Cambiano però il contesto, il mandato e i limiti.
Chi esegue il test deve conoscere quali sistemi può verificare, quali attività sono consentite, quali sono escluse, in quale finestra temporale può operare e chi contattare se emerge un problema critico.
Il concetto è lo stesso che distingue l’hacking etico da un accesso non autorizzato: la tecnica da sola non stabilisce la legittimità dell’attività.
Lo scope è anche un limite tecnico del risultato. Se un’applicazione è stata testata ma un servizio esterno, una rete interna o una particolare API sono rimasti fuori dal perimetro, il report non può essere esteso automaticamente anche a quei componenti.
Cosa può dimostrare un penetration test
Un buon test può fornire evidenza concreta su domande come queste: una vulnerabilità è realmente sfruttabile nelle condizioni osservate? Può essere concatenata con altre debolezze? Quali dati, privilegi o sistemi potrebbe raggiungere un attaccante? Quali controlli riescono a fermare o limitare il percorso?
Questo cambia anche la priorità delle correzioni.
Due finding con la stessa classificazione teorica possono avere un’importanza molto diversa se uno non porta oltre un controllo compensativo mentre l’altro apre un percorso verso un account privilegiato o dati sensibili.
Il valore del penetration testing sta quindi nella relazione:
debolezza → sfruttabilità → percorso → impatto → correzione
Cosa non può dimostrare
Un pentest non dimostra che un sistema sia “sicuro” in senso assoluto.
Un risultato senza vulnerabilità critiche significa che, entro il perimetro, le condizioni e il tempo del test, non sono state dimostrate compromissioni di quel tipo. Non significa che non esistano altre debolezze.
Il sistema può cambiare il giorno successivo con una nuova release, una configurazione diversa, un account aggiunto o una vulnerabilità appena scoperta. Possono inoltre esistere componenti fuori scope o percorsi che il test non era progettato per verificare.
Anche il NCSC mette esplicitamente in guardia dall’idea del penetration test come soluzione capace da sola di garantire la sicurezza: deve essere integrato in un processo più ampio di gestione delle vulnerabilità.
Penetration test e vulnerability assessment: qual è la differenza
Penetration test e vulnerability assessment sono collegati, ma non rispondono alla stessa domanda.
Il vulnerability assessment mira soprattutto a trovare e classificare le debolezze presenti in un ambiente. Il pentest aggiunge una verifica più selettiva della loro sfruttabilità e delle conseguenze che possono produrre.
La distinzione non implica che uno sia “migliore” dell’altro. Sono strumenti diversi.
| Aspetto | Vulnerability assessment | Penetration test |
|---|---|---|
| Domanda principale | Quali vulnerabilità sono presenti? | Quali debolezze possono diventare un attacco concreto? |
| Copertura | Tendenzialmente ampia | Più focalizzata e profonda |
| Automazione | Spesso rilevante | Strumenti + analisi manuale |
| Exploitation controllata | Non è normalmente il fulcro | Può essere utilizzata entro lo scope |
| Output | Finding e priorità | Finding, evidenze, percorsi e impatto |
| Uso ideale | Gestione continuativa delle vulnerabilità | Validazione di rischio e controlli |
La NIST SP 800-115 tratta infatti penetration testing, vulnerability scanning e altre tecniche come strumenti distinti di security testing e assessment, ciascuno con vantaggi e limiti propri.
Il vulnerability assessment cerca ampiezza e priorità
Un vulnerability assessment può coprire molti host, servizi o componenti e individuare versioni vulnerabili, configurazioni deboli, esposizioni note e altre anomalie.
Gli scanner sono particolarmente utili in questa fase perché permettono di raccogliere rapidamente una grande quantità di segnali.
Un esempio specifico per WordPress è WPScan, che può enumerare componenti ed evidenziare vulnerabilità note o configurazioni esposte. È uno strumento prezioso per l’assessment, ma l’esecuzione di uno scanner non trasforma automaticamente l’attività in un penetration test completo.
Il penetration test verifica sfruttabilità, percorsi e impatto
Nel pentest il professionista seleziona le debolezze più significative e cerca di capire cosa permettono realmente di fare.
La differenza emerge soprattutto quando più elementi apparentemente secondari possono essere concatenati. Una configurazione informativa, una gestione imperfetta delle sessioni e un controllo di autorizzazione debole potrebbero assumere un significato molto diverso se insieme permettono di raggiungere dati o privilegi che singolarmente sembravano protetti.
Il penetration tester deve quindi interpretare ciò che osserva, non limitarsi a riportare l’output di un tool.
Quando serve uno, quando serve l’altro e quando usarli insieme
Se l’obiettivo è controllare continuamente un ambiente ampio e individuare vulnerabilità note, il vulnerability management e gli assessment periodici sono la base.
Se invece vuoi sapere quanto sia concretamente sfruttabile un rischio, quali controlli resistano a un attacco controllato oppure quali conseguenze possa produrre una specifica catena di debolezze, il penetration test fornisce un’altra qualità di evidenza.
In molte organizzazioni le due attività funzionano meglio insieme: l’assessment amplia la visibilità, il pentest approfondisce le aree nelle quali è necessario validare il rischio.
Come si svolge un penetration test
Non esiste una singola sequenza valida per ogni incarico. Un’applicazione web, una rete interna e un ambiente cloud richiedono scope e tecniche differenti.
La logica generale, però, è abbastanza stabile:
scope → ricognizione → analisi → verifica controllata → evidenza → report → remediation → retest
La OWASP Web Security Testing Guide 4.2 offre un riferimento strutturato per il testing di applicazioni e servizi web. OWASP indica attualmente la 4.2 come release stabile, mentre la versione 5.0 è ancora in sviluppo.
Scoping, obiettivi e rules of engagement
La prima fase non consiste nell’avviare uno scanner.
Bisogna stabilire cosa deve essere verificato e perché.
Lo scope può includere domini, indirizzi IP, applicazioni, API, reti, account di test o ambienti specifici. Deve chiarire anche cosa resta escluso, quali tecniche sono consentite, quali potrebbero avere un impatto operativo e cosa fare se durante il test emerge una condizione critica.
Le rules of engagement traducono questi elementi in regole operative: orari, contatti, limiti, procedure di escalation, gestione dei dati, condizioni per interrompere il test.
Uno scope generico come “testate la nostra infrastruttura” è debole perché rende difficile capire sia cosa debba fare il penetration tester sia cosa significherà il risultato finale.
Ricognizione e mappatura della superficie
Una volta definito il perimetro, il tester cerca di capire come è composto il target.
Può analizzare servizi esposti, tecnologie, endpoint, funzioni applicative, meccanismi di autenticazione, ruoli utente e relazioni tra componenti.
La ricognizione non serve a raccogliere informazioni per accumularle nel report. Serve a costruire una mappa abbastanza precisa da formulare ipotesi verificabili.
Anche una distribuzione specializzata come Kali Linux può supportare varie attività di reconnaissance, enumeration e security testing, ma la presenza di molti strumenti non sostituisce la metodologia. Il professionista deve sapere quale domanda sta cercando di risolvere prima di scegliere il tool.
Analisi e validazione controllata delle vulnerabilità
A questo punto entrano in gioco scanner, controlli manuali, analisi delle configurazioni e verifiche specifiche per il target.
Nel caso di una web application possono essere esaminati autenticazione, autorizzazione, gestione delle sessioni, input, business logic, configurazione e altri controlli pertinenti.
La metodologia OWASP non deve essere interpretata come una checklist da completare meccanicamente. Il tipo di applicazione, l’architettura, gli utenti e gli obiettivi del test determinano quali verifiche abbiano realmente senso.
Quando viene individuata una debolezza, il passo successivo è capire se sia riproducibile e quali conseguenze produca, evitando azioni non necessarie rispetto agli obiettivi concordati.
Verifica dell’impatto e raccolta delle evidenze
Dimostrare una vulnerabilità non significa massimizzare il danno.
Un tester dovrebbe raccogliere l’evidenza minima sufficiente per dimostrare il rischio entro le condizioni dell’incarico. Se è già possibile provare che un controllo è superabile e che permette di accedere a una determinata risorsa, spesso non serve spingersi oltre.
Le evidenze devono consentire di ricostruire ciò che è successo: componente interessato, precondizioni, comportamento osservato, impatto, eventuale percorso seguito e informazioni necessarie per riprodurre il problema in un ambiente controllato.
Questo è il punto nel quale il pentest smette di essere una semplice ricerca di vulnerabilità e diventa uno strumento decisionale.
Report, remediation e retest
Il report è parte del test, non il documento che si produce quando “la parte tecnica è finita”.
Deve trasformare l’evidenza in qualcosa che il team possa utilizzare per correggere i problemi.
Un finding utile chiarisce almeno il contesto, il rischio, le evidenze disponibili, l’impatto e le indicazioni per la remediation. La priorità non dovrebbe dipendere esclusivamente da un punteggio numerico: asset, esposizione, controlli compensativi e conseguenze reali possono cambiare la decisione.
Dopo la correzione, il retest verifica che il problema sia stato eliminato e che la modifica non lasci aperto lo stesso percorso in un’altra forma.
Senza questo passaggio, “abbiamo corretto il finding” rimane una dichiarazione; con il retest diventa una condizione verificata.
Tipi di penetration test: due classificazioni da non confondere
Uno degli errori più comuni è mettere nello stesso elenco black box, grey box, web application e network penetration test.
Non appartengono alla stessa classificazione.
Black, grey e white box descrivono principalmente quante informazioni o accessi vengono forniti al tester.
Web application, API, network, cloud e wireless descrivono invece che cosa viene testato.
Un web application penetration test, quindi, può essere black box, grey box oppure white box.
Black box, grey box e white box: cambia ciò che il tester conosce
| Modalità | Informazioni iniziali | Scenario utile |
|---|---|---|
| Black box | Minime | Osservare ciò che può scoprire un soggetto esterno partendo da poche informazioni |
| Grey box | Parziali, spesso con credenziali o ruolo definito | Testare scenari realistici con un determinato livello di accesso |
| White box | Ampie informazioni tecniche e accessi | Massimizzare visibilità e profondità su componenti specifici |
Nessuna delle tre modalità è universalmente superiore.
Un black box può essere utile per osservare la superficie esterna, ma parte del tempo viene inevitabilmente spesa nella discovery. Un white box può consentire una copertura molto più approfondita, ma risponde a una domanda differente.
Il modello va scelto in funzione dell’obiettivo del test, non perché “black box sembra più realistico”.
Web application e API penetration test
Le applicazioni web hanno una superficie che comprende interfaccia, backend, autenticazione, autorizzazioni, sessioni, API, dipendenze e logica applicativa.
Un web application penetration test cerca di capire come questi elementi reagiscono a input e comportamenti non previsti, con particolare attenzione alle condizioni che permettono di superare controlli di sicurezza.
Le API meritano spesso uno scope esplicito. Il fatto che un’applicazione utilizzi un’API non significa automaticamente che ogni endpoint, ruolo o integrazione sia stato coperto dal test dell’interfaccia web.
Per un sito WordPress, un pentest rappresenta inoltre solo una parte del lavoro complessivo. Aggiornamenti, privilegi, configurazione, backup, hardening e monitoraggio appartengono al processo più ampio di sicurezza WordPress.
Network, cloud e wireless penetration test
Un network penetration test concentra l’attenzione su host, servizi, segmentazione, configurazioni, accessi e relazioni tra sistemi.
Negli ambienti cloud il perimetro cambia: identità, ruoli, policy, servizi gestiti, storage, configurazioni e relazioni tra account possono essere altrettanto importanti dei singoli server.
Anche il wireless testing ha un proprio contesto, perché coinvolge tecnologie, autenticazione e superfici differenti.
La parola “penetration test” da sola, quindi, non descrive abbastanza bene l’incarico. Serve sempre indicare almeno target, obiettivo e modalità di accesso.
Perché target e modalità di accesso sono due scelte diverse
Immagina due test sulla stessa applicazione.
Nel primo il tester riceve soltanto l’URL pubblico e lavora in black box. Nel secondo dispone anche di account con ruoli differenti, informazioni sull’architettura e documentazione delle API.
Il target è identico: l’applicazione.
La profondità, le precondizioni e le domande alle quali il test può rispondere sono molto diverse.
Separare questi due assi rende anche più semplice confrontare preventivi e report: invece di chiedere genericamente “un pentest”, puoi definire cosa deve essere testato e con quale livello di conoscenza.
Chi esegue un penetration test
Il professionista che conduce queste verifiche viene normalmente indicato come penetration tester, pentester o security tester.
La capacità di utilizzare tool offensivi è solo una parte del lavoro. Servono conoscenze di reti, sistemi, applicazioni, autenticazione, protocolli e sicurezza, ma anche capacità di definire ipotesi, raccogliere evidenze e comunicare il rischio.
Un pentest eccellente eseguito tecnicamente ma tradotto in un report incomprensibile perde gran parte del suo valore.
Cosa fa un penetration tester
Il penetration tester parte dall’obiettivo concordato, analizza la superficie disponibile, individua possibili debolezze e decide quali meritino una verifica più approfondita.
Deve inoltre sapere quando fermarsi.
Se una determinata prova ha già dimostrato il rischio, continuare senza una ragione può aumentare l’impatto operativo senza produrre informazione utile.
Il lavoro richiede quindi judgment oltre alla competenza tecnica: selezionare le verifiche, distinguere falsi positivi da problemi reali, capire le relazioni fra finding e descrivere il risultato con precisione.
Penetration test e hacking etico non sono sinonimi perfetti
L’hacking etico è un concetto più ampio.
Può comprendere penetration testing, ricerca di vulnerabilità autorizzata, security assessment e altre attività svolte con finalità difensive e nel rispetto del perimetro concordato.
Il penetration test è invece un incarico con obiettivi e scope definiti.
Dire che un pentester opera nell’ambito dell’ethical hacking può essere corretto; ridurre tutto l’hacking etico al penetration testing lo è molto meno.
Pentest, red team e threat-led penetration testing: dove cambia lo scenario
Pentest e red team exercise possono utilizzare alcune tecniche simili, ma normalmente hanno obiettivi differenti.
Il pentest tende a concentrarsi su un perimetro tecnico e sulla validazione di vulnerabilità e controlli. Un’attività red team può invece simulare un avversario con obiettivi più ampi e valutare anche capacità di rilevamento, risposta, processi e persone.
La terminologia varia tra provider, quindi il nome del servizio non basta: scope e obiettivi devono essere letti concretamente.
Ancora più specifico è il Threat-Led Penetration Testing previsto da DORA. Il Regolamento delegato UE 2025/1190 stabilisce criteri e requisiti per il TLPT applicabile alle entità finanziarie identificate secondo il quadro normativo, disciplinando scope, metodologia, fasi, risultati, remediation e altri aspetti.
Questo non significa che ogni normale penetration test aziendale sia un TLPT e neppure che DORA imponga lo stesso test indistintamente a qualsiasi organizzazione.
Quando ha senso fare un penetration test
Non esiste un intervallo universale valido per tutte le aziende.
Un ecommerce pubblico, un’applicazione interna, una piattaforma finanziaria e un piccolo sito informativo hanno superfici, minacce e conseguenze molto differenti.
La frequenza dovrebbe derivare dal rischio e dai cambiamenti reali, non da una regola editoriale del tipo “fai un pentest ogni X mesi”.
Dopo cambiamenti rilevanti o prima di esporre sistemi critici
Una nuova applicazione, una modifica significativa dell’architettura, l’introduzione di funzioni sensibili o l’esposizione di nuovi servizi possono giustificare una verifica.
Il punto non è testare ogni modifica minore.
Il punto è riconoscere quando cambia materialmente la superficie o il possibile impatto di una compromissione.
Un pentest può essere particolarmente utile prima di affidare a un sistema funzioni critiche o dopo trasformazioni che rendono poco rappresentativo un precedente assessment.
Quando serve validare un rischio già individuato
Un vulnerability assessment, una revisione del codice, un audit o un incidente possono far emergere un problema che non è ancora ben compreso dal punto di vista dell’impatto.
Qui il pentest può rispondere a una domanda più precisa: questa debolezza apre realmente un percorso utilizzabile e fino a dove conduce?
Per un sito web questo lavoro non sostituisce un audit della sicurezza, che può avere un perimetro più ampio di configurazione, aggiornamenti, accessi, backup e controlli preventivi.
Compliance e requisiti normativi: evitare le generalizzazioni
Penetration test e security assessment possono comparire in standard, contratti, policy interne o regimi normativi.
Questo, però, non permette di affermare genericamente che “un pentest rende compliant” oppure che qualsiasi azienda debba effettuare lo stesso test con la stessa frequenza.
Prima bisogna identificare quale requisito si applica, a quale organizzazione, a quale sistema, secondo quale metodologia e con quali evidenze richieste.
Anche quando il test è obbligatorio, superarlo non equivale automaticamente a dimostrare la sicurezza complessiva dell’organizzazione.
Perché non esiste una frequenza corretta per ogni organizzazione
La frequenza può dipendere da criticità degli asset, cambiamenti applicativi, esposizione, minacce, obblighi specifici e maturità del vulnerability management.
Un ambiente che cambia ogni settimana non può essere trattato come un sistema stabile modificato raramente.
Allo stesso modo, un penetration test ripetuto periodicamente sullo stesso scope ma scollegato dai cambiamenti e dalle remediation rischia di trasformarsi in una fotografia rituale invece che in uno strumento di gestione del rischio.
Come valutare un penetration test prima di affidare l’incarico
La qualità dell’incarico si decide in buona parte prima che inizi la parte tecnica.
Un preventivo che promette genericamente “scansione completa e penetration test” dice poco se non chiarisce cosa verrà verificato, con quale profondità e quale risultato verrà consegnato.
Il NCSC propone un modello di engagement che comprende contatto iniziale, scoping, testing, reporting e follow-up. È una buona traccia anche per capire quali domande fare a un fornitore prima di affidargli il lavoro.
Scope, esclusioni e responsabilità devono essere scritti prima
Il documento di incarico dovrebbe identificare gli asset inclusi e quelli esclusi, le finestre di test, gli account disponibili, i limiti tecnici, i contatti e le condizioni nelle quali interrompere o modificare l’attività.
Sono importanti anche le dipendenze da fornitori terzi.
Avere l’autorizzazione sul proprio sistema non significa necessariamente poter sottoporre a qualunque tecnica infrastrutture che appartengono a un provider esterno.
Uno scope chiaro protegge quindi il cliente, il tester e l’affidabilità del risultato.
Metodologia e competenze contano più della lista dei tool
Nmap, Burp Suite, Metasploit, scanner e distribuzioni specializzate possono essere strumenti validi. Una lunga lista di software nel preventivo, però, non dimostra automaticamente la qualità del test.
La domanda migliore è: come verranno scelti i controlli e come verranno validati i finding?
Un professionista dovrebbe riuscire a spiegare metodologia, livello di verifica manuale, gestione dei falsi positivi, modalità di raccolta delle evidenze e criteri utilizzati per fermare una prova quando l’impatto è già dimostrato.
Gli strumenti cambiano. Il ragionamento che collega evidenza tecnica e rischio è ciò che rende utile il lavoro.
Da cosa dipendono durata e costo
Non esiste un prezzo sensato senza conoscere il perimetro.
Durata e costo possono cambiare in base al numero di applicazioni o asset, quantità di ruoli utente, complessità delle API, modello black/grey/white box, profondità richiesta, tecnologia, necessità di test in finestre specifiche e attività di retest.
Anche il reporting incide: un elenco di output grezzi richiede un lavoro molto diverso da un report con evidenze validate, impatto, priorità e indicazioni utilizzabili dal team tecnico.
Per questo confrontare due preventivi soltanto sul prezzo senza normalizzare lo scope può significare confrontare servizi completamente differenti.
Cosa deve contenere un report realmente utilizzabile
Un report utile deve permettere sia al responsabile del rischio sia a chi correggerà tecnicamente il problema di capire cosa fare.
Per ogni finding materiale servono contesto, asset coinvolto, precondizioni, evidenza, impatto e indicazione di remediation.
È utile distinguere anche ciò che non è stato testato. Le esclusioni non sono una nota burocratica: delimitano la validità delle conclusioni.
Infine, un buon report dovrebbe rendere riconoscibili le catene di attacco. Se tre finding diventano critici soltanto quando sono combinati, presentarli come tre righe indipendenti può nascondere il rischio reale.
Perché remediation e retest fanno parte del risultato
Il test crea valore soltanto se cambia qualcosa.
Dopo il report, i finding devono essere assegnati, corretti o gestiti consapevolmente. Le correzioni più importanti meritano poi una nuova verifica.
Il retest non deve ripetere necessariamente l’intero penetration test: può essere focalizzato sui problemi corretti e sui percorsi che dipendevano da essi.
La relazione finale diventa quindi:
finding → decisione → remediation → retest → evidenza della chiusura
È molto più utile di un PDF archiviato fino al penetration test successivo.
Conclusione
Un penetration test ha valore quando risponde a una domanda precisa: quali debolezze possono trasformarsi, entro un perimetro autorizzato, in un percorso di compromissione concreto e con quale impatto?
Per arrivare a questa risposta non basta eseguire uno scanner. Servono scope, metodologia, interpretazione, verifiche controllate, evidenze e un report utilizzabile.
Se devi scegliere tra vulnerability assessment e pentest, parti dall’obiettivo. Il primo è particolarmente utile per mantenere visibilità ampia sulle vulnerabilità; il secondo quando devi verificare sfruttabilità, percorsi e conseguenze reali.
E se devi commissionare il test, non partire dalla lista dei tool o dal prezzo. Parti da target, obiettivo, modalità di accesso, esclusioni, reporting e retest. Sono questi elementi a determinare che cosa potrà davvero dirti il risultato.