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, brauchen drei Fragen belastbare Antworten: Ist sie sicher? Verfügst du über die nötigen Rechte? Kann jemand anderes als der ursprüngliche Entwickler sie warten? Eine funktionierende Demo beantwortet diese Fragen nicht. Diese Checkliste behandelt Sicherheitskontrollen, die vertragliche und urheberrechtliche Lage von KI-unterstütztem Code sowie die Betriebsreife. Sie ist eine allgemeine Orientierung für die Due Diligence, keine Rechtsberatung.

Die Werkzeuge ändern sich schnell, die Fragen der Due Diligence nicht. Für die Ebene "funktioniert es" beginne mit unserem Audit von Vibe-Coded-Software und der Checkliste zur Produktionsreife. Dieser Beitrag ergänzt die Sicherheits-, Rechts- und Investorenebene.

Sicherheit: Kontrollen statt Markenversprechen prüfen

Die aktuelle Dokumentation der Anbieter stützt vier konkrete Prüfpunkte:

• Datenbankrechte und Policies. Laut Supabase ist ein Publishable Key oder alter anon-Key für den Client gedacht. Sicher ist er nur mit korrekt konfigurierter Row-Level-Security und minimalen Grants. Secret- und service_role-Keys dürfen nie im Client landen. Teste erlaubte und verweigerte Operationen für anonyme und authentifizierte Rollen. Siehe Supabase-Sicherheitsleitfaden und RLS-Leitfaden.
• Plattform-Scans haben Grenzen. Lovable führt vor der Veröffentlichung einen Basis-Sicherheits-Scan aus und bietet tiefere Scans. Die eigene Dokumentation beschreibt den Basis-Scan jedoch als Prüfung verbreiteter Konfigurations- und Code-Muster. Anwendungsspezifische Autorisierungstests ersetzt er nicht. Siehe Lovables Sicherheitsübersicht.
• Exposition öffentlicher Projekte. Lovable legte offen, dass Regressionen vom 3. Februar bis 20. April 2026 einem authentifizierten Nutzer mit dem Link zu einem öffentlichen Projekt Zugriff auf Quellcode und Chatverlauf ermöglichten. Private Projekte und Lovable Cloud seien nicht betroffen gewesen; Lovable behob den Fehler und stellte öffentliche Projekte auf privat. Prüfe frühere Freigaben und rotiere betroffene Secrets. Siehe Lovables Incident-Bericht.
• Agentenzugriff auf Produktion. Replit bestätigte 2025, dass Agent Daten einer App-Datenbank löschte, bevor die heutige Trennung von Entwicklung und Produktion existierte. Laut Replit ist Agent heute auf die Entwicklungsdatenbank beschränkt und Rollback verfügbar. Siehe Replits Incident-Reaktion und Snapshot-Architektur.

Die praktische Schlussfolgerung ist enger als jede Schlagzeilenstatistik: Prüfe das bereitgestellte System. Teste Autorisierung, Datenbank-Policies, Secret-Handling, Abhängigkeiten, Wiederherstellung sowie die Trennung von Entwicklung und Produktion.

IP: Vertragliches Eigentum ist nur eine Ebene

Die aktuellen Bedingungen ordnen Ausgaberechte im Allgemeinen dem Kunden zu, unterscheiden sich aber bei öffentlichen Projekten, Training, Garantien und Rechten Dritter. Lies die für dein Konto geltenden Bedingungen und archiviere eine datierte Fassung.

Lovable ordnet Kundendaten und KI-Ausgaben im Verhältnis der Parteien dem Kunden zu, vorbehaltlich Rechten Dritter, und schließt Einzigartigkeit sowie Nichtverletzung aus. Kundendaten können fürs Training genutzt werden, bis du der künftigen Nutzung widersprichst. Replit belässt Nutzern ihre Rechte, lizenziert Inhalte öffentlicher Apps aber automatisch unter MIT und kann sie fürs Training verwenden. Bolt erklärt erzeugten Code zum Eigentum des Nutzers und erlaubt kommerzielle Nutzung. Vercels AI Terms behandeln Prompts und Ausgaben als Customer Content; Trainingskontrollen hängen von Tarif und Einstellungen ab. Cursor tritt eigene Rechte an Suggestions an den Kunden ab, garantiert aber keine Einzigartigkeit. Siehe Lovable Terms, Replit Terms, Bolt FAQ, Vercel AI Terms und Cursor MSA.

Urheberrecht ist eine gesonderte und rechtsordnungsabhängige Frage. Der Bericht des U.S. Copyright Office von 2025 hält Prompts allein grundsätzlich nicht für ausreichende menschliche Kontrolle. Menschlich geschaffener Ausdruck, kreative Auswahl oder Anordnung und kreative Änderungen können dagegen geschützt sein. Die Nutzung von KI macht nicht das ganze Werk schutzlos. Dokumentiere wesentliche menschliche Entwurfs- und Implementierungsentscheidungen und prüfe Herkunft sowie Lizenzpflichten.

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. Vereinbarungen mit Beitragenden. Rechtsberatung hat die Verträge aller Gründer, Mitarbeiter und Auftragnehmer nach dem geltenden Recht geprüft. Warnsignal: Ein Auftragnehmer baute Kernfunktionen und der Vertrag ist zu IP still oder unklar.
4. Open-Source-Compliance. Halte Software Bill of Materials und Lizenzinventar aktuell und erfülle alle Lizenzpflichten. Warnsignal: unbekannte Herkunft von generiertem Code oder Abhängigkeiten.
5. Training und Datenexposition. Dokumentiere Tarif, Datenschutzeinstellungen, Unterauftragsverarbeiter und Aufbewahrungsregeln zum Zeitpunkt der Übermittlung. Warnsignal: vertraulicher Code wurde ohne Prüfung der Kontrollen übermittelt.

Investorenreife

1. Bus-Faktor. Mehr als eine Person kann jedes kritische System betreiben und ändern. Warnsignal: Niemand außer dem ursprünglichen Entwickler 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. Portierbarkeit und Differenzierung. Belege, dass Export, Build, Deployment, Restore und Betrieb ohne die Sitzung einer einzelnen Person funktionieren. Dokumentiere die echte Differenzierung. Warnsignal: kein getesteter Export- oder Wiederherstellungspfad.

"Eine Demo belegt, dass ein Pfad einmal funktioniert hat. Due Diligence fragt, wer jeden Pfad nutzen darf, wer Daten wiederherstellen kann, welche Rechte das Unternehmen hält und wer das System nach dem Weggang des ursprünglichen Entwicklers warten kann."

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.