L’annuncio è arrivato dopo la denuncia di un ricercatore di sicurezza: Grok Build, l’assistente di coding di xAI, avrebbe caricato segretamente interi repository privati dei clienti in un bucket di archiviazione Google Cloud controllato dall’azienda . Il CEO di OpenAI Sam Altman ha definito «preoccupante» la questione della privacy dei dati .
Il piano di Musk contiene tre elementi chiave:
Restano però da chiarire aspetti essenziali: non è stato annunciato quando avverrà la pubblicazione, dove sarà ospitato il codice, quale licenza verrà adottata o quali componenti rientreranno nella definizione tecnica di «intero codice» .
La promessa di luglio amplia drasticamente un impegno assunto da Musk a gennaio 2026. Allora aveva annunciato che il nuovo algoritmo di raccomandazione di X, basato su Grok, sarebbe stato reso open source entro sette giorni. Il piano comprendeva il codice usato per scegliere i post organici e gli annunci mostrati agli utenti, oltre ad aggiornamenti ogni quattro settimane accompagnati da note tecniche per spiegare le modifiche .
Quella promessa aveva quindi un perimetro preciso: il motore che stabilisce l’ordine dei contenuti nel feed «Per te» e la selezione dei post pubblicitari. Il 20 gennaio 2026 xAI ha pubblicato su GitHub l’algoritmo di raccomandazione basato su Grok con licenza Apache 2.0, continuando poi con aggiornamenti periodici .
L’annuncio del 15 luglio rappresenta un salto di scala: non più soltanto il sistema di raccomandazione, ma l’intero codebase di X, senza esclusioni, più un controllo esterno per dimostrare che il codice pubblico corrisponda a quello in produzione . Se realizzata, sarebbe un’iniziativa molto più ampia della precedente apertura dell’algoritmo, già considerata insolita per una grande piattaforma social .
Se X mantenesse l’impegno, ricercatori esterni, giornalisti e autorità di controllo potrebbero analizzare più a fondo il funzionamento della piattaforma: dai sistemi di moderazione dei contenuti alla logica di selezione degli annunci, fino alla gestione dei dati e alla configurazione dell’infrastruttura .
La verifica sul sistema in produzione sarebbe particolarmente importante. Pubblicare codice non significa necessariamente dimostrare che quel codice sia quello effettivamente utilizzato: un’azienda potrebbe, in teoria, rendere disponibile una versione diversa o incompleta. Il confronto condotto da revisori indipendenti punta proprio a colmare questo divario .
Tuttavia, «open source» non equivale automaticamente a «trasparenza assoluta». Per essere davvero verificabile, il progetto dovrebbe spiegare con precisione quali servizi, dipendenze, configurazioni e procedure sono inclusi. E anche in quel caso, leggere il codice non sarebbe sufficiente per ricostruire da soli ogni decisione della piattaforma, soprattutto quando entrano in gioco dati, modelli e sistemi distribuiti.
Rendere pubblico un codice di produzione così ampio potrebbe offrire vantaggi alla comunità di sicurezza, ma anche fornire agli aggressori una mappa dettagliata dell’infrastruttura. I principali rischi sono almeno quattro:
Il contesto del 2026 rende la decisione ancora più delicata. Le CVE attribuibili a codice generato dall’intelligenza artificiale sono passate da 6 a gennaio a 35 a marzo 2026, quasi sei volte tanto in due mesi . Un’analisi ha stimato che il numero reale di falle sfruttabili introdotte dagli strumenti di coding basati sull’IA nei repository open source pubblici potrebbe essere da cinque a dieci volte superiore a quello confermato: tra 400 e 700 casi osservabili, senza contare i codebase aziendali privati .
La Open Source Security Foundation (OpenSSF) ha inoltre avvertito del rischio di un grande attacco informatico basato sull’IA contro l’infrastruttura open source. Christopher Robinson, CTO della fondazione, ha descritto un simile evento come un’inevitabilità, non una semplice possibilità, citando la combinazione tra capacità dell’IA in rapida crescita, incentivi economici per gli aggressori e risorse limitate a disposizione dei manutentori .
Uno studio del dicembre 2025 ha rilevato vulnerabilità nel 45% delle attività di sviluppo che coinvolgevano codice generato dall’IA; le richieste di modifica assistite dall’IA producevano 2,74 volte più problemi di sicurezza rispetto a quelle scritte esclusivamente da esseri umani . Se il codice di X includesse componenti generati dall’IA o non sottoposti a revisioni sufficienti, la pubblicazione potrebbe rendere sfruttabili difetti ancora sconosciuti.
Al momento della pubblicazione non risultavano commenti specifici di esperti di sicurezza sull’annuncio del 15 luglio, che era stato diffuso solo da poche ore. Esistono però precedenti e valutazioni generali sui rischi di rendere pubblico il codice di una grande piattaforma.
Nel 2022, quando Musk aveva già ipotizzato di pubblicare l’algoritmo di Twitter durante l’acquisizione, Jamie Moles, senior sales engineer della società di cybersicurezza ExtraHop, aveva riconosciuto il valore della trasparenza, avvertendo però che il codice avrebbe potuto essere adottato da altre piattaforme social, inserzionisti e soggetti interessati a studiare più da vicino il funzionamento del servizio. La stessa informazione utile ai ricercatori può infatti aiutare anche gli attaccanti .
Altri esperti hanno sottolineato il problema di fondo: rendere il sistema trasparente per i ricercatori legittimi significa renderlo, almeno in parte, trasparente anche per i soggetti malintenzionati . A questo si aggiungono la difficoltà di verificare ogni componente in esecuzione e l’impossibilità di ritirare davvero dal pubblico una vulnerabilità dopo che il codice è stato distribuito.
La promessa del 15 luglio 2026 è molto più ambiziosa della precedente apertura dell’algoritmo. X si è impegnata, nelle parole di Musk, a rendere pubblico l’intero codebase senza eccezioni e a consentire verifiche indipendenti sul sistema reale .
Ma per ora manca il calendario e mancano le specifiche tecniche. Non sappiamo quando terminerà la revisione, quando arriverà il repository, quale licenza verrà applicata o che cosa X considererà parte dell’intero codice .
Il vero test non sarà quindi l’annuncio, ma la capacità di trasformarlo in una pubblicazione completa, aggiornata e verificabile senza esporre inutilmente utenti e infrastruttura. In un ecosistema in cui la scoperta automatizzata delle vulnerabilità accelera, le falle medie per codebase sono più che raddoppiate e l’OpenSSF prevede una minaccia significativa per l’infrastruttura open source , la trasparenza potrebbe diventare uno strumento di fiducia oppure una nuova superficie d’attacco. Per X, la differenza dipenderà soprattutto da come questa promessa verrà messa in pratica.