Android spiazza tutti: fine delle patch mensili con RBUS. Gli hacker festeggiano?

Per 10 anni, senza alcuna interruzione, Google ha pubblicato ogni mese il Bollettino di Sicurezza Android (Android Security Bulletin, ASB). Questo tipo di attività ha rappresentato un punto di riferimento per l’intero ecosistema Android: un elenco dettagliato delle vulnerabilità corrette, con indicazioni sul livello di gravità e sui componenti coinvolti.

A nel luglio 2025, tuttavia, è accaduto qualcosa di inedito: per la prima volta, il bollettino non riportava neanche una vulnerabilità. Com’è possibile? Davvero il team Google non ha rilevato alcuna nuova problematica di sicurezza e non ha rilasciato alcuna patch correttiva?

Una rottura con la tradizione che ha generato curiosità e interrogativi. La spiegazione, arrivata solo in seguito, è che Google ha introdotto una revisione radicale del processo di aggiornamento di Android.

Aggiornamenti Android concentrati nei bollettini trimestrali

Google spiega di aver introdotto una nuova strategia che mira a bilanciare l’equilibro tra necessità reali degli utenti sul piano della sicurezza, capacità di risposta dei produttori (OEM) e gestione del ciclo di rilascio delle patch.

L’approccio portato al debutto in estate si chiama Risk-Based Update System (RBUS) e segue uno schema pragmatico. Le vulnerabilità classificate come “high-risk” – cioè sfruttate attivamente o integrate in catene di exploit note – sono incluse immediatamente nel bollettino mensile.

Le correzioni di vulnerabilità a rischio minore, anche se con severità “alta” o “critica”, sono invece accorpate nei bollettini trimestrali (marzo, giugno, settembre, dicembre).

Da qui si capisce perché il bollettino di luglio 2025 fosse vuoto, senza che ciò implichi l’assenza di vulnerabilità. Al contrario, i bollettini trimestrali tendono a diventare molto più corposi: quello di settembre 2025, ad esempio, ha registrato 119 vulnerabilità, un record assoluto.

I motivi della scelta di Google

Il modello precedente prevedeva la raccolta di tutte le correzioni validate in un bollettino mensile, con una versione privata (destinata ai partner) distribuita circa 30 giorni prima della pubblicazione sul sito Web di Android.

Secondo la visione della società di Mountain View, questo approccio aveva due limiti principali.

Molti produttori, soprattutto quelli con portafogli ampi e versioni di Android fortemente personalizzate, faticavano a integrare e distribuire patch ogni mese. Alcuni si limitavano a rilasci trimestrali o addirittura semestrali, lasciando scoperti diversi dispositivi.

Le vulnerabilità ad alto rischio, soprattutto quelle già sfruttate in attacchi reali, rischiavano di attendere troppo prima di arrivare sui dispositivi degli utenti.

Con il nuovo modello RBUS, chi vuole garantire update mensili può continuare a farlo, mentre gli altri possono concentrarsi su rilasci trimestrali più consistenti. Inoltre, nei mercati in cui gli obblighi di sicurezza sono stringenti, gli OEM possono garantire copertura con patch mensili limitate ai casi più urgenti.

I rischi e le criticità del nuovo modello

C’è da dire che il nuovo schema RBUS applicato da Google per la gestione delle patch Android desta non poche preoccupazioni.

Con i bollettini trimestrali, i partner ricevono in anticipo informazioni su decine di vulnerabilità non ancora corrette pubblicamente. Anche se il canale di distribuzione è sicuro, coinvolge migliaia di ingegneri in molte aziende: il rischio di fughe di dati non è trascurabile. In caso di leak, i criminali informatici possono disporre di settimane di vantaggio per sviluppare exploit funzionanti.

Inoltre, poiché Google ha scelto di rilasciare il codice sorgente delle patch solo in corrispondenza dei bollettini trimestrali, i progetti basati su AOSP (Android Open Source Project) – come le ROM alternative e personalizzate – non possono più garantire aggiornamenti mensili, riducendo ulteriormente la loro attrattiva e capacità di risposta.

Per progetti come GrapheneOS e “soci”, si tratta di un’ulteriore “spallata” dopo l’esclusione da AOSP del codice sorgente relativo all’ecosistema Pixel, che per gli sviluppatori indipendenti era un vero e proprio punto di riferimento.

Da ultimo, imbattersi in un bollettino vuoto come quello di luglio 2025, può suggerire agli utenti un’assenza di vulnerabilità, quando in realtà si tratta solo di una differente strategia di condivisione delle informazioni.