Drei Fragen und Antworten: Wie KI wirklich bei der Schwachstellensuche hilft

KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber ein Selbstläufer ist das nicht. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt Stephan Zeisberg, Titelautor der neuen iX 8/2026.

Stephan Zeisberg ist Head of Research bei Security Research Labs (SRLabs) und forscht zu KI-gestützten Codeaudits und Schwachstellenanalyse.

(Bild: iX)

Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?

Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich „almost entirely unmanageable“.

Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben, was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.

Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?

Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.

Mozilla hat seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Darauf haben sie die agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination.

Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.

Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?

Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren, statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.

Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.

Stephan, vielen Dank für die Antworten! Einen Überblick, wie sich KI sinnvoll in Codereviews nutzen lässt, gibt es in der neuen iX. Außerdem zeigen wir, wie KI-Tools im Unternehmensumfeld für Pentesting genutzt werden. All das und viele weitere Themen finden Leser im August-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)