Schwachstellen finden mit KI: Der Workflow entscheidet, nicht das Modell

Zwei Meldungen aus derselben Juliwoche 2026. Erstens: Der Sicherheitsforscher Chaofan Shou ließ das Modell Kimi K3 auf Redis 8.8.0 los und hatte nach rund 90 Minuten 19 bisher unbekannte Sicherheitslücken auf dem Tisch, samt Proof-of-Concept-Code. Die Redis-Entwickler haben die Funde inzwischen mit Patch-Releases bestätigt. Zweitens: Projekte wie curl und Node.js haben ihre Bug-Bounty-Programme pausiert oder eingestellt, weil sie in KI-generierten Sicherheitsmeldungen ersticken, von denen der Großteil wertlos ist.

Dieselbe Technik, im einen Fall ein Durchbruch, im anderen eine Plage. Der Unterschied liegt nicht im Modell. Er liegt in dem, was um das Modell herum gebaut ist, und genau das macht den Fall für jeden interessant, der eigene Software betreibt und sie prüfen lassen will.

Der Engpass ist nicht das Finden, sondern das Prüfen

KI-Modelle sind darin, verdächtige Stellen in Code zu markieren, inzwischen erschreckend produktiv. Das Problem sitzt eine Stufe später. Jede Meldung muss jemand prüfen, und diese Prüfkapazität wächst nicht mit, wenn die Fundmenge explodiert. Stephan Zeisberg, Head of Research bei Security Research Labs, bringt es auf diesen Punkt: Der eigentliche Wert entsteht erst durch die Verifikation, und genau die ist knapp.

Die Zahlen dazu sind deutlich. Für KI-Sicherheitsmeldungen ohne eingebaute Gegenprüfung wurden in den Jahren 2024 und 2025 False-Positive-Quoten um die 80 Prozent berichtet. Vier von fünf Meldungen sind dann Fehlalarm, klingen aber genauso dringend wie der eine echte Fund. Wer so eine Liste ungefiltert auf ein kleines Team kippt, erzeugt keine Sicherheit, sondern Stillstand. Die pausierten Bug-Bounty-Programme sind die logische Folge, denn dort kippten Fremde diese Listen bei den Maintainern ab, in der Hoffnung auf Prämien.

Was die erfolgreichen Fälle anders machen

Der Redis-Fund und ein zweites Beispiel zeigen, wie die produktive Variante aussieht. Mozilla hat für Firefox 150 insgesamt 271 Sicherheitsbugs geschlossen, und zwar nicht mit einem besseren Modell, sondern mit einer Pipeline, die eine harte Regel durchsetzt: Jeder Befund braucht einen reproduzierbaren Testfall. Eine Meldung ohne Nachweis existiert für den Prozess schlicht nicht. Beim Redis-Fall steckte dieselbe Idee im Vorgehen, denn die 19 Lücken kamen nicht als Behauptungen, sondern mit lauffähigem Proof-of-Concept-Code, den die Maintainer direkt nachvollziehen konnten.

Das ist der ganze Trick, und er ist unspektakulärer, als die Schlagzeilen klingen. Die KI darf so viel Verdacht schöpfen, wie sie will, aber in die Fundliste kommt nur, was sich konkret vorführen lässt. Mit dieser einen Regel fällt der 80-Prozent-Müllberg in sich zusammen, weil Fehlalarme naturgemäß keinen funktionierenden Nachweis produzieren können.

Foto: afgprogrammer / Unsplash

Wie ein Audit-Durchgang für ein Webprojekt aussieht

Ich arbeite täglich mit KI am Code und lasse sie regelmäßig als zweite Sicht über Projekte laufen. Aus dieser Praxis heraus hat sich für normale Webprojekte, also die Größenordnung Firmenwebsite, Shop, Buchungssystem oder internes Tool, ein Ablauf in fünf Schritten bewährt:

1. Scope klein schneiden. Nicht “prüf mal alles”, sondern gezielt die Stellen, an denen etwas zu holen ist: Login und Session-Handling, Datei-Uploads, API-Endpunkte, alles rund um Zahlungen, jede Stelle, die Nutzereingaben verarbeitet. Ein enger Auftrag liefert tiefere Ergebnisse als ein breiter.
2. Nachweis-Pflicht in den Auftrag schreiben. Die KI bekommt die Regel mit, dass jeder Fund einen konkreten Testfall braucht, etwa den genauen Request, der das Problem auslöst. Was sie nicht belegen kann, darf sie höchstens als offene Frage markieren.
3. Funde deduplizieren und begrenzen. Modelle melden dieselbe Schwäche gern fünfmal in Varianten. Pro Code-Bereich eine begrenzte Zahl von Findings zulassen und Doppelungen zusammenfassen, sonst wächst die Liste schneller, als sie schrumpft.
4. Von außen nach innen priorisieren. Zuerst alles, was ein Fremder ohne Zugangsdaten erreichen kann, dann die Probleme, die einen bestehenden Account voraussetzen, zuletzt theoretische Schwächen, die im konkreten Aufbau gar nicht erreichbar sind.
5. Fixes mit Test absichern und wiederholen. Jeder bestätigte Fund bekommt nach dem Fix einen Test, der das Wiederauftreten meldet. Der Durchgang selbst wird bei größeren Änderungen wiederholt, ein Audit ist ein Zustand zum Zeitpunkt X, kein Dauerzertifikat.

Der Zeitaufwand dafür ist überschaubar geworden, das Durchkämmen selbst kostet eher Minuten als Tage. Die Arbeit steckt in den Schritten drumherum, und die lassen sich nicht wegautomatisieren, weil sie Urteilsvermögen brauchen.

Foto: andrewtneel / Unsplash

Wo der Mensch gesetzt bleibt

Drei Dinge kann die Pipeline nicht übernehmen. Das erste ist die Verifikation selbst, denn auch ein mitgelieferter Testfall muss jemand ausführen, verstehen und im Kontext bewerten. Das zweite ist das Threat-Modell, also die Frage, was in diesem konkreten System überhaupt schützenswert ist und wer realistisch angreift. Eine KI findet den unverschlossenen Keller, aber sie weiß nicht, ob dort Werkzeug oder Goldbarren lagern. Das dritte sind Logik- und Berechtigungsfehler im Geschäftsprozess, etwa wenn ein Nutzer über eine legale Abfolge von Klicks an Daten kommt, die nicht für ihn bestimmt sind. Solche Lücken sehen für jeden Scanner wie normales Verhalten aus.

Gerade bei Projekten, die überwiegend per KI gebaut wurden, ist diese zweite menschliche Sicht der eigentliche Gewinn. Der Code entsteht dort schneller, als ihn je ein Mensch gelesen hat, und die beiläufige Kontrolle eines klassischen Code-Reviews fehlt komplett. Was dabei typischerweise liegen bleibt, habe ich im Beitrag zur Due Diligence für KI-gebaute Projekte aufgeschrieben, das Audit ist das passende Werkzeug dazu.

Unterm Strich hat sich die Frage verschoben. Ob KI Schwachstellen finden kann, ist seit spätestens diesem Juli keine Diskussion mehr wert, 19 bestätigte Zero-Days in 90 Minuten beenden sie. Die Frage ist, ob aus dem Fundstrom geprüfte, priorisierte und behobene Probleme werden oder eine Liste, die alle lähmt. Das entscheidet der Workflow, nicht das Modell.

Wenn du eine Anwendung betreibst, ob klassisch entwickelt oder mit KI gebaut, und wissen willst, wo sie sicherheitstechnisch steht, melde dich gerne. Ich mache so einen Durchgang mit nachvollziehbaren Nachweisen statt einer Schreckensliste, und danach weißt du, was wirklich zu tun ist und was nicht.