Was diese Woche passiert ist
Laut einem Bericht von CoinDesk vom 5. Juni hat ein KI-Modell eine kritische Schwachstelle im Zcash-Protokoll aufgedeckt. Der Bug war vier Jahre alt. Vier Jahre, in denen menschliche Auditoren, Bug-Bounty-Programme und interne Reviews diesen Fehler übersehen haben. Zcash ist keine Bastel-Chain. Das Protokoll setzt auf Zero-Knowledge-Kryptographie, gilt als technisch anspruchsvoll und wurde von einigen der bekanntesten Kryptographen der Branche mitentwickelt.
Das Pikante: Die KI brauchte keinen Zugang zu privilegierten Informationen. Sie las öffentlichen Code. Sicherheitsforscher in dem Artikel ziehen die naheliegende Konsequenz. Wenn ein LLM in einem auditierten, akademisch begleiteten Protokoll einen vier Jahre alten Fehler findet, was liegt dann in Bank-Codebasen, die seit den 1990er Jahren gewachsen sind?
Die Antwort darauf ist unbequem. Aber sie ist auch eine Chance, je nachdem, auf welcher Seite des Tisches Sie sitzen.
Warum das jetzt für Finanzinstitute zählt
Drei Dinge ändern sich gerade gleichzeitig, und das ist keine Marketingaussage.
Erstens: Die Werkzeuge sind asymmetrisch verfügbar. Ein Angreifer braucht keine Lizenz, kein Compliance-Team und keinen Vorstandsbeschluss, um Claude oder GPT-5 auf öffentlich einsehbaren Bank-Code, auf veröffentlichte API-Spezifikationen oder auf decompilierten Mobile-Banking-Code loszulassen. Ein CISO einer Sparkasse hingegen braucht für genau dasselbe ein internes Projekt, eine Datenschutz-Folgenabschätzung und meistens auch noch eine Stellungnahme der BaFin-Aufsicht zu DORA-Konformität.
Diese Asymmetrie ist neu. Sie wird sich verschärfen.
Zweitens: Der Code in europäischen Banken ist im Schnitt deutlich älter als der in Krypto-Protokollen. COBOL-Module aus den 80ern. Java-Layer aus den frühen 2000ern. Eine Schicht REST-APIs darüber. Eine Schicht Microservices darüber. Wer schon einmal ein Core-Banking-Refactoring begleitet hat, weiß, dass dort Geschäftslogik schlummert, die niemand mehr vollständig versteht. Genau das ist die Sorte Codebase, in der LLMs glänzen. Sie ermüden nicht, sie verstehen Pattern, sie ziehen Querverbindungen über tausende Dateien.
Drittens: DORA ist seit Januar 2025 anwendbar. Threat-Led Penetration Testing (TLPT) ist für signifikante Institute verpflichtend. Die Frage ist nicht mehr, ob Sie KI-gestützte Sicherheitstests durchführen. Die Frage ist, ob Sie es vor oder nach dem nächsten ernsthaften Vorfall tun. Und ob Sie es selbst tun oder es Ihnen passiert.
Aus meiner Sicht: Wer 2026 noch glaubt, klassische Pentests reichen aus, hat das Tempo der Werkzeugentwicklung nicht verstanden. Ein menschliches Red Team kostet 80.000 bis 200.000 Euro pro Engagement und arbeitet zwei bis vier Wochen. Eine KI-gestützte Code-Analyse kann 24 Stunden laufen, kostet einen Bruchteil und findet eine andere Klasse von Fehlern. Beides braucht es. Aber nur eines wird derzeit von 90 Prozent der Häuser ernsthaft betrieben.
Was Smart-Contract-Auditing und Bank-IT verbindet
Der Zcash-Fall ist deshalb relevant, weil er zwei Welten verbindet, die in deutschen Finanzhäusern oft getrennt gedacht werden.
Smart-Contract-Auditing in der Krypto-Welt ist eine reife Disziplin geworden. Firmen wie Trail of Bits, OpenZeppelin oder ConsenSys Diligence setzen LLMs seit über einem Jahr produktiv ein. Sie kombinieren das mit formaler Verifikation und symbolischer Ausführung. Die Tools sind teilweise Open Source. Slither, Mythril, jetzt KI-augmentiert.
Dieselben Techniken sind eins zu eins übertragbar auf Smart Contracts, die Banken künftig im Rahmen von MiCA-konformen Krypto-Dienstleistungen anbieten. Tokenisierte Anleihen, programmierbares Geld auf der EZB-Wholesale-CBDC, On-Chain-Settlement. Wer hier auf den Markt geht ohne KI-gestütztes Auditing seiner eigenen Verträge, riskiert nicht nur Geld. Er riskiert seine Lizenz.
Und der Transfer geht weiter. Dieselben Modelle, die Solidity-Code prüfen, prüfen auch Java, Python, C++. Sie prüfen Konfigurationen, IAM-Policies, Netzwerk-Regeln. Ein typisches Muster bei aktuellen Engagements: Das LLM findet nicht den spektakulären Zero-Day, sondern die langweiligen Dinge. Eine fehlerhafte Rechteprüfung in einem Reporting-Tool. Eine vergessene Test-API mit Produktivdaten. Ein Logging-Endpoint, der Klartext-Passwörter mitschreibt. Genau die Sachen, die in DORA-Audits später teuer werden.
Konkrete Handlungsempfehlung
Drei Schritte, die in den nächsten 90 Tagen umsetzbar sind, unabhängig davon, ob Sie eine Regionalbank, ein FinTech oder ein Vermögensverwalter sind.
Schritt 1: Inventur der angreifbaren Oberfläche. Bevor Sie KI-gestützte Sicherheit kaufen, müssen Sie wissen, was Sie haben. Listen Sie auf: Welcher Code ist öffentlich einsehbar? Mobile Apps werden decompiliert. SDKs liegen offen. Open-Source-Beiträge Ihrer Entwickler verraten interne Strukturen. API-Dokumentationen sind oft halb-öffentlich. Ein Angreifer mit einem guten LLM kennt Ihr Haus möglicherweise besser als Ihr eigenes Security-Team. Diese Inventur ist die Grundlage für alles Weitere.
Schritt 2: Pilot mit einem klar abgegrenzten Scope. Wählen Sie ein einzelnes, mittelgroßes System aus. Idealerweise etwas, das Sie ohnehin refactoren wollen. Lassen Sie ein qualifiziertes externes Team einen KI-gestützten Code-Audit durchführen. Bestehen Sie auf einem Report, der unterscheidet zwischen Befunden, die ein klassisches Tool auch gefunden hätte, und solchen, die spezifisch durch LLM-Analyse aufgetaucht sind. Das gibt Ihnen die Vergleichsbasis für die Investitionsentscheidung danach.
Schritt 3: Klären Sie die Datenschutz-Frage einmal sauber, statt sie bei jedem Projekt neu zu verhandeln. Die größte Bremse bei KI in der Bank-IT-Sicherheit ist nicht die Technik, sondern die wiederkehrende Diskussion, ob man Code an OpenAI schicken darf. Klären Sie einmalig mit Datenschutz, Compliance und gegebenenfalls der Aufsicht: Welche Modelle dürfen wo eingesetzt werden? On-Premise-Modelle wie Llama oder Mistral sind technisch ausgereift. Azure OpenAI mit EU-Datenresidenz ist für viele Häuser bereits akzeptiert. Schaffen Sie einen Katalog erlaubter Werkzeuge, dann muss nicht jedes Projektteam bei null anfangen.
Was ich nicht empfehle
Ich empfehle nicht, jetzt panisch ein Budget für KI-Security freizugeben und das nächstbeste Tool zu kaufen. Der Markt ist voll mit Anbietern, die KI auf die Schachtel drucken und darunter klassische statische Codeanalyse verkaufen. Lassen Sie sich konkrete Befund-Beispiele zeigen. Lassen Sie sich erklären, was das Tool kann, was Semgrep oder SonarQube nicht können.
Und ich empfehle nicht, Krypto als exotisches Sonderthema abzutun. Der Zcash-Vorfall ist nicht über Krypto. Er ist über die Tatsache, dass die Werkzeuge zum Finden von Sicherheitslücken in komplexem Code in den vergangenen 18 Monaten qualitativ besser geworden sind als das, was Banken intern einsetzen. Das ist ein Strukturthema. Wer es jetzt ernst nimmt, hat einen Vorsprung. Wer es ignoriert, lernt es im nächsten Vorfallbericht.