De dag waarop 8,5 miljoen computers stierven — en wat het me leerde over het bouwen van software die niet kan falen
Ik zat in een hotellobby in Hyderabad toen mijn telefoon begon te trillen. Niet het gebruikelijke druppeltje Slack-meldingen — dit was een stortvloed. Het volledige wagenpark aan Windows-machines van een klant was blauw geworden. Toen nog een klant. Toen kwam het nieuws naar buiten: luchthavens die vluchten aan de grond hielden, ziekenhuizen die operaties afzegden, banken die transacties bevroren. Allemaal vanwege één bestandsupdate van CrowdStrike die kleiner was dan de foto die je van je lunch zou maken.
19 juli 2024. De dag waarop ongeveer 8,5 miljoen Windows-systemen tegelijkertijd crashten in het Blue Screen of Death. De dag die de wereldeconomie uiteindelijk meer dan $10 miljard aan schade zou kosten. En de dag waarop ik geobsedeerd raakte door een vraag die me nog altijd uit mijn slaap houdt: Waarom bouwen we de meest kritieke systemen in de menselijke geschiedenis op fundamenten die door een configuratiebestand kunnen worden vernietigd?
Ik leid Veriprajna, een AI-consultancy. Wij bouwen wat ik "Deep AI"-oplossingen noem — systemen die integreren met de kerninfrastructuur, niet de dunne ChatGPT-wrappers die de markt op dit moment domineren. Toen de CrowdStrike-storing plaatsvond, haalde de helft van de AI-industrie zijn schouders op. "Beveiligingsprobleem," zeiden ze. "Niet ons domein." Maar ik zag iets anders. Ik zag exact dezelfde architecturale kwetsbaarheid die elke onderneming teistert die zich haast om AI aan hun operatie vast te schroeven zonder te begrijpen wat er onderhuids gebeurt.
Ik heb maandenlang na de storing de root-cause-analyse uit elkaar getrokken, de rechtszaak van Delta Air Lines gevolgd en het opkomende onderzoek naar formele verificatie bestudeerd. Wat ik ontdekte veranderde hoe mijn team alles bouwt. Ik heb hier een uitgebreide interactieve ontleding van de volledige analyse geschreven, maar dit essay is het verhaal achter het onderzoek — de delen die niet netjes in een whitepaper passen.
Een bestand kleiner dan een JPEG legde de wereldwijde luchtvaart plat
Dit is wat er werkelijk gebeurde, ontdaan van het jargon.
CrowdStrike's Falcon-beveiligingsplatform draait binnen de Windows-kernel — de diepste, meest bevoorrechte laag van het besturingssysteem. Zie het als de machinekamer van een schip. Als er iets misgaat boven op het dek, kun je het repareren. Als er iets misgaat in de machinekamer, zinkt het schip.
Om nieuwe bedreigingen snel te detecteren, bouwde CrowdStrike een systeem genaamd "Rapid Response Content." In plaats van volledige software-updates te pushen (die traag zijn en getest moeten worden), pushen ze kleine configuratiebestanden — in wezen instructiebladen die de beveiligingsengine vertellen naar welke patronen te zoeken. Het is slim. Het is ook, zoals we leerden, angstaanjagend gevaarlijk.
Op die ochtend werden twee nieuwe instructiesets ingezet voor het detecteren van een specifiek type interprocescommunicatie. Deze instructies verwezen naar 21 invoerparameters. Het probleem? De engine die op elk endpoint draaide — de daadwerkelijke code die in de kernel wordt uitgevoerd — begreep slechts 20 parameters.
De cloud zei "lees 21 velden." De kernel kende er maar 20. Die mismatch liet 8,5 miljoen computers crashen.
De validator in de cloud keurde de update goed omdat zijn definitie van het sjabloon 21 velden bevatte. Het controleerde tegen zijn eigen verwachting, niet tegen de realiteit van wat het endpoint aankon. Toen de interpreter op kernelniveau probeerde dat 21e veld te benaderen, las hij voorbij de grens van het toegewezen geheugen. In kernelruimte is dat geen herstelbare fout. Het is een onmiddellijke crash. Blauw scherm. Herstart. Weer crash. Herstart. Weer crash. Een oneindige doodslus.
Ik herinner me dat ik dit een paar weken later tijdens een diner uitlegde aan een niet-technische investeerder. Hij staarde me aan en zei: "Dus je vertelt me dat niemand heeft getest of het ding dat de update ontving die update daadwerkelijk kon verwerken?" Ik knikte. Hij legde zijn vork neer. "Dat is geen softwarefout. Dat is nalatigheid."
Hij had geen ongelijk. En een rechter in Georgia zou het in wezen met hem eens zijn.
Waarom 40.000 servers met de hand moesten worden gerepareerd
Het deel van het verhaal dat te weinig aandacht krijgt is het herstel — of beter gezegd, de onmogelijkheid van herstel op afstand.
Hier is de wrede ironie: de CrowdStrike-agent is het ding dat commando's ontvangt van de cloud. "Draai deze update terug." "Pas deze fix toe." Maar de crash gebeurde zo vroeg in de opstartvolgorde dat de agent nooit initialiseerde. De software die het reddingssignaal zou moeten ontvangen was precies datgene wat de verdrinking veroorzaakte.
Mijn team begon dit het "Dead Agent"-probleem te noemen. Elke getroffen machine was verweesd. Ze kon niet naar huis bellen. Ze kon geen instructies ontvangen. De enige oplossing was om elke machine fysiek op te starten in de Veilige Modus, te navigeren naar C:\Windows\System32\drivers\CrowdStrike\, en het defecte bestand handmatig te verwijderen.
Voor Delta Air Lines betekende dat het aanraken van ongeveer 40.000 servers en duizenden werkstations. Met de hand. Eén voor één.
Ik heb eerder IT-hersteloperaties beheerd, en de logistiek op die schaal is bijna onvoorstelbaar. Je hebt fysieke toegang nodig tot machines die zich mogelijk in vergrendelde serverruimtes in verschillende steden bevinden. Je hebt technici nodig die weten hoe je opstart in de Veilige Modus — wat, in een tijdperk van BitLocker-versleuteling, vaak herstelsleutels vereist die zijn opgeslagen op... andere servers die ook gecrasht zijn. Het zijn schildpadden helemaal naar beneden.
Delta's concurrenten — American Airlines, United — herstelden binnen één tot drie dagen. Delta's verstoring duurde meer dan vijf dagen en resulteerde in meer dan 7.000 geannuleerde vluchten en $550 miljoen aan verliezen. Het verschil? Delta's crew-trackingsysteem, de software die de luchtvaartmaatschappij vertelt waar haar piloten en cabinepersoneel zijn en wanneer ze beschikbaar zijn, draaide bijna volledig op Windows. Toen die servers uitvielen, verloor Delta niet alleen computers. Ze verloren het vermogen om te weten waar hun eigen mensen waren.
Wat gebeurt er wanneer een softwarefout "grove nalatigheid" wordt?
Dit is waar het verhaal verschuift van de serverruimte naar de rechtszaal, en waar ik denk dat de implicaties werkelijk industrieveranderend worden.
Delta klaagde CrowdStrike aan. Dat alleen is niet verrassend — bedrijven klagen leveranciers voortdurend aan na grote storingen. Wat verrassend is, is wat de rechter toestond om door te gaan.
Historisch gezien worden softwareleveranciers beschermd door hun contracten. Verstopt in de servicevoorwaarden zit altijd een aansprakelijkheidsplafond — meestal beperkt tot wat de klant voor het abonnement betaalde. Het is een knus arrangement. Je verkoopt software die op het diepste niveau van de infrastructuur van een klant opereert, en als het alles vernietigt, is je maximale blootstelling twaalf maanden aan licentiekosten.
In mei 2025 weigerde rechter Kelly Lee Ellerbe van de Fulton County Superior Court om Delta's claims van grove nalatigheid af te wijzen en — dit is degene waardoor ik rechtop ging zitten — computerinbraak.
Het argument van grove nalatigheid is eenvoudig: CrowdStrike pushte de update tegelijkertijd naar alle 8,5 miljoen systemen. Geen gefaseerde uitrol. Geen canary-deployment. Geen "laten we dit eerst op 1% van de machines proberen en kijken wat er gebeurt." Delta's advocaten betoogden dat dit een bewuste veronachtzaming van bekende risico's vertegenwoordigde. CrowdStrike's eigen rapport na het incident gaf toe dat de Content Validator een logicafout had en dat de Content Interpreter een runtime-grenzencontrole ontbeerde.
Maar de claim van computerinbraak is degene die elke SaaS-leverancier die dit leest de stuipen op het lijf zou moeten jagen. Delta had zich afgemeld voor automatische updates in hun instellingen. CrowdStrike pushte de update toch via het channel-file-mechanisme op kernelniveau. De rechter oordeelde dat wettelijke plichten met betrekking tot computerinbraak onafhankelijk zijn van de abonnementsovereenkomst — wat betekent dat het aansprakelijkheidsplafond in het contract niet van toepassing is.
Wanneer een leverancier je expliciete voorkeuren overschrijft om code in je kernel te pushen, beschermt het aansprakelijkheidsplafond in het contract hen mogelijk niet. Dat is de nieuwe juridische realiteit.
Ik heb sinds deze uitspraak met drie verschillende CISO's gesproken, en elk van hen zei hetzelfde: "We herschrijven onze leveranciersovereenkomsten." Het tijdperk van onbeperkt vertrouwen in geautomatiseerde updates van beveiligingsleveranciers is voorbij.
De ongemakkelijke parallel met de AI-industrie
Nu ga ik bot zijn, en waar sommige van mijn vakgenoten in de AI-sector niet blij zullen zijn met wat ik te zeggen heb.
De AI-industrie bouwt op dezelfde kwetsbare fundamenten die CrowdStrike blootlegde. We doen het alleen sneller en met meer hype.
De markt wordt op dit moment gedomineerd door wat ik "LLM-wrappers" noem — dunne applicatielagen die API-aanroepen doen naar GPT-4 of Claude, het antwoord in een mooie UI verpakken, en het een AI-product noemen. Ik heb pitchdecks gezien van bedrijven wiens hele technische architectuur letterlijk is "we sturen een prompt naar OpenAI en tonen het resultaat." Ze worden gewaardeerd op tientallen miljoenen dollars.
Ik was vorig jaar op een conferentie waar een oprichter trots zijn "AI-aangedreven beveiligingsanalysetool" demonstreerde. Ik stelde een simpele vraag: "Wat gebeurt er als OpenAI hun API verandert, de prijzen 10x verhoogt, of zes uur uitvalt?" Hij keek me aan alsof ik had gevraagd wat er gebeurt als de zwaartekracht ophoudt te werken. "Dat zal niet gebeuren," zei hij.
Het zal gebeuren. Het gebeurt altijd. De CrowdStrike-storing bewees dat zelfs de meest vertrouwde infrastructuurleveranciers, degenen waarop je je hele operatie hebt ingezet, één slecht bestand kunnen pushen en alles kunnen platleggen.
Dit is waarom we Veriprajna hebben opgebouwd rond wat ik "Deep AI" noem — en ik wil precies zijn over wat ik bedoel, want de term wordt losjes rondgestrooid.
Een Deep AI-oplossing huurt haar intelligentie niet van één externe provider. Het gebruikt hybride architecturen — gespecialiseerde kleine taalmodellen, vision-language-modellen, graph neural networks — ingezet op de eigen infrastructuur van de klant wanneer de use case dat vereist. Het integreert op systeemniveau, niet op UI-niveau. En cruciaal: het gebruikt formele verificatie om wiskundige garanties over zijn gedrag te bieden, niet slechts probabilistische beste gissingen.
Het verschil doet ertoe. Een LLM-wrapper geeft je een chatbot die meestal gelijk heeft. Een Deep AI-systeem geeft je een engine die bewijsbaar correct is voor de specifieke taak waarvoor het is ontworpen.
Waarom ik geobsedeerd raakte door formele verificatie
Ik zal eerlijk zijn: vóór de CrowdStrike-storing dacht ik dat formele verificatie een academische curiositeit was. Iets waarover onderzoekers artikelen publiceerden en dat niemand in productie gebruikte. De seL4-microkernel — een formeel geverifieerde besturingssysteemkernel — was indrukwekkend maar leek een eenmalige prestatie die jaren van werk op PhD-niveau vereiste.
Toen las ik CrowdStrike's root-cause-analyse voor de derde keer, en er viel iets op zijn plaats.
De hele ramp kwam neer op een semantische kloof. De cloud-validator geloofde dat het sjabloon 21 velden had. De endpoint-interpreter geloofde dat het er 20 had. Twee componenten van hetzelfde systeem hielden tegenstrijdige overtuigingen over de realiteit vast, en niemand ving het op omdat er geen gedeelde, wiskundig rigoureuze specificatie was waartegen beide componenten werden geverifieerd.
Formele verificatie elimineert semantische kloven. Het gebruikt wiskundige bewijzen om ervoor te zorgen dat software — de daadwerkelijke implementatie — altijd aan haar specificatie voldoet. Niet "meestal." Niet "in onze tests." Altijd. Als het bewijs klopt, kan de software haar specificatie niet schenden. Punt uit.
Mijn team bracht vorig jaar weken door met experimenteren met een framework genaamd VeCoGen, dat grote taalmodellen combineert met formele-verificatie-engines om automatisch geverifieerde C-code te genereren. Het LLM stelt kandidaat-implementaties voor, en een bewijscontroleur bevestigt wiskundig de correctheid voordat er iets wordt ingezet. Als de code een fout heeft — zelfs een subtiele zoals een off-by-one-fout in een array-grens — mislukt het bewijs en wordt de code afgewezen.
Ik herinner me de eerste keer dat we het aan de praat kregen op een niet-triviaal voorbeeld. Mijn hoofdingenieur, die sceptisch was geweest over de hele onderneming, keek naar de geverifieerde output en zei: "Dus de AI schrijft de code én het bewijs dat de code correct is?" Ja. En de bewijscontroleur is een apart, vertrouwd systeem dat zich niets aantrekt van het vertrouwen van de AI — het geeft alleen om wiskundige waarheid.
We betreden een tijdperk waarin AI-gegenereerde code de voorkeur zal krijgen boven met de hand gemaakte code — niet omdat AI slimmer is, maar omdat AI het wiskundige bewijs naast de implementatie kan genereren.
Martin Kleppmann deed onlangs deze voorspelling, en ik denk dat hij precies gelijk heeft. De "bewijscontroleur" wordt de poortwachter. Geen bewijs, geen inzet. Het is het tegenovergestelde van het CrowdStrike-model, waar de validator in wezen updates afstempelde op basis van zijn eigen aannames.
Wat als het systeem zichzelf had kunnen genezen?
Er is een detail over 19 juli dat me achtervolgt. De crash gebeurde wereldwijd, over alle 8,5 miljoen endpoints, omdat er geen geautomatiseerd mechanisme was om het faalpatroon te detecteren en de uitrol in realtime te stoppen.
Denk daar eens over na. Miljoenen machines begonnen tegelijkertijd te crashen. De telemetriesignalen waren er — geheugenuitlezingen buiten de grenzen, onmiddellijke kernelpanieken, opstartlussen. Maar geen enkel systeem lette op die signalen op een manier die een automatische noodschakelaar kon activeren.
Dit is het probleem dat AI-gedreven telemetrie is gebouwd om op te lossen. Traditionele monitoring werkt op statische regels: "Waarschuw als CPU-gebruik 90% overschrijdt." Dat is als een rookmelder instellen die pas afgaat wanneer het huis al in vlammen staat. Wat je nodig hebt is een systeem dat begrijpt hoe "normaal" eruitziet op een granulair niveau en de eerste microseconden van afwijking kan detecteren.
We hebben gebouwd aan wat de onderzoeksgemeenschap AI-Driven Telemetry Analytics, of AITA-frameworks, noemt. Deze gebruiken ongesuperviseerd machinaal leren — isolation forests, autoencoders, dichtheidsgebaseerde clustering — om gedragsbaselines voor systeemcomponenten vast te stellen. De resultaten van recent onderzoek zijn opvallend: 35% vermindering in gemiddelde tijd om anomalieën te detecteren, 40% vermindering in valse positieven, en anomaliedetectienauwkeurigheid die 97,5% precisie met 96,2% recall bereikt.
In het CrowdStrike-scenario zou een AITA-ingeschakeld systeem de uitlezing buiten de grenzen als een afwijking van het basisgedrag hebben gedetecteerd binnen de eerste milliseconden nadat de update was toegepast. Het had een lokale noodschakelaar kunnen activeren — de defecte driver isoleren, terugrollen naar de laatst bekende goede configuratie — voordat de crash escaleerde. Niet nadat 8,5 miljoen machines waren uitgevallen. Voordat de tweede machine uitviel.
We hebben het niet over sciencefiction. We hebben het over systemen die al bestaan in onderzoek en de productie in bewegen. De vraag is niet of ondernemingen zelfherstellende architecturen zullen adopteren. Het is of ze deze zullen adopteren vóór of na de volgende wereldwijde cascade.
Hoe bouw je hier eigenlijk voor de toekomst voor?
Mensen vragen me altijd een of andere versie van: "Oké, ik ben ervan overtuigd dat dit ertoe doet. Maar mijn bedrijf kan niet alles vanaf nul herbouwen. Waar beginnen we?"
Terechte vraag. Hier is waar mijn denken is beland na een jaar dit doorwerken.
Ten eerste, controleer wat er in je kernel draait. De meeste ondernemingen hebben geen idee hoeveel externe agents er op Ring 0 opereren — het diepste privilegeniveau. Elk van die agents is een potentieel CrowdStrike-achtig risico. Eis dat elke leverancier die op kernelniveau opereert bewijs levert van gefaseerde uitrolprocedures, schemaversionering tussen hun cloud-validators en endpoint-interpreters, en boot-loop-simulatietesten. Als ze het niet kunnen leveren, is dat je antwoord over hun engineeringrigoureusheid.
Ten tweede, stop met AI te behandelen als een UI-laag. Als je "AI-strategie" een verzameling LLM-wrappertools is die allemaal afhankelijk zijn van dezelfde twee of drie modelproviders, heb je een concentratierisico dat het CrowdStrike-afhankelijkheidsprobleem weerspiegelt. Begin met het bouwen of verwerven van gespecialiseerde modellen die op je infrastructuur draaien voor je meest kritieke workflows. Dit is wat AI-soevereiniteit in de praktijk betekent — geen ideologie, maar operationele veerkracht.
Ten derde, maak formele verificatie een inkoopeis, geen onderzoeksaspiratie. De tools bestaan nu. VeCoGen en soortgelijke frameworks maken het mogelijk om geverifieerde code op schaal te genereren. Voor elk veiligheidskritiek component — alles dat de kernel raakt, financiële transacties verwerkt, of medische beslissingen neemt — eis wiskundig bewijs van correctheid, niet slechts percentages testdekking.
Ik had een discussie met een potentiële klant over dit laatste punt. Hij zei: "Je vraagt ons om onze deployment-pijplijn te vertragen." Ik zei: "CrowdStrike's deployment-pijplijn was zeer snel. Het pushte een defecte update naar 8,5 miljoen machines in enkele minuten. Snelheid was niet het probleem. Snelheid zonder verificatie was het probleem."
Hij tekende het contract.
Het precedent dat alles verandert
Hier is wat ik denk dat de meeste mensen in tech missen over de zaak Delta v. CrowdStrike.
De uitspraak over grove nalatigheid gaat niet alleen over één luchtvaartmaatschappij en één beveiligingsleverancier. Het vestigt een nieuwe zorgvuldigheidsnorm voor geautomatiseerde software-updates. Wanneer een rechter zegt dat het pushen van ongeteste code naar miljoenen machines zonder gefaseerde uitrol grove nalatigheid zou kunnen vormen, geldt dat voor elke leverancier die hetzelfde doet. Wanneer een rechter zegt dat het overschrijven van de update-voorkeuren van een klant om code op kernelniveau te pushen computerinbraak zou kunnen vormen, onafhankelijk van het contract, herschrijft dat de regels voor elk SaaS-bedrijf met automatische-update-mechanismen.
De "grove nalatigheid" van vandaag zal de basisverwachting van morgen worden. Gefaseerde uitrollen, formele verificatie, runtime-grenzencontrole, zelfherstellende telemetrie — dit zijn geen concurrentievoordelen meer. Het zijn de minimumnorm die rechtbanken en toezichthouders zullen eisen.
En hier is het ding dat me opwindt, zelfs terwijl het me de stuipen op het lijf jaagt: de AI-industrie staat op het punt om deze zelfde afrekening onder ogen te zien. Op dit moment opereren de meeste AI-systemen probabilistisch — ze hebben "meestal gelijk," en wanneer ze het mis hebben, halen we onze schouders op en noemen het een hallucinatie. Maar naarmate AI dieper in de kritieke infrastructuur beweegt — het beheren van elektriciteitsnetten, het goedkeuren van medische behandelingen, het uitvoeren van financiële transacties — zal "meestal gelijk" hetzelfde juridische gewicht dragen als "we hebben de update niet getest voordat we hem naar 8,5 miljoen machines pushten."
De kosten van $10 miljard van de CrowdStrike-storing zijn niet de prijs van een fout. Het is de aanbetaling op een wereldwijde upgrade van hoe we software bouwen en verifiëren.
De bedrijven die dit begrijpen — die nu investeren in Deep AI, formele verificatie en soevereine architecturen — zullen niet alleen de volgende catastrofe vermijden. Ze zullen de norm definiëren die iedereen erna probeert te halen wanneer het gebeurt.
Ik weet aan welke kant van die kloof ik wil staan. De vraag is of jij zult kiezen vóór de volgende 19 juli, of erna.
