Gestione delle vulnerabilità e pentest rispondono a domande diverse. La gestione delle vulnerabilità è un processo continuo che scopre, prioritizza e corregge falle note su larga scala. Il pentest è una valutazione puntuale che sfrutta le falle — note o meno — per provare l'impatto reale. Uno copre l'ampiezza; l'altro, la profondità. I programmi maturi usano entrambi.
Confondere i due è una delle cause più comuni di budget di sicurezza speso male. Un'azienda esegue uno scanner, riceve un report con migliaia di voci e crede di aver fatto un "pentest". Un'altra acquista un penetration test annuale e presume di essere coperta per tutto l'anno. Nessuna delle due sbaglia sullo strumento usato — sbaglia su ciò che quello strumento dimostra. Questo articolo separa i concetti e mostra come inserirli in un unico programma.
Che cos'è la gestione delle vulnerabilità?
La gestione delle vulnerabilità è il ciclo operativo di identificare, classificare, prioritizzare, correggere e verificare le falle note in tutto il parco tecnologico. È continua per definizione: nuovi asset entrano in produzione, nuove CVE vengono pubblicate ogni giorno e le configurazioni cambiano. Un processo maturo percorre queste fasi in modo ricorrente:
- Scoperta e inventario — mappare asset, servizi esposti, versioni software e dipendenze. Senza un inventario affidabile non c'è gestione delle vulnerabilità, solo scansioni alla cieca.
- Scansione — scanner autenticati e non autenticati confrontano ciò che esiste nell'ambiente con i database di vulnerabilità note (CVE) e le regole di configurazione.
- Prioritizzazione — non tutte le falle contano allo stesso modo. La prioritizzazione combina gravità tecnica (CVSS), probabilità di sfruttamento (per esempio, indicatori come EPSS e la presenza nei cataloghi di sfruttamento attivo) e contesto dell'asset: una voce di gravità media su un server di pagamento esposto può superare una alta su una postazione isolata.
- Remediation — applicare correzioni, modificare configurazioni o mitigare il rischio con controlli compensativi quando la patch non è praticabile.
- Verifica — rieseguire la scansione per confermare che la correzione abbia avuto effetto e non abbia introdotto regressioni.
Ciò che la gestione delle vulnerabilità fa bene è copertura e velocità. Vede l'intero ambiente in cicli brevi e segnala rapidamente quando emerge una nuova falla critica. Ciò che non fa è provare che una falla sia davvero sfruttabile nel vostro contesto, né concatenare più debolezze minori in una compromissione reale. Gli scanner generano falsi positivi e, soprattutto, non comprendono la logica di business.
Che cos'è un pentest?
Un pentest, o penetration test, è una valutazione condotta da specialisti che sfruttano attivamente le falle di un bersaglio definito per dimostrare un impatto concreto. Invece di elencare ciò che potrebbe andare storto, il pentest mostra ciò che va storto: fin dove arriva un attaccante, quali dati raggiunge e cosa riesce a fare con quell'accesso.
La differenza centrale è il metodo. Uno scanner correla versioni e firme; un pentester ragiona come un avversario. Concatena le falle — combina una configurazione debole con una credenziale riutilizzata e una falla di autorizzazione per raggiungere un obiettivo — e mette alla prova la logica di business, terreno su cui gli scanner sono ciechi: abusare di un flusso di checkout, manipolare un parametro di autorizzazione, aggirare una regola di approvazione.
I pentest si organizzano per bersaglio e per livello di conoscenza fornito al team. Tra le modalità più richieste ci sono il pentest di rete, il pentest di API, il pentest cloud e il pentest mobile, oltre agli esercizi di Red Team con obiettivi definiti che misurano rilevamento e risposta. Ogni ingaggio termina con risultati prioritizzati, proof of concept riproducibile e raccomandazioni di correzione.
Ciò che il pentest fa bene è profondità ed evidenza. Convalida lo sfruttamento reale, rivela catene di attacco che nessuno scanner costruisce e traduce il rischio tecnico in impatto di business. Ciò che non fa è coprire l'intero ambiente in modo continuo: è un'istantanea di un perimetro specifico in un momento specifico.
Qual è la differenza tra gestione delle vulnerabilità e pentest?
La tabella seguente riassume gli assi che più spesso confondono le due pratiche.
| Criterio | Gestione delle vulnerabilità | Pentest |
|---|---|---|
| Obiettivo | Trovare e correggere falle note su larga scala | Provare l'impatto sfruttando le falle in profondità |
| Copertura | Ampia — tutto l'ambiente | Focalizzata — perimetro definito |
| Frequenza | Continua (scansioni ricorrenti) | Puntuale (per progetto o finestra) |
| Metodo | Automatizzato, basato su firme e CVE | Manuale e creativo, condotto da specialisti |
| Concatena le falle | No | Sì |
| Testa la logica di business | No | Sì |
| Falsi positivi | Comuni, richiedono triage | Rari — i risultati sono convalidati |
| Proof of concept | No | Sì |
| Risultato | Elenco prioritizzato di vulnerabilità | Catene di attacco con impatto dimostrato |
| Costo per ciclo | Minore, ricorrente | Maggiore, concentrato |
Nessuna colonna è "migliore". Misurano cose diverse. La gestione delle vulnerabilità risponde a "dove sono oggi le mie falle note?". Il pentest risponde a "cosa riesce davvero a fare un attaccante con ciò che esiste qui?".
Con quale frequenza eseguire ciascuno?
La gestione delle vulnerabilità è continua — è la sua natura. In pratica significa di solito scansioni autenticate in cicli brevi (mensile è una soglia minima ragionevole per molti ambienti), scansioni non autenticate del perimetro esterno con frequenza ancora maggiore, e verifica ogni volta che c'è un cambiamento significativo: un nuovo sistema in produzione, una modifica di architettura o la pubblicazione di una CVE critica che riguarda il vostro stack.
Il pentest è periodico e guidato dagli eventi. La buona pratica combina una cadenza di calendario con dei trigger:
- Annualmente, come minimo, per i sistemi critici e il perimetro esposto.
- Dopo cambiamenti rilevanti — una nuova applicazione, una revisione dell'architettura, una migrazione al cloud o l'esposizione di una nuova API.
- Prima di traguardi di business — il lancio di un prodotto, un audit, una due diligence di acquisizione.
I requisiti normativi e contrattuali definiscono spesso la cadenza minima. Il PCI DSS, per esempio, richiede scansioni di vulnerabilità interne ed esterne almeno trimestrali (quelle esterne tramite ASV) e penetration test almeno annuali, oltre a ripetizioni dopo cambiamenti significativi — un caso chiaro in cui i due processi sono obbligatori e complementari. Nel settore finanziario brasiliano, le risoluzioni BACEN/CMN sulla sicurezza informatica, inclusa la 4.893, trattano gestione delle vulnerabilità e test come parte di un programma continuo di resilienza. Verificate sempre la norma applicabile al vostro settore prima di fissare una cadenza.
Uno sostituisce l'altro?
No. Trattare uno come sostituto dell'altro lascia lacune prevedibili, ed è qui che la maggior parte dei programmi fallisce:
- Solo gestione delle vulnerabilità — vedete le falle note, ma non sapete mai se sono sfruttabili nel vostro contesto né come si concatenano. Le falle di logica di business e di autorizzazione passano inosservate, perché nessuno scanner le comprende. Il report ha volume ma non impatto dimostrato, e la prioritizzazione diventa un gioco di ipotesi.
- Solo pentest — avete profondità una o due volte l'anno, ma l'ambiente cambia ogni giorno. Tra un test e l'altro emergono nuove CVE, nuovi asset entrano in produzione e la superficie di attacco cresce senza monitoraggio. L'istantanea invecchia in fretta.
I due processi si rafforzano in un ciclo. La gestione delle vulnerabilità riduce il rumore: quando il pentester arriva, il "di base" è già corretto, e il test si concentra su ciò che richiede intelligenza umana — catene di attacco, logica di business, difetti di progettazione. Il pentest, a sua volta, calibra la gestione delle vulnerabilità: provando quali falle contano davvero nel vostro ambiente, mostra dove la prioritizzazione automatica sbagliava e aiuta a mettere a punto ciò che merita attenzione urgente. In una pipeline DevSecOps, la scansione continua entra nel CI/CD e il pentest convalida le release più sensibili.
Come lo esegue Berghem
Berghem tratta gestione delle vulnerabilità e pentest come livelli di uno stesso programma, non come servizi concorrenti. Il punto di partenza è sempre il perimetro reale: quali asset esistono, quali sono critici, quali obblighi normativi si applicano e dove lo sfruttamento causerebbe più danno.
Per il livello di profondità, il penetration test segue la metodologia Ethical Hacking Test (EHT), con ricognizione, sfruttamento manuale, concatenamento delle falle e prova di impatto allineati a OWASP, PTES e NIST SP 800-115. Ogni risultato è accompagnato da proof of concept riproducibile, prioritizzazione per rischio e retest per convalidare le correzioni. La scelta della modalità — rete, API, cloud, mobile o Red Team — dipende da ciò che l'azienda deve dimostrare; per capire come è strutturata la metodologia, consultate la pagina del servizio Ethical Hacking Test (EHT).
Le aziende con obblighi normativi integrano di solito questi livelli in percorsi di conformità come PCI DSS, ISO/IEC 27001 e adeguamento alla LGPD. Come azienda di sicurezza delle informazioni a San Paolo, adattiamo la cadenza delle scansioni e la periodicità dei test al rischio di ciascuna operazione — perché l'investimento rifletta ciò che va protetto, e non una tabella generica.
Domande frequenti
Uno scanner di vulnerabilità sostituisce il pentest?
No. Lo scanner trova falle note in modo automatizzato e su larga scala, ma non conferma se sono sfruttabili, non concatena le debolezze e non comprende la logica di business. Il pentest sfrutta attivamente il bersaglio e prova l'impatto reale, con proof of concept riproducibile per ogni risultato convalidato.
Con quale frequenza devo eseguire ciascuno?
La gestione delle vulnerabilità è continua: scansioni ricorrenti (mensile come soglia minima) e verifica a ogni cambiamento significativo. Il pentest è periodico e guidato dagli eventi: almeno annuale per i sistemi critici, e sempre dopo cambiamenti rilevanti o prima dei rilasci. Norme come il PCI DSS definiscono minimi obbligatori per entrambi.
Da dove iniziare se il budget è limitato?
Iniziate dall'inventario e da una routine di scansione autenticata — senza sapere cosa avete, nessun investimento si giustifica. Con il di base corretto, commissionate un pentest focalizzato sugli asset più critici ed esposti. Così il test, più costoso, si concentra su ciò che richiede intelligenza umana e non su ciò che uno scanner risolverebbe già.