Ein Unternehmen möchte eine bestehende Anwendung weiterentwickeln lassen. Der bisherige Entwickler ist nicht mehr verfügbar, die Agentur soll gewechselt werden oder ein internes Projekt braucht externe Unterstützung. Fachlich ist oft schon klar, was als Nächstes entstehen soll.
Technisch sollte ein neuer Dienstleister trotzdem nicht mit dem Feature beginnen.
Bevor Software weiterentwickelt wird, muss geklärt sein, ob Quellcode, Daten, Infrastruktur und Betriebswissen vollständig übernommen werden können.
Eine saubere Softwareübernahme reduziert das Risiko, dass wichtige Zugänge, Abhängigkeiten oder implizites Wissen erst dann auffallen, wenn bereits Änderungen geplant oder produktive Systeme betroffen sind.
1. Wer besitzt und verwaltet das Repository?
Der Quellcode sollte in einem nachvollziehbaren Versionsverwaltungssystem vorliegen. Relevant ist nicht nur ein ZIP-Archiv des aktuellen Stands, sondern die tatsächliche Projektstruktur inklusive Historie und Branching.
- GitHub, GitLab, Bitbucket oder eigener Git-Server
- Eigentümer des Repositorys
- Administrationsrechte
- Branches und Tags
- Release-Historie
- Issues und Pull Requests
- Webhooks
- Deployment Keys
- Actions oder andere CI/CD-Pipelines
GitHub weist beispielsweise darauf hin, dass bei einer Repository-Übertragung neben dem Code auch Issues, Pull Requests, Releases, Einstellungen und weitere verknüpfte Elemente relevant sein können.
Ein Quellcode-Download ist nicht dasselbe wie die vollständige Übernahme eines Softwareprojekts. Historie, CI/CD, Issues, Secrets und Betriebswissen können außerhalb dieses Archivs liegen.
2. Lässt sich die Anwendung lokal oder in einer Testumgebung starten?
Ein neuer Dienstleister sollte reproduzieren können, wie die Anwendung gebaut und gestartet wird.
- Runtime und Version
- Package Manager
- Environment-Variablen
- Datenbank
- Seed- oder Testdaten
- Container-Konfiguration
- Build-Schritte
- externe Services
Wenn der produktive Server die einzige Umgebung ist, auf der das System zuverlässig läuft, ist das ein wichtiges Risikosignal.
3. Welche Abhängigkeiten verwendet die Software?
Moderne Anwendungen bestehen aus zahlreichen externen Komponenten. Deshalb sollte bekannt sein, welche direkten und indirekten Dependencies verwendet werden.
OWASP bezeichnet ein korrektes Inventar der eingesetzten Softwarekomponenten als grundlegende Voraussetzung für weitere Risikoanalysen. GitHub kann Dependencies beispielsweise aus Manifest- und Lock-Dateien ableiten und in einem Dependency Graph darstellen.
- Welche Libraries und Packages werden verwendet?
- Welche Versionen sind installiert?
- Werden die Komponenten noch unterstützt?
- Werden private Registries genutzt?
- Gibt es bekannte Sicherheitsprobleme?
4. Wo liegen Zugangsdaten und Secrets?
API-Schlüssel, Datenbankzugänge, SMTP-Passwörter, Zertifikate und Deployment-Credentials gehören nicht unkontrolliert in Quellcode oder Übergabe-E-Mails.
OWASP empfiehlt eine zentrale und kontrollierte Verwaltung von Secrets. Bei einem Anbieterwechsel sollten relevante Zugangsdaten inventarisiert, Besitzverhältnisse geklärt und bei Bedarf rotiert werden.
- Datenbank-Credentials
- API Tokens
- SSH Keys
- Cloud-Zugänge
- SMTP-Zugänge
- OAuth Client Secrets
- Zertifikate und private Schlüssel
5. Wie ist die Datenbank aufgebaut?
Die Datenbank ist häufig der wertvollste Teil einer Anwendung. Deshalb reicht es nicht zu wissen, welche Datenbanktechnologie verwendet wird.
- Schema und Tabellen
- Migrationen
- Indizes
- Backups
- Restore-Prozess
- historische Daten
- personenbezogene oder besonders schützenswerte Daten
- Import- und Exportprozesse
Ein Backup ist erst dann belastbar, wenn bekannt ist, wie es wiederhergestellt werden kann.
6. Wie gelangt eine Änderung in Produktion?
Der Deployment-Prozess entscheidet wesentlich darüber, wie sicher eine Anwendung weiterentwickelt werden kann.
- Gibt es Staging und Produktion?
- Wer darf deployen?
- Wird manuell oder automatisiert deployed?
- Gibt es Freigaben?
- Wie werden Datenbankmigrationen ausgeführt?
- Gibt es eine Rollback-Strategie?
- Wo liegen Logs?
GitHub Environments können beispielsweise unterschiedliche Deployment-Ziele, Freigaberegeln und secretspezifische Zugriffe abbilden. Unabhängig vom verwendeten Werkzeug sollte der Prozess nachvollziehbar sein.
7. Welche Infrastruktur gehört zur Anwendung?
Zur Software gehören häufig mehr Systeme als nur Webserver und Datenbank.
- DNS und Domains
- Cloud- oder Hosting-Accounts
- Object Storage
- Redis oder andere Caches
- Message Queues
- CDN
- E-Mail-Dienst
- Monitoring
- Backup-Systeme
- Drittanbieter-APIs
Bei einer Übernahme muss sichtbar werden, welche dieser Komponenten vom bisherigen Dienstleister betrieben werden und welche dem Unternehmen selbst gehören.
8. Welche Tests gibt es?
Tests zeigen nicht automatisch, dass eine Software gut ist. Sie geben einem neuen Team aber eine wichtige Rückmeldung darüber, ob kritische Funktionen nach Änderungen weiterhin erwartungsgemäß arbeiten.
- Unit Tests
- Integrationstests
- End-to-End-Tests
- manuelle Abnahmeszenarien
Fehlen Tests, sollte zumindest dokumentiert werden, welche fachlichen Abläufe vor jedem Release überprüft werden müssen.
9. Welche Schnittstellen existieren?
Eine Anwendung kann äußerlich eigenständig wirken und trotzdem von zahlreichen Fremdsystemen abhängen.
- Zielsystem
- Zweck
- Authentifizierung
- Datenformat
- Fehlerbehandlung
- Rate Limits
- verantwortlicher Account
- Dokumentation
10. Welche fachliche Logik ist nur im Kopf einzelner Personen?
Ein besonders großes Risiko lässt sich nicht automatisch scannen: implizites Wissen.
- Warum existiert dieser Sonderfall?
- Welche Daten dürfen nie automatisch verändert werden?
- Welche Hintergrundjobs sind geschäftskritisch?
- Welche Funktion sieht ungenutzt aus, wird aber regelmäßig benötigt?
- Welche manuellen Schritte gehören zum Release?
Wenn eine Übergabe mit dem bisherigen Dienstleister möglich ist, sollte diese Zeit genau dafür genutzt werden.
11. Welche Rechte und Verträge müssen geklärt werden?
Technischer Zugriff bedeutet nicht automatisch, dass alle rechtlichen und vertraglichen Fragen geklärt sind.
Unternehmen sollten prüfen lassen, welche Nutzungs-, Bearbeitungs- und Herausgaberechte vertraglich vereinbart wurden und welche Drittanbieter-Lizenzen bestehen. Bei Unsicherheit ist eine rechtliche Prüfung sinnvoll.
12. Erst übernehmen, dann verändern
1. Zugänge und Eigentum klären
2. Anwendung reproduzierbar starten
3. Deployment verstehen
4. Backup und Restore prüfen
5. Abhängigkeiten und Risiken erfassen
6. kritische Fachprozesse nachvollziehen
7. erst danach neue Features planen
Diese Reihenfolge wirkt langsamer als ein sofortiger Entwicklungsstart. In der Praxis verhindert sie jedoch, dass unbekannte technische Risiken mitten im Projekt auftauchen.
Fazit
Eine Softwareübernahme ist deutlich mehr als die Übergabe eines Git-Repositories. Quellcode, Daten, Infrastruktur, Zugänge, Secrets, Deployment, Lizenzen und fachliches Wissen bilden zusammen das tatsächliche System.
Wer diese Bestandteile zuerst strukturiert übernimmt, schafft eine belastbare Grundlage für jede weitere Entwicklung.
Häufige Fragen
Was braucht ein neuer Dienstleister zur Übernahme bestehender Software?
Mindestens Quellcode und Repository-Zugang, Informationen zu Datenbank, Hosting, Dependencies, Deployment, Schnittstellen, Secrets, Backups und vorhandener Dokumentation.
Reicht ein ZIP-Archiv des Quellcodes aus?
Für eine vollständige Übernahme meist nicht. Versionshistorie, Issues, CI/CD, Webhooks, Deployment-Konfigurationen, Secrets und weitere Projektinformationen können außerhalb des Archivs liegen.
Sollten Zugangsdaten beim Anbieterwechsel geändert werden?
Je nach Zugriffssituation kann eine Rotation von Secrets und Zugangsdaten sinnvoll sein. Wichtig ist zunächst ein vollständiges Inventar der relevanten Zugänge und ihrer Besitzer.
Was passiert, wenn keine Dokumentation existiert?
Dann muss ein Teil des Wissens aus Code, Infrastruktur und Gesprächen mit Fachanwendern rekonstruiert werden. Das erhöht den Analyseaufwand vor der Weiterentwicklung.