Il giorno in cui 8,5 milioni di computer sono morti — e ciò che mi ha insegnato sul costruire software che non può fallire
Ero seduto nella hall di un hotel a Hyderabad quando il mio telefono ha iniziato a vibrare. Non il solito rivolo di notifiche Slack: era un'inondazione. L'intera flotta di macchine Windows di un cliente era diventata blu. Poi un altro cliente. Poi è arrivata la notizia: aeroporti che bloccavano i voli a terra, ospedali che annullavano interventi chirurgici, banche che congelavano le transazioni. Tutto a causa di un singolo aggiornamento di un file di CrowdStrike più piccolo della foto che faresti al tuo pranzo.
19 luglio 2024. Il giorno in cui circa 8,5 milioni di sistemi Windows si sono schiantati simultaneamente nella Blue Screen of Death. Il giorno che avrebbe finito per costare all'economia globale oltre 10 miliardi di dollari di danni. E il giorno in cui sono diventato ossessionato da una domanda che ancora mi tiene sveglio la notte: Perché stiamo costruendo i sistemi più critici della storia umana su fondamenta che possono essere distrutte da un file di configurazione?
Dirigo Veriprajna, una società di consulenza sull'IA. Costruiamo quelle che io chiamo soluzioni di "Deep AI": sistemi che si integrano con l'infrastruttura di base, non i sottili wrapper di ChatGPT che dominano il mercato in questo momento. Quando è successa l'interruzione di CrowdStrike, metà del settore dell'IA ha alzato le spalle. "Problema di sicurezza", hanno detto. "Non è il nostro campo." Ma io ho visto qualcosa di diverso. Ho visto esattamente la stessa fragilità architetturale che affligge ogni azienda che si precipita a innestare l'IA sulle proprie operazioni senza capire cosa sta accadendo al di sotto.
Ho passato mesi dopo l'interruzione a smontare l'analisi delle cause profonde, a seguire il contenzioso di Delta Air Lines e a studiare la ricerca emergente sulla verifica formale. Ciò che ho scoperto ha cambiato il modo in cui il mio team costruisce ogni cosa. Ho scritto qui un'analisi interattiva completa dell'intero studio, ma questo saggio è la storia dietro la ricerca: le parti che non entrano ordinatamente in un whitepaper.
Un file più piccolo di un JPEG ha messo in ginocchio l'aviazione mondiale
Ecco cosa è successo davvero, spogliato dal gergo.
La piattaforma di sicurezza Falcon di CrowdStrike gira all'interno del kernel di Windows, lo strato più profondo e privilegiato del sistema operativo. Pensalo come la sala macchine di una nave. Se qualcosa va storto in coperta, puoi ripararlo. Se qualcosa va storto nella sala macchine, la nave affonda.
Per individuare rapidamente le nuove minacce, CrowdStrike ha costruito un sistema chiamato "Rapid Response Content". Invece di distribuire aggiornamenti software completi (che sono lenti e richiedono test), distribuiscono piccoli file di configurazione, in sostanza fogli di istruzioni che dicono al motore di sicurezza quali schemi cercare. È ingegnoso. È anche, come abbiamo appreso, spaventosamente pericoloso.
Quella mattina, sono stati distribuiti due nuovi set di istruzioni per rilevare un tipo specifico di comunicazione tra processi. Queste istruzioni facevano riferimento a 21 parametri di input. Il problema? Il motore in esecuzione su ogni endpoint, il codice effettivo che gira nel kernel, ne comprendeva solo 20 parametri.
Il cloud diceva "leggi 21 campi". Il kernel ne conosceva solo 20. Quel disallineamento ha mandato in crash 8,5 milioni di computer.
Il validatore nel cloud ha approvato l'aggiornamento perché la sua definizione del template includeva 21 campi. Verificava rispetto alle proprie aspettative, non rispetto alla realtà di ciò che l'endpoint poteva gestire. Quando l'interprete a livello di kernel ha tentato di accedere a quel ventunesimo campo, ha letto oltre il confine della memoria allocata. Nello spazio del kernel, non è un errore recuperabile. È un crash istantaneo. Schermata blu. Riavvio. Crash di nuovo. Riavvio. Crash di nuovo. Un ciclo di morte infinito.
Ricordo di aver spiegato tutto questo a un investitore non tecnico durante una cena qualche settimana dopo. Mi ha fissato e ha detto: "Quindi mi stai dicendo che nessuno ha testato se la cosa che riceveva l'aggiornamento fosse davvero in grado di elaborare l'aggiornamento?" Ho annuito. Ha posato la forchetta. "Questo non è un bug del software. Questa è negligenza."
Non aveva torto. E un giudice in Georgia gli avrebbe sostanzialmente dato ragione.
Perché 40.000 server hanno dovuto essere sistemati a mano
La parte della storia che non riceve abbastanza attenzione è il ripristino, o meglio, l'impossibilità del ripristino da remoto.
Ecco l'ironia crudele: l'agente di CrowdStrike è la cosa che riceve i comandi dal cloud. "Annulla questo aggiornamento." "Applica questa correzione." Ma il crash è avvenuto così presto nella sequenza di avvio che l'agente non si è mai inizializzato. Il software che avrebbe dovuto ricevere il segnale di soccorso era proprio la cosa che causava l'annegamento.
Il mio team ha iniziato a chiamarlo il problema dell'"Agente Morto". Ogni macchina colpita era orfana. Non poteva chiamare casa. Non poteva ricevere istruzioni. L'unica soluzione era avviare fisicamente ogni macchina in Modalità provvisoria, navigare fino a C:\Windows\System32\drivers\CrowdStrike\ e cancellare manualmente il file difettoso.
Per Delta Air Lines, ciò significava mettere mano a circa 40.000 server e migliaia di postazioni di lavoro. A mano. Una alla volta.
In passato ho gestito operazioni di ripristino IT, e la logistica di quella scala è quasi incomprensibile. Serve accesso fisico a macchine che potrebbero trovarsi in sale server chiuse a chiave in città diverse. Servono tecnici che sappiano come avviare in Modalità provvisoria, il che, in un'era di crittografia BitLocker, spesso richiede chiavi di ripristino conservate su... altri server anch'essi in crash. È tartarughe fino in fondo.
I concorrenti di Delta — American Airlines, United — si sono ripresi entro uno-tre giorni. L'interruzione di Delta è durata oltre cinque giorni e ha portato a più di 7.000 voli cancellati e 550 milioni di dollari di perdite. La differenza? Il sistema di tracciamento degli equipaggi di Delta, il software che dice alla compagnia aerea dove si trovano i suoi piloti e assistenti di volo e quando sono disponibili, girava quasi interamente su Windows. Quando quei server sono morti, Delta non ha perso solo dei computer. Ha perso la capacità di sapere dove fossero le proprie persone.
Cosa succede quando un bug del software diventa "colpa grave"?
È qui che la storia si sposta dalla sala server all'aula di tribunale, ed è qui che credo le implicazioni diventino davvero capaci di cambiare il settore.
Delta ha citato in giudizio CrowdStrike. Questo da solo non sorprende: le aziende citano in giudizio i fornitori dopo i grandi fallimenti in continuazione. Ciò che sorprende è ciò che il giudice ha permesso di procedere.
Storicamente, i fornitori di software sono stati protetti dai loro contratti. Sepolto nei termini di servizio c'è sempre un tetto alla responsabilità, di solito limitato a quanto il cliente ha pagato per l'abbonamento. È un accordo comodo. Vendi software che opera al livello più profondo dell'infrastruttura di un cliente, e se distrugge tutto, la tua massima esposizione è pari a dodici mesi di canoni di licenza.
Nel maggio 2025, la giudice Kelly Lee Ellerbe della Fulton County Superior Court ha rifiutato di archiviare le richieste di Delta relative a colpa grave e — questa è quella che mi ha fatto raddrizzare sulla sedia — violazione informatica.
L'argomentazione sulla colpa grave è semplice: CrowdStrike ha distribuito l'aggiornamento a tutti gli 8,5 milioni di sistemi simultaneamente. Nessun rilascio graduale. Nessun deployment canary. Nessun "proviamolo prima sull'1% delle macchine e vediamo cosa succede". Gli avvocati di Delta hanno sostenuto che ciò rappresentava una consapevole indifferenza verso rischi noti. Il rapporto post-incidente della stessa CrowdStrike ha ammesso che il Content Validator aveva un errore logico e che il Content Interpreter era privo di un controllo dei limiti a runtime.
Ma la richiesta relativa alla violazione informatica è quella che dovrebbe terrorizzare ogni fornitore SaaS che legge questo articolo. Delta aveva disattivato gli aggiornamenti automatici nelle proprie impostazioni. CrowdStrike ha distribuito l'aggiornamento comunque, attraverso il meccanismo dei channel file a livello di kernel. La giudice ha stabilito che gli obblighi di legge relativi alla violazione informatica sono indipendenti dal contratto di abbonamento, il che significa che il tetto alla responsabilità previsto dal contratto non si applica.
Quando un fornitore scavalca le tue preferenze esplicite per inserire codice nel tuo kernel, il tetto alla responsabilità del contratto potrebbe non proteggerlo. Questa è la nuova realtà giuridica.
Ho parlato con tre diversi CISO da quando è stata emessa questa sentenza, e ognuno di loro ha detto la stessa cosa: "Stiamo riscrivendo i nostri contratti con i fornitori." L'era della fiducia illimitata negli aggiornamenti automatici dei fornitori di sicurezza è finita.
Il parallelo scomodo con il settore dell'IA
Ora ecco dove sarò schietto, e dove alcuni dei miei colleghi nel settore dell'IA non gradiranno ciò che ho da dire.
Il settore dell'IA sta costruendo sulle stesse fondamenta fragili che CrowdStrike ha messo a nudo. Lo stiamo solo facendo più velocemente e con più clamore.
Il mercato in questo momento è dominato da ciò che io chiamo "wrapper di LLM": sottili strati applicativi che effettuano chiamate API a GPT-4 o Claude, avvolgono la risposta in una bella interfaccia e la chiamano prodotto di IA. Ho visto pitch deck di aziende la cui intera architettura tecnica è letteralmente "inviamo un prompt a OpenAI e mostriamo il risultato". Sono valutate decine di milioni di dollari.
L'anno scorso ero a una conferenza dove un fondatore ha dimostrato con orgoglio il proprio "strumento di analisi della sicurezza basato sull'IA". Ho posto una domanda semplice: "Cosa succede se OpenAI cambia la propria API, aumenta i prezzi di 10 volte o va offline per sei ore?" Mi ha guardato come se avessi chiesto cosa succede se la gravità smette di funzionare. "Non succederà", ha detto.
Succederà. Succede sempre. L'interruzione di CrowdStrike ha dimostrato che persino i fornitori di infrastrutture più fidati, quelli su cui hai scommesso la tua intera operazione, possono distribuire un singolo file difettoso e far crollare tutto.
È per questo che abbiamo costruito Veriprajna attorno a ciò che io chiamo "Deep AI", e voglio essere preciso su cosa intendo, perché il termine viene usato con leggerezza.
Una soluzione di Deep AI non affitta la propria intelligenza da un singolo fornitore terzo. Utilizza architetture ibride — modelli linguistici piccoli e specializzati, modelli visione-linguaggio, reti neurali a grafo — distribuite sull'infrastruttura del cliente quando il caso d'uso lo richiede. Si integra a livello di sistema, non a livello di interfaccia. E, cosa fondamentale, utilizza la verifica formale per fornire garanzie matematiche sul proprio comportamento, non semplici congetture probabilistiche.
La differenza conta. Un wrapper di LLM ti dà un chatbot che di solito ha ragione. Un sistema di Deep AI ti dà un motore dimostrabilmente corretto per lo specifico compito che è progettato per svolgere.
Perché sono diventato ossessionato dalla verifica formale
Sarò onesto: prima dell'interruzione di CrowdStrike, pensavo che la verifica formale fosse una curiosità accademica. Qualcosa su cui i ricercatori pubblicavano articoli e che nessuno usava in produzione. Il microkernel seL4 — un kernel di sistema operativo verificato formalmente — era impressionante ma sembrava un risultato unico nel suo genere che aveva richiesto anni di lavoro a livello di dottorato.
Poi ho letto l'analisi delle cause profonde di CrowdStrike per la terza volta, e qualcosa è scattato.
L'intero disastro si riduceva a un divario semantico. Il validatore nel cloud credeva che il template avesse 21 campi. L'interprete sull'endpoint credeva ne avesse 20. Due componenti dello stesso sistema nutrivano convinzioni contraddittorie sulla realtà, e nessuno se ne è accorto perché non esisteva una specifica condivisa e matematicamente rigorosa rispetto alla quale entrambi i componenti fossero verificati.
La verifica formale elimina i divari semantici. Utilizza dimostrazioni matematiche per garantire che il software — l'implementazione effettiva — soddisfi sempre la propria specifica. Non "di solito". Non "nei nostri test". Sempre. Se la dimostrazione regge, il software non può violare la propria specifica. Punto.
Il mio team ha passato settimane l'anno scorso a sperimentare con un framework chiamato VeCoGen, che combina grandi modelli linguistici con motori di verifica formale per generare automaticamente codice C verificato. L'LLM propone implementazioni candidate, e un verificatore di dimostrazioni conferma matematicamente la correttezza prima che qualsiasi cosa venga distribuita. Se il codice ha un bug — anche uno sottile come un errore di off-by-one nel confine di un array — la dimostrazione fallisce e il codice viene rifiutato.
Ricordo la prima volta che siamo riusciti a farlo funzionare su un esempio non banale. Il mio ingegnere capo, che era stato scettico sull'intera impresa, ha guardato l'output verificato e ha detto: "Quindi l'IA scrive il codice e la dimostrazione che il codice è corretto?" Sì. E il verificatore di dimostrazioni è un sistema separato e fidato a cui non importa nulla di quanto l'IA sia sicura della propria risposta: gli importa solo della verità matematica.
Stiamo entrando in un'era in cui il codice generato dall'IA sarà preferito al codice scritto a mano, non perché l'IA sia più intelligente, ma perché l'IA può generare la dimostrazione matematica insieme all'implementazione.
Martin Kleppmann ha fatto questa previsione di recente, e credo che abbia perfettamente ragione. Il "verificatore di dimostrazioni" diventa il guardiano. Nessuna dimostrazione, nessun deployment. È l'opposto del modello CrowdStrike, in cui il validatore in sostanza timbrava gli aggiornamenti basandosi sulle proprie assunzioni.
E se il sistema avesse potuto guarire se stesso?
C'è un dettaglio sul 19 luglio che mi perseguita. Il crash è avvenuto a livello globale, su tutti gli 8,5 milioni di endpoint, perché non esisteva alcun meccanismo automatizzato per rilevare lo schema del guasto e fermare il rilascio in tempo reale.
Pensaci. Milioni di macchine hanno iniziato a bloccarsi simultaneamente. I segnali di telemetria c'erano — letture di memoria fuori dai limiti, panic immediati del kernel, cicli di avvio. Ma nessun sistema era in ascolto di quei segnali in un modo che potesse attivare un interruttore di arresto automatico.
Questo è il problema che la telemetria guidata dall'IA è costruita per risolvere. Il monitoraggio tradizionale funziona su regole statiche: "Avvisa se l'utilizzo della CPU supera il 90%". È come impostare un rilevatore di fumo che scatta solo quando la casa è già avvolta dalle fiamme. Ciò di cui hai bisogno è un sistema che comprenda come appare il "normale" a un livello granulare e che possa rilevare i primi microsecondi di deviazione.
Stiamo costruendo ciò che la comunità di ricerca chiama AI-Driven Telemetry Analytics, o framework AITA. Questi utilizzano l'apprendimento automatico non supervisionato — isolation forest, autoencoder, clustering basato sulla densità — per stabilire linee di base comportamentali per i componenti del sistema. I risultati della ricerca recente sono sorprendenti: riduzione del 35% del tempo medio di rilevamento delle anomalie, riduzione del 40% dei falsi positivi e accuratezza nel rilevamento delle anomalie che raggiunge il 97,5% di precisione con il 96,2% di richiamo.
Nello scenario di CrowdStrike, un sistema dotato di AITA avrebbe rilevato la lettura fuori dai limiti come una deviazione dal comportamento di base entro i primi millisecondi dall'applicazione dell'aggiornamento. Avrebbe potuto attivare un interruttore di arresto locale — isolando il driver difettoso, ripristinando l'ultima configurazione nota come funzionante — prima che il crash si propagasse a cascata. Non dopo che 8,5 milioni di macchine erano andate in tilt. Prima che la seconda macchina andasse in tilt.
Non stiamo parlando di fantascienza. Stiamo parlando di sistemi che esistono già nella ricerca e che stanno passando alla produzione. La domanda non è se le aziende adotteranno architetture in grado di auto-ripararsi. È se le adotteranno prima o dopo la prossima cascata globale.
Come si costruisce davvero per questo futuro?
Le persone mi chiedono sempre una qualche versione di: "Va bene, sono convinto che questo conti. Ma la mia azienda non può ricostruire tutto da zero. Da dove cominciamo?"
Domanda legittima. Ecco dove è approdato il mio pensiero dopo un anno passato ad affrontare la questione.
Primo, fai un audit di cosa sta girando nel tuo kernel. La maggior parte delle aziende non ha idea di quanti agenti di terze parti operino a Ring 0, il livello di privilegio più profondo. Ognuno di quegli agenti è un potenziale rischio in stile CrowdStrike. Esigi che qualsiasi fornitore che opera a livello di kernel fornisca prove di procedure di rilascio graduale, di versionamento degli schemi tra i propri validatori nel cloud e gli interpreti sull'endpoint, e di test di simulazione dei cicli di avvio. Se non riescono a fornirle, quella è la tua risposta sul loro rigore ingegneristico.
Secondo, smetti di trattare l'IA come uno strato di interfaccia. Se la tua "strategia di IA" è una raccolta di strumenti wrapper di LLM che dipendono tutti dagli stessi due o tre fornitori di modelli, hai un rischio di concentrazione che rispecchia il problema della dipendenza da CrowdStrike. Inizia a costruire o acquisire modelli specializzati che girano sulla tua infrastruttura per i tuoi flussi di lavoro più critici. È questo che significa sovranità dell'IA nella pratica: non ideologia, ma resilienza operativa.
Terzo, rendi la verifica formale un requisito di approvvigionamento, non un'aspirazione di ricerca. Gli strumenti esistono ora. VeCoGen e framework simili stanno rendendo possibile generare codice verificato su larga scala. Per qualsiasi componente critico per la sicurezza — qualsiasi cosa tocchi il kernel, elabori transazioni finanziarie o prenda decisioni mediche — esigi una dimostrazione matematica di correttezza, non semplici percentuali di copertura dei test.
Ho avuto una discussione con un potenziale cliente proprio su quest'ultimo punto. Ha detto: "Ci stai chiedendo di rallentare la nostra pipeline di deployment." Ho risposto: "La pipeline di deployment di CrowdStrike era molto veloce. Ha distribuito un aggiornamento difettoso a 8,5 milioni di macchine in pochi minuti. La velocità non era il problema. La velocità senza verifica era il problema."
Ha firmato il contratto.
Il precedente che cambia tutto
Ecco cosa penso che la maggior parte delle persone nel settore tecnologico stia trascurando riguardo al caso Delta contro CrowdStrike.
La sentenza sulla colpa grave non riguarda solo una compagnia aerea e un fornitore di sicurezza. Sta stabilendo un nuovo standard di diligenza per gli aggiornamenti software automatizzati. Quando un giudice afferma che distribuire codice non testato a milioni di macchine senza un rilascio graduale potrebbe costituire colpa grave, ciò vale per ogni fornitore che fa la stessa cosa. Quando un giudice afferma che scavalcare le preferenze di aggiornamento di un cliente per inserire codice a livello di kernel potrebbe costituire violazione informatica indipendentemente dal contratto, ciò riscrive le regole per ogni azienda SaaS con meccanismi di aggiornamento automatico.
La "colpa grave" di oggi diventerà l'aspettativa di base di domani. Rilasci graduali, verifica formale, controllo dei limiti a runtime, telemetria in grado di auto-ripararsi: questi non sono più vantaggi competitivi. Sono lo standard minimo che tribunali e regolatori esigeranno.
Ed ecco la cosa che mi entusiasma, anche se mi terrorizza: il settore dell'IA sta per affrontare questa stessa resa dei conti. In questo momento, la maggior parte dei sistemi di IA opera in modo probabilistico — hanno "di solito ragione", e quando sbagliano, alziamo le spalle e la chiamiamo allucinazione. Ma man mano che l'IA si spinge più a fondo nell'infrastruttura critica — gestendo reti elettriche, approvando trattamenti medici, eseguendo transazioni finanziarie — "di solito ha ragione" avrà lo stesso peso legale di "non abbiamo testato l'aggiornamento prima di distribuirlo a 8,5 milioni di macchine".
Il costo di 10 miliardi di dollari dell'interruzione di CrowdStrike non è il prezzo di un bug. È l'acconto su un aggiornamento globale del modo in cui costruiamo e verifichiamo il software.
Le aziende che lo capiscono — che investono ora in Deep AI, verifica formale e architetture sovrane — non si limiteranno a evitare la prossima catastrofe. Definiranno lo standard che tutti gli altri si affanneranno a raggiungere dopo che sarà accaduta.
So da quale lato di quella divisione voglio stare io. La domanda è se sceglierai prima del prossimo 19 luglio, o dopo.
