Un agent AI ha ricontrollato 10 mila alert cloud: tre quarti…

Studio di Sola Security su 9.967 finding HIGH: il 58,5% viene abbassato e il 16,6% alzato. Le severita statiche dei vendor CSPM non rispecchiano il rischio reale in

Il 13 ottobre 2026 Sola Security rende pubblico il risultato di un esperimento in produzione: un agent AI con accesso read-only agli ambienti cloud ha ricontrollato 9.967 finding classificati HIGH da due piattaforme commerciali, e ne ha modificato il grado di severita nel 75,1% dei casi. Lo studio, non ancora replicato indipendentemente, si limita a finding HIGH in otto account AWS e non misura dati di incidente o recall rate dell'agent. Il dato non e una prova di superintelligenza, ma una misura del disallineamento sistemico tra le regole dei vendor CSPM e la realta operativa degli ambienti sottoposti a verifica.

La posta in gioco e la coda di remediation che i team cloud gestiscono ogni giorno, ordinata per severita che nel 58,5% dei casi sovrastima il rischio e nel 16,6% lo sottostima.

Punti chiave

Sola Security ha testato un agent AI su 9.967 finding HIGH severity da due piattaforme commerciali in otto ambienti di produzione: il 58,5% e stato downgraded, il 16,6% upgraded.
Il 32,3% dei downgrade riguarda risorse inerti, orfane o non collegate a percorsi di attacco reali.
Il 49,0% dei verdeti dell'agent si e basato su evidence esterna alla risorsa flaggata, da risorse connesse o altri prodotti di sicurezza.
Probe read-only su AWS hanno confermato i fatti dell'agent nel 99,4% dei casi verificabili; l'accuratezza conservativa scende all'81,8% se si contano tutti i finding non verificabili come errati, cioe quei casi in cui il probe non poteva stabilire i fatti per mancanza di visibilita o dati insufficienti.

Come funziona la riclassificazione contestuale

L'agent opera con una metodologia articolata in due fasi: una "theory of exploitation" che modella il percorso di attacco specifico per ogni risorsa, e una "evidence collection" che verifica connettivita, esposizione internet, servizi live e controlli compensativi tramite API cloud e asset graph. Non si limita a riapplicare il CVSS environmental score: ricostruisce lo stato effettivo della rete, dei gruppi di sicurezza e delle dipendenze tra risorse.

Leon Goldberg e Gal Engelberg, autori dello studio, scrivono che "a static severity reflects the risk of the condition in general, and a queue ordered by it is ordered by the general case". La regola vendor, cioe, trasporta il contesto che il suo autore ha potuto codificare una volta per tutti gli ambienti; il contesto che decide quanto valga quella condizione in un dato ambiente "lies elsewhere".

L'agent lo recupera, e il risultato e che 599 regole vendor hanno emesso una severita unica su 99.073 finding totali, indipendentemente dalla risorsa o dall'ambiente.

Il pattern del 32,3%: risorse che non possono essere attaccate

Il pattern piu frequente di downgrade, quasi un terzo del totale, riguarda risorse inerti, orfane o non collegate. Non si tratta di falsi positivi tecnici: la condizione rilevata dalla regola vendor esiste, ma la risorsa non e raggiungibile, non e associata a un servizio live, o e isolata in modo che l'exploit teorico non abbia un percorso praticabile.

La severita statica misura il rischio della condizione in astratto; l'agent misura il rischio della condizione in quella specifica topologia di rete. Il dato si collega a un problema noto nel cloud security management: le piattaforme CSPM generano volumi di alert che i team non riescono a smaltire, e la priorita e determinata da un punteggio che non incorpora lo stato di runtime.

Lo studio di Sola Security quantifica per la prima volta, su una popolazione di quasi diecimila finding, l'entita di questo disallineamento in ambiente di produzione.

"The rule-severity gap is large in production, and closing it requires evidence from the whole environment"

Le regole che sbagliano in entrambe le direzioni

Un dato meno intuitivo emerge dall'analisi delle 138 regole con piu finding: 62 hanno prodotto risultati sia downgradati che upgradati, e per 57 di queste entrambi gli esiti si sono verificati nello stesso ambiente. La stessa regola, applicata a risorse diverse dello stesso account, ha richiesto correzioni opposte. Non e un problema di regola troppo sensibile o troppo rigida: e un problema di regola senza contesto.

L'evidence map dello studio documenta un caso esemplare: una security group rule e stata downgraded quando associata a un load balancer interno, e raised quando lo stesso tipo di regola si trovava su un percorso esposto a internet. La condizione e identica, il vendor assegna la stessa severita, il rischio effettivo e diverso.

Il 49,0% dei verdeti si e basato su evidence esterna alla risorsa flaggata, confermando che la valutazione del rischio richiede un campo di visibilita piu ampio di quello del singolo asset.

Cosa cambia

La transizione da severity statiche a re-grading evidence-based non e una soluzione completa, ma ricalibra il trade-off tra coverage e precisione che i team cloud affrontano quotidianamente. Le piattaforme CSPM tendono a preferire la coverage: piu regole attive generano piu finding, e piu finding coprono piu superficie di attacco. Il costo e l'alert fatigue, con team che spendono tempo su risorse inerti mentre risorse esposte restano in coda con la stessa etichetta HIGH.

Goldberg e Engelberg chiariscono che "verified, environment-specific reading of each finding is a precondition for acting on findings autonomously". La distinzione e netta: la lettura contestuale e prerequisito, non attivazione, dell'automazione. L'agent dello studio ha operato in modalita read-only; il re-grading e raccomandazione di priorita, non azione di remediation.

Il dilemma industriale resta aperto: i vendor CSPM usano regole statiche per design, non per negligenza. Una severita unica per condizione e scalabile e deterministicamente riproducibile. Integrare il contesto runtime richiede accesso continuo allo stato degli asset, capacita di reasoning sulle dipendenze di rete, e governance dei permessi di un agent di terze parti che legga l'intero environment. Il 92% dei finding re-graded proviene da AWS, con solo l'8% da altri cloud: la generalizzabilita a piattaforme diverse resta da verificare.

Per i team operativi, l'implicazione e piu modesta e piu immediata: prima di riordinare la coda di remediation, verificare se il finding HIGH in testa alla lista riguarda una risorsa effettivamente esposta o una risorsa orfana che la regola vendor ha classificato con la stessa severita di un percorso di attacco reale.

Questo articolo si basa su un unico studio empirico pubblicato da Sola Security su Help Net Security. I dati non sono stati replicati indipendentemente e lo scope e limitato a otto ambienti AWS e a finding HIGH severity.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter