L'IA sta trovando vulnerabilità critiche più velocemente di quanto Teams possa risolverle

Negli ultimi 90 giorni abbiamo eseguito pentest autonomi su vari sistemi di produzione — e i risultati sono difficili da ignorare.
Le applicazioni moderne non sono solo vulnerabili. Sono vulnerabili in modo continuo.
Il problema non è che i team non testino la sicurezza. È che oggi gli attaccanti operano a velocità macchina, mentre test e remediation avvengono ancora con tempi umani.
Con l’AI che accelera la scoperta delle vulnerabilità, la finestra tra l’introduzione di un bug e il suo sfruttamento si sta riducendo. Se test e correzioni non si muovono alla stessa velocità, quel divario diventa la superficie d’attacco.

Quello che vediamo sul campo

In 28 aziende, i nostri agenti hanno identificato:

• ~2000 vulnerabilità totali

• 44,6% critiche o ad alta gravità (829 risultati)

• 21,6 vulnerabilità per scansione in media (mediana: 15)

• Nel 65,1% delle scansioni è emerso almeno un problema critico

• Picco: 88 vulnerabilità in una singola scansione

Non si tratta di rischi teorici. Ogni risultato viene convalidato con uno sfruttamento proof-of-concept funzionante.
Quasi la metà di tutte le vulnerabilità che abbiamo trovato è grave, e la maggior parte dei sistemi presenta almeno un problema critico.
Ancora più preoccupante è il tipo di vulnerabilità dietro questi numeri. Non si tratta di semplici errori di configurazione o dipendenze obsolete. Sono problemi più profondi nel modo in cui le applicazioni sono progettate e si comportano.

Non sono bug semplici

I problemi più comuni che vediamo sono i logic flaw.
Un logic flaw significa che il sistema si comporta esattamente come è stato programmato, ma il design stesso non è sicuro.
Non sono errori di configurazione o librerie obsolete. Sono bug nel modo in cui l’applicazione funziona davvero, nel modo in cui scorrono i dati, nel modo in cui vengono applicati i permessi e nel modo in cui i sistemi si fidano l’uno dell’altro.

Ecco come si presenta in pratica:

• IDOR (Insecure Direct Object Reference) — 177 risultati
  Gli attaccanti possono accedere o modificare i dati di altri utenti semplicemente cambiando gli identificatori (per esempio ID utente, ID file). Questo può esporre dati sensibili su larga scala o persino consentire la compromissione dell’account.

• SSRF (Server-Side Request Forgery) — 122 risultati
  Gli attaccanti possono indurre il server a fare richieste per loro conto, spesso verso sistemi interni. Questo può esporre API interne, credenziali cloud o infrastrutture che non dovrebbero mai essere accessibili pubblicamente.

• Autenticazione mancante — 105 risultati
  Endpoint o azioni sensibili sono accessibili senza effettuare il login. Questo significa che chiunque su internet può attivare funzionalità critiche o accedere a dati protetti.

Queste vulnerabilità sono particolarmente pericolose perché sfruttano il comportamento dell’applicazione, non solo la sua configurazione.
I scanner tradizionali qui fanno fatica perché non capiscono il comportamento. Cercano firme, non la logica.

Perché l’AI trova di più

Fino a poco tempo fa, trovare e sfruttare questo tipo di vulnerabilità richiedeva tempo, competenza e lavoro manuale.
Questo è cambiato.

Gli agenti AI ora possono interagire con le applicazioni come farebbe un attaccante umano, ma con una scala e una velocità completamente diverse.
Non si limitano a scansionare gli endpoint, li esplorano.

• Mettono alla prova i casi limite

• Collegano più passaggi tra loro

• Iterano rapidamente su migliaia di possibilità

Invece di controllare problemi noti, sondano attivamente il comportamento di un’applicazione e cercano modi per romperla. Non dormono mai. La loro giornata lavorativa non finisce mai. Hanno memorizzato la base di conoscenza del mondo.
Questo cambiamento è ciò che sta guidando i risultati che vediamo: una scoperta costante di problemi critici nella maggior parte delle scansioni.

Perché l’open source può accelerare la scoperta delle vulnerabilità

L’open source cambia il modo in cui le vulnerabilità vengono scoperte.
Immagina di scegliere una serratura. Quando conosci il funzionamento interno della serratura, è molto più facile aprirla.
Quando i sistemi AI hanno accesso al codice sorgente, possono analizzare direttamente ogni percorso di codice invece di dedurre il comportamento dall’esterno.
In test di benchmark controllati usando il XBow validation suite disponibile pubblicamente, l’accesso al codice sorgente ha aumentato il rilevamento delle vulnerabilità di circa 20% rispetto al black-box testing.
Vediamo questo divario anche in scenari reali.
Con visibilità completa, gli agenti AI possono:

• Tracciare i flussi di dati dall’inizio alla fine

• Identificare assunzioni errate nella logica di business

• Esplorare i casi limite in modo molto più efficiente

Questo rende i logic flaw significativamente più facili da trovare e sfruttare.
Man mano che sempre più applicazioni vengono costruite in modo aperto e i sistemi AI migliorano, la velocità di scoperta delle vulnerabilità continua ad aumentare.
Detto questo, il fatto di essere closed source non ti rende sicuro per impostazione predefinita.
La sicurezza per oscurità non è mai stata una vera difesa. Un attaccante determinato, con abbastanza potenza di calcolo e abbastanza token da consumare, può comunque enumerare, fare fuzzing e alla fine scoprire percorsi sfruttabili, anche senza accesso diretto al codice.
Quindi il punto non è scegliere tra open o closed source. È adattare il modo in cui testi e proteggi i sistemi.
Indipendentemente dall’architettura, le valutazioni tradizionali puntuali non colgono nel segno. I codebase evolvono a velocità macchina, e lo stesso vale per le superfici d’attacco.

Il vero problema: maggiore velocità = costo minore

Fino a qualche anno fa, trovare e sfruttare le vulnerabilità richiedeva tempo, competenza e pazienza.
Oggi, quella tempistica si è compressa.
I sistemi AI possono:

• Eseguire migliaia di test in parallelo

• Esplorare continuamente nuovi percorsi di codice

• Collegare automaticamente più exploit tra loro

Questo significa che le vulnerabilità vengono scoperte più velocemente che mai, spesso entro ore o giorni dalla loro introduzione.
Ma la maggior parte delle organizzazioni non si è ancora adattata a questo cambiamento.
I test di sicurezza vengono ancora trattati come un evento periodico:

• Una volta all’anno

• Forse una volta al trimestre

E la remediation spesso procede ancora più lentamente, aspettando la priorità, la disponibilità del team engineering e i cicli di release. Persino il tempo necessario per portare il codice in produzione crea lacune che sistemi più veloci possono sfruttare.
Questo crea un divario sempre più ampio:

• Le vulnerabilità vengono scoperte a velocità macchina

• Le correzioni vengono distribuite con tempi umani

Quel divario è la vera superficie d’attacco.
Se una vulnerabilità critica esiste per giorni o settimane prima di essere corretta, non importa come sia stata scoperta. È sfruttabile.
Il modello tradizionale “testa, segnala, correggi più tardi” semplicemente non regge quando sia gli attaccanti sia i sistemi di scoperta operano in modo continuo.
Quel modello è già superato.

Cosa funziona davvero

Il cambiamento non riguarda gli strumenti. Riguarda l’approccio.
La sicurezza deve passare da:

• Test puntuali → testing continuo

In pratica, non si tratta solo di un cambio di strumenti.
Richiede di ripensare a come la sicurezza si inserisce nel ciclo di sviluppo.
Il testing continuo di solito combina:

• Sistemi automatizzati che eseguono test in modo continuo, non solo una volta all’anno

• Sicurezza integrata direttamente nelle pipeline CI/CD

• Sviluppatori che si occupano dei problemi e li correggono come parte dei normali workflow

• Test umani periodici per percorsi di attacco più profondi e complessi

Non è qualcosa che la maggior parte dei team può risolvere solo assumendo più persone.
Il testing manuale non scala abbastanza da tenere il passo con la velocità dello sviluppo moderno o degli attaccanti moderni.
Per questo stiamo vedendo uno spostamento verso l’automazione e, in molti casi, verso l’outsourcing del testing continuo a sistemi che possono operare a velocità macchina.
L’urgenza qui è reale.

E adesso?

L’AI sta già accelerando la scoperta delle vulnerabilità. Gli attaccanti non stanno aspettando il tuo prossimo pentest programmato.
Se la tua applicazione cambia ogni giorno, il tuo security testing e la tua capacità di correggere i problemi devono tenere il passo.
Indipendentemente dall’architettura, le valutazioni tradizionali puntuali non colgono nel segno. I codebase evolvono a velocità macchina, e lo stesso vale per le superfici d’attacco.
I sistemi open source devono riconoscere e gestire l’esposizione aggiuntiva che deriva dalla visibilità del codice. I sistemi closed source, invece, non possono affidarsi all’oscurità e dovranno migliorare anche il proprio livello di sicurezza.
Il divario tra quanto velocemente costruiamo software e quanto spesso lo testiamo si sta ampliando.
L’AI sta accelerando entrambi i lati, ma al momento gli attaccanti hanno il vantaggio.
Se non stai scalando attivamente la sicurezza per stare al passo con la minaccia, i tuoi sistemi falliranno.

Il benchmark citato sopra (XBow) è disponibile pubblicamente su GitHub. I nostri risultati combinano test di benchmark controllati con dati reali di sistemi di produzione su tutta la nostra piattaforma.