
Il pentesting agentico punta alla finestra di sfruttamento di 5 giorni
Lo sfruttamento è ora all'origine del 31% delle violazioni mentre le patch richiedono 43 giorni, e una guida di un fornitore sostiene che il pentesting agentico può colmare questo divario.
Il pentesting agentico, la pratica di indirizzare agenti software autonomi verso siti web e applicazioni per cercare punti deboli di sicurezza, è l'oggetto di una nuova guida rivolta ai responsabili della sicurezza, e la sua tesi si basa su un divario che i dati di terze parti rendono difficile ignorare. Lo sfruttamento di vulnerabilità note è ora all'origine del 31 percento delle violazioni, secondo il Data Breach Investigations Report 2026 di Verizon, rendendolo il modo più comune con cui gli attaccanti entrano, mentre l'organizzazione mediana impiega ancora 43 giorni per correggere una falla che è già in fase di sfruttamento.
Il rapporto 2026 di Verizon, basato su più di 22.000 violazioni confermate, segna quello che la guida definisce un punto di svolta: lo sfruttamento delle vulnerabilità ha superato le credenziali rubate come principale vettore di accesso iniziale. Lo stesso rapporto mostra che la remediation si muove nella direzione sbagliata. Il tempo mediano per correggere una falla nota e sfruttata è salito da 32 a 43 giorni, e la quota di falle nel catalogo CISA KEV (la lista dell'agenzia statunitense per la cybersecurity e la sicurezza delle infrastrutture delle vulnerabilità note per essere sfruttate in natura) che le organizzazioni hanno effettivamente corretto è scesa dal 38 al 26 percento. La telemetria di Google Mandiant citata nella guida colloca il tempo medio di sfruttamento a circa cinque giorni, mentre il State of Pentesting 2026 di Cobalt colloca il tempo mediano per risolvere un problema ad alto rischio a 39 giorni, con un divario di 25 volte tra i migliori e i peggiori. Un difensore che lavora su un orologio di 43 giorni contro un avversario che si muove in cinque giorni non sta gestendo il rischio tanto quanto lo sta documentando a posteriori, sostiene la guida.
La guida indica anche l'intelligenza artificiale che spinge da entrambe le direzioni. Gli attaccanti usano l'IA per trovare e trasformare le falle in armi più velocemente, mentre i team di sviluppo usano l'IA per rilasciare codice più velocemente di quanto qualsiasi sforzo di test umano possa tenere il passo. La ricerca di Cobalt, citata nella guida, ha rilevato che le applicazioni di IA e di modelli linguistici di grandi dimensioni presentano problemi ad alto rischio a un tasso 2,7 volte superiore rispetto alle applicazioni tradizionali. La guida stima che il pentesting annuale lascia circa il 90 percento del patrimonio di un'organizzazione non testato: un'istantanea scattata una volta all'anno, che copre una frazione della superficie, consegnata con settimane di ritardo.
La tesi che gli agenti automatizzati possano effettivamente fare questo lavoro si basa su risultati che la guida attribuisce ad altri. Un sistema autonomo di XBOW ha guidato la classifica statunitense di HackerOne nel 2025, e una ricerca peer-reviewed di Fang et al. nel 2024 ha rilevato che gli agenti hanno sfruttato l'87 percento delle falle appena divulgate (i cosiddetti one-day) senza assistenza. Il State of Pentesting 2026 di Cobalt è citato per l'affermazione che il testing programmatico rende i team 4,5 volte più propensi a correggere i problemi critici entro tre giorni.
La guida percorre una singola catena di attacco per mostrare dove gli strumenti esistenti falliscono: un riferimento diretto a oggetto non sicuro, o IDOR, in un'area account autenticata. Un IDOR è una falla in cui un sito web consegna un record semplicemente perché qualcuno lo ha richiesto, senza verificare che la persona che lo chiede ne sia il proprietario. Nell'esempio, un attaccante accede a un account ordinario, modifica il valore account_id su una richiesta di aggiornamento del profilo e scopre che l'applicazione non verifica mai la proprietà. L'attaccante poi enumera gli ID su larga scala, riscrive gli indirizzi email di altri utenti, attiva i reset delle password e si impossessa degli account. Non c'è alcun CVE (una voce di catalogo pubblico per una falla software nota) e nessun input malformato, solo logica di business che l'applicazione ha sbagliato. La guida osserva che questa esatta classe di bug ha esposto 885 milioni di record di mutui e titoli presso First American Financial nel 2019, dove cambiare una cifra in un link di un documento rivelava il file di qualcun altro.
Contro quella stessa catena, la guida descrive quattro esiti. Uno scanner che confronta le risposte con un database di CVE non trova nulla, perché non esiste alcun CVE per la logica propria di un'applicazione. Anche uno strumento DAST (dynamic application security testing, che lancia una lista fissa di schemi di attacco contro un sito) lo manca, perché l'exploit richiede una sessione valida e una sequenza a più passaggi che nessuna lista di payload contiene. Un tester umano lo trova solo se quell'endpoint cade per caso nel 5-10 percento campionato del patrimonio, e il problema diventa obsoleto al rilascio successivo. Un sistema agentico, secondo il racconto della guida, mappa l'endpoint, deduce la relazione di proprietà e concatena enumerazione, riscrittura email e reset password, poi ricontrolla quell'elemento di lavoro a ogni esecuzione.
La guida separa le piattaforme reali dalle dimostrazioni in tre scelte architetturali. La prima è la copertura imposta dagli elementi di lavoro: se l'IA decide cosa testare, la copertura diventa non dimostrabile, perché un modello tende verso i risultati interessanti e salta silenziosamente il resto, quindi una matrice di test completa dovrebbe essere generata in anticipo con ogni endpoint testato contro ogni categoria di attacco applicabile come elementi non saltabili. L'IA può essere adattiva nel modo in cui attacca ogni elemento, mai nel se lo fa. La seconda è un agente validatore indipendente, così un problema raggiunge il rapporto solo dopo che un agente separato lo riproduce, spostando la rimozione dei falsi positivi fuori dalla coda di triage del cliente. La terza è un agente nativo del browser: la maggior parte degli strumenti agentici sono, nelle parole della guida, effettivamente curl con un modello attaccato, e i siti web reali con rendering dinamico, codici monouso, autenticazione a più fattori (una seconda prova di identità oltre la password) e difese anti-bot li rompono. "L'80% di copertura non è più sufficiente, perché gli attaccanti hanno bisogno solo dell'unico varco che hai mancato", ha detto Ysrael Gurt, CTO e co-fondatore di Reflectiz, nella guida.
Poiché lo strumento è un sistema autonomo che gira in produzione, la guida tratta la governance come una precondizione piuttosto che un ripensamento. La sua checklist richiede una definizione dell'ambito esplicita e revocabile, protezioni sul raggio d'azione con un arresto sicuro immediato, isolamento dei dati senza accesso all'infrastruttura dei dati dei clienti, una traccia di audit completa ed esportabile, una supervisione umana definita e garanzie del fornitore. Il test che la guida propone è diretto: se non sai rispondere a quale sia la cosa peggiore che l'agente potrebbe fare alla produzione, e cosa lo ferma, non sei pronto ad autorizzare un'esecuzione.
L'economia è presentata come favorevole all'adozione. Un incarico manuale costa in media circa 18.300 dollari prima di un comune superamento del 30-50 percento, e un programma maturo spende ancora più di 150.000 dollari all'anno per testare una stima del 5-10 percento dei suoi asset, numeri che la guida attribuisce a un'analisi dei costi di Reflectiz sui prezzi pubblicati dai fornitori. Contro questo, i fornitori della categoria riportano fino a 10 volte la capacità di testing per il costo di un incarico manuale, e la cifra IBM del 2025 per la violazione media è di 4,44 milioni di dollari. Quei multipli di capacità sono affermazioni riportate dai fornitori, non risultati misurati in modo indipendente.
La guida inquadra anche il testing continuo come un dividendo di conformità. Sostiene che il testing documentato e ripetuto produce le prove necessarie per le clausole "dopo un cambiamento significativo" nel PCI DSS 4.0.1, cosa che il testing annuale non può fare per sua natura, e si mappa al lavoro di controllo e garanzia sotto DORA, NIS2, SOC 2, ISO 27001, GDPR Articolo 32 e HIPAA. Si dice che ogni esecuzione generi il proprio pacchetto di prove che copre una matrice di copertura, problemi validati con passaggi di riproduzione e reportistica di tendenza che i revisori possono interrogare.
Vale la pena essere chiari su cosa sia questo documento. Hacker News etichetta l'elemento come un pezzo contribuito da uno dei suoi partner, e la persona citata e l'analisi dei costi citata provengono entrambe da Reflectiz, un fornitore nello spazio della sicurezza web. Le statistiche al suo interno provengono da terze parti nominate (Verizon, Mandiant, Cobalt, IBM e Fang et al.), mentre l'inquadramento, i criteri di valutazione e il panorama dei fornitori appartengono agli autori della guida. I lettori dovrebbero trattare i suoi confronti come un'argomentazione fatta da una parte interessata, verificare i rapporti sottostanti dove possono e giudicare qualsiasi fornitore rispetto alle domande di governance sopra. Per i proprietari di siti che vogliono aiuto esterno per applicare quel tipo di disciplina al proprio patrimonio web, AEU-I (https://aeu-i.com) fornisce servizi IT, infrastrutturali e di consulenza orientati alla sicurezza, e l'ambito di ciò che copre è esposto chiaramente sul suo sito.
Il messaggio pratico per chiunque gestisca un sito web riguarda meno l'acquisto di uno strumento e più la chiusura dei tempi. Due cose decidono se una falla diventa un incidente: quanto del tuo sito qualcuno testa effettivamente, comprese le parti dietro un login, e quanti giorni passano tra la disponibilità di una correzione e la sua applicazione. L'affermazione centrale della guida è che il secondo numero, 43 giorni in media, è quello su cui gli attaccanti contano.
Come Proteggerti
- Aggiorna il software del tuo sito, i plugin e le app non appena compaiono gli aggiornamenti, e attiva gli aggiornamenti automatici dove esiste l'opzione, perché la maggior parte delle intrusioni inizia con una falla per cui esiste già una c
- Chiedi a chi costruisce o ospita il tuo sito se i test coprono le pagine che vedi solo dopo aver effettuato l'accesso, non solo le pagine pubbliche che chiunque può raggiungere.
- Se il tuo sito ha account cliente, fai verificare da qualcuno che cambiare un numero o un nome in un link web non mostri le informazioni di un cliente a un altro.
- Attiva l'accesso in due passaggi per ogni account amministratore del tuo sito, così una password rubata da sola non basta per entrare.
- Scrivi chi è responsabile di applicare gli aggiornamenti di sicurezza e quanti giorni ha per farlo, così è una scadenza e non una speranza.
- Se paghi per un test di sicurezza, chiedi la prova di cosa è stato testato e cosa no, invece di un riassunto che elenca solo i risultati.
I Termini Spiegati
- agentic pentesting Usare robot software che lavorano da soli per cercare punti deboli di sicurezza in un sito web o in un'app, invece di una persona che lo fa una volta all'anno.
- pentesting Un tentativo pianificato di entrare nel tuo stesso sito web o sistema di proposito, per trovare i punti deboli prima dei criminali.
- IDOR Un errore di un sito web in cui il sito consegna un record solo perché qualcuno lo ha chiesto, senza verificare che chi lo chiede sia autorizzato a vederlo.
- DAST Uno strumento automatico che lancia una lista fissa di schemi di attacco noti contro un sito web e riporta cosa risponde.
- CVE Una voce di catalogo pubblico che assegna a una falla software nota un numero di riferimento standard.
- CISA KEV Una lista pubblica tenuta dall'agenzia statunitense per la cybersecurity delle falle che gli attaccanti sono noti per usare in attacchi reali.
- MFA Una seconda prova di chi sei quando effettui l'accesso, come un codice sul tuo telefono, oltre alla password.
- blast radius Quanto danno potrebbe fare qualcosa se andasse storto, in questo caso quanto lontano potrebbe arrivare uno strumento di testing fuori controllo dentro i tuoi sistemi.