Automatisierter Pentest mit KI: Wie er funktioniert und wann er sich lohnt

Ein klassischer Penetrationstest liefert eine Momentaufnahme. Moderne Entwicklungsteams liefern jedoch nicht einmal im Jahr aus, sondern täglich. Jeder Merge kann eine neue Schwachstelle in die Produktion bringen, die beim letzten Pentest noch gar nicht existierte. Ein automatisierter Pentest mit KI schließt genau diese Lücke: Er prüft Anwendungen kontinuierlich, liest den Quellcode mit und weist ausnutzbare Schwachstellen nach, bevor Angreifer sie finden.

In diesem Ratgeber erfahren Sie, wie automatisiertes Pentesting funktioniert, worin es sich vom manuellen Test unterscheidet, welche Rolle es für ISO 27001, NIS2 und DORA spielt und wo seine Grenzen liegen.

Was ist ein automatisierter Pentest?

Ein automatisierter Pentest ist ein Sicherheitstest, bei dem eine Software, heute meist KI-gestützt, eine Anwendung wie ein Angreifer untersucht, Schwachstellen identifiziert und deren Ausnutzbarkeit belegt. Anders als ein Schwachstellenscanner meldet er nicht nur verdächtige Muster, sondern prüft, ob sich ein Fund tatsächlich zu einem Angriff verketten lässt.

Der Unterschied ist für Entwicklerteams entscheidend. Ein klassischer Scanner gleicht Code und Abhängigkeiten mit bekannten Signaturen ab und erzeugt dabei oft lange Listen mit theoretischen Risiken. Ein automatisierter Pentest stellt eine andere Frage: Kann ein Angreifer diese Schwachstelle in dieser konkreten Anwendung wirklich ausnutzen? Erst wenn die Antwort „ja“ lautet, landet der Fund im Bericht.

Abgrenzung zu SAST, DAST und Schwachstellenscannern

In der Praxis werden die Begriffe oft vermischt. Eine kurze Einordnung hilft bei der Auswahl:

• SAST (Static Application Security Testing) analysiert den Quellcode, ohne ihn auszuführen. Die Methode findet viele potenzielle Probleme früh, kann aber selten belegen, ob sie in der laufenden Anwendung erreichbar sind.
• DAST (Dynamic Application Security Testing) greift die laufende Anwendung von außen an. Die Methode sieht reale Reaktionen, kennt aber den Code dahinter nicht.
• Schwachstellenscanner prüfen Systeme und Abhängigkeiten auf bekannte Schwachstellen, etwa anhand von CVE-Datenbanken.
• Automatisierter Pentest mit KI verbindet Code-Verständnis mit Angriffslogik: Er sucht im Code nach Schwachstellen, verkettet sie zu realistischen Angriffspfaden und prüft ihre Ausnutzbarkeit.

Damit ersetzt ein automatisierter Pentest nicht zwingend alle anderen Werkzeuge, beantwortet aber die Frage, die für Priorisierung am wichtigsten ist: Was davon ist wirklich gefährlich?

Manueller vs. automatisierter Pentest im Vergleich

Beide Ansätze verfolgen dasselbe Ziel, unterscheiden sich aber deutlich in Rhythmus, Abdeckung und Kostenstruktur.

Warum jährliche Pentests bei täglichen Deployments nicht ausreichen

Ein Pentest im Frühjahr sagt wenig über den Code aus, der im Herbst ausgeliefert wird. Zwischen zwei Tests entstehen neue Endpunkte, neue Abhängigkeiten und neue Berechtigungslogik. Gerade durch KI-gestützte Programmierung wächst der Codeumfang schneller als je zuvor. Wer Sicherheit nur punktuell prüft, akzeptiert lange Zeitfenster, in denen Schwachstellen unentdeckt in Produktion laufen.

Automatisiertes Pentesting verschiebt die Prüfung dorthin, wo Änderungen entstehen: in den Entwicklungsprozess selbst.

White-Box-Pentest: Warum der Quellcode den Unterschied macht

Bei einem Black-Box-Test sieht der Tester nur, was auch ein externer Angreifer sieht. Ein White-Box-Pentest erhält dagegen Zugriff auf den Quellcode. Das klingt nach einem Vorteil für den Verteidiger, und genau das ist es: Die KI kann Datenflüsse über Dateigrenzen hinweg verfolgen, Authentifizierungslogik nachvollziehen und Stellen finden, die von außen kaum erreichbar wirken.

Moderne KI-gestützte Lösungen setzen genau hier an: Sie lesen den Quellcode, identifizieren ausnutzbare Schwachstellen und belegen die Funde entweder in einer Sandbox oder gegen bereits bereitgestellte Anwendungen.

Exploits im Sandbox-Umfeld nachweisen statt nur Muster melden

Der Nachweis ist der Kern eines echten Pentests. Statt „hier könnte eine SQL-Injection vorliegen“ liefert ein guter automatisierter Test einen reproduzierbaren Beleg: Diese Anfrage, an diesen Endpunkt gesendet, führt zu diesem Ergebnis. Für Entwickler bedeutet das weniger Diskussion über die Relevanz eines Fundes und schnellere Behebung.

Weniger False Positives für Entwicklerteams

False Positives sind einer der Hauptgründe, warum Sicherheitstools in Entwicklerteams ignoriert werden. Wenn neun von zehn Warnungen irrelevant sind, wird auch die zehnte übersehen. Ein Ansatz, der nur nachweisbar ausnutzbare Schwachstellen meldet, verändert diese Dynamik: Jeder Fund verdient Aufmerksamkeit, weil er belegt ist.

Pentesting im Pull Request: Sicherheit bei jeder Codeänderung

Der konsequenteste Schritt besteht darin, Sicherheitsprüfungen direkt in den Pull Request zu verlagern. Der Ablauf sieht in der Praxis so aus:

1. Eine Entwicklerin öffnet einen Pull Request mit neuer Funktionalität.
2. Das Tool analysiert die Änderung im Kontext der gesamten Codebasis, nicht nur die geänderten Zeilen.
3. Findet es eine ausnutzbare Schwachstelle, kommentiert es den Pull Request mit Beschreibung und Nachweis.
4. Die Entwicklerin behebt das Problem, bevor der Code in den Main-Branch gelangt.

Gute Tools arbeiten nach diesem Prinzip: Sie prüfen Pull Requests mit der gesamten Codebasis als Kontext und melden nur Probleme, deren Ausnutzbarkeit sie belegen können. Für Teams bedeutet das: Sicherheit wird Teil des normalen Code-Reviews und kein nachgelagerter Audit-Termin.

Was sich für Security- und Entwicklungsteams ändert

Mit Prüfungen im Pull Request verschiebt sich die Rolle des Security-Teams. Statt nach jedem Pentest lange Listen zu triagieren und an Entwickler zu verteilen, landen belegte Funde direkt bei der Person, die den Code geschrieben hat, solange der Kontext noch frisch ist. Das Security-Team kann sich auf Architekturfragen, Bedrohungsmodelle und die wirklich komplexen Fälle konzentrieren.

Für Entwickler sinkt die Hürde ebenfalls. Ein Kommentar im Pull Request mit konkretem Nachweis ist leichter umzusetzen als ein Ticket aus einem Bericht, der Wochen nach der Implementierung erstellt wurde. Wichtig ist dabei, das Tool schrittweise einzuführen: zunächst in wenigen Repositories, mit klaren Regeln, welche Funde einen Merge blockieren und welche nur als Hinweis erscheinen.

Was kostet ein automatisierter Pentest?

Die Kosten hängen stark vom Modell ab. Auf dem Markt haben sich drei Ansätze etabliert:

• Pro Pentest: Ein einmaliger Test einer Anwendung oder eines Repositories, oft gestaffelt nach Codeumfang.
• Nach Codeumfang: Der Preis richtet sich nach der Anzahl der Codezeilen, was größere Codebasen planbar macht.
• Pro Entwickler und Monat: Typisch für kontinuierliche Prüfungen im Pull Request.

Viele Anbieter bieten zudem kostenlose Testphasen und individuelle Enterprise-Modelle an. Vergleichen Sie die Preise immer auf Basis Ihrer Teamgröße und Release-Frequenz.

Im Vergleich dazu wird ein manueller Pentest üblicherweise nach Testtagen abgerechnet. Der eigentliche Kostenunterschied entsteht jedoch über die Zeit: Ein manueller Test deckt einen Stichtag ab, ein automatisierter Ansatz jeden Release.

Automatisierter Pentest und Compliance: ISO 27001 und SOC 2

Für viele Unternehmen ist ein Pentest nicht nur eine Sicherheitsfrage, sondern ein Compliance-Nachweis.

ISO 27001: Die Norm fordert in Anhang A, Control 8.29 („Security testing in development and acceptance“), Sicherheitstests im Entwicklungsprozess. Der Begriff „Penetrationstest“ selbst taucht in ISO 27001 nicht auf. Der Leitfaden ISO 27002 nennt Code-Reviews, Schwachstellenscans und Penetrationstests jedoch ausdrücklich als Maßnahmen, die bei der eigenen Softwareentwicklung zu berücksichtigen sind.

SOC 2: Auditoren erwarten Nachweise, dass Schwachstellen systematisch identifiziert und behoben werden. Regelmäßige Tests mit dokumentierten Ergebnissen erleichtern diese Nachweisführung erheblich.

Achten Sie darauf, dass das Tool Berichte erstellt, die sich als Nachweis in SOC-2- und ISO-27001-Audits einsetzen lassen. Der Vorteil kontinuierlicher Tests: Statt eines einzelnen Berichts pro Jahr liegt eine laufende Dokumentation vor, die zeigt, wann eine Schwachstelle gefunden und wann sie behoben wurde.

Relevanz für regulierte Branchen in der EU: NIS2 und DORA

Zwei EU-Regelwerke rücken Sicherheitstests zusätzlich in den Fokus:

• NIS2: Artikel 21 Absatz 2 Buchstabe e der Richtlinie verlangt Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen und deren Offenlegung.
• DORA: Die Verordnung verpflichtet Finanzunternehmen zu Programmen für Tests der digitalen operationalen Resilienz. Artikel 25 nennt dabei unter anderem Schwachstellenbewertungen, Quellcodeprüfungen und Penetrationstests als mögliche Testarten. Systeme, die kritische oder wichtige Funktionen unterstützen, sind mindestens jährlich zu testen.

Automatisierte Pentests ersetzen nicht die vollständige Umsetzung dieser Vorgaben. Sie liefern aber einen wiederholbaren Baustein für den Nachweis, dass Schwachstellen im Entwicklungsprozess systematisch behandelt werden. Welche konkreten Pflichten für Ihr Unternehmen gelten, sollten Sie mit Ihrer Rechts- oder Compliance-Abteilung klären.

Grenzen: Wann ein manueller Pentest weiterhin nötig ist

Automatisierung ist kein Ersatz für jede Form menschlicher Expertise. Ein manueller Pentest bleibt sinnvoll, wenn:

• komplexe Geschäftslogik geprüft werden soll, etwa mehrstufige Zahlungsprozesse oder Berechtigungsmodelle mit vielen Sonderfällen;
• Social Engineering oder physische Sicherheit Teil des Scopes sind;
• regulatorische Vorgaben ausdrücklich einen Test durch externe Spezialisten verlangen, wie bei bestimmten bedrohungsorientierten Tests unter DORA;
• Infrastruktur und Organisation ganzheitlich angegriffen werden sollen. Hier sind Red-Teaming-Einsätze die richtige Wahl.

Der sinnvollste Ansatz ist für die meisten Teams eine Kombination: automatisierte Prüfung jeder Codeänderung als Grundlage, ergänzt durch gezielte manuelle Tests für besonders kritische Bereiche.

Checkliste: So wählen Sie eine Lösung für automatisiertes Pentesting

Achten Sie bei der Auswahl auf folgende Punkte:

• Nachweis statt Vermutung: Belegt das Tool die Ausnutzbarkeit eines Fundes?
• Code-Kontext: Analysiert es nur geänderte Zeilen oder die gesamte Codebasis?
• Integration: Lässt es sich in Ihre Pull-Request- und CI/CD-Prozesse einbinden?
• False-Positive-Rate: Wie viele Funde erweisen sich in einer Testphase als irrelevant?
• Compliance-Berichte: Eignen sich die Berichte als Nachweis für ISO 27001 oder SOC 2?
• Datenschutz: Wo wird Ihr Quellcode verarbeitet, und gibt es eine On-Premises-Option?
• Testphase: Können Sie das Tool vor dem Kauf an einem echten Repository prüfen?
• Preismodell: Passt die Abrechnung zur Größe Ihres Teams und Ihrer Codebasis?

FAQ

Ersetzt ein KI-Pentest einen manuellen Penetrationstest?

Nicht vollständig. Ein automatisierter Pentest deckt jede Codeänderung ab und findet viele Schwachstellen schneller als ein manueller Test. Für komplexe Geschäftslogik, Social Engineering oder regulatorisch vorgeschriebene externe Tests bleibt der manuelle Pentest eine sinnvolle Ergänzung.

Ist ein automatisierter Pentest für ISO 27001 ausreichend?

ISO 27001 schreibt keinen bestimmten Testtyp vor, verlangt aber Sicherheitstests im Entwicklungsprozess. Automatisierte Pentests mit dokumentierten Ergebnissen können dafür einen wesentlichen Nachweis liefern. Ob sie allein genügen, hängt vom Scope Ihres ISMS und der Bewertung Ihres Auditors ab.

Wie lange dauert ein automatisierter Pentest?

Das hängt vor allem vom Codeumfang ab. Ein automatisierter Test benötigt weder Terminplanung noch Testtage vor Ort und liefert Ergebnisse deshalb in der Regel deutlich schneller als ein manuelles Projekt. Bei der Prüfung im Pull Request erfolgt die Analyse direkt im Entwicklungsprozess, sodass Funde behoben werden können, bevor der Code ausgeliefert wird.

Werden beim White-Box-Pentest Quellcode-Daten gespeichert?

Das hängt vom Anbieter und vom gewählten Bereitstellungsmodell ab. Prüfen Sie vor dem Einsatz die Datenschutzbestimmungen und fragen Sie nach einer On-Premises-Variante, wenn Ihr Quellcode das Unternehmen nicht verlassen darf.

Hinweis zum Beispiel: Im Kundenprojekt steht an dieser Stelle der Call-to-Action des Anbieters, etwa zum Start eines White-Box-Pentests. Erstellt mit KI-Unterstützung und mehrstufig geprüft auf Struktur, Terminologie und Fakten.