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

Il problema con "abbiamo fatto il pentest"

Un'azienda su tre, nel mid-market italiano, esegue un penetration test una volta all'anno e lo considera sufficiente per dichiarare la propria infrastruttura "sicura". Il report va al CDA, viene archiviato, i finding critici vengono messi in backlog. Nel frattempo l'infrastruttura cambia: nuovi microservizi, nuove pipeline CI/CD, nuove integrazioni SaaS.

Il pentest fotografa un momento. Non misura una condizione.

---

Cosa copre effettivamente un pentest standard

Un penetration test condotto secondo metodologie consolidate — OWASP Testing Guide, PTES, OSSTMM — copre uno scope definito a contratto. Tipicamente:

Rete esterna (external network): esposizione di servizi verso internet, misconfigurazioni DNS, porte aperte, versioni software vulnerabili.
Applicazione web: OWASP Top 10 (injection, broken auth, IDOR, SSRF, ecc.), logica applicativa se il tester ha accesso autenticato.
Rete interna (se previsto): lateral movement, privilege escalation, segmentazione VLAN.
Social engineering (se previsto): phishing simulato, vishing, test fisici di accesso.

Un pentest di qualità su un'applicazione web mid-size richiede 5-10 giorni/uomo. Uno su infrastruttura complessa, 15-20. Meno di così, è una scansione automatica con un report di Nessus riconfezionato.

---

Cosa manca strutturalmente

1. La deriva post-test

Il giorno dopo la chiusura del pentest, inizia la deriva. Un nuovo servizio esposto, una dipendenza npm aggiornata con una CVE critica, una chiave API committata per errore su GitHub. Nessuno di questi eventi compare nel report consegnato ieri.

I dati lo confermano: il tempo medio tra introduzione di una vulnerabilità e rilevamento (MTTD) è ancora superiore ai 200 giorni in molte organizzazioni. Un pentest annuale copre una finestra di ~1 giorno su 365.

2. La logica di business

I tester automatici e molti tester manuali trovano vulnerabilità tecniche. Trovare che un utente con ruolo viewer può promuoversi a admin manipolando un parametro REST richiede comprensione del dominio applicativo. Questo tipo di testing — business logic abuse — richiede sessioni dedicate con sviluppatori e product owner, e raramente è incluso nel SOW standard.

3. La supply chain

Le dipendenze di terze parti, i vendor SaaS integrati via API, gli SDK inclusi nel frontend: nessun pentest classico tocca questi componenti perché sono fuori scope per contratto. Eppure il 62% delle compromissioni nel 2023 ha coinvolto almeno un componente della supply chain software (fonte: Verizon DBIR 2024).

4. Il fattore umano in contesti reali

Un phishing simulato durante il pentest è atteso, almeno psicologicamente. Le campagne reali arrivano in momenti di stress operativo, venerdì pomeriggio, durante un'emergenza di produzione. Il test non replica le condizioni cognitive reali.

5. Cloud e ambienti effimeri

Kubernetes, Lambda, container spinnati e distrutti ogni pochi minuti: un pentest tradizionale su un ambiente cloud-native richiede approcci specifici — CSPM (Cloud Security Posture Management), test delle IAM policy, analisi dei secrets nei log CloudWatch. La maggior parte dei SOW standard non lo prevede.

---

Come strutturare una copertura reale

Un approccio maturo combina livelli complementari:

┌─────────────────────────────────────────────────────┐
│  CONTINUO                                           │
│  - SAST/DAST nelle pipeline CI/CD                  │
│  - SCA (Software Composition Analysis) su deps     │
│  - CSPM per drift di configurazione cloud          │
│  - Secret scanning (truffleHog, git-secrets)       │
├─────────────────────────────────────────────────────┤
│  PERIODICO (trimestrale / semestrale)               │
│  - Vulnerability assessment esterno automatizzato  │
│  - Revisione IAM e privilege access                │
│  - Phishing interno non annunciato                 │
├─────────────────────────────────────────────────────┤
│  PUNTUALE (annuale o post-release major)           │
│  - Penetration test manuale con scope esteso       │
│  - Red team exercise (se il team lo supporta)      │
│  - Test di business logic con il dominio team      │
└─────────────────────────────────────────────────────┘

Il SAST nell'integrazione continua non sostituisce il pentest manuale: trova pattern noti in modo prevedibile, produce falsi positivi, non ragiona sulla logica. Ma riduce la superficie prima che un tester umano la debba esaminare.

---

Con quale frequenza ripetere il pentest

Non esiste una risposta universale. Esistono trigger oggettivi:

| Evento | Azione consigliata | |---|---| | Release major (nuovo modulo, nuova API pubblica) | Pentest parziale sullo scope nuovo | | Cambio di infrastruttura (cloud migration, nuovo DC) | Pentest infrastrutturale | | M&A o onboarding di un nuovo vendor critico | Assessment sulla superficie acquisita | | Incident di sicurezza | Post-incident pentest per validare il remediation | | Annuale baseline | Pentest completo con scope aggiornato |

L'errore più comune è trattare la frequenza come una questione di compliance («ci vuole almeno una volta all'anno per ISO 27001»). La compliance è un floor, non un ceiling.

---

Cosa chiedere a un fornitore di pentest

Quando si valuta un vendor, quattro domande concrete:

Qual è il numero di giorni/uomo effettivi dedicati al progetto? Qualsiasi risposta sotto i 5 giorni per un'app web di medie dimensioni è una scansione automatica.
Il testing include business logic o solo OWASP Top 10? Se la risposta è vaga, il SOW non lo prevede.
Come viene gestito il retesting dopo remediation? Deve essere incluso, non fatturato a parte.
Il report include exploit proof-of-concept riproducibili? Un finding senza PoC è un'ipotesi, non una vulnerabilità dimostrata.

---

Take-away operativo

Un pentest annuale è necessario ma non sufficiente. La sicurezza reale si costruisce con una combinazione di automazione continua nelle pipeline, assessment periodici della superficie esposta, e testing manuale approfondito nei momenti di cambiamento significativo.

Il report consegnato a fine test è un punto di partenza, non un certificato.

---

Evviva Group supporta aziende e partner IT nella strutturazione di programmi di sicurezza continuativa, dalla scelta dei vendor di pentest all'integrazione di SAST/DAST nelle pipeline esistenti.