Der CrowdStrike-Absturz lag an einer Feldanzahl: 21 statt der vom Kernel erwarteten 20. Keine unabhängige Schicht prüfte nach.
Am 19. Juli 2024 brachte ein einziges Anbieter-Update Millionen von Windows-Rechnern in weniger als 90 Minuten zum Absturz, und die Ursache war eine Zahl. Eine Channel-Datei für „Rapid Response Content“ von CrowdStrike deklarierte 21 Felder, wo der bereitgestellte Kernel-Interpreter 20 erwartete. Das zusätzliche Feld erzeugte einen Out-of-Bounds-Read, einen sofortigen Bluescreen, und da der Absturz so früh beim Booten auftrat, konnte der abstürzende Agent nie wieder hochfahren, um einen Rollback-Befehl zu empfangen. Die Wiederherstellung bedeutete, zu jeder einzelnen Maschine zu gehen und sie manuell im abgesicherten Modus zu reparieren.
Ich habe die eigene Ursachenanalyse von CrowdStrike, die im August veröffentlicht wurde, mehr als einmal gelesen, bevor mir klar wurde, was mich daran störte. Das war kein Hack. Es war kein fehlerhaftes Modell. Es war eine entscheidbare arithmetische Tatsache, 21 gegen 20, eingebettet in eine Nutzlast, die vor Erreichen der Produktion von keiner unabhängigen Schicht jemals überprüft wurde. Der Validator des Anbieters winkte sie durch. Die Unternehmen, die lahmgelegt wurden, besaßen diesen Validator nicht. Sie trugen die Konsequenzen.
Ich habe die letzte Zeit damit verbracht, eine Demo rund um diese Lücke zu entwickeln: eine Konsole namens Kestrel, die zwischen einem Softwareanbieter und einer Produktionsflotte sitzt und im Code entscheidet, was der Anbieter ausliefern darf. Sie können sich ansehen, wie das funktioniert unter veriprajna.com/demos/software-update-integrity. Was mich beim Bauen überraschte, war die Stelle, an der sich die Lösung tatsächlich befand. Ich ging davon aus, dass ich ein klügeres Modell brauchen würde – und ein paar Zeilen einfaches Python fingen den Absturz als Erstes ab.
Ich habe den Absturz nachgebaut und dann den Code entscheiden lassen
Ich habe die Fehlersignatur vom 19. Juli als Fixture nachgebaut und mein eigenes System darauf angesetzt, wobei ich fast erwartete, von meinem eigenen Replay unterwältigt zu sein. Das Paket ist C-00000291, eine Channel-Datei für Rapid Response Content von einem fiktiven Anbieter namens SentinelEdge, verteilt auf eine synthetische Flotte von 8.500 Endpunkten namens Acme Financial. Nichts davon sind reale Unternehmen. Die Fehlersignatur ist die echte: Ein deklariertes Schema von 20 wächst auf 21 an und wird in einer einzigen Welle ohne Canary-Plan auf 100 % der Flotte ausgerollt.
Das Gate schlägt bei vier Prüfungen gleichzeitig an, und jede davon ist reine Arithmetik oder ein einfacher Lookup, niemals eine Ermessensentscheidung. Der Schema-Diff erkennt 21 Felder, wo der Interpreter 20 erwartet, und markiert den Out-of-Bounds-Read. Eine simulierte Sandbox – ein deterministisches Profil-Ergebnis-Modell und keine Farm echter Windows-VMs – führt bei 5 von 6 Flottenprofilen über Reboot-Zyklen hinweg zu Bootschleifen. Sie leitet dies aus einem Treiberkompatibilitätssignal ab, das unabhängig von der Schemaprüfung ist, sodass sich beide Befunde gegenseitig untermauern, statt sich nur zu wiederholen. Der Dead-Agent-Detektor setzt die Rollback-Schleife auf „true“, weil der abstürzende Agent selbst derjenige wäre, der das Rollback empfängt, und er ist vor dem Booten tot. Der Explosionsradius beträgt 100 % gegenüber einer Canary-Richtlinie von 5 %. Urteil: BLOCK. Auf dem Bildschirm steht: Blockiert, bevor ein Produktionsendpunkt neu gestartet wurde.
Die geschätzte verhinderte Ausfallzeit bei diesem einen Update beträgt 5.000.000 $, und ich möchte genau darlegen, worum es sich bei dieser Zahl handelt. Es ist das eigene Modell der Demo: der betroffene Anteil mal einer Eingabe von 5 Mio. $ pro Stunde mal einer einständigen Mindestwiederherstellungszeit, wobei die Formel auf dem Bildschirm abgedruckt ist. Es ist kein Geld, das ein Kunde gespart hat. Die reale Wiederherstellung am 19. Juli dauerte Tage, nicht eine Stunde, weshalb der Mindestwert bewusst konservativ gewählt ist.
Der grüne Fall machte mir mehr Angst als der rote
Der grüne Fall machte mich nervöser als der rote, denn eine Governance-Schicht, die das gefährliche Update blockiert und zugleich das sichere abwürgt, ist nur ein Ausfall, den man sich selbst terminiert hat. Derselbe fiktive Anbieter pusht RRC-7741, ein harmloses Update für Erkennungssignaturen, deklariertes Schema 20 zu 20, mit einem gestaffelten Canary-Plan von 1,2 %. Die Crew läuft durch, das Schema passt, 5 von 6 Profilen bestehen ihre Reboot-Zyklen, die Dead-Agent-Schleife ist „false“, der Explosionsradius bleibt innerhalb der Richtlinie. Urteil: APPROVE ROLLOUT, freigegeben für einen Canary-Ring von 102 Endpunkten. Grün, schnell, unspektakulär.
Über die sechs harmlosen Updates in diesem Satz hinweg erzeugte das Gate null Fehlsperren. Ich sage das mit genanntem Nenner, denn sechs ist sechs, und ich lasse nicht zu, dass man das zu einem Versprechen für Ihre Flotte aufrundet. Der Wert des ALLOW-Falls ist enger gefasst und wichtiger als eine Prozentangabe. Ein Gate ist nur dann glaubwürdig, wenn es im normalen Datenverkehr unsichtbar bleibt und bei dem einen Ereignis, das Ihre Flotte lahmlegen könnte, unerschütterlich standhält.
Warum ich das Urteil aus dem Modell herausgenommen habe
Ich begann dieses Projekt unter der Annahme, dass der schwierige Teil das logische Schlussfolgern sei und dass ein schärferes Modell oder ein klügerer Kritiker dasjenige Element wäre, das das fehlerhafte Update abfängt. Ich lag auf eine Weise falsch, die einzugestehen mich einige Zeit kostete. Es gibt eine LLM-Crew in Kestrel: einen Normalisierer, einen Sandbox-Interpreter und zwei gegnerische Kritiker – einer argumentiert, das Update könne sicher ausgeliefert werden, der andere argumentiert, es werde abstürzen. Das gegnerische Paar verdient seinen Platz, weil es das Urteil aus beiden Richtungen einem Red-Teaming unterzieht, bevor irgendetwas entschieden wird. Aber kein einziger dieser Agenten fällt das Urteil.
Das Urteil wird von zwei einfachen Python-Dateien gefällt, verifier.py und gate.py, die vollständig außerhalb des Agenten-Frameworks angesiedelt sind. Die Crew läuft auf Pydantic AI mit dem Standardmodell claude-opus-4-8, und das gesamte System läuft über ein deterministisches beratendes Fallback auch offline ohne API-Schlüssel. In jedem dieser Modi ist das Gate identisch und liefert dieselbe Entscheidung, da die Entscheidung Arithmetik ist, keine Inferenz. Agenten beraten, Code entscheidet. Ein beratender Agent, der zu „allow“ neigt, kann einen kritischen deterministischen Befund nicht ausräumen – und das ist keine Frage des Geschmacks.
Eine Schicht, die gebaut wurde, um den Anbieter zu kontrollieren, darf sich beim Thema Sicherheit nicht auf das Wort des Anbieters verlassen. Sie darf sich auch nicht auf das Wort ihres eigenen Modells verlassen.
Dieser Satz ist der Grund, warum die Architektur genau so aussieht. Das Vertrauen in ein Produkt, dessen einzige Aufgabe darin besteht, zu steuern, was ein Anbieter ausliefert, darf niemals über eine Komponente laufen, die sich zu einem Ja überreden lässt.
Was ich einem Auditor vorlegen würde
Ich hatte den Cyber Resilience Act der EU auf einem zweiten Monitor geöffnet, während ich den Evidence-Record aufbaute, denn dieser Nachweis ist das Artefakt, das ich tatsächlich verteidigen müsste. Jede Entscheidung exportiert eine unveränderliche HTML-Datei und eine signierte JSON-Datei mit einem SHA-256-Content-Hash, dem Urteil, den deterministischen Nachweisen, den profilbezogenen Sandbox-Ergebnissen, den Urteilen der beratenden Agenten samt deren Modell-ID, den ausgelösten Richtlinienregeln und einem schrittweisen Evaluierungs-Trace, bei dem jeder Schritt seine eigene Latenz aufweist.
Der Trace ist das Detail, das ich unterschätzt habe, bis ich auf einen einzelnen Schritt klickte. Ein Ereignis lautet: „Signiertes Anbietermanifest normalisieren, abgeschlossen in 184 ms“, und es wird zusammen mit dem Entscheidungsergebnis für die Audit-Prüfung aufbewahrt. Jeder Schritt ist reproduzierbar. Eine Regulierungsbehörde muss meinem Dashboard nicht blind vertrauen. Sie kann die Arithmetik nachrechnen und erhält dasselbe Ergebnis.
Ich differenziere genau, was die Signatur ist und was nicht. Es handelt sich um ein lokales SHA-256, keine Enterprise-PKI. Der Update-Feed des Anbieters und die dahinter liegenden ITSM-Tickets sind Fixture-Stubs, keine Live-Konnektoren. Der Datensatz ist darauf ausgelegt, Meldepflichten zu erfüllen: die kurzfristige Vorfallmeldung nach dem CRA, die Offenlegung wesentlicher Cybersicherheitsvorfälle innerhalb von vier Geschäftstagen gemäß SEC und die Fragen der Anbieterhaftung aus Delta v. CrowdStrike in Fulton County 2025. Darauf ausgelegt. Er zertifiziert niemanden, er stellt keine Rechtsberatung dar, und wer Ihnen ein Audit-Protokoll verkauft, das Sie angeblich compliant macht, will Ihnen nur etwas verkaufen.
Es gibt noch eine weitere Entscheidung, auf die ich stolz bin, und es ist eine Verweigerung. Fixture XX-0000 ist ein verschlüsselter proprietärer Inhalts-Blob, den das Gate nicht parsen kann – also rät es nicht. Es gibt ABSTAIN zurück und leitet an einen Menschen weiter, denn ein Gate, das durchwinkt, was es nicht lesen kann, ist schlimmer als gar kein Gate. Legacy-Hosts, die die Sandbox nicht modellieren kann, werden markiert und ausgeschlossen, niemals als sicher vorausgesetzt. Das Vokabular umfasst vier Wörter: ALLOW, HOLD, BLOCK, ABSTAIN – und das letzte ist dasjenige, das ich am vehementesten verteidigen würde.
Was 12 von 12 bedeuten darf
Hier muss ich das Tempo drosseln, denn genau an dieser Stelle fängt ein Gründer an aufzurunden. Und ich habe das Unternehmen Veriprajna genannt, wahre Weisheit, weshalb Aufrunden nicht infrage kommt. Über einen festen, gelabelten Satz von zwölf Updates hinweg trifft das Gate bei allen zwölf die richtige Entscheidung. Sechs davon sind harmlos und es blockiert keines davon. Eines ist das ehrliche ABSTAIN. Die Anzeigetafel weist 12/12 verifizierte Entscheidungen, 0/6 Fehlsperren und 13,3 Mio. $ an geschätzter verhinderter Ausfallzeit über den gesamten Satz aus, wovon 5 Mio. $ auf die einzelne Blockade der CrowdStrike-Klasse entfallen.
Nun zu dem Teil, den ich mich weigere zu verkürzen. Das sind Ergebnisse auf zwölf gelabelten Elementen, kein Versprechen über das nächste Update, das in Ihrer Flotte eintrifft. Sechs harmlose Elemente sind sechs. Das bedeutet nicht: „Blockiert 100 % aller fehlerhaften Updates“ – das wird es nie bedeuten, und sollten Sie mich jemals dabei ertappen, wie ich diesen Satz schreibe, sollten Sie aufhören, mich zu lesen. Die Zahl, hinter der ich stehe, ist anderer Natur: dieselbe Eingabe, dieselbe Entscheidung, bei jedem Lauf, weil das Urteil keine Modelltemperatur beinhaltet. Führen Sie den Fixture-Satz morgen erneut aus und er liefert byte-identische Ergebnisse. Genau das ermöglicht es, eine deterministische Schicht auf eine Weise zu auditieren, wie es bei einer probabilistischen unmöglich ist.
Die Frage, die mir bleibt
Was mir von diesem Build im Gedächtnis bleibt, ist, wie gewöhnlich der Fehler war. Einundzwanzig Felder, wo zwanzig erwartet wurden. Eine Zahl, die jeder unabhängige Verifizierer durch Arithmetik hätte abfangen können, bevor ein einziger Rechner neu startete – wenn ein unabhängiger Verifizierer zwischen dem Anbieter und der Flotte gestanden hätte. Es gab keinen. Bis heute gibt es meistens keinen.
Jedes Unternehmen betreibt acht bis zwölf Agenten mit Kernel-Rechten von Anbietern, die es nicht kontrolliert, und jeder davon kann eine Datei direkt in den Ring 0 schreiben. SBOM-Tools überwachen Open-Source-Abhängigkeiten. Identitätssysteme überwachen Zugriffe. Niemand liest das proprietäre Update des Anbieters beim Eingang und beweist dessen Sicherheit. Kestrel ist kein EDR und berührt den Kernel niemals. Es sitzt über diesen Agenten und regelt, was sie ausliefern dürfen. Das ist die Schicht, die ich zu bauen versucht habe, und die vollständige Aufschlüsselung finden Sie unter veriprajna.com/demos/software-update-integrity.
Und wenn Sie das Ganze lieber in Aktion sehen möchten, statt meine Beschreibung zu lesen: Hier läuft das gesamte System von Anfang bis Ende.
Hier ist also, was ich nun bei jeder Flotte frage, die ich sehe: Wenn das nächste Anbieter-Update eintrifft, was steht dann zwischen dieser Datei und der Produktion – und kann es seine Arbeit nachweisen? Wenn die Antwort ein Change Advisory Board ist, das dem Anbieter blind vertraut, dann läuft die Arithmetik, die Millionen von Rechnern lahmgelegt hat, immer noch ungeprüft weiter. Sie wird sich nicht ankündigen. Sie wird genauso aussehen wie jedes Update davor – bis zum Neustart.
