Google ha pubblicato dati interessanti sull’adozione di Rust nel progetto Android, e i numeri confermano una cosa che fino a poco tempo fa sembrava impossibile: rendere il codice più sicuro può anche velocizzare il lavoro degli sviluppatori.

Come riporta il Security Blog di Google, nel 2025 le vulnerabilità legate alla gestione della memoria sono scese sotto il 20% per la prima volta nella storia di Android.

Perché Rust funziona (davvero)

La scelta di adottare Rust per nuove componenti di sistema non era scontata. C e C++ dominano da decenni lo sviluppo di sistemi operativi, e cambiare linguaggio in un progetto delle dimensioni di Android era una scommessa rischiosa.

I risultati però parlano chiaro: il codice Rust mostra una densità di vulnerabilità di memory safety 1000 volte inferiore rispetto a C/C++ presente in Android. E no, non è un refuso: mille volte meno.

Ma c’è un altro dato che forse è ancora più significativo per chi sviluppa ogni giorno: il codice scritto in Rust richiede il 25% di tempo in meno nelle code review e ha un tasso di rollback 4 volte inferiore rispetto al C++. In pratica, chi scrive Rust produce codice che funziona meglio al primo colpo.

I numeri dello sviluppo

Google ha analizzato le metriche usando il framework DORA, lo standard de facto per misurare le performance dei team di sviluppo. Quello che emerge è che il volume di nuovo codice Rust ormai rivaleggia con quello del C++ nel progetto Android.

Le revisioni necessarie per integrare modifiche in Rust sono circa il 20% in meno rispetto a quelle per C++. Questo significa meno cicli di rework, meno tempo sprecato, meno attrito tra i team.

I rollback, ovvero quando bisogna fare marcia indietro perché qualcosa non funziona, sono particolarmente costosi. Non si tratta solo di riscrivere codice: coinvolgono meeting, post mortem, nuove procedure di sicurezza, e bloccano altri team. Con Rust questi eventi sono drasticamente ridotti.

Il primo (quasi) bug

A ottobre 2024 Google ha assegnato il CVE-2025-48530 a una vulnerabilità trovata in CrabbyAVIF, una libreria Rust per la gestione delle immagini AVIF. Era un buffer overflow, proprio il tipo di bug che Rust dovrebbe prevenire.

La buona notizia? Non è mai arrivato agli utenti. Il crash è stato rumoroso e facilmente individuabile, permettendo di fixare tutto prima del rilascio.

Questo episodio ha però sollevato la domanda: se anche Rust può avere bug di memory safety, qual è il vantaggio?

Il 4% che fa la differenza

Circa il 4% del codice Rust in Android usa i blocchi unsafe{}, che permettono di aggirare le protezioni del linguaggio quando necessario (ad esempio per interfacciarsi con hardware o codice C). Alcuni temevano che questo 4% potesse essere un tallone d’Achille.

I dati dimostrano il contrario. Con circa 5 milioni di righe di Rust in Android e una sola potenziale vulnerabilità trovata (e corretta prima del rilascio), la densità è di 0.2 vulnerabilità per milione di righe. Per C/C++ in Android siamo a circa 1000 vulnerabilità per milione di righe.

Questo succede probabilmente perché:

• I blocchi unsafe sono piccoli e ben delimitati
• Vengono scrutinati con più attenzione durante le review
• L’ecosistema Rust spinge verso pattern più sicuri anche quando usi unsafe
• Le API di Rust tendono a far emergere i problemi prima

Oltre Android

Google sta ora espandendo l’uso di Rust ad altri progetti e l’approccio è pragmatico: non si tratta di riscrivere tutto, ma di usare Rust dove ha più senso, specialmente per nuovo codice e componenti critiche per la sicurezza.

La lezione più importante forse è questa: la sicurezza non deve più essere un compromesso. Non è più “scegliamo se andare veloci o essere sicuri”. Con gli strumenti giusti forse si possono fare entrambe le cose.