Penetration test oggi: cosa copre davvero, cosa manca, cosa va ripetuto

Un'azienda su tre, dopo aver ricevuto il report di pentest con zero finding critici, subisce un incidente entro dodici mesi. Il problema non è il fornitore del test. È la definizione di scope.

Cosa copre davvero un pentest standard

Quando un cliente commissiona un penetration test, nella maggior parte dei casi riceve una delle tre varianti classiche:

Black box: il tester non ha credenziali né documentazione. Simula un attaccante esterno senza informazioni privilegiate.
Grey box: credenziali limitate, architettura parzialmente condivisa. È lo scenario più comune nei test su applicazioni web B2B.
White box: accesso completo a codice sorgente, documentazione, credenziali di test. Il più costoso, il più accurato.

Un grey box su una web application copre tipicamente: OWASP Top 10, autenticazione e gestione sessioni, autorizzazione verticale e orizzontale, injection (SQL, NoSQL, command), esposizione di dati sensibili nelle API REST, configurazioni errate nei header HTTP.

Questo è già sostanziale. Ma fermiamoci qui e guardiamo cosa non entra quasi mai nello scope.

I gap strutturali che nessun pentest annuale risolve

1. La superficie cambia continuamente

Un'applicazione SaaS B2B tipica rilascia codice ogni una o due settimane. Un pentest eseguito a gennaio fotografa lo stato di gennaio. A marzo sono stati aggiunti tre nuovi endpoint, un'integrazione con un provider di pagamenti terzo e una funzionalità di export CSV. Nessuno di questi è stato testato.

La soluzione non è fare dodici pentest l'anno — non è sostenibile economicamente. La soluzione è affiancare al pentest periodico un programma di DAST continuativo (Dynamic Application Security Testing) su ogni deploy, integrato nella CI/CD pipeline.

Un esempio pratico con OWASP ZAP in GitHub Actions:

- name: DAST scan
  uses: zaproxy/action-full-scan@v0.10.0
  with:
    target: 'https://staging.example.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'

Non sostituisce il pentest manuale, ma garantisce che i nuovi endpoint vengano almeno attraversati da scanner automatici prima di andare in produzione.

2. Il cloud infrastructure layer è spesso fuori scope

La maggior parte dei pentest su applicazioni non tocca l'infrastruttura cloud sottostante. IAM policies su AWS, bucket S3 pubblici per errore, security groups troppo permissivi, secrets nei log di CloudWatch: sono attack surface reale, ma vengono esclusi perché "non è una web app test".

Per coprire questo layer servono strumenti dedicati: Prowler per AWS, ScoutSuite per multi-cloud, o un Cloud Security Posture Management (CSPM) come AWS Security Hub con finding continui.

Esempio di audit rapido con Prowler:

prowler aws --services s3 iam cloudtrail \
  --output-formats json-asff \
  --output-directory ./prowler-reports

Un'ora di esecuzione su un account AWS medio produce decine di finding che nessun pentest applicativo avrebbe rilevato.

3. Il fattore umano non è testabile in un pentest standard

Le campagne di phishing, il social engineering, il vishing: questi vettori sono spesso contrattualizzati a parte (red team engagement) o esclusi per motivi organizzativi. Eppure il 74% delle violazioni — secondo il Verizon DBIR 2023 — coinvolge l'elemento umano.

Se il tuo budget non consente un red team completo, considera almeno una campagna di phishing simulata trimestrale con strumenti come GoPhish (open source) o servizi gestiti. I dati che ottieni — click rate, credential submission rate — sono metriche operative concrete, non opinioni.

4. Le dipendenze di terze parti non vengono testate

Il tuo codice può essere pulito. Ma se usi venti pacchetti npm, tre SDK di provider esterni e un widget di chat in iframe, la superficie reale è molto più grande di quella che il pentest ha coperto.

L'analisi delle dipendenze è un processo separato: SCA (Software Composition Analysis) con strumenti come Snyk, Dependabot, o OWASP Dependency-Check nella pipeline.

Cosa va ripetuto e con quale cadenza

Non esiste una cadenza universale, ma esiste un framework ragionevole:

| Attività | Cadenza consigliata | Trigger aggiuntivi | |---|---|---| | Pentest manuale (grey/white box) | Annuale | Rilascio major feature, cambio architetturale significativo | | DAST automatico | Ogni deploy (staging) | — | | CSPM scan (cloud posture) | Settimanale / continuo | Ogni modifica IaC | | SCA (dipendenze) | Ogni build | — | | Phishing simulato | Trimestrale | Post-incidente, cambio team significativo | | Review manuale IAM/secrets | Semestrale | Offboarding sviluppatori senior |

Il pentest annuale rimane fondamentale perché l'intelligenza umana trova vulnerabilità logiche che nessuno scanner trova. Ma è un punto di ancoraggio, non una copertura completa.

Il report non è la fine: è l'inizio

Un errore ricorrente: ricevere il report, correggere i finding critici e alti, chiudere il ticket. I finding medi e bassi restano aperti per mesi.

La prioritizzazione corretta non si basa solo sul CVSS score. Si basa sul contesto di business: una vulnerabilità CVSS 5.5 su un endpoint che gestisce dati di pagamento è più urgente di una CVSS 7.0 su una pagina di documentazione pubblica.

Integrare i finding del pentest in un sistema di tracking (Jira, Linear, qualunque cosa usiate) con SLA definiti per categoria è il minimo per trasformare un documento in processo.

Take-away operativo

Definisci lo scope del prossimo pentest includendo esplicitamente infrastruttura cloud, API interne e integrazioni di terze parti — non solo la web app principale.
Affianca DAST automatico nella CI/CD per coprire il delta tra un pentest e l'altro.
Usa CSPM per il cloud layer: è quasi sempre fuori scope nei pentest standard.
Traccia i finding come task con SLA, non come PDF da archiviare.
Pianifica la ripetizione del pentest ogni volta che cambia significativamente l'architettura, non solo per scadenza calendario.

La sicurezza è un processo continuo con checkpoint periodici, non un audit annuale con firma finale.

---

Evviva Group supporta partner e system integrator nella strutturazione di programmi di security testing continuativi. Se stai rivedendo il tuo approccio al pentest, possiamo ragionarne insieme.