Du hast eine App vibegecodet, sie funktioniert, sieht gut aus — und jetzt? Releasen? Irgendwie hast du ein mulmiges Gefühl. Nicht weil der Code schlecht ist, sondern weil du ehrlich gesagt keine Ahnung hast, ob da Sicherheitslücken drin sind. Und genau diese Unsicherheit hält viele davon ab, ihre Projekte live zu schalten.
Ich hab letzte Woche für einen Freund genau das getestet. Seine SaaS-App — vibegecodet, Next.js, Cloudflare Workers, in der Alpha-Phase. Ich hab einen KI-Pentesting-Agenten drauf losgelassen. 90 Minuten später hatte ich einen 55-seitigen Security Report mit 14 Schwachstellen, davon 10 als "High" eingestuft. Kosten: rund 30 Euro an API-Tokens.
Was ist AI Pentesting überhaupt?
Klassisches Penetration Testing — also das gezielte Suchen nach Sicherheitslücken in einer Anwendung — ist teuer. Ein manueller Pentest kostet fünfstellig, dauert Wochen, und liefert am Ende einen PDF-Report, der zum Zeitpunkt der Übergabe schon halb veraltet ist. Für Startups und Solo-Entwickler ist das schlicht nicht drin.
AI Pentesting dreht das um. Statt einem menschlichen Tester arbeitet ein Multi-Agenten-System, das Quellcode analysiert und die Live-Anwendung systematisch angreift — genau wie ein erfahrener Pentester, nur schneller und deutlich günstiger.
Das Tool, das ich genutzt habe, heißt Shannon und kommt von Keygraph. Es ist Open Source und kombiniert mehrere spezialisierte AI-Agenten, die parallel arbeiten: Einer kartiert die Architektur, einer sucht nach Injection-Schwachstellen, einer prüft die Authentifizierung, einer testet auf Server-Side Request Forgery. Orchestriert wird das Ganze über Temporal, ein Workflow-Framework, das bei Abstürzen automatisch weitermacht.
Was der Agent in 90 Minuten gefunden hat
Von den 14 Schwachstellen waren drei Findings besonders eindrucksvoll — nicht weil sie offensichtlich waren, sondern weil sie in der Anwendungslogik steckten. Das sind genau die Lücken, die ein einfacher Scanner nie findet.
Server dazu bringen, beliebige URLs aufzurufen (SSRF)
Die App hatte einen Webhook-Endpoint, über den Nutzer eine URL für Benachrichtigungen hinterlegen können. Der "Test"-Modus macht einen serverseitigen Request an die angegebene URL — ohne jegliche Validierung. Shannon hat einfach eine externe URL eingesetzt und bewiesen, dass der Server sie tatsächlich aufruft. Noch kritischer: Man konnte auch interne Cloud-Adressen eintragen, über die theoretisch AWS-Zugangsdaten abrufbar wären.
Das Fiese: Shannon hat insgesamt fünf verschiedene Wege gefunden, den Server dazu zu bringen, beliebige URLs aufzurufen. Über Webhooks, über den Crawler, über einen Third-Party-Service der als Proxy diente. Mein Freund hatte keine Ahnung, wie viele Angriffsvektoren da offen standen.
Daten anderer Kunden manipulieren (Cross-Tenant)
Die App nutzte eine globale Datenbanktabelle ohne Workspace-Trennung. Wenn Workspace A und Workspace B denselben Competitor tracken, teilen sie sich denselben Datenbankeintrag. Shannon hat herausgefunden, dass ein Nutzer die Datenquellen auf dem globalen Eintrag überschreiben kann — und damit die Daten aller anderen Workspaces vergiftet, die denselben Competitor tracken.
Das ist kein theoretisches Risiko. Shannon hat es live durchgeführt und die Datenänderung verifiziert. Ein fundamentales Architekturproblem, das beim Entwickeln leicht übersehen wird — besonders wenn man schnell iteriert.
Admin-Bereich ohne Admin-Check
Ein /api/admin/-Endpoint war für jeden eingeloggten User zugänglich. Im Code stand sogar der Kommentar // Auth check (admin only in future). Shannon hat als normaler User Crawl-Error-Logs aller Tenants gelesen und sogar eigene Crawl-Jobs eingespeist. In Kombination mit der SSRF-Lücke hätte jeder User darüber interne Server scannen können.
Was mich hier besonders beeindruckt hat: Shannon hat diese Verkettung von Schwachstellen selbstständig erkannt und im Report als kombinierte Angriffskette dokumentiert. Das ist die Art von logischem Vorgehen, die man normalerweise nur von erfahrenen Pentestern erwartet.
Was der Agent NICHT gefunden hat — und warum das genauso wichtig ist
Shannon hat XSS und SQL Injection korrekt als "nicht vorhanden" eingestuft und erklärt warum. React escaped automatisch, der einzige SQL-Kandidat wird durch parseInt() neutralisiert. Auch Account Enumeration war bewusst mitigiert — Shannon hat das erkannt und als korrekt implementiert gemeldet.
Ein gutes Security-Audit zeichnet sich nicht nur durch die Findings aus, sondern auch durch die Confidence in den Bereichen, die sauber sind. Dass der Agent mir sagen kann "hier bist du sicher, und hier ist warum" — das gibt fast genauso viel wie die Schwachstellen-Liste.
Was das für Vibe Coder bedeutet
Hier ist der Punkt, der mich am meisten beschäftigt hat: Mein Freund ist ein guter Entwickler. Die App ist sauber gebaut, React 19, moderne Architektur. Trotzdem steckten 14 Schwachstellen drin — nicht weil er schlampig war, sondern weil Security-Blindspots beim schnellen Iterieren einfach passieren. // admin only in future schreibt man mit den besten Absichten, und dann vergisst man es.
Und genau das ist der Punkt für alle, die gerade ihre vibegecodeten Projekte vor sich haben und sich fragen, ob sie die wirklich releasen können:
Ja, releast sie. Aber lasst vorher einen Pentesting-Agenten drüberlaufen.
Das ist kein Audit, das Wochen dauert und fünfstellig kostet. Das sind 90 Minuten und 30 Euro. Ihr bekommt eine priorisierte Liste mit Schwachstellen, fixt die kritischen, und geht live. Danach nach jedem größeren Feature-Push nochmal laufen lassen. Fertig.
Das ersetzt keinen Security-Experten für komplexe Enterprise-Systeme. Aber es demokratisiert den Zugang zu einer Analyse-Qualität, die sich die meisten in der Frühphase schlicht nicht leisten können.
Wie du es selbst machst
Shannon ist Open Source: github.com/KeygraphHQ/shannon
Was du brauchst:
- Docker
- Einen Anthropic API-Key
- Den Quellcode deiner App
- Idealerweise eine Staging-URL mit Test-Login
Der Agent braucht Zugriff auf beides — Code und Live-App. Bei OAuth-Login (Google, GitHub etc.) loggt man sich manuell ein und übergibt den Session-Cookie. Klingt frickelig, funktioniert aber problemlos.
Ein Hinweis zur Ehrlichkeit: Der Prozess ist noch nicht 100% fire-and-forget. Bei meinem Test ist der Recon-Agent dreimal fehlgeschlagen, bevor er durchlief. Man muss den Prozess beobachten und gelegentlich eingreifen. Aber die Analyse-Tiefe, wenn er läuft, ist beeindruckend.
FAQ: AI Pentesting
Findet ein AI-Pentesting-Agent wirklich echte Schwachstellen?
Ja — und zwar nicht nur offensichtliche Fehlkonfigurationen, sondern Lücken in der Anwendungslogik. In meinem Test hat Shannon Schwachstellen gefunden, die ein einfacher Scanner nie entdecken würde: fehlende Tenant-Isolation, SSRF über Third-Party-Services, verkettete Angriffspfade.
Was kostet AI Pentesting?
Die Token-Kosten lagen bei meinem Test bei rund 30 Euro für einen vollständigen Durchlauf mit 14 Findings und 55-seitigem Report. Ein vergleichbarer manueller Pentest kostet 10.000–30.000 Euro.
Ersetzt das einen menschlichen Pentester?
Für Startups in der Frühphase und vibegecodete Projekte: Es liefert 80–90% des Werts zu einem Bruchteil der Kosten. Für Enterprise-Systeme in regulierten Branchen: Nein, da brauchst du zusätzlich menschliche Expertise.
Kann ich das als Nicht-Entwickler nutzen?
Du brauchst grundlegende Docker-Kenntnisse und musst mit der Kommandozeile umgehen können. Wenn du bereits mit Claude Code arbeitest, ist die Einstiegshürde niedrig.
Wie oft sollte man den Test laufen lassen?
Vor dem ersten Release und danach nach jedem größeren Feature-Push. Bei 30 Euro pro Durchlauf ist das keine Budget-Frage mehr.
