KI-Schwachstellenforschung 2026 — was sich ändert, was bleibt

Matthias Barth · 2026-05-20 · 5 Min.

> Vor zwölf Monaten haben wir den ersten KI-gestützten Audit gefahren. Seitdem ist > aus dem Versuch eine eigenständige Disziplin geworden — mit Werkzeugen, Workflows > und einer Liste an Stolperfallen, die nirgendwo dokumentiert war. ## Was sich geändert hat Sprachmodelle der zweiten Generation lesen Code, der gut strukturiert ist, fast so verlässlich wie ein erfahrener Reviewer. Wir nutzen sie in **drei Stufen**: 1. **Statische Triage** — Modelle scannen Diffs und PRs, markieren Auffälligkeiten (Auth-Bypass-Muster, unsichere Deserialisierung, Race-Conditions), und sortieren nach Wahrscheinlichkeit. Das ist kein Ersatz für SAST, aber es findet die Dinge, die ein klassischer Linter nicht versteht: *Was* der Code tun *will*. 2. **Hypothesen-Test** — Für jeden Befund baut die Pipeline aus dem Codepfad automatisch einen Repro-Versuch. Falsch-positive landen früh im Müll, weil sie sich nicht reproduzieren lassen. 3. **Kontext-Bewertung** — Wir prüfen, ob die Schwachstelle im jeweiligen Kunden-Setup überhaupt ausnutzbar ist. Ein RCE in einem Service ohne öffentlichen Endpunkt ist eben kein RCE im Sinne des Incident-Playbooks. ## Was *nicht* funktioniert hat - **Pure-Prompt-Audits** (»scan this for vulnerabilities«) liefern Listen, die zu 80 % aus Halluzinationen bestehen. Wir bauen Tooling, nicht Konsumenten-Chats. - **Vollautomatische Tickets**: ohne menschliche Triage füllt sich das Ticketsystem mit Lärm. Wir lassen das LLM Befunde *vorsortieren*, nicht *abschließen*. - **„Einfach das größte Modell nehmen"**: Kostenseitig nicht haltbar, und die Qualitätsgewinne sind im Sicherheitskontext kleiner, als die Marketing-Decks versprechen. ## Was wir wieder so machen würden - **Ergebnisse versionieren wie Code.** Findings landen in Git, mit Hash der zugrunde liegenden Quelle. So sind Re-Audits reproduzierbar. - **Confidence-Scores belasten, nicht garnieren.** Wir nehmen Modelle nur dort ernst, wo wir die Outputs gegen ein zweites Verfahren (statische Analyse, Symbol-Execution, Manuell-Review) gegengeprüft haben. - **Den Menschen behalten.** Modelle lesen Code, sie verstehen aber selten den Betrieb dahinter. Die schwersten Funde — *Wer kann das wann überhaupt triggern?* — kommen weiter aus Gesprächen mit Ops-Teams, nicht aus Tokens. ## Wo wir hingehen 2026 wird das Jahr, in dem KI-gestützte Pipelines aus dem Beratungs- in den Produktbereich rutschen. Unsere Hypothese: Wer **jetzt** sauberes Tooling baut, das Modelle als *Inspector* einbindet — nicht als Autopilot — hat in 18 Monaten einen messbaren Vorsprung beim **Mean Time to Patch**. Wir sehen das jeden Tag in Kundenprojekten. Was wir nicht sehen: dass diese Disziplin in 24 Monaten noch wegzudenken wäre. --- > Du willst wissen, wie ein KI-gestütztes Vulnerability-Management in deinem > Stack konkret aussehen würde? [Schreib uns einen Satz](/#contact) — wir > antworten persönlich.