In vielen Stuttgarter Unternehmen entstehen interne Tools nicht mehr nur in der IT, sondern auch in Fachabteilungen, die mit Lovable, Base44 oder einem Coding-Agenten eigene Lösungen bauen. Das beschleunigt die Digitalisierung, erzeugt aber Schatten-IT mit unbekanntem Sicherheitsniveau. Ein gezieltes Security-Audit macht sichtbar, welche Risiken in solchem Code stecken, und schafft die Grundlage, damit Informationssicherheit und Fachbereich gemeinsam entscheiden können, was in den Betrieb darf.
Warum KI-generierter Code ein eigenes Audit braucht
KI-App-Builder und Coding-Agenten erzeugen in kurzer Zeit funktionierende Anwendungen. Funktionieren heißt aber nicht sicher sein. Modelle optimieren darauf, dass eine Funktion läuft, nicht darauf, dass sie gegen Missbrauch gehärtet ist. Hinzu kommt, dass viele Prototypen von Menschen gebaut werden, die den erzeugten Code nie im Detail gelesen haben. Der Agent hat zwar getan, was verlangt wurde, aber niemand hat ihm gesagt, wovor die Anwendung geschützt werden muss.
Typische Folgen sind API-Schlüssel im Frontend, Datenbanken ohne wirksame Zugriffsregeln, ungeprüfte Eingaben und veraltete Pakete. Solche Lücken fallen im Prototyp nicht auf, werden aber zum Risiko, sobald echte Nutzer und echte Daten im Spiel sind.
Die vier häufigsten Schwachstellen
Secrets: Schlüssel für Zahlungsanbieter, KI-APIs oder E-Mail-Dienste landen schnell im Client-Code oder in der Git-Historie. Alles, was im Browser oder in einer App ausgeliefert wird, ist öffentlich. Geheime Schlüssel gehören in serverseitige Funktionen und Umgebungsvariablen, bereits veröffentlichte Schlüssel müssen rotiert werden.
Supabase Row Level Security: Bei Lovable-Projekten mit Supabase entscheidet RLS darüber, wer welche Zeilen lesen und schreiben darf. Fehlt RLS auf einer Tabelle oder ist eine Policy zu großzügig formuliert, kann jeder mit dem öffentlichen Anon-Key auf fremde Daten zugreifen.
Injection und Abhängigkeiten: Wo Eingaben ungeprüft in SQL, Shell-Befehle, HTML oder Prompts fließen, entstehen klassische Angriffsflächen, inklusive Prompt Injection bei LLM-Funktionen. Außerdem installieren Agenten gern Pakete, teils veraltet, teils mit bekannten Schwachstellen oder mit erfundenen Namen, die Angreifer gezielt registrieren. Ein einziges kompromittiertes Paket genügt, um Schadcode in den Build zu schleusen, ohne dass es im eigenen Code auffällt.
So gehen Sie bei einem Audit vor
Ein Audit muss nicht mit einem vollständigen Penetrationstest beginnen. Eine strukturierte Prüfung in festen Schritten deckt die meisten Probleme bereits auf.
- Durchsuchen Sie Repository und Git-Historie mit einem Secret-Scanner und rotieren Sie alle gefundenen Schlüssel.
- Prüfen Sie in Supabase jede Tabelle auf aktivierte RLS und testen Sie die Policies mit verschiedenen Benutzerrollen, auch ohne Anmeldung.
- Kontrollieren Sie alle Stellen, an denen Nutzereingaben verarbeitet werden, auf Validierung, parametrisierte Abfragen und sauberes Escaping.
- Lassen Sie einen Dependency-Scan laufen, entfernen Sie ungenutzte Pakete und aktualisieren Sie solche mit bekannten Schwachstellen.
- Prüfen Sie Authentifizierung, Rate Limits, CORS-Einstellungen und Fehlermeldungen, die interne Details preisgeben könnten.
- Verankern Sie die Prüfungen dauerhaft in der CI, damit neue Lücken gar nicht erst in den Hauptzweig gelangen.
- Dokumentieren Sie die Ergebnisse und ergänzen Sie Ihre CLAUDE.md oder AGENTS.md um Sicherheitsregeln, damit der Agent dieselben Fehler künftig vermeidet.
Datenschutz und laufender Betrieb
Sicherheitslücken in Anwendungen mit personenbezogenen Daten sind nicht nur ein technisches Problem. Die DSGVO verlangt angemessene technische und organisatorische Maßnahmen, und ein offener Datenbankzugriff kann eine meldepflichtige Datenpanne auslösen. Ein Audit vor dem Livegang ist deshalb deutlich günstiger als die Aufarbeitung danach.
neooutput bietet im Rahmen von Deploy, Convert und Scale ein Security-Audit von KI-generiertem Code an: Wir prüfen Secrets, RLS, Eingabeverarbeitung und Abhängigkeiten, beheben die kritischen Punkte und richten automatische Prüfungen ein. Auf Wunsch übernehmen wir anschließend das Production-Hardening und den Betrieb rund um die Uhr.
KI-Code in regulierten Umgebungen absichern
Automobilhersteller, Zulieferer und Maschinenbauer in der Region Stuttgart unterliegen oft strengen Anforderungen an Informationssicherheit, etwa durch Kundenvorgaben oder branchenspezifische Standards. Ein KI-generiertes Dashboard, das Produktionsdaten anzeigt, oder ein internes Bestelltool mit Lieferantendaten muss diesen Anforderungen genauso genügen wie klassisch entwickelte Software. Häufig fehlen aber Dokumentation, Tests und eine klare Verantwortlichkeit. Wer die Anwendung gebaut hat, kann oft nicht mehr erklären, welche Daten wohin fließen und wer Zugriff darauf hat.
neooutput prüft solche Anwendungen bei Ihnen vor Ort, mit Anreise aus Freiburg, oder remote in Ihrer freigegebenen Umgebung. Das Ergebnis ist ein nachvollziehbarer Bericht mit priorisierten Befunden, der sich in die bestehenden Prozesse Ihrer Konzern-IT einfügt, sowie auf Wunsch die direkte Behebung der kritischen Punkte durch unsere AI Code Engineers. Auf Wunsch schulen wir zusätzlich die Fachabteilungen, damit künftige KI-Projekte von Anfang an sicherer entstehen.
Häufige Fragen
Ist mein Lovable-Projekt automatisch sicher, weil es Supabase nutzt?
Nein. Supabase stellt mit Row Level Security ein starkes Werkzeug bereit, das aber korrekt konfiguriert werden muss. Ohne passende Policies können Daten über den öffentlichen Schlüssel abrufbar sein.
Können Coding-Agenten selbst ein Security-Audit durchführen?
Agenten helfen beim Aufspüren typischer Muster und beim Beheben gefundener Lücken. Sie ersetzen aber keine bewusste Prüfung durch Menschen, die das Bedrohungsmodell der Anwendung verstehen. Am besten kombinieren Sie automatische Scanner, agentische Unterstützung und ein menschliches Review.
Wann sollte ein Security-Audit stattfinden?
Spätestens bevor echte Nutzer und personenbezogene Daten ins Spiel kommen, also vor dem Livegang oder der Store-Einreichung. Danach empfiehlt sich eine Wiederholung bei größeren Funktionserweiterungen sowie automatische Prüfungen bei jedem Pull Request.
Liefern Sie einen Bericht, den unsere Informationssicherheit in Stuttgart verwenden kann?
Ja. Sie erhalten eine priorisierte Übersicht der Befunde mit Beschreibung, Risiko und empfohlener Maßnahme. Das Format stimmen wir vorab mit Ihrer IT-Sicherheit ab, damit es in Ihre bestehenden Freigabeprozesse passt.