La portata dell'individuazione delle vulnerabilità basata sull'IA non ha precedenti. Nel suo primo mese di attività, Project Glasswing, il consorzio di partner per la sicurezza difensiva di Anthropic che utilizza il modello Mythos, ha rilevato 6.202 vulnerabilità di gravità elevata o critica in oltre 1.000 progetti open source. Una verifica indipendente condotta su un sottogruppo di questi risultati ha confermato una percentuale di veri positivi del 90,6%.2
Questi dati danno già un’indicazione importante. Ciò che merita un’attenzione immediata è la loro risoluzione. Su circa 23.000 vulnerabilità individuate, solo 75 sono state corrette e documentate nei primi mesi. Lo afferma Thomas Tschersich, CSO di Deutsche Telekom, il quale ha anche osservato che alcuni fornitori e gestori di software hanno chiesto ad Anthropic di rallentare la frequenza delle segnalazioni perché non riescono fisicamente ad assorbire le correzioni con sufficiente rapidità.3
Il Verizon Data Breach Investigations Report (DBIR) del 2026 conferma questo modello a livello di settore. Per la prima volta nei suoi 19 anni di storia, il DBIR ha rilevato che lo sfruttamento delle vulnerabilità ha superato il furto di credenziali e il phishing come principale vettore di accesso iniziale per le violazioni, rappresentando il 31% di tutti gli incidenti. Il volume delle istanze di vulnerabilità ha raggiunto i 527,3 milioni nel 2025, un numero otto volte superiore rispetto al dato del 2022. Intanto, il tempo mediano per l'applicazione completa delle patch è peggiorato, salendo a 43 giorni e la percentuale di vulnerabilità sfruttate note alla Cybersecurity and Infrastructure Security Agency (CISA) che sono state completamente corrette è scesa dal 38% al 26%.4
Nel giugno del 2026, Anthropic ha segnalato che altre aziende e sviluppatori di IA avrebbero realizzato capacità di IA offensive equivalenti entro 6-12 mesi. La finestra a disposizione dei provider di servizi per prepararsi è ristretta e si sta chiudendo.5
Perché i provider di servizi sono particolarmente esposti
Le reti di telecomunicazioni sono tra gli ambienti tecnologici più complessi in assoluto. Sono anche tra i più presi di mira e al centro di una serie di sfide specifiche.
Infrastruttura obsoleta, precedente ai moderni modelli di sicurezza. Come ha osservato nel 2024 Dave Harcourt, Chief Security Authority di BT, gran parte dell'infrastruttura di telecomunicazioni oggi operativa è stata progettata in un'epoca che non ha mai previsto l'attuale panorama delle minacce.6 I provider di servizi gestiscono vasti ambienti brownfield: decenni di elementi di rete, sistemi operativi e protocolli stratificati tra loro nel corso di anni caratterizzati da espansioni, fusioni e transizioni tecnologiche. Oltre il 45% delle vulnerabilità rilevate in questi ambienti resta senza patch dopo 12 mesi.4
Una superficie di attacco con poche analogie in qualsiasi settore. L'ambiente del provider di servizi comprende sistemi di fatturazione e gestione delle relazioni con i clienti (CRM), protocolli della rete centrale come SIP e Diameter, API (application programming interface) per l'architettura basata sui servizi 5G, infrastrutture di routing e trasporto, sistemi di intercettazione legale e milioni di dispositivi di rete. Gran parte di tutto questo esegue software proprietario di fornitori, su cui i provider di servizi non possono eseguire audit o applicare patch in modo indipendente.
Attacchi sistematici da parte di autori di minacce sofisticate. La campagna Salt Typhoon ha compromesso almeno nove provider di servizi statunitensi, accedendo ai sistemi di intercettazione legale e ai record di dettaglio delle chiamate di oltre 1 milione di utenti.7 I tempi di permanenza fino a due anni sono passati inosservati. A Singapore, la campagna UNC3886 ha violato tutti e quattro i provider di servizi nazionali, richiedendo una contro-operazione coordinata di 11 mesi.9 In Canada, un autore di minacce ha sottratto almeno 700 TB di dati a un importante provider di servizi.10 Non si tratta di incidenti isolati, bensì di campagne durature e dotate di ampie risorse, rivolte nello specifico all'infrastruttura delle telecomunicazioni.
La dipendenza da fornitori condivisi introduce rischi associati. I provider di servizi in tutto il mondo si affidano a un gruppo ristretto di fornitori di apparecchiature per le reti di accesso radio (RAN), nonché per l'infrastruttura di trasporto e della rete centrale. Una vulnerabilità nel software di un singolo fornitore interessa più provider di servizi contemporaneamente. L'interconnessione tra provider aggiunge una seconda dimensione di rischio associato: discutendo del motivo per cui il settore ha istituito il C2 ISAC, Mark Clancy, il responsabile della sicurezza informatica di T-Mobile, ha osservato che in casi come le frodi relative a SIM box, un operatore può rilevare il dispositivo sulla propria rete mentre il server di comando e controllo risiede sull'infrastruttura di un altro provider, richiedendo a entrambi di indagare in modo congiunto.11
Misure di difesa attuali: notevoli progressi con una lacuna critica
Il settore non è rimasto a guardare. Sono emerse tre iniziative fondamentali in risposta diretta all'evoluzione del panorama delle minacce. Ciascuna di esse offre un valore concreto, ma lascia irrisolta una lacuna specifica.
Project Glasswing offre alle organizzazioni partecipanti l'accesso a Mythos per la scansione proattiva delle vulnerabilità. Hanno aderito oltre 200 organizzazioni in 15 paesi, tra cui provider di servizi come Verizon, AT&T e BT. Glasswing ha già evidenziato migliaia di risultati critici nell'ambito di progetti open source alla base dell'infrastruttura dei provider di servizi. Tuttavia, la sua portata ha dei limiti. Nokia, Ericsson e altri importanti provider di apparecchiature di rete (NEP) non sono tra i membri. Il software proprietario eseguito sulle apparecchiature RAN, della rete centrale e di trasporto, che costituisce la vera e propria spina dorsale delle reti dei provider di servizi, non viene sottoposto a scansione. I provider di servizi non possono eseguire audit o applicare patch a questo codice in modo indipendente. Il ciclo di correzione rimane interamente vincolato alle tempistiche dei fornitori.
C2 ISAC riunisce i CISO di otto principali provider di servizi statunitensi per la condivisione di intelligence in tempo reale, riservata al solo settore privato. Colma una carenza critica di coordinamento, consentendo loro di condividere indicatori di compromissione, tecniche degli aggressori e playbook di mitigazione alla velocità richiesta dalle operazioni. Tra i primi risultati figurano tecniche di rilevamento di SIM box tra diversi provider di servizi e risposte coordinate alle reti proxy residenziali. Tuttavia, C2 ISAC attualmente si concentra sugli Stati Uniti, non ha tra i membri provider di servizi internazionali, e non vede la partecipazione di fornitori NEP o di sistemi di supporto operativo/sistemi di supporto al business (OSS/BSS). Si tratta di un meccanismo di condivisione dell'intelligence, non di un motore di correzione.
Gli ISAC e i framework regionali, tra cui GSMA T-ISAC (globale), ET-ISAC (Europa), ICT-ISAC (Giappone) e altri, aggiungono ulteriori livelli di sensibilizzazione, allineamento normativo e cooperazione internazionale. L'ET-ISAC europeo organizza conference call quindicinali di CERT-SOC (Computer Emergency Response Team-Security Operations Center) e stabilisce un benchmark annuale per la sicurezza. GSMA T-ISAC include fornitori e provider di servizi, a differenza di quanto fa attualmente C2 ISAC. Si tratta di strutture preziose per la visibilità e la preparazione. Tuttavia, nessuna di esse distribuisce patch.
L'elemento comune alle tre iniziative è l’incremento della rapidità con cui il settore rileva e condivide le informazioni sulle minacce. Tuttavia, queste iniziative non accelerano i tempi con cui le vulnerabilità vengono effettivamente corrette.
Tschersich di Deutsche Telekom ha identificato il problema principale commentando direttamente i risultati di Glasswing: "L'IA individua le vulnerabilità più rapidamente che mai. Tuttavia, individuarle più rapidamente non significa correggerle più in fretta. Ogni giorno risparmiato nell'applicazione delle patch conta."3
I piani di correzione sono in crisi: ecco dove risiede il rischio reale
I dati parlano chiaro. La principale sfida di sicurezza del settore si è spostata dal rilevamento alla correzione.
Il 90% del codice delle applicazioni aziendali è costituito da dipendenze open source o di terze parti. La base di codice open source media verificata da Black Duck presenta ora 581 vulnerabilità note, un numero raddoppiato in un solo anno.12 Il tempo medio di exploit è sceso a -7 giorni, il che significa che gli aggressori sfruttano abitualmente le vulnerabilità un'intera settimana prima della disponibilità delle patch.13
Gli attuali approcci di correzione non riescono a tenere il passo. Quando uno strumento di scansione segnala una CVE (Common Vulnerabilities and Exposures) critica in una dipendenza open source transitiva, la risposta standard richiede agli sviluppatori di analizzare il problema, scaricare una nuova versione del pacchetto, ricompilare l'applicazione, verificare l'assenza di modifiche che causano interruzioni e, spesso, riscrivere il codice per adattarlo alla nuova versione. Negli ambienti regolamentati, in cui i provider di servizi devono mantenere configurazioni software testate e certificate, gli upgrade forzati delle versioni possono attivare cicli completi di ricertificazione.
Gli strumenti di scansione svolgono un lavoro fondamentale. Indicano ai team responsabili della sicurezza dove si trovano i problemi. Ma non li risolvono. L'output di uno scanner è una dashboard che mostra dei risultati. Tra la dashboard e un artefatto corretto, firmato e pronto per la produzione si trova il punto in cui si accumula il rischio.
Le soluzioni alternative interne, che prevedono il fork dei pacchetti per correggere manualmente le vulnerabilità, l'accettazione di backlog di rischio e il rinvio degli upgrade per preservare la stabilità, creano a loro volta problemi. Ogni fork interno si discosta dall'upstream, generando oneri permanenti di manutenzione. Gli elementi di rischio si trasformano in mancanza di conformità in sede di audit. I ritardi negli upgrade aumentano il debito tecnico. Nessuno di questi approcci è scalabile, quando l'IA genera migliaia di segnalazioni di vulnerabilità ogni mese.
