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:
- 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.
- 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.
- 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 — wir antworten persönlich.