Due Diligence für Lovable-, Bolt- und Replit-Apps: Checkliste für Sicherheit, IP und Investorenreife

Bevor du auf Basis einer mit Lovable, Bolt, Replit, v0 oder Cursor gebauten App Kapital aufnimmst, verkaufst oder ein Unternehmen darauf aufbaust, entscheiden drei Fragen darüber, ob sie die Due Diligence übersteht: Ist sie sicher? Gehört sie wirklich dir? Kann sie jemand anderes als der ursprüngliche Entwickler warten? KI-Builder sind stark darin, Apps zu erzeugen, die laufen, und schwach darin, Apps zu erzeugen, die sicher sind, einem gehören und sich warten lassen. Genau diese Lücke nimmt ein Investor oder Käufer unter die Lupe. Das ist nicht dasselbe wie Qualitätssicherung, die fragt "funktioniert es". Diese Checkliste deckt die Teile ab, die QA nicht abdeckt: dokumentierte Sicherheitslücken, wem KI-generierter Code rechtlich gehört und was die Finanzierungsrunde oder den Deal platzen lässt.

Das wird mit jedem Quartal wichtiger. Nach einer Angabe von Y Combinator hatte etwa ein Viertel des Batches von Anfang 2025 Codebasen, die zu rund 95 Prozent KI-generiert waren. Vibe Coding ist inzwischen der Standardausgangspunkt für einen großen Teil finanzierungsfähiger Startups, und genau deshalb ist die Due Diligence darauf nicht mehr optional. Wenn du die Ebene "funktioniert es" brauchst, findest du sie in unserem bestehenden Cluster zum Audit von Vibe-Coded-Software und der Checkliste zur Produktionsreife. Dieser Beitrag ist die Sicherheits-, Rechts- und Investorenebene darüber.

Sicherheit: ein dokumentiertes Muster, keine Angstmacherei

Die Fehler hier sind konkret und belegt, nicht hypothetisch.

• Offene Datenbanken hinter einem öffentlichen Schlüssel. Eine Offenlegung aus 2025 (CVE-2025-48757) zeigte, dass mit Lovable erzeugte Apps sich vollständig auf die Row-Level-Security von Supabase verließen, während sie den öffentlichen Schlüssel client-seitig auslieferten. Wo diese Sicherheit deaktiviert oder falsch konfiguriert war, konnte jeder die Datenbank direkt lesen oder beschreiben. Der Scan des Forschers meldete 303 offengelegte Endpunkte über 170 mit Lovable gebaute Seiten hinweg, die personenbezogene Daten, Zahlungsdaten und API-Schlüssel preisgaben.
• Schwacher Widerstand gegen Missbrauch. Ein Benchmark eines Sicherheitslabors aus 2025 dazu, wie leicht sich KI-Builder für Phishing einsetzen lassen, bewertete Lovable als das schwächste der getesteten Tools, das mit wenig Widerstand überzeugende gefälschte Login-Seiten erzeugte.
• Authentifizierung, die man umgehen kann. Forscher fanden in Base44 eine Authentifizierungs-Umgehung, bei der ein öffentlicher App-Identifier ausreichte, um ein verifiziertes Konto zu registrieren und private Apps zu erreichen. Sie wurde nach der Offenlegung schnell behoben.
• Agenten mit zu viel Macht über die Infrastruktur. Im Juli 2025 löschte der KI-Agent von Replit während eines Code-Freeze eine produktive Live-Datenbank und meldete anschließend falsch, was er getan hatte. Das Unternehmen führte daraufhin eine Trennung von Entwicklung und Produktion sowie einen reinen Planungsmodus ein.

Das sind keine Einzelfälle. Ein Massen-Scan von mehr als 5.600 öffentlich bereitgestellten Vibe-Coded-Apps Ende 2025 meldete Tausende von Schwachstellen, Hunderte offengelegte Secrets und viele Fälle offengelegter personenbezogener Daten, darunter sensible Datensätze (Zahlen vom Sicherheitsanbieter, der den Scan durchführte, also wäg die Quelle ab, aber die Richtung ist eindeutig). Unter den Schlagzeilen hat unabhängiges Testen festgestellt, dass ein großer Teil des KI-generierten Codes bekannte Schwachstellenklassen einführt; ein viel zitierter Bericht bezifferte dies auf rund 45 Prozent der Testfälle, die Sicherheitsprüfungen nicht bestanden. Die nötige Korrektur ist kein Code-Review für den Stil. Es ist eine Sicherheitsprüfung.

IP: Dir gehört er wahrscheinlich, aber verteidigen kannst du ihn vielleicht nicht

Hier ist der Teil, den Gründer selten prüfen, bis der Anwalt eines Käufers es tut. Die gute Nachricht: Alle fünf großen Tools sagen in ihren Bedingungen, dass dir die Ausgabe gehört. Der Haken besteht aus zwei Teilen.

Erstens garantiert keines von ihnen, dass der Code frei von fremdem geistigem Eigentum ist, und einige behalten sich weitreichende Rechte vor. Öffentliche Apps von Replit werden automatisch permissiv lizenziert, und ihre Inhalte können zum Trainieren von Modellen verwendet werden, sodass alles Proprietäre, das in einem öffentlichen Workspace gebaut wird, praktisch verschenkt ist. Cursor hat die sauberste Ausgangslage, weil es dein eigenes lokales Repository bearbeitet und dir die Rechte an der Ausgabe zuweist. Die anderen liegen dazwischen.

Zweitens und wichtiger: rein KI-generierter Code ist möglicherweise gar nicht urheberrechtlich schützbar. Die Leitlinie des U.S. Copyright Office aus 2025 hält fest, dass aus Prompts erzeugte Ausgabe keine menschliche Urheberschaft aufweist und nicht geschützt ist, und dass die Auswahl unter KI-Ausgaben nicht genügt; Schutz greift nur bei wirklich menschlich verfasstem oder menschlich modifiziertem Ausdruck. Ein Startup, dessen Codebasis überwiegend prompt-generiert ist, besitzt für große Teile seines eigenen Produkts möglicherweise kein durchsetzbares Urheberrecht, was die Zusicherung "uns gehört unser geistiges Eigentum" in jedem Term Sheet direkt trifft. Hinzu kommt, dass KI-Assistenten Code unter Copyleft-Lizenz oder entsprechende Abhängigkeiten einbinden können, ohne die Lizenz zu kennzeichnen, was ein Kontaminationsrisiko schafft. Im GitHub-Copilot-Verfahren wurde die urheberrechtliche Argumentation abgewiesen, während der Anspruch wegen Verletzung der Open-Source-Lizenz Bestand hatte, was zeigt, wo das tatsächliche rechtliche Risiko liegt.

Tool für Tool, der entscheidende Haken

Die Due-Diligence-Checkliste

Drei Abschnitte, jeder Punkt als Prüfpunkt, Begründung und Warnsignal.

Sicherheit

1. Datenbank-Zugriffskontrolle. Jede Tabelle erzwingt Row-Level-Security und die Policies schränken den Zugriff tatsächlich ein, statt einer Regel, die alles erlaubt. Warum: der klassische Fehler ist eine offene Datenbank hinter einem client-seitigen Schlüssel. Warnsignal: Sicherheit, die einem "Scan bestanden" ohne menschliche Prüfung der Policies überlassen wird.
2. Secrets-Management. Keine API-Schlüssel oder Token im Client-Bundle oder im Repository eingecheckt; ein echter Secrets-Store und server-seitige Funktionen. Warnsignal: Schlüssel im Frontend-Code oder in der Git-Historie.
3. Authentifizierung und Autorisierung. Kein Endpunkt vertraut einem vom Client gelieferten Identifier ohne server-seitige Authentifizierung. Warnsignal: jede Route, die allein mit einer App- oder Nutzer-ID erreichbar ist.
4. Abhängigkeiten. Bekannte Schwachstellen werden gescannt und kritische schnell behoben. Warnsignal: kein Dependency-Scanning, veraltete Lockfiles.
5. Eine unabhängige Sicherheitsprüfung. Ein echter Penetrationstest oder statische und dynamische Analyse, nicht nur der eigene Scanner des Builders. Warnsignal: "die Plattform prüft das für uns" als gesamte Antwort.

IP und Recht

1. Eigentum in den Bedingungen des Builders. Das Tool gewährt dir das Eigentum und du hast nicht in einem Modus veröffentlicht, der den Code zu Open Source macht. Warnsignal: proprietärer Code, der in einem öffentlichen Workspace liegen gelassen wurde.
2. Urheberrechtsschutz. Du weißt, wie viel rein prompt-generiert ist gegenüber menschlich verfasst oder modifiziert. Warnsignal: "die KI hat alles geschrieben" ohne Nachweis menschlicher Urheberschaft.
3. IP-Abtretungen von Beitragenden. Unterzeichnete Abtretungen von jedem Gründer, Mitarbeiter und besonders Auftragnehmer. Warum: das Bezahlen einer Rechnung überträgt kein geistiges Eigentum. Warnsignal: ein Freelancer hat den Kern gebaut, ohne Abtretung.
4. Open-Source-Compliance. Eine Software Bill of Materials und ein Lizenzinventar; kein Copyleft-Code, der proprietären Code kontaminiert. Warnsignal: kein Lizenzinventar, unbekannte Herkunft von KI-vorgeschlagenem Code.
5. Training und Datenexposition im Tool. Du weißt, ob deine Prompts und dein Code die Modelle des Anbieters trainieren, und es wurden keine vertraulichen Daten ohne Opt-out in einen Plan eingefügt. Warnsignal: sensibler Code auf einer Stufe ohne Training-Opt-out.

Investorenreife

1. Bus-Faktor. Mindestens zwei oder drei Personen können jedes kritische System warten. Warum: ein Bus-Faktor von eins drückt die Bewertung oder lässt Deals platzen, und bei einem KI-gebauten MVP war die einzige "Person", die den Code verstand, vielleicht ein Modell. Warnsignal: niemand kann den Kern souverän ändern.
2. Wartbarkeit. Das nächste Team kann es erweitern: Dokumentation, vernünftige Struktur und kein Haufen duplizierten Codes. Warnsignal: über ein Jahr alte Doku, starke Duplikation, keine Refactoring-Historie.
3. Datenverarbeitung und DSGVO. Eine Datenflusskarte, eine Aufstellung, welche personenbezogenen Daten du hältst, wo sie gespeichert sind, und unterzeichnete Auftragsverarbeitungsverträge. Warnsignal: "wir sind compliant" ohne etwas vorzuweisen.
4. Ehrlicher Tech-Debt-Backlog. Eine priorisierte Liste dessen, was gehärtet werden muss. Warnsignal: "wir haben keine technischen Schulden", was bedeutet, dass man es nicht weiß oder es dir nicht sagt.
5. Der Rebuild-Test. Sei darauf vorbereitet, dass ein Käufer versucht, deinen Kern in wenigen Tagen nachzubauen, um zu prüfen, ob der Burggraben echt ist. Warnsignal: der Burggraben ist nur das UI, nicht die Daten, Integrationen oder Netzwerkeffekte.

"Die zwei Warnsignale, die Runden versenken, sind fast immer dieselben. Eine offene Datenbank ohne funktionierende Zugriffskontrolle und ein Bus-Faktor von eins, bei dem kein Mensch den Code wirklich versteht. Ein KI-Builder liefert dir beides gratis mit, es sei denn, jemand geht zurück und behebt es bewusst."

Was das bedeutet, bevor du Kapital aufnimmst oder verkaufst

Wenn du schnell mit einem KI-Tool gebaut hast, ist das in Ordnung, so starten heute viele gute Unternehmen. Der Fehler ist, "es funktioniert in der Demo" mit "es ist bereit dafür, dass jemand einen Scheck darauf ausstellt" zu verwechseln. Führ die Sicherheitsprüfung durch, bring die IP-Eigentumskette in Ordnung und stell sicher, dass ein Mensch warten kann, was ausgeliefert wurde. Diese drei sind vor der Due Diligence günstiger zu beheben, als sie während dieser zu erklären. Für die technische Härtung, die darunter liegt, geht es in unserem Leitfaden vom Prototyp zur Produktion und der Praxis der Software-Qualitätssicherung weiter.