Risiken bei der Programmierung mit Vibe: Sicherheit, Wartbarkeit und Produktionsreife

Eine App, die dadurch entsteht, dass ein KI-Agent zur Codegenerierung aufgefordert wird, kann völlig fertig wirken und dennoch echte Sicherheitsrisiken bergen, wie beispielsweise eine Authentifizierungsprüfung, die nie programmiert wurde, oder ein Geheimnis, das in einer Konfigurationsdatei versteckt ist. Nichts davon wird in der Demo sichtbar. Es kommt erst zum Vorschein, wenn jemand mit bösen Absichten einen Blick darauf wirft.

Die Sicherheit beim „Vibe-Coding“ ist das offensichtlichste Risiko, aber nicht das einzige. Die gleiche Geschwindigkeit, die „Vibe-Coding“ attraktiv macht, lässt keine Zeit, um zu prüfen, ob eine App betrieblich standhält und auch dann noch wartbar bleibt, wenn die Person, die sie erstellt hat, das Projekt verlässt.

Dieser Artikel behandelt die Prüfungen, die es sich lohnt durchzuführen, bevor eine mit „Vibe-Coding“ erstellte App mit echten Daten oder geschäftlicher Verantwortung betraut wird, drei Beispiele dafür, wo das Risiko beginnt, und die verfügbaren Vorgehensweisen, sobald die Überprüfung abgeschlossen ist.

Wann wird ein mit „Vibe-Coding“ entwickelter Prototyp zu einem Geschäftsrisiko?

„Vibe-Coding“ ist der Prozess, bei dem ein KI-Programmieragent so lange angesteuert wird, bis eine Anwendung das tut, was man möchte – und das mit nur wenig manueller Programmierung, wie sie bei der traditionellen Softwareentwicklung erforderlich ist. Was für das Risiko jedoch tatsächlich zählt, ist nicht, wie die App erstellt wurde. Es geht darum, was sich ändert, sobald sie keine Demo mehr ist.

Stellen Sie sich drei Beispiele vor, die zunächst jeweils nur geringe Risiken bergen:

• Ein Mockup, das anhand von Beispieldaten zeigt, wie ein neues Dashboard aussehen könnte. Der Wendepunkt kommt, wenn es statt Beispielen Live-Daten einliest.
• Ein internes Antragsformular, über das Mitarbeiter Urlaubsanträge einreichen können und das diese zunächst nur in einer Tabelle erfasst. Der Wendepunkt kommt, wenn es die Berechtigung erhält, Unternehmensdaten tatsächlich zu aktualisieren.
• Ein kundenorientiertes Portal, das die Bestellhistorie und Kontodaten anzeigt. Der Wendepunkt kommt, wenn es für echte Kunden statt nur für eine Handvoll interner Tester zugänglich wird.

Keines dieser Projekte ist von Anfang an gefährlich. Was jedes einzelne verändert, ist dasselbe Element, das in einer anderen Form auftaucht – seien es echte Daten, echte Berechtigungen oder echte Nutzer, die einen harmlosen Platzhalter ersetzen.

Was tatsächlich zählt, sind die Nutzer einer App, ihr Datenzugriff, womit sie integriert ist und inwieweit ein Arbeitsablauf nun von ihr abhängt – nicht, ob die Demo ausgefeilt wirkte. Auch ein internes Tool ist nicht automatisch risikoarm. Der Umgang mit sensiblen Daten oder das Vornehmen von Änderungen an wichtigen Datensätzen kann genauso viele Risiken bergen wie alles, was kundenorientiert ist.

Was sollten Teams vor der Einführung überprüfen?

Professionelle Entwickler und Laienentwickler nutzen mittlerweile KI-Codierungstools, um durch schnelle Iterationen Befehle in natürlicher Sprache in funktionierende Software umzuwandeln – oft ohne die menschliche Aufsicht, die Sicherheitsteams normalerweise erwarten würden. Das ist KI-gestützte Entwicklung in ihrer schnellsten Form, und diese Geschwindigkeit lässt keine Zeit für die üblichen Überprüfungen.

Die Geschwindigkeit, mit der KI Code generiert, verdichtet traditionelle Sicherheitsprozesse wie das Schreiben, Überprüfen und Ausliefern zu einem einzigen „Vibe-Coding“-Zyklus. Das bedeutet, dass Probleme, die ein langsamerer Prozess normalerweise aufdecken würde – wie Sicherheitslücken oder übersehene Randfälle –, stattdessen direkt in die Produktion gelangen können. Herkömmliche AppSec-Tools (Anwendungssicherheit) sind zwar nach wie vor hilfreich, wurden jedoch nicht für das Tempo entwickelt, mit dem Vibe-Coding-Tools heute arbeiten. Außerdem können sie Logikfehler übersehen, die erst zutage treten, wenn jemand versteht, was eine Funktion eigentlich leisten soll.

Die Absicherung der Ergebnisse aus dem Vibe-Coding beginnt mit denselben fünf Fragen, die jede Produktionsanwendung beantworten sollte.

1. Auf welche Daten kann die App zugreifen, und wer darf sie nutzen?

Beginnen Sie mit der Sensibilität der Daten, Zugangsdaten, Authentifizierung, Sicherheitskontrollen und Berechtigungen. Wurde dies tatsächlich einer menschlichen Überprüfung unterzogen, wie beispielsweise einer Code-Review bei einem Pull-Request, oder nur automatisierten Prüfungen? Wurde der Zugriff auch für Benutzer getestet, die etwas nicht sehen oder ändern dürfen sollten – und nicht nur für diejenigen, die dazu berechtigt sind?

Die Sensibilität von Daten ist zudem nicht nur eine interne Ermessensfrage. Eine App, die auf Gesundheitsakten, Zahlungsdaten oder personenbezogene Informationen zugreift, kann unter Vorschriften wie HIPAA, SOX oder DSGVO fallen, und deren Einhaltung kann echte architektonische Änderungen erfordern – statt nur das Ankreuzen eines Kästchens in einer Richtlinie.

Beispielcode, der aus dem ersten Entwurf einer Eingabeaufforderung kopiert wurde, ist nicht von Natur aus sicherer Code. Unsicherer Code, der mit Authentifizierungslogik verknüpft ist, gehört zu den Dingen, die bei einer schnellen Überprüfung am leichtesten übersehen werden. KI-Modelle, die auf riesigen Mengen an Trainingsdaten trainiert wurden, können unsichere Muster und andere Sicherheitslücken reproduzieren, ohne dass dies beabsichtigt ist.

Eine viel zitierte Studie der NYU ergab, dass GitHub Copilot in etwa 40 % der Testfälle ausnutzbare Fehler oder sicherheitsrelevante Designfehler erzeugte, und der BaxBench-Benchmark stellte fest, dass 62 % der Lösungen selbst des leistungsstärksten Modells entweder falsch waren oder eine Sicherheitslücke enthielten. Wenn man KI-generierten Code allein deshalb als sicher betrachtet, weil er funktioniert, schlüpfen solche Muster durch die Maschen.

Dokumentieren Sie, auf welche Daten und Systeme die App zugreifen kann, welche Rollen die Berechtigung zur Nutzung haben und was die Zugriffstests ergeben haben.

2. Werden Geschäftsregeln und Fehler korrekt behandelt?

Das Testen des beabsichtigten Ablaufs zeigt Ihnen nur den „Happy Case“, in dem die Geschäftslogik funktioniert. Testen Sie auch ungültige Eingaben, fehlende Informationen, widersprüchliche Aktionen und fehlgeschlagene Anfragen. Verhält sich die App unter erwarteten Nutzungsbedingungen – einschließlich gleichzeitiger Aktionen oder eines Traffic-Spikes, wo dies relevant ist – immer noch so, wie sie sollte?

Softwarefehler und unsichere Logik, die in einer ansonsten funktionierenden Funktion verborgen sind, treten selten zutage, bis jemand die Pfade testet, an die niemand gedacht hat. Eine KI-generierte Funktion kann jeden Test bestehen, den jemand geschrieben hat, und dennoch bei dem einen versagen, an den niemand gedacht hat.

Überlegen Sie sich genau, was passiert, wenn das Ergebnis schlichtweg falsch ist – insbesondere bei Vorgängen, die Bestellungen, Genehmigungen oder Kontoänderungen betreffen. Halten Sie fest, welche Szenarien getestet wurden und welche Fehler noch ungelöst sind. „Es läuft“ und „es liefert durchweg das richtige Ergebnis“ sind zwei sehr unterschiedliche Feststellungen, und es passiert leicht, dass man das eine mit dem anderen verwechselt.

3. Was passiert, wenn eine Integration ausfällt?

Identifizieren Sie jedes System, aus dem die App Daten liest oder in das sie schreibt, einschließlich aller Cloud-Ressourcen, die sie dabei erstellen, ändern oder löschen kann. Achten Sie auf unvollständige Aktualisierungen, doppelte Aktionen, inkonsistente Daten und Fehlermeldungen, die tatsächlich Aufschluss darüber geben, was schiefgelaufen ist. Kann das Team eine fehlgeschlagene Integration erkennen und sicher beheben?

Dokumentieren Sie die Integrationen selbst, was die Fehlertests in den Testumgebungen ergeben haben und wie das Team eine nur teilweise abgeschlossene Aktion korrigieren oder rückgängig machen würde.

4. Kann eine andere Person die App warten?

Wie der von KI generierte Code erstellt wurde, ist genauso wichtig wie die Frage, ob er funktioniert. Eine von KI generierte App, die niemand erklären kann, ist schwieriger zu warten als bestehender Code oder von Menschen geschriebener Code, der bereits den normalen Prozess eines Teams durchlaufen hat.

Eine Versionskontrolle, die jede Runde der Codegenerierung nachverfolgt, bietet einem zukünftigen Wartungsmitarbeiter eine Nachverfolgbarkeit, die Prompts allein nicht bieten, und für jeden neuen Stapel KI-generierten Codes sollte jemand verantwortlich sein, der ihn vor der Auslieferung überprüft.

Jemand anderes als der ursprüngliche Entwickler muss in der Lage sein, die wichtigen Codepfade, Abhängigkeiten und Entwurfsentscheidungen zu erklären – und nicht nur grob wiedergeben zu können, was eine Eingabeaufforderung oder eine Reihe von Entwicklungstools eigentlich bewirken sollte. Achten Sie auf Tests, die zukünftige Änderungen sicherer machen, und auf einen Verantwortlichen, der tatsächlich dafür zuständig ist, den Betrieb der Anwendung aufrechtzuerhalten.

Vergewissern Sie sich, dass sowohl der Verantwortliche als auch mindestens ein weiteres qualifiziertes Teammitglied in der Lage sind, Änderungen an der App vorzunehmen, ohne sich auf das Gedächtnis des ursprünglichen Entwicklers oder den Verlauf der Eingabeaufforderungen stützen zu müssen. Eine manuelle Überprüfung durch jemanden, der mit dem Projekt nicht vertraut ist, ist hierfür ein guter Test.

5. Kann das Team die App nach dem Start betreuen?

Stellen Sie sicher, wer tatsächlich Benachrichtigungen erhält, Vorfälle untersucht, Änderungen genehmigt und Updates durchführt, sobald die App live ist. Wo wird sie ausgeführt, wie gelangen Änderungen tatsächlich in die Produktionssysteme, und wie würde das Team eine fehlerhafte Version identifizieren und rückgängig machen? Die Transparenz während der Laufzeit – also die Möglichkeit, tatsächlich zu sehen, was die App tut, sobald sie live ist – ist hier genauso wichtig wie während der Testphase.

Prüfen Sie, ob das Team den Dienst nach einem Ausfall wiederherstellen kann – und nicht nur erkennen, dass einer aufgetreten ist. Halten Sie den Support-Verantwortlichen, die Konfiguration der Benachrichtigungen sowie die Schritte für die Veröffentlichung und Wiederherstellung fest. Der laufende Support gehört von Anfang an zur Startbereitschaft – und nicht erst als Aufgabe, die jemand nach dem ersten Vorfall zuweist.

Was sollten Sie nach der Risikoprüfung tun?

Eine technische Überprüfung bedeutet nicht immer nur kleine Korrekturen. Sie kann zu echten Änderungen, einer umfassenden Neugestaltung oder sogar zum Wechsel zu einem völlig anderen Implementierungsansatz führen.

Es gibt keine starre Risikobewertung, die diese Entscheidung automatisch trifft. Wichtig ist, dass hinter dem gewählten Weg konkrete Belege stehen und dass jemand die Entscheidung tatsächlich absegnet. Der Anwendungsverantwortliche sollte technische und Sicherheitsprüfer hinzuziehen, wenn das Risikoniveau der Anwendung dies erfordert.

Wo kann Liferay DXP bei dieser Entscheidung ins Spiel kommen?

Wenn eine Überprüfung darauf hindeutet, etwas Neues zu entwickeln, anstatt das Bestehende zu flicken, lautet die nächste Frage: Auf welcher Grundlage soll dies geschehen? Vieles, was bei einer Überprüfung tatsächlich auffällt – unklare Dateneigentumsverhältnisse, fehlende Genehmigungsschritte, Berechtigungen, die niemand vollständig abgebildet hat –, sind Lücken, die eine regulierte Plattform standardmäßig schließen soll, und keine Probleme, die ein Team selbst entwerfen und erproben muss.

Liferay DXP löst dies durch:

• Objekte, die strukturierten Daten von Anfang an eine definierte Form, einen Eigentümer und eine Historie verleihen
• Formulare, die Eingaben erfassen und bereits mit Validierungen und Berechtigungen versehen sind
• Workflows, die Genehmigungen durch Schritte leiten, die ein Team einsehen und überprüfen kann
• Rollen und Berechtigungen, die den Zugriff auf Plattformebene steuern und nicht im Anwendungscode verborgen sind
• APIs und Integrationen, die über einen unterstützten, getesteten Weg eine Anbindung an bestehende Systeme herstellen

Nichts davon macht das eigene Urteilsvermögen überflüssig. Ein Team muss weiterhin entscheiden, was tatsächlich auf die Plattform gehört und was wirklich eine individuelle Entwicklung erfordert, und jede individuelle Komponente muss denselben Prüf- und Testprozess durchlaufen wie alles andere auch. Was sich ändert, ist der Ausgangspunkt. Anstatt Berechtigungen, Genehmigungen und Integrationen von Grund auf neu zu erproben, startet ein Team, das hier entwickelt, von einer Grundlage aus, die diese Hürde bereits genommen hat.

Treffen Sie die Entscheidung zur Produktionsfreigabe wohlüberlegt

Die eigentliche Frage ist nicht, ob eine App fertig aussieht. Es geht darum, welche Voraussetzungen erfüllt sein müssen, damit man sich auf diese bestimmte App tatsächlich sicher verlassen kann. Der richtige Weg hängt von ihrem Zweck ab, welchen Risiken sie ausgesetzt ist und wie lange sie voraussichtlich bestehen bleibt – nicht davon, wie sie ursprünglich entwickelt wurde.

Entdecken Sie die Low-Code-Funktionen von Liferay DXP, wenn eine geregelte Anwendungsgrundlage für Ihre nächsten Schritte die richtige Wahl zu sein scheint.

Häufig gestellte Fragen zu den Risiken der Vibe-Codierung

Kann eine intern mit Vibe programmierte App dennoch ein hohes Risiko darstellen?

Ja. Der interne Charakter schränkt lediglich ein, wer auf die App zugreifen kann, nicht jedoch, was sie tun kann, sobald sie genutzt wird. Ein internes Tool, das auf sensible Daten zugreift oder wichtige Datensätze verändert, kann genauso viele Risiken bergen wie jede kundenorientierte Anwendung – manchmal sogar noch mehr, da interne Tools oft weniger genau unter die Lupe genommen werden.

Bedeutet eine Sicherheitsüberprüfung, dass eine mit Vibe programmierte App bereit für den Produktiveinsatz ist?

Nicht allein. Sicherheit ist nur ein Teil des Gesamtbildes, unabhängig davon, welche KI-Tools bei der Entwicklung der App zum Einsatz kamen. Eine App muss außerdem Fehler korrekt behandeln, Integrationsprobleme bewältigen, von anderen Personen als dem ursprünglichen Entwickler gewartet werden können und nach der Einführung über einen konkreten Supportplan verfügen.

Was ist, wenn eine „Vibe-codierte“ App bereits Nutzer hat?

Führen Sie dieselben Prüfungen an dieser „Vibe-codierten“ App durch, nur mit noch größerer Dringlichkeit. Bestehende Nutzer machen eine App nicht sicherer. Sie bedeuten lediglich, dass die Folgen einer Sicherheitslücke bereits eintreten. Priorisieren Sie die Prüfungen, die mit den Daten oder Geschäftsprozessen zusammenhängen, mit denen die App derzeit in Berührung kommt.

Muss jeder „Vibe-codierte“ Prototyp zu einer Produktions-App werden?

Nein. Viele mit KI-Codierungsassistenten erstellte Prototypen erfüllen ihren Zweck, indem sie eine Frage beantworten oder eine Idee validieren, und werden anschließend ausgemustert. Der Druck, etwas zu formalisieren, entsteht meist erst, wenn Menschen beginnen, sich darauf zu verlassen – und genau das ist der Moment, in dem diese Art der Überprüfung am wichtigsten ist.