Vibe-Coding und Sicherheit: 80 Prozent der Lücken sind trivial

Wie du dein Projekt trotz Vibe-Coding wirklich sicher bekommst, kann ich dir nicht abschließend sagen. Was ich dir sagen kann: Wenn du dich ein bisschen damit beschäftigst, bist du einen großen Teil der Angriffsfläche schon los. Grob geschätzt 80 Prozent, denn die meisten Fehler, die man machen kann, sind ziemlich trivial.

Warum ich gerade darüber schreibe

Die Creatorin Lea hat in einem Video gezeigt, wie sie im gevibecodeten Projekt des YouTubers Trymacs Sicherheitslücken gefunden hat. Gravierend waren diese Lücken, und gleichzeitig einfach zu beheben.

Genau das lässt mich nicht los. Ich verstehe nicht, wie bei einem Projekt, das mit KI gebaut wurde, solche Lücken stehen bleiben können. Mit einfachen Skills wären sie zu finden gewesen. Man hätte nur fragen müssen.

Für mich zeigt das vor allem eins: Da hat jemand etwas gebaut und sich danach keine Gedanken mehr gemacht. Am Werkzeug lag es also nicht, eher am fehlenden Schritt nach dem Bauen.

Bauen ist nur die halbe Arbeit

Wenn du mit KI baust, geht das Bauen schnell. Gefährlich wird es, wenn mit dem letzten „funktioniert“ auch die Arbeit endet. Der Schritt danach kostet wenig und bringt viel:

1. Lass einen KI-Agenten gezielt nach Sicherheitsproblemen suchen. Je konkreter der Auftrag, desto besser: offene Admin-Bereiche, fehlende Berechtigungsprüfung, Secrets im Code, ungeprüfte Eingaben.
2. Nutze fertige Skills oder Prüfregeln, statt jedes Mal neu zu fragen. Was einmal als Regel formuliert ist, wird bei jeder Änderung geprüft.
3. Diskutiere mit einem großen Modell über deinen Code. Ein kurzes Gespräch über die Frage „Was könnte hier jemand missbrauchen?“ fördert die einfachen Sachen zutage.

Nach dem klassischen 80-20-Prinzip findest du damit nicht jede Lücke. Aber die groben Schnitzer sind weg, und genau die sind es, über die man in Videos wie dem von Lea stolpert.

Ein Beispiel von heute, aus diesem Blog

Wie trivial solche Fehler sind, habe ich heute an meinem eigenen Projekt gesehen. Mein Code Guard hat beim Lauf über diesen Blog gemeldet:

BEFUND [app-static/S4] .dockerignore schließt .git nicht aus — COPY . in docker/Dockerfile:77 kopiert das Repository ins Image
BEFUND [app-static/S4] .dockerignore schließt .env.local nicht aus — COPY . in docker/Dockerfile:77 kopiert das Repository ins Image

Übersetzt: Es gab überhaupt keine .dockerignore. Das Dockerfile kopiert mit COPY . den ganzen Projektordner ins Image, und damit auch die .env.local mit Zugangsdaten und die komplette Git-Historie. Niemand hat das absichtlich so gebaut. Es ist einfach passiert, wie solche Dinge eben passieren.

Ich bin seit 24 Jahren Entwickler, und trotzdem lag der Fehler da. Aufgefallen ist er einer Regel, die nach jeder Änderung automatisch läuft. Zum Beheben reicht eine Datei mit ein paar Zeilen.

Was ich daraus mitnehme

• Die meisten Lücken sind langweilig: offene Konfigurationen, Secrets am falschen Ort, fehlende Prüfungen. Genau deshalb findet eine Maschine sie zuverlässig.
• Prüfen gehört zum Bauen. Wer mit KI baut, sollte das Prüfen genauso automatisieren wie das Schreiben.
• 80 Prozent sind nicht 100. Ein KI-Review ersetzt keinen Penetrationstest. Aber es sorgt dafür, dass niemand mit einem einzigen Video dein Projekt vorführen kann.

Wie mein Code Guard aufgebaut ist, welche Prüfungen er fährt und wo du ihn auf GitHub findest, beschreibe ich auf der Seite Code Guard. In den nächsten Folgen zeige ich, wie du noch mehr von diesen Schnitzern loswirst und wie du das Ganze testest.