Oltre l'automazione: perché l'aumento delle vulnerabilità di sicurezza basate sull'IA richiede un supporto tecnico umano

In futuro gli storici ricorderanno la primavera del 2026 come l'inizio della segnalazione delle vulnerabilità di sicurezza basate sull'IA. Il 7 aprile, Anthropic ha annunciato l'anteprima del suo modello di IA, Claude Mythos, messo a disposizione di aziende selezionate nell'ambito del Project Glasswing. L'iniziativa ha affermato di aver rilevato migliaia di vulnerabilità di gravità elevata e critica nell'ecosistema open source. Tre settimane dopo, l'iniziativa Xint ha annunciato una vulnerabilità legata all'escalation dei privilegi locali del kernel Linux denominata Copy Fail. Pochi giorni dopo, il mondo ha scoperto un'altra vulnerabilità, chiamata Dirty Frag, seguita da un'altra, chiamata Fragnesia. Ne seguiranno altre.

Project Glasswing, Copy Fail e Dirty Frag condividono problemi in termini di divulgazione responsabile. Project Glasswing ha condiviso poche informazioni fruibili, nonostante l'ampio risalto dato al progetto. I ricercatori di Copy Fail hanno condiviso i risultati con gli sviluppatori di kernel.org, ma non con i fornitori di sistemi. Qualcuno ha divulgato prematuramente i dettagli di Dirty Frag, costringendo il ricercatore Hyunwoo Kim a rivelare i dettagli in un thread di email pubblico, prima che chiunque potesse sviluppare le patch.

Questo articolo del blog esamina la risposta di Red Hat a Copy Fail e spiega in che modo il servizio Technical Account Management per la sicurezza dei prodotti può aiutare le organizzazioni a gestire il proprio profilo di sicurezza in questa nuova era di divulgazione rapida e incessante generata dall'IA.

Cronologia e background di Red Hat Product Security

Il team Red Hat Product Security è un leader nella community della sicurezza IT dal 2001 e si è costantemente evoluto di pari passo con il panorama delle minacce. 

CVE.org gestisce la reportistica delle vulnerabilità software nel settore IT utilizzando un concetto chiamato Common Vulnerabilities and Exposures (CVE). Una CVE Numbering Authority (CNA) è un'organizzazione membro che pubblica i CVE. CVE.org conta oltre 500 membri CNA in tutto il settore IT. Una CNA-LR è una CVE Numbering Authority di ultima istanza. Le organizzazioni che ne fanno parte si affidano a queste autorità per risolvere le controversie sui CVE. Le organizzazioni root insegnano alle altre CNA come inviare i CVE.

Oggi Red Hat è l'unica azienda del settore privato al mondo a ricoprire il ruolo di CNA-LR, e una delle sole due aziende del settore privato a ricoprire il ruolo root. Ciò significa che Red Hat detiene una meritata posizione di rispetto, responsabilità e fiducia in tutto il settore. Spesso siamo noi a tradurre un complesso commit del kernel in qualcosa di fruibile, mentre il resto del mondo insegue i titoli dei giornali.

Con l'aumento della segnalazione delle vulnerabilità di sicurezza basate sull'IA, il panorama delle minacce non si limita a evolversi, ma accelera. Mozilla ha recentemente collaborato con Anthropic per individuare 22 bug sensibili alla sicurezza nel proprio motore JavaScript, seguiti da altre 271 vulnerabilità in un passaggio successivo, che ha esaminato l'intero codebase del browser. Nell'intero ecosistema software, entro la metà di maggio 2026, gli strumenti di rilevamento basati sull'IA, guidati in gran parte da Mythos, hanno segnalato oltre 10.000 potenziali problemi, l'equivalente di quasi un anno di rilevamento tradizionale in sole due settimane.

Red Hat si trova nel bel mezzo di questa esplosione. Nel 2025, Red Hat Product Security ha analizzato 7.722 vulnerabilità di sicurezza. Nei primi quattro mesi del 2026, dal 1° gennaio al 30 aprile, il numero era pari a 2.826: di questo passo, il totale annuale potrebbe arrivare a 8.596. Dal 1° maggio al 15 maggio 2026, il numero di vulnerabilità sottoposte a triage è salito a 712, dato che proietta il totale a oltre 17.000 per l'intero anno, ovvero più del doppio rispetto al 2025.

Copy Fail: il primo di molti a seguire

Ogni giorno, CVE.org pubblica centinaia di record di vulnerabilità. Il 22 aprile 2026 una CNA, kernel.org, ha pubblicato 100 vulnerabilità, numerate da CVE-2026-31431 a CVE-2026-31530. 

CVE-2026-31431 fornisce questa descrizione.

“Nel kernel Linux è stata risolta la seguente vulnerabilità: crypto: algif_aead - Revert to operating out-of-place Questo ripristina principalmente il commit 72548b093ee3, fatta eccezione per la copia dei dati associati. L'esecuzione in loco in algif_aead non offre alcun vantaggio, poiché la sorgente e la destinazione provengono da mappature diverse. Elimina tutta la complessità aggiunta per l'operazione in loco e limita la procedura a copiare direttamente i dati associati.”

Non c'era nulla di cui entusiasmarsi finché, una settimana dopo, il 29 aprile, un servizio denominato Xint.io di un'azienda chiamata Theori ha pubblicato un attacco proof-of-concept denominandolo Copy Fail. Dietro quella descrizione arcana si nascondeva un mezzo che consentiva a qualsiasi utente locale senza privilegi, su bare metal, in una macchina virtuale (VM) o all'interno di un container, di ottenere l'accesso root a un sistema.

Fortunatamente, questo attacco richiede l'accesso alla macchina. Un malintenzionato deve prima effettuare l'accesso. Purtroppo, Red Hat ed altre distribuzioni Linux hanno appreso dell'attacco lo stesso giorno in cui il pubblico ne è venuto a conoscenza.

Gli articoli di stampa e le discussioni online sono esplosi. La corsa era iniziata.

Red Hat Product Security ha immediatamente aggiornato la valutazione di gravità di questo CVE a Important e ha aggiornato il proprio bollettino sulla sicurezza con una strategia di mitigazione e una tempistica di risoluzione. Red Hat ha rilasciato il primo di molti avvisi di sicurezza cinque giorni dopo, il 4 maggio. Molti altri sono seguiti rapidamente.

Ma la storia non finisce qui.

Distribuzione ai clienti

Entro mezzogiorno, negli Stati Uniti Il 12 maggio, secondo l'ora legale centrale, Copy Fail ha generato 1.132 richieste di supporto da parte di clienti che utilizzano Red Hat Enterprise Linux (RHEL), Red Hat OpenShift e Red Hat OpenStack. Più tardi, a maggio, il numero è cresciuto fino a superare i 1.300 casi. Molte di queste richieste di supporto includevano domande dettagliate o problemi complessi che non possono essere inseriti in un semplice documento di domande frequenti (FAQ). Eccone alcune.

• Alcune organizzazioni dipendono da applicazioni con supporto limitato o nullo, che tendono a smettere di funzionare in seguito ad aggiornamenti e patch del sistema operativo. In questa nuova era di patch e aggiornamenti rapidi e frequenti, queste applicazioni presentano rischi ancora maggiori.
• Sorgono sempre domande su come utilizzare i punteggi del Common Vulnerability Scoring System (CVSS) per valutare il rischio. La risposta migliore è: dipende. I punteggi CVSS assegnano i livelli di gravità in modo isolato. La valutazione del rischio dipende dalle specifiche del cliente e richiede il giudizio umano.
• Come si può tenere il passo con un flusso infinito di problemi segnalati dall'IA? Cercare di "correggere tutto" è un approccio fallimentare. Invece di interrompere costantemente le attività per l'applicazione delle patch, progetta l'ambiente IT in modo da mitigare le vulnerabilità con una difesa approfondita, usa il tradizionale giudizio umano per valutare quali vulnerabilità rappresentano effettivamente una minaccia per il tuo ambiente specifico e applica le patch a queste ultime.
• Almeno un cliente doveva sapere come applicare le patch a OpenStack 17.1, che dipende da Red Hat Enterprise Linux 9.2. La risposta è stata utilizzare il flusso di rilascio SAP di Red Hat Enterprise Linux 9.2.
• Un altro cliente aveva bisogno di sapere cosa sarebbe successo se avesse utilizzato kernel più recenti con patch insieme a sistemi Red Hat Enterprise Linux 8 meno recenti. 
• Alcune organizzazioni utilizzavano versioni obsolete di OpenShift e avevano bisogno di una strategia per le patch.
• Molti avevano bisogno di aiuto per coordinare la distribuzione delle patch con i team delle applicazioni che richiedono l'assenza di tempi di fermo.
• Altre organizzazioni erano preoccupate per le prestazioni.
• Diverse organizzazioni avevano bisogno di aiuto con le analisi dei rischi per varie iniziative di conformità.
• In numerosi casi, i clienti hanno richiesto dichiarazioni ufficiali di Red Hat da condividere con i dirigenti.

Questi sono solo alcuni esempi. I timori legati alla sicurezza sono sempre fonte di stress e riteniamo utile collaborare direttamente con i clienti per separare le speculazioni dalla realtà, soprattutto quando emergono notizie sul bug di Linux più allarmante degli ultimi dieci anni. 

Per un partner commerciale, la necessità di colmare il divario tra l'innovazione upstream e le protezioni di sicurezza di livello enterprise non è mai stata così evidente.

Servizio Red Hat Technical Account Management per la sicurezza dei prodotti

Per aiutare a gestire situazioni di sicurezza simili, Red Hat ora offre il servizio Red Hat Technical Account Management per la sicurezza dei prodottiPagina disponibile in Inglese (Italiano non disponibile). I Technical Account Manager (TAM) fungono da collegamento tra i clienti e i gruppi di prodotto e di ingegneria di Red Hat e della community open source. Mentre la maggior parte dei TAM si concentra su un particolare prodotto o tecnologia, i TAM per la sicurezza di Red Hat si concentrano in modo olistico sull'impronta di sicurezza dell'intero portafoglio prodotti Red Hat. Questi TAM aiutano a:

• condividere formazione ad hoc sulle varie tattiche di attacco;
• aiutare i clienti a utilizzare gli strumenti di sicurezza e conformità di Red Hat;
• suggerire configurazioni e distribuzioni potenziate, a seconda dei casi;
• spiegare come Red Hat aiuta a ridurre i rischi e a mitigare le vulnerabilità;
• fornire un'analisi delle vulnerabilità più accurata per i prodotti Red Hat;
• fornire assistenza nel triage dei report di scansione delle vulnerabilità;
• facilitare la comunicazione con i clienti, i team Red Hat, i partner, gli altri fornitori e la community open source, ove possibile;
• influenzare la gestione dei prodotti Red Hat, i team di sicurezza dei prodotti, i partner, gli altri fornitori e la community open source rappresentando il punto di vista dei clienti;
• promuovere la consapevolezza sulla catena di valore del software e sugli attacchi alla supply chain;
• offrire consulenza sulle potenziali misure di mitigazione per affrontare i principali incidenti di sicurezza;
• contribuire a produrre valutazioni in seguito agli incidenti di sicurezza.

La comunicazione continua è sempre di importanza critica, soprattutto durante un'emergenza, e ancora di più quando l'IA aumenta la velocità e la gravità delle segnalazioni delle vulnerabilità di sicurezza. I TAM di Red Hat security sono in una posizione privilegiata per aiutare i clienti a distinguere tra le informazioni importanti e quelle irrilevanti, e ad affrontare altre problematiche. 

Per stare tranquilli

In questa nuova era di segnalazioni di vulnerabilità basate sull'IA, la principale minaccia non è il volume dei bug, ma l'eccessiva dipendenza dall'automazione. L'IA può individuare le vulnerabilità, ma non può fornire una strategia di sicurezza basata sul rischio o garantire l'integrità necessaria per sostenere l'organizzazione durante una crisi. Il giudizio umano rimane l'unico elemento su cui puoi davvero contare. L'interruzione dei processi di divulgazione responsabile rappresenta un'ulteriore minaccia, perché ogni volta che qualcuno rivela una nuova vulnerabilità prima che gli sviluppatori possano rilasciare una mitigazione o una patch, consente agli aggressori di cogliere i clienti impreparati.

Nessuno può garantire la completa immunità dagli attacchi, ma i Red Hat security TAM possono aiutare collaborando strettamente con Red Hat Product Security e la community, per fornire l'orientamento strategico e il supporto tecnico che l'IA non può offrire. 

La capacità di riconoscere un attacco reale o ottenere qualche ora di preavviso su un attacco imminente, può fare la differenza tra l'applicazione di una mitigazione all’ultimo minuto e un'emergenza. Non aspettare la prossima divulgazione critica per proteggere la tua infrastruttura. Scopri di più su come un Red Hat security TAM fornisce la pianificazione proattiva e il supporto tecnico di cui la tua organizzazione ha bisognoPagina disponibile in Inglese (Italiano non disponibile).

Contatta il tuo account team Red Hat per saperne di più, oppure chiedi a Red Hat.
 

Trova i riferimenti accedendo al database CVE di Red Hat, leggibile in chiaro, selezionando un intervallo di date appropriato e osservando il conteggio in fondo alla pagina.