venerdì 02 ottobre 2026
· Maurizio Ceravolo
Nel 1994 Pirelli costruì una delle campagne pubblicitarie più famose della storia intorno a una frase che, trentadue anni dopo, sembra scritta per descrivere bene anche lo sviluppo software con l'intelligenza artificiale: Power is nothing without control. La potenza è nulla senza controllo. Oggi abbiamo a disposizione modelli capaci di scrivere codice, analizzarlo, generare test, cercare vulnerabilità, documentare sistemi e svolgere in pochi minuti attività che fino a pochi anni fa richiedevano ore. È una potenza straordinaria, e chi sviluppa software ignorandola probabilmente sta rinunciando a uno degli strumenti più importanti arrivati nella nostra professione da molto tempo.
Ma potenza e controllo non sono la stessa cosa. Negli ultimi giorni è circolata una storia che, secondo me, rappresenta perfettamente questo problema. Un ricercatore di sicurezza di sedici anni, conosciuto online come Faav, ha individuato una vulnerabilità molto grave in Titan, una piattaforma analytics interna di Microsoft. Lo spunto mi è arrivato da un articolo di Hardware Upgrade, ma la ricostruzione tecnica che segue si basa soprattutto sulla fonte primaria pubblicata dallo stesso Faav.
Ed è una storia particolarmente interessante perché contiene contemporaneamente Microsoft, AI, un errore apparentemente elementare, un sistema enorme e un essere umano che alla fine vede ciò che l'automazione non aveva visto.
Un sistema enorme protetto da un controllo che mancava
Titan è una piattaforma analitica interna di Microsoft collegata, secondo il write-up del ricercatore, a numerosi database ClickHouse. Faav ha stimato che attraverso l'ambiente raggiungibile fossero presenti complessivamente oltre 17 mila miliardi di righe. Attenzione però al numero, perché è il genere di dato che produce immediatamente titoli spettacolari.
Non significa che siano stati rubati 17 mila miliardi di record, né che esistano 17 mila miliardi di utenti coinvolti. È la dimensione stimata dei dati potenzialmente raggiungibili attraverso quel percorso di accesso. Faav racconta di aver limitato deliberatamente le proprie verifiche, utilizzando metadati e campioni minimi, e non risultano prove pubbliche di un precedente sfruttamento criminale della vulnerabilità. Il problema interessante non è quindi il numero. È come si poteva entrare.
Titan utilizzava dei JSON Web Token, o JWT, per autenticare le richieste. Dentro un token di questo tipo troviamo una serie di informazioni, chiamate claim, che possono indicare per esempio l'utente, il tenant, l'applicazione e il destinatario del token. Ma quelle informazioni sono affidabili soltanto se il sistema verifica una cosa fondamentale: la firma crittografica del token. La firma è ciò che permette al server di stabilire che quelle informazioni siano state realmente emesse da un soggetto autorizzato e non siano state modificate da chi presenta il token.
Secondo il write-up di Faav, Titan controllava diversi elementi del token: tenant, audience, application ID e identità dichiarata. Non verificava però correttamente la firma.
Il risultato è quasi paradossale. Il sistema faceva parecchi controlli, ma tutti quei controlli poggiavano su informazioni che l'attaccante poteva modificare. È un po' come un addetto alla sicurezza che controlla con estrema attenzione nome, data di nascita e indirizzo scritti su un documento, ma non controlla mai se il documento sia autentico.
E poi bastava scrivere “admin”
Una volta capito che la firma non veniva realmente utilizzata per stabilire l'autenticità del token, Faav ha potuto costruire un JWT non firmato e modificare i claim. La parte che ha reso la storia particolarmente appetibile per i titoli è arrivata dopo. Il campo upn, normalmente utilizzato per rappresentare l'identità dell'utente, veniva provato dal sistema come nome utente locale. Faav aveva tentato per molto tempo identità nel formato tipico degli account Microsoft. Poi ha provato una cosa decisamente meno sofisticata:
admin
Titan ha associato quel valore all'utente locale con privilegi amministrativi. La successiva query SQL di test è stata accettata. La cosa importante, però, non è ridurre tutta la vulnerabilità a “Microsoft aveva come password admin”, perché non sarebbe corretto. Non c'era una password admin. Il problema era molto più serio dal punto di vista architetturale: il sistema si fidava del contenuto di un token senza prima aver verificato che quel token fosse autentico.
La parola admin è soltanto l'ultimo passaggio di una catena di fiducia sbagliata.
La parte più interessante: c'era già l'AI
Questa storia sarebbe interessante anche senza intelligenza artificiale. Ma diventa molto più significativa perché Faav non ha lavorato da solo. Ha utilizzato Antares, uno strumento sviluppato da lui per automatizzare attività di security research con l'aiuto di modelli AI. Lo strumento ha individuato l'API pubblicamente raggiungibile, recuperato informazioni storiche e lavorato per giorni sui diversi errori restituiti dal sistema mentre venivano modificati i claim del JWT. Quindi l'AI ha fatto moltissimo lavoro. Ha esplorato.
Ha ripetuto test. Ha elaborato risposte. Ha ridotto enormemente il costo di una attività che manualmente avrebbe richiesto molto più tempo. Ma c'è un dettaglio che trovo bellissimo. Antares non provava admin.
Continuava a ragionare nell'ipotesi che upn dovesse contenere un'identità Microsoft nel formato atteso. È stato il ricercatore umano, tornando sul problema, a provare il valore banale che ha aperto definitivamente la porta. L'AI ha portato potenza. L'essere umano ha cambiato il modello mentale.
Questo articolo non dimostra che l'AI abbia creato il bug
Qui è necessaria una precisazione importante. Non sappiamo chi abbia scritto quel codice, quando sia stato scritto e se sia stata utilizzata o meno una AI durante lo sviluppo. Usare questa vulnerabilità per sostenere che “l'AI scrive codice insicuro” sarebbe quindi scorretto. Il caso dimostra qualcosa di diverso e, secondo me, più interessante. Microsoft è una delle aziende tecnologiche più grandi al mondo, dispone di enormi competenze ingegneristiche ed è oggi uno dei principali protagonisti dello sviluppo e dell'utilizzo dell'intelligenza artificiale.
Eppure un sistema reale può comunque contenere un errore concettualmente molto semplice nel punto più delicato dell'autenticazione. Questo dovrebbe renderci abbastanza prudenti davanti all'idea che sia sufficiente aumentare la potenza degli strumenti per eliminare la necessità di competenza tecnica.
L'AI può generare più codice. Non può trasformare automaticamente quel codice in buon software.
Funziona non significa che è progettato bene
Questo è un errore che nello sviluppo software esiste da sempre, ma con l'AI rischia di diventare più frequente. Un sistema può:
- compilare;
- superare una demo;
- autenticare correttamente gli utenti normali;
- rispondere velocemente;
- avere una interfaccia perfetta;
- superare molti test automatici;
e contemporaneamente contenere un errore architetturale grave. Nel caso Titan, il sistema eseguiva controlli sui claim. Quindi superficialmente stava facendo autenticazione. Il problema era che nessuno di quei controlli aveva senso se prima non veniva verificata l'autenticità del token. Questa differenza è esattamente il punto nel quale entra l'ingegneria.
Un programmatore può chiedersi:
“la funzione restituisce il risultato giusto?”
Un ingegnere deve anche chiedersi: “su quale assunzione sto costruendo questa funzione, e cosa succede se quella assunzione è falsa?”
La potenza senza controllo
Il famoso slogan Pirelli nasceva nel 1994 con Carl Lewis fotografato da Annie Leibovitz ai blocchi di partenza con un paio di tacchi a spillo rossi. Il concetto era semplice: avere una enorme capacità di accelerazione è inutile se non siamo in grado di governarla. Trovo difficile immaginare una metafora migliore per quello che sta succedendo oggi nello sviluppo software.
L'AI ci permette di produrre molto più velocemente:
- codice;
- API;
- query;
- test;
- documentazione;
- refactoring;
- integrazioni;
- prototipi.
Benissimo. Ma se aumentiamo di dieci volte la quantità di codice prodotto e contemporaneamente riduciamo il tempo dedicato a architettura, review, test indipendenti e comprensione del sistema, non abbiamo necessariamente aumentato la produttività. Potremmo aver semplicemente aumentato la velocità con cui produciamo debito tecnico.
Per una piccola azienda il rischio è persino maggiore
Una Microsoft può permettersi moltissime cose. Ha team di sicurezza, processi di incident response, bug bounty, ricercatori, specialisti e strutture dedicate. Faav ha segnalato il problema al Microsoft Security Response Center il 5 settembre e l'endpoint esposto risultava bloccato il 9 settembre. Quattro giorni. È una capacità di reazione notevole. Una piccola azienda può invece trovarsi con:
- un gestionale prodotto rapidamente;
- molto codice generato con AI;
- nessun security engineer;
- code review superficiale o inesistente;
- nessun threat modeling;
- nessun penetration test;
- una sola persona che conosce veramente l'architettura;
- documentazione incompleta;
- dipendenze che nessuno ha verificato.
E per mesi può sembrare che tutto funzioni perfettamente. Finché non succede qualcosa. A quel punto il costo che avevamo “risparmiato” durante lo sviluppo ritorna sotto forma di fermo operativo, consulenze urgenti, rifacimenti, perdita di dati, incident response e danno reputazionale. Questo è uno dei costi nascosti che temo quando sento dire: “con l'AI possiamo fare lo stesso software con metà degli sviluppatori.”
Forse. Ma bisogna prima capire quali sviluppatori stiamo togliendo e quale parte del loro lavoro pensiamo che l'AI abbia realmente sostituito.
Scrivere codice non è tutto il lavoro dello sviluppatore
Uno degli equivoci attuali nasce secondo me dal fatto che chi guarda lo sviluppo software dall'esterno tende a identificare il lavoro del programmatore con la digitazione del codice. Se la AI scrive codice molto più velocemente, allora servono meno programmatori. Il ragionamento sembra lineare. Solo che scrivere le istruzioni è soltanto una parte del lavoro. In un progetto serio qualcuno deve:
- capire il problema;
- trasformarlo in requisiti coerenti;
- progettare l'architettura;
- stabilire i confini di fiducia;
- scegliere tecnologie e dipendenze;
- definire standard;
- verificare il codice;
- progettare test che non confermino soltanto ciò che ci aspettiamo;
- gestire sicurezza, prestazioni e scalabilità;
- capire cosa succede nei casi che nessuno aveva previsto.
L'AI può aiutare in praticamente tutti questi punti. Ma aiutare non significa assumersi la responsabilità della decisione.
Il vero rischio è l'illusione di produttività
Qui secondo me c'è il pericolo più grande per le aziende. Con una AI è facilissimo vedere risultati immediati. Ieri servivano tre giorni per fare una funzionalità. Oggi in due ore abbiamo una demo. Il confronto sembra schiacciante.
Ma una demo misura soprattutto la velocità con cui siamo arrivati al primo risultato visibile. Non misura automaticamente:
- quanto sarà facile modificarlo fra due anni;
- quanti bug contiene;
- quanto è sicuro;
- se le scelte architetturali sono corrette;
- se rispetta davvero tutti i requisiti;
- se abbiamo duplicato logica;
- se stiamo introducendo dipendenze inutili;
- se un altro team riuscirà a manutenerlo;
- quanto costerà quando qualcosa andrà storto.
L'AI può ridurre enormemente il costo iniziale di produzione del codice. Non necessariamente riduce il costo totale del software. Anzi, se viene usata male può semplicemente spostare parte del costo più avanti, dove correggere gli errori è spesso molto più caro.
E intanto leggiamo dei licenziamenti
C'è poi una cosa che, personalmente, mi preoccupa. Negli ultimi mesi continuiamo a leggere titoli su grandi aziende tecnologiche che riducono l'organico mentre aumentano gli investimenti nell'intelligenza artificiale. Bisogna essere precisi: non tutti quei licenziamenti significano “questa persona è stata sostituita da ChatGPT”. Microsoft, per esempio, nel luglio scorso ha annunciato circa 4.800 tagli ma ha scritto esplicitamente ai dipendenti che i ruoli eliminati non venivano sostituiti dall'AI, pur riconoscendo che l'AI sta cambiando il modo in cui viene svolto il lavoro. In altri casi il collegamento è più diretto.
Atlassian ha annunciato a marzo il taglio di circa 1.600 posti, spiegando di voler riallocare risorse per finanziare ulteriori investimenti in AI e vendite enterprise. Thomson Reuters ha comunicato tagli nei team di ingegneria, con una stima fino a circa 500 ruoli, mentre nello stesso momento dichiarava di voler aggiungere nei due anni successivi più di 250 nuovi ruoli ingegneristici, in grande maggioranza senior e AI-native. Oracle ha chiuso l'anno fiscale con circa 21.000 dipendenti in meno rispetto all'anno precedente. La ristrutturazione è stata attribuita a più fattori, fra i quali anche l'adozione dell'AI. La realtà quindi è più complessa dei titoli.
Ma la direzione esiste.
Quello che mi fa paura
Questa parte è una considerazione personale. Mi fanno paura i titoli “azienda X licenzia migliaia di persone perché con l'AI ne servono meno”. Non perché penso che il modo di sviluppare software non cambierà. Sta già cambiando. E non penso neppure che gli organici debbano rimanere artificialmente identici mentre la produttività aumenta. Sarebbe assurdo sostenere che ogni innovazione debba lasciare immutato il modo in cui organizziamo il lavoro.
Quello che mi preoccupa è un'altra cosa. Mi preoccupa l'idea che una azienda possa confondere: meno tempo necessario per scrivere codice con meno necessità di ingegneri competenti.
Almeno con gli strumenti che abbiamo oggi, considero questa strategia una strada diretta verso il fallimento tecnico del progetto. Non significa necessariamente fallimento dell'azienda. Una grande organizzazione può assorbire errori, riscrivere prodotti, assumere nuovamente persone, comprare competenze all'esterno e spendere milioni per correggere ciò che non ha funzionato. Una piccola impresa molto meno.
Io farei esattamente il contrario
Se l'AI mi permette di produrre tre volte più velocemente, non userei tutto quel guadagno per eliminare controllo. Userei una parte del tempo risparmiato per aumentarlo. Più review. Più test. Più progettazione.
Più documentazione. Più security assessment. Più confronto fra persone competenti. Userei l'AI per togliere lavoro meccanico agli ingegneri e lasciare loro più tempo per fare la parte del lavoro che richiede davvero esperienza, contesto e giudizio. Perché il codice sta diventando economico.
La responsabilità tecnica no.
Microsoft non è il problema. È l'avvertimento
Il punto di questo articolo non è ridere di Microsoft. Sarebbe sciocco. Ogni software sufficientemente grande contiene bug e ogni azienda che sviluppa sistemi complessi prima o poi sbaglia. Anzi, il caso Titan mostra anche il lato positivo: un ricercatore trova un problema, lo segnala responsabilmente e Microsoft interviene rapidamente. La parte utile è un'altra.
Se una azienda con le risorse, le competenze e gli strumenti di Microsoft può avere un errore di autenticazione così elementare in un sistema reale, dovremmo avere molta cautela prima di raccontarci che basterà mettere un modello AI davanti a un progetto per rendere superflua l'ingegneria. L'AI è una enorme moltiplicazione di potenza. La useremo sempre di più. Io certamente voglio usarla sempre di più. Ma più aumenta la potenza, più deve aumentare il controllo.
Nel software quel controllo ha ancora un nome molto poco rivoluzionario: ingegneria. E forse Pirelli aveva già trovato la frase giusta nel 1994. La potenza è nulla senza controllo. ---
Fonti principali