Per dieci anni abbiamo fatto pen test in modo sostanzialmente immutato: scan con Nessus o OpenVAS, fuzzing con Burp, exploitation manuale di quello che trovi, report con CVSS, patch cycle. Un processo collaudato, con limiti ben noti — primo fra tutti: gli scanner automatici trovano bug nelle librerie, non bug nel modo in cui hai scritto la tua applicazione.
Gli agenti offensivi basati su LLM cambiano questa equazione. Non perché siano più veloci (spesso sono più lenti), ma perché cercano cose diverse. E le cose diverse sono, per il difensore italiano medio, molto più pericolose.
Cosa un agente AI trova che uno scanner ignora
Prendiamo un caso reale che abbiamo visto tre mesi fa in un pen test concordato su un'applicazione di un cliente. Nessun scanner aveva mai segnalato niente di grave. L'agente di Intrusio, dopo 40 minuti di esplorazione, ha messo insieme questa catena:
- Una pagina pubblica di reset password mandava un'email con link JWT.
- Il JWT veniva generato con un segreto statico contenuto nel codice JS del frontend (offuscato, ma recuperabile).
- Il claim
roledentro il JWT non era verificato lato server al reset. - Modificando il claim a
admin, l'agente ha avuto accesso amministrativo — senza mai rubare una credenziale.
Nessun SAST avrebbe trovato questa vulnerabilità, perché ogni pezzo singolarmente non è un bug. Il segreto statico in JS è una cattiva pratica, non una CVE. Il JWT non verificato è una riga di codice mancante. Il link di reset è funzionalità normale. È la composizione che fa il danno, e un LLM ragionante concatena pezzi in modo molto simile a come fa un pen tester umano — ma per 24 ore consecutive, senza stancarsi.
Perché in Italia siamo particolarmente esposti
Tre motivi, in crescita:
1. Applicazioni legacy ancora in produzione
Gran parte dei sistemi gestionali italiani — da quelli degli ordini professionali a quelli sanitari regionali — è stata scritta tra il 2008 e il 2015. Architetture monolitiche, autenticazione rudimentale, autorizzazioni affidate alla struttura dei menu più che a controlli server-side. Sono esattamente il tipo di bersaglio su cui un agente ragionante eccelle.
2. Personale di sicurezza sottodimensionato
Il team di sicurezza medio di un'azienda italiana da 500 dipendenti è 1-3 persone. Non possono fare pen test continuo, non possono studiare ogni CVE, non possono ricostruire catene logiche per ogni webapp in dote. Gli attaccanti sì — o meglio, i loro agenti sì.
3. La PA e le infrastrutture critiche come moltiplicatore
In Italia c'è una concentrazione anomala di infrastrutture critiche gestite da partner privati di medie dimensioni: acqua, energia, trasporti locali, sanità territoriale. Non sono target di frontiera per APT statali — ma sono perfettamente raggiungibili da una campagna guidata da agenti semi-autonomi.
Cosa dovrebbe fare chi difende, oggi
La risposta realistica non è "compra un altro scanner". È riorganizzare il modo in cui pensi la superficie d'attacco. Tre mosse concrete.
Prima: mappa i punti dove la logica applicativa decide l'autorizzazione
Fai un audit interno di tutti i controlli di autorizzazione: sono centralizzati o sparsi? Sono espressi in codice leggibile o nascosti in logiche di UI? Le modifiche future a questi punti passano per una review dedicata? Se la risposta è "non lo so", hai appena identificato il tuo rischio numero uno.
Seconda: introduci pen test agentico nel ciclo, non una tantum
Il pen test annuale era adeguato a un'epoca in cui l'ambiente cambiava lentamente. Oggi gli agenti possono scansionare le tue applicazioni settimanalmente, correlando ogni nuovo deploy con la superficie esposta. Non deve sostituire il pen test umano — deve affiancarlo come monitoraggio continuo. Per questo in Intrusio permettiamo di schedulare cicli autonomi con perimetro autorizzato.
Terza: rendi auditable la catena di autorizzazione
Ogni volta che un utente fa un'operazione sensibile, il log deve dire: chi l'ha autorizzata, contro quale policy, con quale ruolo. Se il log dice solo "user X did operation Y", sei cieco rispetto a catene di privilege escalation. Con log strutturati, tu puoi usare un LLM per cercare anomalie nella tua autorizzazione — stessa tecnica, dalla parte giusta.
"Abbiamo scoperto tre percorsi di escalation in una settimana, di cui uno aperto dal 2019. Nessun audit interno li aveva mai trovati." — Responsabile sicurezza di un'azienda sanitaria, dopo il primo ciclo con Intrusio.
L'obiezione: "ma gli attaccanti non usano ancora agenti così"
Risposta onesta: alcuni sì, molti no, tra 12 mesi quasi tutti. Il costo di un agente offensivo decente, in cloud, è sotto i 200 € per una campagna contro una webapp. Non è una tecnologia da Stati — è una tecnologia da gruppo criminale di medie dimensioni, o da competitor sleale.
Se aspetti di vedere l'attacco per credere alla minaccia, prepari una reazione. Se lo fai adesso, prepari una difesa. Non è la stessa cosa.
Cosa facciamo noi
Intrusio non è un sostituto del pen tester umano, ed è importante dirlo. Un agente AI non capisce il contesto di business, non sa se un'esposizione è critica per quella azienda, non sa negoziare con chi ti apre le porte per il test. Ma un agente AI ti libera dall'80% del lavoro meccanico — ricognizione, enumerazione, tentativi iniziali — e lascia al tester umano il 20% che serve davvero: catene di business logic, social engineering tecnico, creatività.
Se fai sicurezza oggi in un'azienda italiana e non stai ancora affiancando un agente offensivo al tuo processo, non è che sei indietro: sei asimmetrico rispetto a chi attacca. E l'asimmetria in sicurezza si paga sempre.
