Warum KI-Security-Audits ab sofort in jeden Release gehören

Vor achtzehn Monaten war „KI im Security-Audit“ noch ein Bullet auf einer Roadmap. Heute sitzt in fast jeder Entwicklungsabteilung der Welt ein Modell, das besser darin ist, Schwachstellen in einer fremden Codebasis zu finden als die meisten mittelerfahrenen Pentester — und zwar innerhalb von Minuten statt Tagen. Claude ist das sichtbarste Beispiel, aber bei weitem nicht das einzige. Die Frage ist nicht mehr, ob sich das Bedrohungsmodell Ihrer Organisation dadurch verschoben hat. Die Frage ist, wie schnell Sie Ihre Prozesse entsprechend anpassen.

Die Asymmetrie, die sich gerade auflöst

Security hat seit jeher von einer Asymmetrie zugunsten der Angreifer gelebt: Ein Angreifer muss eine Lücke finden, ein Verteidiger alle. Was sich jetzt ändert, ist die Kostenstruktur auf Angreiferseite. Was früher ein spezialisierter Researcher mit Wochen Review-Aufwand war, ist heute ein API-Aufruf für wenige Euro. Bekannte Klassen — unsichere Deserialisierung, SSRF durch fehlende Allowlists, Auth-Bypasses über inkonsistente Middleware, Race Conditions in Zahlungsflüssen — werden in einer Geschwindigkeit gefunden, die mit manuellen Reviews nicht konkurrieren kann.

Das Problem ist nicht, dass Claude das kann. Das Problem ist, dass jeder das kann. Wer heute eine Reverse-Engineering-Session oder ein Supply-Chain-Audit auf Ihre Open-Source-Abhängigkeiten fährt, braucht weder Spezialwissen noch Infrastruktur. Die Einstiegshürde liegt bei „Kreditkarte“.

Warum der klassische Release-Zyklus nicht mehr passt

Die meisten Organisationen, mit denen wir sprechen, führen jährlich einen externen Pentest durch, halbjährlich vielleicht einen internen, und zwischendrin laufen SAST und DAST im CI. Das war ein vernünftiger Kompromiss, solange der Angriffsaufwand in ähnlicher Größenordnung blieb wie der Verteidigungsaufwand. Dieser Kompromiss bricht jetzt.

Drei Entwicklungen kommen zusammen. Erstens steigt die Release-Frequenz: Teams deployen täglich, viele stündlich, und jeder Release ist eine potenzielle neue Angriffsfläche. Zweitens ist die Zeit zwischen öffentlichem Code-Push und automatisierter Analyse durch Dritte de facto null — Angreifer warten nicht auf Ihren nächsten Jahrespentest. Drittens findet klassisches SAST bekannte Patterns, während KI-gestützte Analyse auch Logikfehler findet, also genau die Klasse, bei der Pentests bisher teuer waren.

Wenn Ihre Gegenseite in Minuten findet, was Ihre eigene Pipeline in sechs Monaten vielleicht entdeckt, haben Sie kein Tooling-Problem. Sie haben ein Kadenz-Problem.

Was „KI-Audit pro Release“ konkret heißt

Die Empfehlung ist nicht, das externe Pentest-Budget zu streichen — klassische Pentests bleiben wertvoll, gerade für Threat Modeling und kreative Angriffspfade, die ein Modell nicht in der Form konstruiert. Die Empfehlung ist, die Lücke zwischen „im CI läuft SAST“ und „einmal im Jahr kommt ein Pentest-Team“ zu schließen.

Ein KI-gestütztes Audit pro Release umfasst typischerweise vier Bestandteile:

• Diff-basierte Code-Analyse. Das Modell bekommt den Delta des Releases plus den relevanten Kontext und prüft auf Lücken, die ein menschlicher Reviewer in einer PR-Prüfung übersehen könnte — insbesondere Auth-, Autorisierungs- und Input-Validierungsprobleme an neuen Endpoints.
• Abhängigkeits- und Konfigurationsprüfung. Neue Dependencies, geänderte IAM-Policies, geänderte CORS- oder CSP-Header, geänderte Feature-Flag-Defaults. Das ist die Klasse von Änderungen, bei denen Supply-Chain- und Mis-Config-Angriffe entstehen — und die im klassischen Code-Review oft durchrutschen.
• Angriffspfad-Simulation. Das Modell wird explizit angewiesen, aus Angreiferperspektive zu denken: Was würde ein informierter externer Akteur an diesem Release zuerst probieren? Welche Vorannahmen ließen sich brechen?
• Regression auf bekannte Findings. Findings aus früheren Audits werden gegen jeden Release geprüft, um eine Reintroduction zu verhindern. Das ist der Schritt, den viele Organisationen unterschätzen.

Wichtig ist, dass das Ergebnis triagiert in Ihrem Issue-Tracker landet, nicht in einem PDF. Ein KI-Audit, das keinen Owner und kein SLA bekommt, ist reine Beruhigung.

Die drei Einwände, die wir am häufigsten hören

„Das produziert zu viele False Positives.“ Stimmt für naive Setups. Die Qualität steht und fällt mit dem Kontext, den Sie dem Modell geben — Zugriff auf die volle Codebasis, auf Test-Coverage, auf Architekturdokumentation und auf frühere Findings. Ein gut kontextualisiertes Audit hat eine False-Positive-Rate, die deutlich unter klassischem SAST liegt. Der Aufwand verschiebt sich von „Signal aus Rauschen ziehen“ zu „Kontext pflegen“ — und das ist die ungleich lohnendere Arbeit.

„Wir schicken keinen Code an einen externen Anbieter.“ Legitimer Einwand. Die Antwort sind Zero-Retention-Verträge, Enterprise-Tenants ohne Training-Nutzung, oder — wenn die Datenklassifizierung es verlangt — self-hosted Modelle hinter Ihrer eigenen Netzgrenze. Die Hyperscaler haben mittlerweile Enterprise-Tiers, die BaFin-, ISO-27001- und HIPAA-Anforderungen abdecken. Wer 2026 noch behauptet, KI sei aus Compliance-Gründen nicht einsetzbar, meint in der Regel: Wir haben die Beschaffung noch nicht angepasst.

„Dafür haben wir kein Budget.“ Rechnen Sie den Vergleich: Ein externer Pentest-Tag kostet im niedrigen bis mittleren vierstelligen Bereich. Ein KI-gestütztes Audit pro Release kostet, bei realistischer Token-Auslastung und einem typischen Enterprise-Stack, pro Release weniger als ein Mittagessen für das Team. Das Problem ist nicht das Budget. Das Problem ist, dass die Pipeline, in die das Audit eingebettet werden muss, noch nicht existiert — und der Aufbau dieser Pipeline braucht Engineering-Zeit, kein Lizenzbudget.

Was Sie diese Woche tun können

Wenn Sie als CTO oder CISO genau einen Schritt setzen wollen: Lassen Sie einen Ihrer letzten drei Releases manuell durch ein KI-Audit laufen. Nehmen Sie Claude, ein vergleichbares Frontier-Modell oder ein self-hosted Äquivalent. Geben Sie dem Modell den Diff plus ausreichend Kontext und bitten Sie um ein Security-Review aus Angreiferperspektive.

Das Ergebnis wird eine von zwei Formen haben. Entweder Sie finden nichts, was Ihre bisherigen Prozesse nicht schon gefunden hätten — dann haben Sie eine vergleichsweise günstige Bestätigung Ihrer aktuellen Posture. Oder Sie finden etwas, das seit Wochen in Produktion ist.

Unsere Erfahrung aus den letzten Monaten deutet auf die zweite Variante. Und sie deutet darauf hin, dass die Angreifer, die mit denselben Tools arbeiten, diesen Zeitvorsprung bereits nutzen.

Die Frage, die Sie Ihrem Team diese Woche stellen sollten, ist deshalb nicht „Sollten wir über KI-Audits nachdenken?“ Sondern: „Warum laufen sie nicht schon heute in jedem Release?“