Du hast das Feature schnell ausgeliefert. Die Demo läuft. Der KI-Assistent hat den Boilerplate erledigt, die Routes ausgefüllt, die Formulare generiert und sogar den Auth-Flow gut genug erraten, um einen schnellen Smoke-Test zu bestehen.

Wenn die erste Begeisterung verflogen ist, kommt die eigentliche Frage. Hat er etwas Sicheres gebaut – oder nur etwas, das zu funktionieren scheint?

Genau an diesem Punkt stehen gerade die meisten kleinen Teams. Sie betreiben kein riesiges AppSec-Programm. Sie wollen schnell vorankommen, Feedback-Loops schließen und nicht versehentlich ein Datenleck ausliefern. Ein solides Vibe Coding Security Audit muss nicht nach Enterprise-Theater aussehen. Es muss wiederholbar sein, auf die konkreten Risiken deiner App zugeschnitten und so wenig Zeit kosten, dass du es auch dauerhaft machst.

Inhaltsverzeichnis

Von „Hauptsache live“ zu „live und sicher“

Viele unsichere KI-gestützte Projekte wirken während der Entwicklung gar nicht leichtsinnig. Sie wirken produktiv. Eine Person promptet einen Login-Flow, eine andere lässt sich eine Billing-Seite bauen, jemand Drittes lässt den Assistenten API-Endpoints aufsetzen, und am Ende des Tages fühlt sich die App echt genug für den Launch an.

Eine fröhliche Frau programmiert während eines Launches im Homeoffice, umgeben von leuchtendem digitalem Code.

Diese Geschwindigkeit ist der Vorteil. Der Nachteil: KI kann unsicheren Code genauso schnell erzeugen wie nützlichen. Laut Veracodes Studie von 2025 enthält fast 45 % des KI-generierten Codes Sicherheitslücken (Accorian fasst Veracodes Studie von 2025 zusammen). Für ein kleines Team ist das wichtig, weil es meist keine eigene Security-Gruppe gibt, die Fehler abfängt, bevor sie bei der Kundschaft ankommen.

Das typische Scheitern besteht nicht darin, dass Teams Sicherheit absichtlich ignorieren. Sondern darin, dass sie Sicherheit wie eine letzte Hürde behandeln. Sie wollen „das später aufräumen“, und später heißt dann: nach dem Launch, wenn es schon Kundendaten gibt und die Codebase längst ausgewuchert ist. Dann werden Fixes teuer.

Praktische Regel: Wenn dein KI-Assistent in Minuten eine neue Angriffsfläche aufmachen kann, muss dein Audit-Prozess ungefähr im selben Tempo laufen.

Besser ist es, das Auditing zum Teil des Auslieferns selbst zu machen. Denk daran so, wie starke Teams über Deployment-Hygiene denken. Wenn du dich ohnehin für automatisierte Release-Strategien für Startups interessierst, gilt hier dieselbe Denkweise. Du willst ein leichtgewichtiges System, das jedes Mal läuft, keinen heroischen Aufräum-Sprint einmal im Quartal.

Für kleine Teams ist der richtige Maßstab nicht „perfekte Sicherheit“, sondern das hier:

  • Wissen, was am meisten zählt: Nutzerdaten, Auth-Flows, Zahlungen, Admin-Aktionen und Secrets.
  • Die offensichtlichen Checks automatisieren: Dependencies, hartcodierte Zugangsdaten und gängige unsichere Muster.
  • Die laufende App abklopfen: Denn Logikfehler tauchen selten allein in Source-Scans auf.
  • Den Zyklus wiederholen: Bei jeder relevanten Änderung, nicht nur vor einem Launch.

So kommst du von „Hauptsache live“ zu live und sicher, ohne den Schwung zu verlieren.

Die Grundlage: leichtgewichtiges Threat Modeling

Viele Teams hören „Threat Modeling“ und denken sofort an Diagramme, Workshops und einen Stapel Dokumentation, den nie wieder jemand liest. Für ein kleines Produktteam ist das das falsche Modell.

Ein brauchbares Threat Model für eine per Vibe Coding gebaute App passt auf einen Bildschirm oder ein Blatt Papier. Du sammelst keine Compliance-Nachweise. Du findest heraus, wo ein Angriff einen Vorteil bekommt.

Ein einfaches Diagramm in drei Schritten, das den Ablauf eines leichtgewichtigen Threat Modelings für Sicherheitsbewertungen zeigt.

Es gibt noch einen Grund, das vorab zu tun. Eine Analyse von Unit 42 aus dem State of Cloud Security Report 2025 hält fest, dass AI Agents in 99 % der Organisationen das Deployment unsicheren Codes beschleunigen, Teams aber weiterhin belastbare Benchmarks zu Exploit-Raten fehlen – dein eigenes Risikomodell zählt also mehr als allgemeine Annahmen (Databricks darüber, wie man den Security-Vibe-Check besteht). In der Praxis heißt das: Du kannst dein Urteil nicht an einen Scanner oder einen Markttrend auslagern. Du brauchst eine einfache Karte deiner App.

Fang mit einer Skizze auf der Serviette an

Zeichne die App so, wie sie tatsächlich funktioniert, nicht so, wie sie auf der Architekturfolie aussieht.

Bei einem typischen kleinen SaaS-Produkt könnte diese Skizze Folgendes enthalten:

  1. Client-Oberfläche
    Web-App, Mobile-Wrapper, Admin-Dashboard, Browser-Storage, hochgeladene Dateien.

  2. Backend-Services
    API-Server, Background-Jobs, Auth-Service, Webhook-Handler.

  3. Datenspeicher und externe Systeme
    Primäre Datenbank, Object Storage, Analytics-Tools, Zahlungsanbieter, E-Mail-Plattform, Drittanbieter-APIs.

Dann markierst du drei Dinge in der Skizze:

  • Wo Nutzereingaben hereinkommen
  • Wo über Berechtigungen entschieden wird
  • Wo sensible Daten liegen

Allein das gibt dir schon einen schärferen Audit-Scope, als ihn die meisten Teams haben.

Wenn du einen Planungsablauf willst, der das an die Codebase bindet, statt es als abstrakte Notizen herumschwirren zu lassen, ist ein Codebase-bewusster KI-Planungs-Workflow ein praktisches Modell. Entscheidend ist, dass die Sicherheitsfragen an der tatsächlichen Implementierung hängen, nicht nur am Feature-Request.

STRIDE nutzen, ohne Papierkram daraus zu machen

STRIDE funktioniert gut, weil es einen breiten Durchgang erzwingt, ohne akademisch zu werden. Wende es auf jedes wichtige Asset und jeden wichtigen Workflow an.

STRIDE-Bereich Stell diese Frage Beispiel aus einer kleinen App
Spoofing Kann sich jemand als anderes Konto oder als anderer Service ausgeben? Gefälschte Session, schwaches JWT-Handling, falscher Webhook-Absender
Tampering Lassen sich Daten ändern, die nicht änderbar sein sollten? Bestellsummen manipulieren oder den Datensatz eines anderen Kontos ändern
Repudiation Kann jemand handeln, ohne brauchbare Logs zu hinterlassen? Admin-Aktion ohne Audit-Trail
Information Disclosure Können Daten beim falschen Konto landen? Öffentliche Datei-URL, offenliegende Konfiguration, kaputte Mandantentrennung
Denial of Service Kann jemand einen öffentlichen Endpoint überlasten? Kein Rate Limiting bei Suche, Login oder Datei-Upload
Elevation of Privilege Kann ein Konto mit wenigen Rechten zum Admin werden? Rollenprüfungen nur im Client

Für diese Übung braucht es kein langes Meeting. Geh einen kritischen Pfad nach dem anderen durch.

Nimm zum Beispiel „jemand ändert die Kontoeinstellungen“. Frag:

  • Wie weist die Person ihre Identität nach?
  • Wo wird die Autorisierung durchgesetzt?
  • Lässt sich der Request wiederholen oder verändern?
  • Kann jemand eine ID austauschen und so den Datensatz eines anderen Kontos treffen?
  • Verrät irgendeine Response Secrets oder interne Details?

Wenn deine App zulässt, dass jemand eine ID in einem Request ändert, geh davon aus, dass es auch jemand versucht. Bau dein Audit um diese Annahme herum.

Aus Bedrohungen werden Audit-Ziele

Ein Threat Model ist nur dann nützlich, wenn es verändert, was du testest. Herauskommen sollte eine kurze Liste von Audit-Zielen, kein Dokumentenarchiv.

Ein gutes, leichtgewichtiges Ergebnis sieht so aus:

  • Admin-Routes brauchen serverseitige Autorisierungsprüfungen
  • Der Datei-Upload braucht Validierung und ein Review der Speicherung
  • Öffentliche Formulare brauchen Eingabevalidierung und Tests zur Laufzeit
  • Beim Passwort-Reset muss das Token-Handling geprüft werden
  • Webhooks brauchen eine Absenderverifizierung
  • Billing-Logik braucht Missbrauchstests, nicht nur Unit-Tests

Diese Liste wird zum Rückgrat deines Vibe Coding Security Audits. Sie sagt deinen Scannern, worauf sie sich konzentrieren sollen, und den Menschen, wo der Automatisierung wahrscheinlich Feinheiten entgehen.

Kleine Teams lassen das oft weg, weil sie glauben, es bremse sie aus. Meistens spart es Zeit. Ohne Threat Modeling verlieren Teams Zeit mit lauten, aber unwichtigen Findings, während eine kaputte Zugriffskontrolle offen vor ihnen liegt.

Automatisierter Schutz: deine erste Verteidigungslinie

Automatisierung sollte die üblichen Fehler finden, bevor Menschen ihre Aufmerksamkeit darauf verwenden. Das ist die richtige Arbeitsteilung. Lass Tools das Offensichtliche finden. Lass Menschen das Gefährliche und Kontextabhängige untersuchen.

In KI-lastigen Codebases ist das umso wichtiger, weil immer wieder dieselben Fehlerklassen auftauchen. Security Audits von per Vibe Coding gebauten Apps finden immer wieder hartcodierte Secrets, fehlende Eingabevalidierung und kaputte Authentifizierung unter den häufigsten Einfallstoren (CodeGeeks-Checkliste zu Sicherheitsrisiken beim Vibe Coding). Genau dort zahlt sich leichtgewichtige Automatisierung aus.

Ein freundlicher Roboter hält einen leuchtenden Stab neben einer digitalen Schatztruhe, umgeben von kleinen Sicherheitsdrohnen.

Zuerst die Dependencies

KI-Assistenten sind gut darin, schnell Pakete einzubinden. Schlecht sind sie darin, das Dependency-Risiko auf lange Sicht zu verantworten.

Fang mit Software Composition Analysis an. Bei JavaScript-Projekten führst du npm audit aus, bei Python pip-audit. Wenn du auf GitHub bist, aktiviere Dependabot. Für breiteres Scanning ist Snyk ein üblicher nächster Schritt.

Was das gut findet:

  • Bekannte verwundbare Pakete
  • Ungepflegte Dependencies, die auf alten Versionen hängen bleiben
  • Risiken über transitive Dependencies
  • Offensichtliche Supply-Chain-Fehler

Was es nicht gut findet:

  • Ob das Paket zu deiner Vertrauensgrenze passt
  • Ob ein Paket ein gefährliches Verhalten eingeführt hat, das deine App jetzt nach außen trägt
  • Ob zwei Agents überlappende Libraries hinzugefügt haben, die sich auf subtile Weise in die Quere kommen

Eine einfache Arbeitsregel hilft: Jede neue Dependency sollte eine klare Frage beantworten.

  • Warum ist dieses Paket hier?
  • Kann die Standardbibliothek das stattdessen?
  • Wer kümmert sich um die Updates?

Wenn die Antwort „die KI hat es hinzugefügt“ lautet, reicht das nicht.

Wenn du Scanner vergleichst und Tool-Wildwuchs vermeiden willst, liefert dieser Überblick zum Vergleich von Application-Security-Tools für SOCs nützlichen Kontext. Nicht, weil du einen riesigen SOC-Stack brauchst, sondern weil er dir hilft, leichtgewichtiges Developer-Tooling von Plattformen für viel größere Betriebe zu unterscheiden.

Dann das Secrets-Scanning

Hartcodierte Secrets sind nach wie vor einer der schnellsten Wege, aus einer Demo einen Sicherheitsvorfall zu machen.

Der Fix beginnt beim Prozess, nicht beim Tooling. Leg Zugangsdaten in .env-Dateien oder in einen richtigen Secret Manager. Halte Produktions-Secrets aus lokalen Defaults heraus. Lass KI-generierten Beispielcode nie zur echten Implementierung des Key-Handlings werden.

Dann automatisierst du den Check. Gitleaks und TruffleHog sind praktische Optionen, um Repositories und die Commit-Historie nach offengelegten Zugangsdaten zu durchsuchen.

Ein einfacher Secrets-Workflow sieht so aus:

  • Vor dem Commit: Lokal einen Secrets-Scan laufen lassen.
  • Beim Pull Request: Den Scan in der CI noch einmal laufen lassen.
  • Wenn etwas anschlägt: Das Secret widerrufen und rotieren, nicht nur die Zeile löschen.
  • Nach dem Aufräumen: Prüfen, ob das Secret schon gepusht, in Logs kopiert oder in einer Preview-Umgebung verwendet wurde.

Arbeitsgewohnheit: Behandle jedes geleakte Secret als kompromittiert, sobald es in einem Repo landet. Aufräumen ohne Rotation ist keine Behebung.

Viele kleine Teams machen an dieser Stelle denselben Fehler. Sie entfernen die sichtbaren Zugangsdaten und machen weiter. Das eigentliche Risiko bleibt, denn das Secret kann längst in der Commit-Historie, in Build-Artefakten oder in Logs stecken.

SAST für den Code, den die KI gerade geschrieben hat

Static Application Security Testing gibt dir schnelles Feedback zu unsicheren Mustern im Quellcode. Für kleine Teams ist Semgrep meist der beste Einstieg, weil es lesbar, schnell und leicht anzupassen ist. Auch CodeQL ist stark, vor allem wenn du ohnehin auf GitHub zu Hause bist.

Sinnvolle Checks für KI-gestützte Apps sind unter anderem:

  • SQL-Queries, die mit Nutzereingaben zusammengebaut werden
  • Unsicher gerendertes HTML
  • Fehlende Validierung von Request-Parametern
  • Schwach eingesetzte Auth-Middleware
  • Umgang mit Dateipfaden
  • Gefährliche Deserialisierung oder Pfade zur Befehlsausführung

Eine einfache Semgrep-Routine funktioniert gut:

  1. Lass das Standard-Ruleset gegen das Repo laufen.
  2. Ergänze Framework-spezifische Regeln für deinen Stack.
  3. Leg eine kleine eigene Regeldatei für die riskanten Muster deiner App an.
  4. Lass den Build nur bei den Findings fehlschlagen, um die du dich auch wirklich kümmern willst.

Der letzte Punkt ist wichtig. Einen lauten Scanner ignoriert man irgendwann. Justier ihn, bis du dem Signal vertrauen kannst.

Wenn du ein praktisches Modell suchst, um KI-geschriebenen Code mit diesen Checks im Kopf zu reviewen, passt dieser Leitfaden zu einem KI-Security-Audit für Code gut zur Arbeitsweise kleiner Teams. Nützlich ist daran nicht, dass es noch eine Checkliste gibt, sondern dass er das Review gegen die tatsächlich generierte Implementierung erzwingt.

Was Automatisierung gut findet und was sie übersieht

Automatisierung ist stark im Erkennen von Mustern. Schwach ist sie beim Verstehen von Absichten.

Hier ein einfacher Vergleich:

Audit-Bereich Das kann Automatisierung gut Hier braucht es weiterhin Menschen
Dependencies Bekannte CVEs, veraltete Pakete, Alerts Ob das Paket überhaupt da sein sollte
Secrets Offengelegte Tokens, kopierte Zugangsdaten Rotation, Schadensradius, Aufräumen danach
SAST Gängige Code Smells und unsichere Konstrukte Business-Logik, Auth-Design, Missbrauchsfälle

Das ist das richtige Denkmodell für ein Vibe Coding Security Audit. Verlang nicht von Scannern, dass sie beweisen, dass deine App sicher ist. Lass sie die billigen Fehler wegräumen, damit deine Zeit fürs manuelle Review in die Probleme fließt, die Systeme wirklich kaputt machen.

Interaktiv prüfen mit dynamischen und manuellen Tests

Statische Scans sagen dir, was der Code zu tun scheint. Dynamische Tests sagen dir, was die App tut, wenn Requests auf ein laufendes System treffen. Der Unterschied ist wichtig, denn einige der schlimmsten Schwachstellen in KI-generierten Projekten stecken im Raum zwischen Routes, Rollen und Laufzeitverhalten.

Das gilt besonders für den Umgang mit Eingaben. Laut Pentests von NetSPI verzichten 70 % der per Vibe Coding gebauten Apps auf Input Sanitization, was in 45 % der Fälle zu SQL Injection führt (NetSPI über Vibe Coding als Pentesting-Traum). Das ist kein Grund zur Panik. Es ist ein Grund, die laufende App zu testen, nicht nur das Repository.

Eine Hand leuchtet mit einer Taschenlampe auf eine digitale Projektion, die eine Computerarchitektur und die Oberfläche eines Systemkerns zeigt.

DAST gegen Staging laufen lassen

Für die meisten kleinen Teams ist OWASP ZAP der richtige Einstieg. Es ist kostenlos, leistungsfähig und gut genug, um viele Fehler zur Laufzeit aufzudecken.

Nutze eine Staging-Umgebung, die der Produktion bei Routing, Auth und Middleware ähnelt. Dann:

  1. Crawle die App, damit ZAP Routes und Eingaben entdeckt.
  2. Lass den aktiven Scanner laufen, gegen öffentliche und authentifizierte Pfade.
  3. Sichte die Findings manuell, statt sie direkt ins Backlog zu kippen.
  4. Teste nach den Fixes erneut, um zu bestätigen, dass sich das Verhalten geändert hat.

ZAP ist gut darin, Dinge wie reflektierte Eingaben, fehlende Header und offensichtliche Schwächen zur Laufzeit sichtbar zu machen. Deine Geschäftsregeln versteht es nicht.

Deshalb brauchst du weiterhin manuelle Checks.

Drei manuelle Checks, die sich jedes Mal lohnen

Die wertvollsten manuellen Tests sind so einfach, dass sie alle im Dev-Team lernen können.

IDOR-Checks

Nimm eine beliebige URL oder einen API-Request, der einen Datensatz über eine ID referenziert. Ändere die ID. Dann schau, was passiert.

Beispiele:

  • /api/invoices/123 wird zu /api/invoices/124
  • Eine Projekt-ID in einem JSON-Body wird gegen einen anderen bekannten Wert getauscht
  • Ein mandantengebundenes Objekt wird mit einer anderen Konto-ID abgerufen

Du suchst nach einem von drei schlechten Ergebnissen:

  • Die App liefert die Daten eines anderen Kontos aus
  • Die App lässt dich die Daten eines anderen Kontos ändern
  • Die App leakt Metadaten, die bestätigen, dass das Objekt existiert

Wenn deine Autorisierung nur prüft, „ist diese Person eingeloggt“, fällt bei diesem Test oft sofort etwas um.

Input-Fuzzing

Für echten Nutzen brauchst du keine komplette Fuzzing-Kampagne. Fang damit an, Felder zu bearbeiten, die Freitext, Filter, Suchanfragen, Sortierparameter und Dateinamen annehmen.

Probier fehlerhafte Eingaben, sehr lange Eingaben, kodierte Eingaben und Werte, die nicht zum erwarteten Typ passen. Achte auf:

  • Serverfehler
  • Nicht escapte Ausgaben
  • Unerwartet verändertes Query-Verhalten
  • Logs oder Responses, die interne Details preisgeben

Selbst ein leichter Durchgang findet Probleme, die statische Tools übersehen, weil Laufzeitpfade, die Reihenfolge der Middleware und das Template-Verhalten oft mehr zählen als der Quellcode-Ausschnitt allein.

Authentifizierungs- und Session-Checks

Dass der Login funktioniert, heißt noch lange nicht, dass die Auth solide ist.

Prüfe:

  • Erreicht jemand ohne Login Seiten, die tabu sein sollten?
  • Entzieht der Logout tatsächlich den Zugriff?
  • Kann eine Rolle die Funktion einer anderen Rolle direkt aufrufen?
  • Verhalten sich Links zum Passwort-Reset und zu Einladungen sicher?
  • Sind privilegierte Aktionen auf dem Server geschützt, nicht nur in der UI versteckt?

Erstaunlich viele KI-gestützte Apps verstecken Admin-Buttons korrekt und lassen die Backend-Aktion trotzdem aufrufbar.

Wenn der Browser einen Button entfernen kann, kann er auch den Request fälschen. Prüf immer, dass der Server die Entscheidung trifft.

Für Teams, die vor den Laufzeittests einen disziplinierteren Review-Schritt wollen, ist dieser Leitfaden zum Code Review beim Vibe Coding eine gute Ergänzung. Entscheidend ist, Code Review mit Live-Tests zu kombinieren, nicht das eine durch das andere zu ersetzen.

Was du festhältst, wenn du etwas findest

Halte das Reporting schlank, aber brauchbar. Jedes Finding sollte vier Fragen beantworten:

  • Welcher Endpoint oder Flow betroffen ist
  • Wie es sich reproduzieren lässt
  • Welche Auswirkung es hat
  • Welche Art von Fix wahrscheinlich nötig ist

Während eines Audits funktioniert eine kurze Tabelle gut:

Finding Reproduktion Auswirkung Wahrscheinlicher Fix
IDOR in der Rechnungsansicht Rechnungs-ID im Request austauschen Datenzugriff über Kontogrenzen hinweg Autorisierung auf Ressourcenebene
Sucheingabe bringt die API zum Absturz Fehlerhaften Query-String senden Instabilität zur Laufzeit, möglicher Injection-Pfad Validierung und sicheres Parsen
Admin-Aktion mit normaler Rolle aufrufbar Privilegierten Request mit einem Konto mit wenigen Rechten wiederholen Rechteausweitung Rollenprüfung auf dem Server

So viel Detail reicht, damit ein kleines Team schnell handeln kann, ohne das Audit in eine Reporting-Übung zu verwandeln.

Das Security-Schwungrad in deinem Workflow

Ein einmaliges Vibe Coding Security Audit hilft. Was dich aber auch sechs Wochen später noch vor Ärger bewahrt, ist ein wiederholbarer Workflow – wenn sich die Codebase verändert hat, neue Prompts gelandet sind und niemand mehr weiß, welche Routes manuell geprüft wurden.

Das nachhaltige Modell ist ein Schwungrad. Automatisierte Checks laufen bei jeder relevanten Änderung. Staging-Tests prüfen das Laufzeitverhalten. Menschen sichten die Findings und schärfen die Regeln nach. Dann startet die nächste Änderung von einer besseren Basis aus.

Ein Diagramm mit dem Titel „The Security Flywheel“, das einen dreistufigen Zyklus automatisierter Software-Sicherheitsprozesse zeigt.

Scans in Pull Requests einbauen

Ein Scan, der nur läuft, wenn jemand daran denkt, ihn anzustoßen, hält nicht lange durch.

Pack deinen Dependency-Scan, den Secrets-Scan und die SAST-Checks in GitHub Actions, damit jeder Pull Request dieselbe Grundbehandlung bekommt. Halte die erste Version einfach. Zuverlässigkeit ist wichtiger als Raffinesse.

Ein praktischer Einstiegs-Workflow umfasst meist:

  • Dependency-Audit: npm audit oder pip-audit
  • Secrets-Scan: Gitleaks oder TruffleHog
  • Statische Analyse: Semgrep oder CodeQL
  • Optionaler Laufzeit-Check: ZAP gegen ein Preview- oder Staging-Deployment

Ein schlanker Aufbau mit GitHub Actions könnte in der Praxis so aussehen:

  • Auslösen bei Pull Requests und bei Pushes auf main
  • Die Runtime der Sprache einrichten
  • Dependencies installieren
  • SCA laufen lassen
  • Secrets-Scanning laufen lassen
  • SAST laufen lassen
  • Artefakte oder Annotationen für Findings hochladen

Lass die Pipeline nicht schon am ersten Tag bei jeder Warnung fehlschlagen. Lass sie zuerst nur bei den Findings scheitern, die dein Team für essenziell hält, etwa offengelegte Secrets oder eindeutige Auth-Probleme. Zieh die Schrauben mit der Zeit an.

Eine PR-Checkliste, an die sich Menschen tatsächlich halten

Die meisten Security-Checklisten scheitern, weil sie zu lang und zu abstrakt sind. Eine gute passt in ein Pull-Request-Template und bezieht sich auf die Änderungen, die gerade im Review liegen.

Eine brauchbare Markdown-Checkliste:

  • Auth-Check Für jede neue privilegierte Aktion gibt es eine serverseitige Autorisierung
  • Umgang mit Eingaben Neue Nutzereingaben werden validiert und, wo nötig, kodiert oder bereinigt
  • Secrets-Hygiene Es wurden keine Zugangsdaten, Tokens oder Konfigurations-Secrets committet
  • Dependency-Review Neue Pakete wurden bewusst hinzugefügt und gescannt
  • Fehlerbehandlung Produktionspfade geben keine Debug-Details oder ausführlichen Traces preis
  • Missbrauchsfall Im Review wurde bedacht, wie sich dieses Feature missbrauchen lässt, nicht nur, wie es genutzt wird
  • Staging-Test Riskante Flows wurden in einer laufenden Umgebung durchgespielt

Die Liste funktioniert, weil sie kurz genug ist, um den Kontakt mit der Realität zu überleben. Außerdem erzwingt sie eine Gewohnheit, die kleine Teams oft auslassen: die Frage, wie sich ein Feature missbrauchen lässt.

Eine PR-Checkliste soll gedankenlose Merges bremsen, nicht das Engineering.

Triage nach Auswirkung und Behebbarkeit

Sobald Scans und manuelle Checks Findings liefern, pendeln Teams oft zwischen zwei schlechten Modi. Entweder sie ignorieren alles, oder sie versuchen, alles sofort zu beheben.

Nutze ein einfaches Triage-Raster:

Priorität Typisches Problem Maßnahme
Sofort beheben Auth-Bypass, offengelegtes Secret, Injection-Pfad, Leck zwischen Mandanten Merge blockieren oder sofort patchen
In diesem Sprint beheben Fehlendes Rate Limiting, schwache Validierung, zu gesprächige Fehlermeldungen Mit klarer Zuständigkeit einplanen
Tracken und justieren Statische Findings mit geringerer Konfidenz, redundante Header, eher stilistische Punkte Regeln verfeinern oder bewusst ins Backlog legen

Die besten Triage-Fragen sind direkt:

  • Kann das die Daten von jemand anderem offenlegen?
  • Kann das mehr Rechte gewähren als vorgesehen?
  • Ist das von einer öffentlichen Oberfläche aus erreichbar?
  • Ist der Fix klein genug, um ihn jetzt zu erledigen?

Wenn die Antwort auf die ersten beiden Fragen Ja lautet, lass dir vom Prozess keinen Aufschub einreden.

Das Schwungrad wird stärker, wenn du Findings zurück ins System speist. Findet ein manuelles Review ein wiederkehrendes Bug-Muster, schreib eine Semgrep-Regel dafür. Taucht ein Dependency-Problem immer wieder auf, verschärf die Paket-Policy. Häufen sich Auth-Fehler in einem Bereich, nimm einen Punkt für diesen Bereich in die PR-Checkliste auf.

So wird Sicherheit von einer wiederkehrenden Unterbrechung zu einem normalen Teil davon, wie das Team ausliefert.

Kontinuierliche Audits mit Tekks Security Loop

Das Schwierigste an moderner KI-gestützter Entwicklung ist meist nicht, noch einen Scanner laufen zu lassen. Sondern die Arbeit zu koordinieren, wenn mehrere Agents Code produzieren, überlappende Bereiche ändern und Specs jeweils leicht anders auslegen.

Genau hier verlieren viele Teams den Faden. Ein Agent aktualisiert die API. Ein anderer passt das Frontend an. Ein dritter schreibt die Middleware um, weil der Prompt nach einem Refactoring klang. Der Code kompiliert vielleicht noch, aber die ursprünglichen Sicherheitsannahmen können unbemerkt wegdriften.

Dieses Drift-Problem bekommt mehr Aufmerksamkeit, weil es kaum Leitlinien dazu gibt. Stand 2026 klafft eine deutliche Lücke bei Leitlinien zur Security-Orchestrierung für Multi-Agent-Workflows. Teams, die Tools wie Cursor und Claude Code nutzen, sind dadurch Risiken wie Spec Drift und unsicheren Übergaben zwischen Agents ausgesetzt (Checkmarx über Sicherheit beim Vibe Coding). Genau dieses Problem muss ein kontinuierliches Audit lösen.

Warum Multi-Agent-Entwicklung ein neues Sicherheitsproblem schafft

Schon wenn eine einzelne Person mit KI programmiert, entsteht Druck beim Review. Multi-Agent-Workflows packen noch ein Koordinationsproblem obendrauf.

Typische Fehlermuster sehen so aus:

  • Ein Agent legt eine Route an und nimmt an, dass es eine Auth-Middleware gibt.
  • Ein anderer Agent ändert die Auth-Schicht, aktualisiert aber nicht die Akzeptanzkriterien.
  • Ein dritter Agent fügt ein Paket hinzu, um ein eng umrissenes Problem zu lösen, ohne die Dependency-Lage insgesamt im Blick zu haben.
  • Ein früherer Security-Fix wird überschrieben, weil ein späterer Prompt auf Funktionalität optimiert.

Keiner dieser Fehler wirkt für sich genommen dramatisch. Zusammen erzeugen sie stille Regressionen.

Hier kann auch ein Blick von außen helfen. Teams, die ihre KI-Prozesse breiter prüfen, profitieren oft von Anbietern, die auf die Integrität des Workflows schauen, nicht nur auf den Code-Output. Die KI-Workflow-Audits von Mindlink Systems sind ein Beispiel für diese breitere Kategorie. Die Lehre ist einfach: Sobald mehrere Agents beteiligt sind, wird das Workflow-Design Teil der Sicherheit.

Was ein Loop findet, das Scanner allein nicht finden

Scanner sehen Artefakte. Ein Loop sieht, was sich geändert hat, und verfolgt es bis zu dem, was es berührt.

Diese Unterscheidung ist wichtig, weil viele der gefährlichen Bugs in KI-gestützten Projekten entstehen, bevor es überhaupt Code gibt. Sie beginnen bei mehrdeutigen Prompts, unvollständigen Akzeptanzkriterien, fehlenden Annahmen zur Autorisierung oder unverbundenen Arbeitssträngen.

Ein stärkeres Modell sieht so aus:

Phase Einmaliges Audit Kontinuierlicher Loop
Planung Vager Prompt, implizite Sicherheitsanforderungen Explizite Spec mit Sicherheits-Akzeptanzkriterien
Umsetzung Mehrere Agents bearbeiten überlappende Bereiche unabhängig voneinander Aufgaben werden gegen die tatsächliche Codebase abgegrenzt
Verifikation Findings kommen erst nach der Implementierung Jede Änderung wird neu gelesen, und jedes Finding wird auf einen echten Request zurückgeführt
Behebung Fixes passieren ad hoc und gehen später wieder kaputt Findings kommen als Proposals; mit Greenlight freigegeben, werden sie zu Specs auf deinem Board

Genau das macht Tekks Security Loop. Er wacht auf, wenn sich dein Code ändert, liest, was sich geändert hat, und prüft es mit dem Blick von jemandem, der kostenlosen Service oder die Daten eines anderen Mandanten haben will: Auth-Lücken, offenliegende Daten, Injection, Lecks zwischen Mandanten. Jedes Finding wird auf einen echten Request zurückgeführt, nicht auf einen Mustertreffer, und kommt als einzelnes Proposal, das du mit Greenlight freigibst oder ablehnst. Tekk schreibt den Fix nie selbst; das macht dein Coding-Agent.

Das verändert den Audit-Loop auf nützliche Weise:

  • Jede Änderung bekommt einen Security-Blick, nicht nur die, bei denen jemand an einen Scan gedacht hat
  • Bereiche, die sich nicht mehr ändern, werden trotzdem auditiert, sobald sie zu lange ungeprüft geblieben sind
  • Findings kommen als Proposals mit angehängten Belegen
  • Fixes werden zu Specs auf deinem Board, nicht zu verstreuten Notizen in Chat-Threads

So läuft der Loop kontinuierlich

Ein brauchbares kontinuierliches Modell mit Tekk sieht in der Praxis so aus:

  1. Starte mit einem Feature- oder Change-Request
    Die Anfrage wird so lange geklärt, bis die riskanten Teile explizit sind: Wer darf darauf zugreifen, welche Daten berührt sie, welche Dependencies braucht sie, was kann schiefgehen.

  2. Schreib sie als Spec auf dein Board
    Von Hand oder aus einem mit Greenlight freigegebenen Proposal. Die Spec ordnet die Änderung echten Dateien, Komponenten, Services und Einschränkungen im bestehenden Repository zu.

  3. Nimm Sicherheits-Akzeptanzkriterien in die Spec auf
    Zum Beispiel Autorisierung auf Ressourcenebene, Erwartungen an die Eingabevalidierung, Regeln für den Umgang mit Secrets und Review-Anforderungen für neue Pakete.

  4. Lass deinen Coding-Agent bauen
    Claude Code, Codex oder Cursor liest die Spec über den Tekk-MCP-Server. Agents arbeiten parallel, aber gegen ein gemeinsames Board statt gegen verstreute Prompts.

  5. Lass den automatisierten Audit-Loop nach Fertigstellung laufen
    Die CI führt Dependency-Checks, Secrets-Scanning und statische Analyse aus. Riskante Features können Laufzeittests in Staging auslösen.

  6. Merge und lass den Security Loop die Änderung lesen
    Der PR mit Closes TEK-123 schließt die Spec ab, sobald ihre Checkliste erledigt ist. Dieser Merge ist die nächste Änderung, die der Loop liest. Findet er eine Lücke, bekommst du ein Proposal mit Kontext, Grenzen und dem erwarteten Fix, nicht noch eine vage Anweisung im Chat.

  7. Entscheide und wiederhole
    Gib das Proposal mit Greenlight frei, und es wird zur nächsten Spec. Lehnst du es mit Begründung ab, lernt der Loop, was für dein Projekt Rauschen ist.

Das brauchen kleine Teams am meisten. Nicht noch mehr isolierte Tools, sondern einen Weg, Planung, Umsetzung, Review und Behebung miteinander verbunden zu halten, während sich die Codebase verändert.

Ohne Loop ist ein Vibe Coding Security Audit meist reaktiv. Teams scannen, was schon existiert, beheben ein paar Probleme und hoffen, dass die nächste Welle an Prompts sie nicht wieder einschleppt. Mit Loop läuft das Audit bei jeder Änderung.

Das ist der Unterschied zwischen dem Hinterherjagen von Schwachstellen und dem Abbau der Bedingungen, unter denen sie entstehen.

Du willst das bei jeder Änderung geprüft haben, nicht nur einmal? Der Security Loop von Tekk.coach prüft jede Änderung aus Angriffsperspektive und bringt dir ein Proposal nach dem anderen, das du mit Greenlight freigibst oder ablehnst. Dein Coding-Agent baut den Fix, und der Merge schließt die Spec.