Applicazioni web e mobile, API, infrastrutture cloud, sistemi IoT e OT e, sempre più spesso, componenti basati su AI e LLM stanno facendo crescere la superficie d’attacco molto più rapidamente della capacità delle organizzazioni di sottoporla a verifiche approfondite.

Il problema, però, non è soltanto trovare più vulnerabilità.

Per un CISO è soprattutto necessario comprendere quali debolezze possano essere realmente sfruttate, con quale impatto e secondo quale priorità debbano essere corrette.

È su questa distanza tra vulnerabilità rilevata e rischio effettivamente dimostrato che interviene il modello di offensive security sviluppato da Unguess Security basato sulla combinazione tra agenti AI specializzati ed ethical hacker, finalista ai Cybersecurity360 Awards. L’automazione aumenta velocità e capacità di analisi, mentre la componente umana interviene per verificare riproducibilità, impatto e contesto dei finding prima che questi vengano restituiti al cliente.

La definizione utilizzata dall’azienda, “hacker-in-control”, sintetizza bene il principio: non sostituire il penetration tester con l’intelligenza artificiale, ma utilizzare l’AI per estendere le capacità dell’offensive security mantenendo il controllo umano sui passaggi più delicati.

Il vulnerability management ha un problema di priorità

Gli scanner automatici hanno permesso alle organizzazioni di aumentare enormemente la capacità di individuare vulnerabilità.

Ma maggiore capacità di detection non significa necessariamente migliore capacità di gestione del rischio.

Una scansione può produrre centinaia o migliaia di finding. Vulnerabilità teoricamente critiche possono risultare difficilmente sfruttabili nello specifico contesto, mentre debolezze apparentemente meno rilevanti possono diventare pericolose quando vengono concatenate con altre condizioni presenti nell’infrastruttura.

Il risultato è un problema ormai familiare ai security team: troppi segnali e risorse insufficienti per verificarli e correggerli tutti con la stessa priorità.

Il penetration testing tradizionale risolve almeno in parte questa criticità introducendo l’analisi umana, ma normalmente opera all’interno di finestre temporali definite. L’articolo di presentazione del progetto contrappone infatti l’approccio continuativo di Unguess alle due o tre settimane indicate per un VA/PT tradizionale.

La domanda diventa allora: è possibile combinare la capacità di scala dell’automazione con la profondità dell’analisi di un ethical hacker?

AI penetration testing: l’agente non lavora da solo

È questo il problema al quale prova a rispondere l’architettura sviluppata da Unguess.

Il sistema utilizza più agenti specializzati, ciascuno incaricato di svolgere una parte del processo di offensive security.

La prima fase è quella dell’Intelligent Reconnaissance, nella quale vengono effettuati scanning dello scope, enumerazione dei servizi, fingerprinting delle applicazioni web e mappatura della superficie d’attacco.

Segue l’Attack Planning: i risultati vengono suddivisi in attività sulla base della tipologia degli asset e vengono definiti i percorsi d’attacco considerati più probabili.

Il passaggio è significativo perché avvicina il modello alla logica del penetration testing: l’obiettivo non consiste semplicemente nell’associare una vulnerabilità a una versione software, ma nel tentare di comprendere come quella debolezza possa inserirsi in un possibile scenario d’attacco.

Dallo scanning alla Controlled Exploitation

È nella fase successiva che emerge la differenza più evidente rispetto a un vulnerability scanner.

La Controlled Exploitation permette di verificare vulnerabilità quali SQL injection, cross-site scripting, SSRF, remote code execution, misconfigurazioni e vulnerabilità delle API all’interno di ambienti monitorati.

In termini di gestione del rischio, il cambio di prospettiva è importante.

Un CVE o un finding indicano l’esistenza potenziale di una debolezza. Dimostrare che quella debolezza è effettivamente sfruttabile significa invece produrre un’informazione molto più utile per stabilire una priorità di remediation.

Per il CISO, dunque, la domanda può passare da “quante vulnerabilità abbiamo?” a “quali vulnerabilità può realmente utilizzare un attaccante?”.

Ed è una differenza tutt’altro che semantica quando bisogna decidere dove concentrare budget, persone e finestre di intervento.

La doppia validazione come barriera ai falsi positivi

Il progetto introduce poi un passaggio particolarmente interessante dal punto di vista della governance dell’AI.

Il finding prodotto durante l’exploitation non viene automaticamente consegnato al cliente. Viene sottoposto prima a un agente indipendente di verifica e successivamente al team Unguess.

Soltanto dopo questa doppia validazione viene pubblicato insieme alla proof-of-exploitation, all’analisi dell’impatto e alle indicazioni di remediation prioritizzate. I risultati possono quindi essere integrati, anche tramite API, nei workflow operativi utilizzati dall’organizzazione, come Jira.

Unguess dichiara che la validazione umana prima della consegna elimina il problema dei falsi positivi. È opportuno considerare questa come un’affermazione del fornitore; più interessante, dal punto di vista architetturale, è il principio sottostante: l’output dell’AI non viene considerato automaticamente affidabile.

Ed è forse una delle lezioni più importanti del progetto.

Hacker-in-control: l’automazione non elimina il controllo umano

L’espressione human-in-the-loop viene utilizzata ormai in moltissimi sistemi AI. Nel campo dell’offensive security, tuttavia, assume un significato particolare.

Qui l’AI non sta generando un testo o classificando un documento: sta partecipando a un processo progettato per individuare e sfruttare vulnerabilità.

Diventano quindi fondamentali isolamento, controllo delle azioni, definizione dello scope e osservabilità.

Secondo la descrizione del progetto, ogni agente opera all’interno di un ambiente Docker isolato, con esecuzione sandboxed e browser automation tramite Playwright. Un orchestratore centrale coordina reconnaissance, attacco, verifica e reporting sotto la supervisione dei cybersecurity engineer.

Il cliente, dal canto suo, definisce scope e regole d’ingaggio, mentre la gestione degli agenti, dei ricercatori, del triage e del reporting rimane in capo al servizio.

La tecnologia aumenta quindi l’autonomia operativa senza eliminare il perimetro di autorizzazione.

Quando gli agenti AI diventano strumenti dual use

Questo punto merita un’attenzione particolare.

Le stesse capacità che consentono a un agente AI di effettuare reconnaissance, identificare possibili percorsi d’attacco e tentare exploitation controllate sono, per loro natura, dual use.

Possono cioè aumentare la produttività dei defender, ma capacità analoghe possono essere utilizzate anche dagli attaccanti.

Per questo l’elemento più interessante del progetto non è soltanto ciò che gli agenti riescono a fare, ma come viene governato ciò che possono fare.

Sandboxing, scope, supervisione, verifica indipendente e tracciabilità delle attività diventano parte integrante dell’architettura di sicurezza.

In altre parole, nell’AI offensive security il guardrail non è un elemento accessorio applicato dopo lo sviluppo: deve essere parte del modello operativo.

Continuous testing contro la fotografia del penetration test

C’è poi un secondo cambiamento rilevante.

Il penetration test tradizionale restituisce inevitabilmente una fotografia dell’organizzazione in un determinato momento. Ma applicazioni, API, configurazioni cloud e componenti software cambiano continuamente.

La possibilità di automatizzare parte delle attività permette invece di avvicinare l’offensive security a un modello di continuous testing.

Unguess affianca all’AI una community composta, secondo quanto dichiarato dall’azienda, da oltre 100 security researcher italiani sottoposti a un processo di selezione e in possesso di certificazioni specialistiche. La piattaforma centralizza inoltre informazioni provenienti da AI Pentest, Bug Bounty e attività VA/PT e consente di effettuare verifiche delle patch su richiesta.

La conseguenza è un possibile cambio di paradigma: il penetration testing può progressivamente smettere di essere soltanto un appuntamento periodico per diventare un processo maggiormente integrato nel ciclo di gestione delle vulnerabilità.

Dalla vulnerability detection alla remediation

Trovare una vulnerabilità, tuttavia, rimane soltanto la prima parte del problema.

Il valore per l’organizzazione emerge quando il finding può essere trasformato rapidamente in un’attività di remediation, assegnato al team competente e successivamente verificato.

Da questo punto di vista, proof-of-exploitation, analisi dell’impatto, prioritizzazione e integrazione con i sistemi di ticketing contribuiscono a ridurre la distanza tra offensive security e security operations.

È una caratteristica particolarmente rilevante in un contesto nel quale NIS2, DORA e Cyber Resilience Act stanno aumentando l’attenzione verso processi strutturati di gestione delle vulnerabilità. La piattaforma viene infatti presentata da Unguess anche come strumento a supporto di questi processi.

Il punto, ancora una volta, non è produrre più finding. È fare in modo che quelli prodotti siano utilizzabili.

Il rischio non si misura contando le vulnerabilità

È probabilmente questa la considerazione più utile che il progetto porta ai CISO.

Per anni il vulnerability management è stato fortemente condizionato dalla quantità: numero di vulnerabilità individuate, severità CVSS, patch mancanti, asset interessati.

Sono informazioni indispensabili, ma non sempre sufficienti per comprendere il rischio.

Sapere che una vulnerabilità esiste è diverso dal dimostrare che possa essere sfruttata nel proprio ambiente. E sapere che può essere sfruttata è ancora diverso dal comprenderne l’impatto sui processi aziendali.

Il modello hacker-in-control tenta di ridurre questa distanza facendo lavorare insieme due capacità complementari: la velocità e la scalabilità dell’automazione agentica e la capacità dell’essere umano di validare, contestualizzare e assumersi la responsabilità del risultato.

È qui che l’AI penetration testing può diventare realmente interessante per le aziende. Non quando promette di sostituire l’hacker, ma quando permette all’hacker di concentrare competenze e tempo sui passaggi nei quali il giudizio umano produce maggiore valore.

Per i CISO la prospettiva cambia di conseguenza: l’obiettivo non dovrebbe essere trovare il maggior numero possibile di vulnerabilità, ma ridurre il tempo necessario per individuare quelle realmente sfruttabili, comprenderne l’impatto, correggerle e verificare che la remediation sia stata efficace.

È il passaggio dalla scansione alla prova. E, soprattutto, dalla quantità dei finding alla qualità della decisione.