AI Code Audit, Code Review oder Pentest: Was passt wann?
Timo Wevelsiep•Aktualisiert: 31.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Sie möchten eine KI-generierte Anwendung einmalig einordnen oder laufend prüfen lassen? WZ-IT bietet den Production Readiness Audit als Baseline und den AI Code Review Retainer für wiederkehrende menschliche Reviews an.
AI Code Audit, laufendes Code Review und Penetrationstest werden in Suchergebnissen häufig nebeneinander genannt. Sie lösen jedoch nicht dasselbe Problem. Die wichtigste Unterscheidung ist nicht das verwendete Werkzeug, sondern die Frage, welche Aussage am Ende belastbar getroffen werden soll.
- Ein Audit fragt: Wo steht die Anwendung heute und was blockiert Go-live oder Übernahme?
- Ein laufendes Review fragt: Welche neuen Risiken entstehen durch die aktuellen Änderungen?
- Ein Pentest fragt: Welche Schwachstellen lassen sich über die erreichbare Anwendung tatsächlich ausnutzen?
- Software-Wartung fragt anschließend: Wer setzt notwendige Änderungen kontrolliert um?
Die Prüfarten im direkten Vergleich
| Merkmal | AI Code & Production Readiness Audit | Laufendes Code Review | Penetrationstest | Software-Wartung |
|---|---|---|---|---|
| Primäres Ziel | Technischen Ausgangsstand und Go-live-Risiken erfassen | Neue Änderungen wiederkehrend prüfen | Ausnutzbare Schwachstellen aus Angreifersicht finden | Vereinbarte Korrekturen, Updates und Releases umsetzen |
| Typischer Zeitpunkt | Vor Go-live, Übernahme, Migration oder Investition | Während fortlaufender Entwicklung | Vor kritischem Launch, nach größeren Änderungen oder nach Risikomodell | Nach bestätigtem Ausgangsstand laufend |
| Betrachtete Ebene | Code, Auth, Daten, Dependencies, Deployment und Betrieb | Diffs, Pull Requests und ihre Wirkung auf das Gesamtsystem | Erreichbare Anwendung, APIs, Identität und technische Angriffsfläche | Repository, Dependencies, Tests und Releaseweg |
| Ergebnis | Priorisierte Baseline mit Blockern und Maßnahmen | Wiederkehrende Findings und technische Entscheidungen | Bericht mit reproduzierbaren Sicherheitsbefunden | Geänderte, getestete und freigegebene Software |
| Behebt automatisch Probleme? | Nein | Nein | Nein | Im vereinbarten Korridor ja |
Die Tabelle zeigt auch, warum ein günstiger automatischer Scan kein vollständiger Ersatz ist. Ein Tool kann eine unsichere Paketversion melden. Es kann aber nicht zuverlässig entscheiden, ob der betroffene Codepfad erreichbar ist, welche Kundendaten betroffen wären, ob eine Zwischenmaßnahme genügt oder ob das Update einen kritischen Ablauf bricht.
Was ist ein AI Code Audit?
Der Begriff ist nicht normiert. Seriös verwendet beschreibt er eine einmalige technische Prüfung von Software, die ganz oder teilweise mit KI-Werkzeugen entstanden ist. Die Prüftiefe muss deshalb im Angebot konkret benannt werden.
Ein belastbarer Audit betrachtet typischerweise:
- Repository, Build und reproduzierbare Laufzeit
- Architektur, APIs, Datenmodell und Hintergrundprozesse
- Authentifizierung, Autorisierung, Rollen und Mandantentrennung
- RLS, Storage-Regeln und administrative Funktionen
- Secrets, Umgebungsvariablen und externe Schlüssel
- Dependencies, bekannte CVEs und End-of-Life-Risiken
- Tests, CI/CD, Staging, Produktion und Rollback
- Logging, Monitoring, Backup und Wiederherstellbarkeit
Bei KI-generiertem Code sind diese Ebenen besonders wichtig, weil ein funktionierender Demo-Flow keine Aussage über unsichtbare Systemgrenzen trifft. Ein Login kann funktionieren, obwohl ein API-Endpunkt nur Authentifizierung und keine Rolle prüft. Ein Dashboard kann korrekt aussehen, obwohl eine Datenbankregel andere Mandanten nicht sauber trennt.
Der Production Readiness Audit von WZ-IT verbindet deshalb Codeprüfung und Betriebsreife. Er ist keine Garantie auf Fehlerfreiheit und kein vollständiger offensiver Sicherheitstest.
Was ist laufendes Code Review?
Ein laufendes Review setzt auf einem bekannten Ausgangsstand auf. Statt die gesamte Anwendung in jedem Zyklus neu zu auditieren, konzentriert es sich auf den vereinbarten Änderungskorridor und dessen Auswirkungen.
Typische Fragen sind:
- Verändert ein Pull Request Rollen, Datenzugriff oder Tenant-Isolation?
- Führt eine neue Dependency eine relevante CVE oder ein EOL-Risiko ein?
- Erzeugt ein neuer API-Endpunkt eine fehlende Autorisierungsgrenze?
- Sind Migration, Rollback und Fehlerbehandlung für die Änderung nachvollziehbar?
- Muss ein Finding vor dem Release behoben werden oder kann es dokumentiert eingeplant werden?
Der Wert entsteht durch Kontinuität. Reviewer kennen Architektur, Risikoprofil und frühere Entscheidungen. Dadurch müssen sie nicht bei jeder Frage wieder bei null beginnen. Das ist besonders sinnvoll, wenn ein kleines Team mit Cursor, Claude Code, Lovable oder anderen KI-Werkzeugen schnell weiterentwickelt, aber keinen eigenen Senior-Reviewprozess vorhalten kann.
Der AI Code Review Retainer trennt diese technische Kontrollfunktion bewusst von Implementierung, Hosting und Incident-Reaktion.
Was prüft ein Penetrationstest anders?
Ein Penetrationstest nimmt primär die Perspektive eines Angreifers ein. Ziel ist nicht nur, problematischen Code zu erkennen, sondern Schwachstellen kontrolliert nachzuweisen. Umfang und Regeln müssen vorab festgelegt werden, etwa erlaubte Ziele, Testkonten, Zeitfenster, ausgeschlossene Systeme und Umgang mit produktiven Daten.
Je nach Scope kann ein Pentest unter anderem untersuchen:
- Authentifizierungs- und Session-Angriffe
- fehlende Zugriffskontrollen und IDOR/BOLA
- Injection, Request Manipulation und unsichere APIs
- Fehlkonfigurationen erreichbarer Dienste
- Rechteausweitung und Kombination mehrerer Schwachstellen
- Verhalten von Rate Limits, Passwort-Reset und administrativen Pfaden
Ein Black-Box-Test sieht dafür nicht automatisch interne Dependency-Risiken, ungenutzte gefährliche Funktionen oder einen fehlenden Restore-Prozess. Ein White-Box-Pentest kann Quellcode und Architektur einbeziehen, bleibt aber auf ein definiertes Sicherheitsziel und Testfenster begrenzt.
OWASP weist mit ASVS und dem Web Security Testing Guide bewusst unterschiedliche Verifikations- und Testperspektiven aus. Das unterstreicht: Sicherheitskontrollen im Entwicklungsprozess und offensive Prüfung sind komplementär.
Wo automatische Prüfungen hineinpassen
Automatisierung ist ein wichtiger Teil jeder der drei Prüfarten:
- Software Composition Analysis erkennt bekannte Risiken in Dependencies.
- Secret Scanning sucht versehentlich eingecheckte Zugangsdaten.
- Static Analysis findet bestimmte Code- und Datenflussmuster.
- Container- und Image-Scans prüfen Betriebssystempakete und Basisimages.
- Dynamic Scans testen die laufende Anwendung auf bekannte Webmuster.
NIST beschreibt im Secure Software Development Framework sichere Entwicklung als wiederholbaren Prozess aus Vorbereitung, Schutz, Produktion und Reaktion. Ein einzelner Scanner erfüllt diesen Prozess nicht. Er liefert Eingaben, die gegen Architektur, Exposition, Geschäftsrisiko und Releaseplanung bewertet werden müssen.
Welche Kombination passt zu welcher Situation?
Vor dem ersten produktiven Einsatz
Starten Sie mit einem einmaligen Audit. Er schafft eine Baseline und trennt Launch-Blocker von technischen Schulden. Bei einer internetexponierten Anwendung, sensiblen Daten oder besonderem Angriffsrisiko kann danach ein Pentest folgen.
Das Team entwickelt nach dem Go-live regelmäßig weiter
Ergänzen Sie laufendes Code Review. Der Rhythmus kann monatlich für planbare Änderungen oder wöchentlich für aktive Releasezyklen gestaltet werden. Kritische Änderungen müssen dabei klar gekennzeichnet und mit ausreichendem Kontext bereitgestellt werden.
Niemand setzt Findings zuverlässig um
Ein Review allein löst das Problem nicht. In diesem Fall braucht es Software-Wartung und laufende Betreuung oder ein internes Team mit festem Korridor für Korrekturen, Tests und Releases.
Die Anwendung verarbeitet besonders schützenswerte Daten
Audit und Review prüfen die Software. Der Betriebsrahmen bleibt eine eigene Ebene. Für Berufsgeheimnisträger kann beispielsweise die §203 Managed Cloud zusätzlich relevant sein. Ein Code Review allein erzeugt keinen solchen Vertrags- und Infrastrukturrahmen.
Eine klare Beauftragung verhindert falsche Erwartungen
Vor jeder Prüfung sollten mindestens folgende Punkte schriftlich feststehen:
- Repository, Anwendungen, APIs und Umgebungen im Scope
- technischer Ausgangsstand und bekannte Altbefunde
- erlaubte Zugriffe und Umgang mit Quellcode
- Reviewzeitraum oder wiederkehrender Rhythmus
- Ergebnisformat und Risikoklassen
- Kommunikations- und Antwortziele
- Zuständigkeit für Fixes, Retest und Releases
- ausdrückliche Ausschlüsse wie Pentest, Hosting oder 24/7-Reaktion
Damit wird aus dem allgemeinen Versprechen "wir schauen auf den Code" eine überprüfbare Leistung.
Quellen
Anfrage
KI-generierte Software prüfen oder laufend begleiten
Beschreiben Sie Anwendung, Ausgangsstand und Arbeitsweise. Wir ordnen ein, ob ein einmaliger Audit, laufendes Code Review, Software-Wartung oder ein kombinierter Produktionsweg passt.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Nein. Ein AI Code Audit ist typischerweise eine einmalige Bestandsaufnahme einer Anwendung und betrachtet neben Quellcode auch Authentifizierung, Datenzugriff, Dependencies, Deployment und Betriebsreife. Ein laufendes Code Review prüft dagegen neue Änderungen wiederkehrend auf Basis eines bekannten Ausgangsstands.
Nein. Ein Code Review bewertet Quellcode und technische Zusammenhänge, während ein Penetrationstest die erreichbare Anwendung mit offensiven Prüfmethoden auf ausnutzbare Schwachstellen untersucht. Beide Verfahren können sich ergänzen, decken aber unterschiedliche Perspektiven ab.
Ein einmaliger Audit passt als Baseline vor dem ersten Go-live, einer Übernahme oder einer größeren Investition. Wird die Anwendung anschließend regelmäßig verändert, altert dieser Befund und sollte durch wiederkehrende Reviews, Software-Wartung oder beides ergänzt werden.
Scanner finden bekannte Muster, Secrets, verwundbare Paketversionen und weitere technische Signale. Sie ersetzen nicht die menschliche Einordnung von Geschäftslogik, Autorisierung, Datenwegen, tatsächlicher Exposition und Auswirkungen einer Änderung.
Nein. Der Begriff beschreibt vor allem den Anlass: Software wurde stark mit generativer KI entwickelt und soll vor produktiver Nutzung unabhängig geprüft werden. Das Vorgehen kann für Lovable, Cursor, Claude Code, Bolt, Replit oder klassisch entwickelte Anwendungen sinnvoll sein.
Audit, Review und Pentest liefern zunächst Befunde. Die Umsetzung kann das bestehende Team, eine Agentur oder WZ-IT über einen getrennten Software-Care- oder Entwicklungsumfang übernehmen. Diese Trennung macht Verantwortung und Preis nachvollziehbar.
Mehr zu KI-Code & Softwarequalität
- AI Code Audit, Code Review oder Pentest?
- KI-generierte Software vor Produktion prüfen
- Laufendes Code Review oder Software-Wartung?
