Sie kaufen gleich einen Anteil an einem Vermögenswert, den Sie nicht besichtigt haben. Ein Code-Audit ist die Besichtigung — aber nur, wenn es auf Investitionsfragen zugeschnitten ist statt auf technische.
Ein Code-Audit vor der Investition ist Teil der breiteren technischen Due Diligence und hat eine engere Aufgabe: festzustellen, was tatsächlich existiert, ob es sauber im Eigentum steht und ob es den finanzierten Plan tragen kann.
Schlecht zugeschnitten produziert es eine Liste von Stilbeschwerden. Gut zugeschnitten produziert es zwei oder drei Befunde, die den Deal verändern.
Welche Zugänge anzufordern sind
Fordern Sie diese vor Unterzeichnung des Term Sheets an. Widerstand in dieser Phase ist für sich genommen aufschlussreich.
- Lesezugriff auf alle Repositories — einschließlich Infrastructure-as-Code und Deployment-Skripten, wo der wahre Zustand oft sichtbar wird
- Vollständige Commit-Historie, kein zusammengefasster Snapshot: Die Historie zeigt, wer das System wirklich gebaut hat und wie schnell es sich bewegt
- Ein Architektur-Walkthrough mit dem Entwickler, der es gebaut hat, ein bis zwei Stunden
- Zugang zum Issue-Tracker und, sofern vorhanden, zu Incident-Aufzeichnungen
- Die Liste der Drittanbieterdienste, von denen das Produkt abhängt
Die acht Fragen, die das Audit beantworten muss
- Entspricht der vorhandene Code dem, was im Pitch beschrieben wurde? (Demoware und Integrationen, die in Wahrheit manuelle Prozesse sind, kommen häufig vor.)
- Wer hat ihn geschrieben, und sind diese Leute noch da?
- Ist das IP-Eigentum sauber — Contractors unter Übertragungsvereinbarung, kein unlizenziert kopierter Code, keine Lizenzkontamination durch GPL-Abhängigkeiten in einem proprietären Produkt?
- Was bricht unter dem Wachstumsplan zuerst, und was kostet es, diese Decke anzuheben?
- Sind Kundendaten zwischen Mandanten isoliert, und wird Autorisierung serverseitig durchgesetzt?
- Für alles Finanzielle: Gibt es ein unveränderliches Ledger, und ist jeder Geldpfad idempotent?
- Kann das Team sicher deployen — Automatisierung, Rollback, Monitoring?
- Wie viel des Produkts gehört wirklich ihnen, verglichen mit einer dünnen Hülle über Anbietern, die die Preise ändern oder verschwinden können?
Befunde, die eine Vertragsklausel rechtfertigen
| Befund | Typische Konsequenz |
|---|---|
| Kern von Contractors gebaut, ohne IP-Übertragung | Vor der Überweisung schließen — juristisches, kein technisches Mittel |
| Kein Ledger in einem Unternehmen, das Geld bewegt | Sanierungsbudget in der Runde finanziert; mögliche Tranchierung |
| Mandantenübergreifende Datenoffenlegung | Behebung als Vollzugsbedingung |
| Kritische Anbieterabhängigkeit ohne Ausweichoption | Klumpenrisiko offengelegt; manchmal eine Covenant |
| Bus-Faktor eins beim Kernsystem | Retention-Paket oder Key-Person-Versicherung |
| Keine automatisierten Deployments | In den Post-Close-Plan eingepreist |
Was Ihre Aufmerksamkeit nicht wert ist
Auditoren, die nach Befunden abrechnen, liefern Ihnen eine lange Liste. Das meiste davon ist für eine Investitionsentscheidung irrelevant:
- Framework- oder Sprachpräferenzen — jede Wahl hat Kritiker
- Uneinheitlicher Code-Stil und Formatierung
- Niedrige Gesamttestabdeckung, wenn Geld- und Auth-Pfade abgedeckt sind
- Veraltete Abhängigkeiten ohne erreichbare Schwachstelle
- Fehlende Dokumentation — wirklich häufig, selten entscheidend, günstig zu beheben
Wenn sich der Auditbericht Ihrem Investmentkomitee nicht in drei Sätzen zusammenfassen lässt, wurde er als Engineering-Übung zugeschnitten und nicht als Investitionsfrage.
Wie ein gutes Ergebnis aussieht
- Eine einseitige Zusammenfassung in Geschäftssprache mit einer klaren Gesamtrisikoposition
- Nach Konsequenz sortierte Befunde, jeweils mit Belegen, die das Team des Targets prüfen kann
- Sanierungskosten in Entwicklerwochen, damit sie in Geld umrechenbar sind
- Ein empfohlener technischer 90-Tage-Plan nach dem Closing
- Eine ausdrückliche Liste dessen, was NICHT geprüft wurde, damit niemand eine Abdeckung annimmt, die es nicht gab
Die benötigten Nachweise im Auftrag festhalten
Ein Befund muss bis zur Quelle zurückverfolgbar sein. Der Käufer sollte Aufwand und Auswirkungen einer Korrektur einschätzen können.
- Repository, Commit, Umgebung und Prüfdatum benennen.
- Beispiele, betroffene Abläufe und Aufwandannahmen anfordern.
- Ausgeschlossene Bereiche und eine mögliche Nachprüfung festhalten.
Häufige Fragen
Wie lange dauert ein Code-Audit vor der Investition?
Drei bis zehn Arbeitstage für die meisten Seed- und Series-A-Targets. Fintech, Healthtech oder ungewöhnlich große Codebasen dauern länger. Jenseits von zwei Wochen kaufen Sie meist Details statt Entscheidungen.
Wird das Startup wissen, dass wir es auditieren?
Ja — sinnvolle Audits erfordern Repository-Zugang und Entwicklerzeit, es ist also ein kooperativer Prozess. Seriöse Targets erwarten das und sind in der Regel entspannt; ungewöhnlicher Widerstand ist für sich genommen bemerkenswert.
Können Sie ohne Quellcodezugang auditieren?
Nur oberflächlich. Ohne Repository lassen sich das laufende Produkt, die öffentliche Sicherheitslage und Teamsignale bewerten, aber nicht IP-Sauberkeit, echte Architektur oder Wartbarkeit — und genau das sind meist die Befunde, auf die es ankommt.
Was, wenn das Audit ernste Probleme findet?
Das ist ein erfolgreiches Audit, und es beendet den Deal selten. Die meisten Befunde werden zu einem Sanierungsbudget, einer Vollzugsbedingung, tranchierter Finanzierung oder einer Bewertungsanpassung. Der Fehlerfall ist, dieselben Probleme im sechsten Monat zu entdecken, wenn sie weit mehr kosten.
Benötigt der Prüfer eine Kopie der Produktionsdatenbank?
Nicht grundsätzlich. Synthetische oder passend bereinigte Daten und begrenzten Zugriff bevorzugen. Mehr Zugang nur für eine konkret anders nicht beantwortbare Frage erwägen.
Brauchen Sie ein Audit, bevor Sie überweisen?
Befunde nach geschäftlicher Konsequenz sortiert, Sanierung in Entwicklerwochen bepreist, geliefert in unter zwei Wochen.
Weiterführend
Technische Due Diligence für Investoren: Der vollständige Leitfaden
Technische Due Diligence ist kein Code-Review. Sie beantwortet eine Frage: Was kostet es, diese Technologie dorthin zu bringen, wo die Investmentthese sie braucht?
Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen
Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.