Pentest vs. Vulnerability Assessment: cosa offre ciascuno (e perché lo scan non sostituisce il test)

Categoria: Pentest | Vulnerability Assessment | Conformità Livello: Principiante a Intermedio Ambiente: Laboratorio controllato — scenario totalmente anonimizzato, senza dati reali di clienti

---

Introduzione

Ogni mese arriva al team di sicurezza una proposta di "test delle vulnerabilità" a basso prezzo e con report automatico in 48 ore. Allo stesso tempo, l'auditor PCI-DSS chiede se il pentest annuale sia stato fatto. Per chi non vive di sicurezza, la confusione è legittima: vulnerability assessment (VA) e penetration test (pentest) sembrano la stessa cosa — entrambi "cercano vulnerabilità". Non lo sono.

La differenza non è di prezzo, è di domanda. Lo scan risponde "quali CVE note esistono su questi asset?". Il pentest risponde "cosa può fare un attaccante, in pratica, con ciò che esiste — e quanto costa al business?". Un'organizzazione matura ha bisogno di entrambi, in momenti diversi, con scopi diversi. Questo articolo spiega la differenza in uno scenario anonimizzato, mostra quando si applica ciascuno e perché nessuno dei due, da solo, soddisfa ciò che richiedono LGPD, PCI-DSS e ISO 27001.

---

1. Cosa sono (definizioni senza gergo)

Vulnerability Assessment (VA / scansione delle vulnerabilità)

È una scansione automatizzata che confronta versioni software e configurazioni di un target contro una base di conoscenza di vulnerabilità note (CVE, plugin, librerie). Il deliverable è un elenco priorizzato per severità (CVSS), con l'indicazione di quale CVE potenzialmente interessa ciascun asset.

• Domanda a cui risponde: "Cosa è obsoleto, mal configurato o con CVE nota?"
• Come funziona: lo strumento gira sulla rete o sull'host (Nessus, Qualys, OpenVAS, nuclei, scanner SAST sul codice), confronta con i feed CVE e genera il report.
• Velocità: giorni, a volte ore — dipende dalla dimensione del perimetro.
• Falso positivo: alto. Lo scan correla versione con CVE, ma non conferma se la condizione di sfruttamento esista davvero (es.: CVE che richiede una configurazione specifica, WAF che blocca, funzionalità disattivata).
• Dipende dall'inventario: uno scan vede solo ciò che può raggiungere e riconoscere. Se l'asset non è nel perimetro o la versione è personalizzata, resta cieco.

Penetration Test (pentest)

È un test manuale, avversariale e orientato a un obiettivo, eseguito da un professionista che pensa come un attaccante — con autorizzazione scritta, perimetro definito e regole di engagement. Il pentester usa strumenti automatizzati come supporto (enumerazione, fuzzing), ma il nucleo del lavoro è umano: incatenare vulnerabilità, testare la logica di business, tentare l'escalation dei privilegi, validare l'impatto reale.

• Domanda a cui risponde: "Cosa può fare un attaccante con questo — e qual è l'impatto reale per il business?"
• Come funziona: ricognizione → threat modeling → sfruttamento controllato → validazione di ogni finding con PoC riproducibile → report con evidenza.
• Velocità: settimane (tipicamente 2-3 settimane per un'applicazione web).
• Falso positivo: basso — ogni finding viene validato manualmente con prova di sfruttamento prima di entrare nel report.
• Dipende da perimetro e contesto: il valore sta proprio in ciò che lo scanner non vede — logica di business, flussi di autenticazione, concatenamento dei difetti.

---

2. Scenario di laboratorio: la "Alfa Retail"

Per rendere concreta la differenza, abbiamo usato uno scenario fittizio: la Alfa Retail, catena di vendita al dettaglio con 400 negozi, e-commerce proprio e un CRM interno con dati dei clienti (la LGPD nella testa della direzione). Il team IT esegue una scansione trimestrale con uno strumento di VA da due anni. Nessuno ha messo in discussione il processo — finché l'ultimo report dello scan è uscito "100% pulito" la stessa settimana in cui un pentest di laboratorio (autorizzato, in ambiente di staging) ha trovato ciò che lo scan non vedeva.

Cosa è successo nello scenario:

Finding 1 — [CRITICO] IDOR nel CRM: lo scanner non testa la logica di business

Lo scan ha esaminato il CRM, ha trovato la versione del framework senza CVE note ed è andato avanti. Il pentester, con un account utente normale, ha modificato l'ID di un record nell'URL e ha acceduto alla scheda completa di un altro cliente — nome, CPF, telefono, storico degli acquisti. Il backend si fidava dell'ID inviato dal client senza validare l'autorizzazione.

• Perché lo scan non lo ha visto: gli accessi indebiti a livello di oggetto (IDOR) non sono CVE — sono un difetto di logica di autorizzazione. Nessun feed CVE descrive "il sistema di Alfa valida gli ID". Solo un test funzionale, pensato in modo avversariale, trova questo.
• Cosa avrebbe riportato lo scan: nulla. Il report è uscito "pulito".
• Mappatura OWASP Top 10 (2021): A01 Broken Access Control.

Finding 2 — [ALTO] Concatenamento: upload dell'avatar → RCE sul server

Lo scan ha identificato la versione del componente di upload come "senza CVE note". Il pentester ha scoperto che l'upload accettava estensioni arbitrarie, ha inviato un file con contenuto eseguibile e, combinato con la mancanza di segregazione tra la directory di upload e il server web, ha eseguito comandi sul server.

• Perché lo scan non lo ha visto: ogni pezzo isolato sembrava innocuo (upload "validato" per estensione, directory sullo stesso host). Il rischio esiste solo nel concatenamento dei due difetti — esattamente il tipo di ragionamento che uno scanner non fa.
• Mappatura OWASP Top 10 (2021): A03 Injection + A05 Security Misconfiguration (concatenati).

Finding 3 — [MEDIO] Fuga di dati nella risposta di un'API

Un endpoint legittimo restituiva, insieme al dato richiesto, campi che lo schermo non usa: CPF completo dell'utente connesso e di terzi, token interni di integrazione. Lo scan di infrastruttura non effettua chiamate funzionali autenticate; solo il test manuale con l'applicazione in uso ha trovato l'eccesso di dati nella risposta.

• Perché lo scan non lo ha visto: il VA valuta il target "dall'esterno" (banner, versione, porta). L'eccesso di dati in un payload API richiede autenticazione e conoscenza del flusso di business.
• Mappatura OWASP Top 10 (2021): A01 Broken Access Control (esposizione eccessiva dei dati).

Il riepilogo dello scenario

Lo scan non è inutile — è incompleto per ciò di cui Alfa aveva bisogno: sapere se un attaccante potesse accedere ai dati dei clienti. Per quella domanda, solo il test manuale serve.

---

3. Quando usare ciascuno (e quando entrambi)

Usa la vulnerability assessment quando:

1. Frequenza alta, costo basso: copertura continua tra i pentest (es.: scan mensile/trimestrale, scan in CI a ogni deploy).
2. Inventario grande e dinamico: rete con centinaia di asset, dove il primo passo è sapere cosa esiste e cosa è obsoleto.
3. Triage iniziale: ridurre l'universo prima del test manuale — lo scan segnala i candidati CVE che il pentester valida dopo.
4. Patch management: alimentare il processo di correzione con priorizzazione per CVSS ed esposizione.

Usa il pentest quando:

1. La domanda è "cosa può fare un attaccante?" — non "cosa è obsoleto?".
2. Requisito di conformità: PCI-DSS Req. 11.4 (v4.0) richiede pentest interni ed esterni annuali; LGPD Art. 46 richiede misure di sicurezza tecniche — che auditor e DPO si aspettano di vedere dimostrate dal test, non dallo scan.
3. Applicazioni con logica di business: e-commerce, fintech, CRM, sistemi di pagamento — dove il rischio sta nei flussi, non nelle versioni.
4. Prima di modifiche significative: lancio del prodotto, nuova integrazione, migrazione dell'architettura.
5. Validazione dei controlli: il pentest verifica se WAF, IDS e patch impediscono davvero lo sfruttamento — lo scan attesta solo che esistono.

La combinazione corretta

Una postura di sicurezza realistica usa entrambi a strati:

[VA continuo]  →  [triage e patch]  →  [pentest periodico/annuale]  →  [remediation]  →  [retest]
      ↑                                                                              │
      └──────────────────────  loop continuo (cadenza per rischio)  ←───────────────┘

Il VA mantiene l'igiene di base tra i cicli; il pentest valida se l'igiene regge a un attaccante reale. L'errore più comune non è sceglierne uno — è trattare lo scan come sostituto del test e scoprire la differenza in un incidente.

---

4. Perché lo scan non soddisfa la conformità da solo

Auditor e regolatori chiedono evidenza di test, non evidenza di scansione:

Il punto pratico: il report di un pentest è firmato da un professionista, porta una PoC riproducibile per ogni finding e descrive l'impatto in linguaggio di business — ciò che un auditor accetta come evidenza. Il report di uno scan è un inventario di rischio potenziale, utile per il team tecnico, ma non risponde a "la vulnerabilità è sfruttabile?".

---

5. Come valutare una proposta di pentest (checklist per chi commissiona)

Non tutte le proposte chiamate "pentest" sono un pentest. Prima di firmare:

1. Perimetro esplicito — cosa verrà testato (applicazioni, API, rete, mobile), con quali accessi (blackbox/graybox/whitebox) e in quale ambiente (staging preferibile).
2. Metodologia dichiarata — OWASP WSTG/PTES come base, test manuali di logica di business previsti (non solo "eseguire lo strumento X").
3. Evidenza per finding — il report deve includere una PoC riproducibile (payload, passo-passo, screenshot) per ogni vulnerabilità.
4. Professionista responsabile — report firmato, con nome e seniority; dietro l'analisi c'è un essere umano.
5. Validazione dell'impatto — severità classificata per contesto di business (il CVSS è il punto di partenza, non la risposta finale).
6. Retest incluso — verifica della remediation dopo le correzioni (comune: 1 ciclo di retest nel perimetro).
7. Tempi compatibili — un pentest di applicazione web richiede settimane, non 48 ore. Una consegna lampo è segno di uno scan rinominato.

---

6. Conclusione (e cosa fare lunedì)

• Se non hai uno scan: inizia da lì — è lo strato di igiene continua e il costo è basso.
• Se hai uno scan e nessun pentest: la domanda "cosa può fare un attaccante?" resta senza risposta. Pianifica il primo pentest sugli asset che movimentano dati sensibili o denaro.
• Se hai entrambi: verifica che il pentest copra la logica di business e i flussi autenticati — se il report elenca solo CVE, hai commissionato uno scan più costoso.

Nello scenario Alfa Retail, lo scan "100% pulito" esisteva da due anni; il pentest di una settimana ha trovato tre difetti sfruttabili nei dati dei clienti. La differenza non sta nello strumento — sta nella domanda a cui ciascuno risponde.

---

Questo articolo descrive uno scenario di laboratorio totalmente fittizio, costruito a scopo educativo. Nessun dato reale di clienti è stato utilizzato. Lo sfruttamento di vulnerabilità in sistemi senza autorizzazione esplicita è illegale.