Viele Unternehmen wissen, dass ihre Software geschäftskritisch ist, aber nicht, wie gesund sie technisch wirklich ist. Die Anwendung läuft, neue Funktionen werden immer langsamer, Fehler häufen sich oder niemand im Team kann sicher sagen, ob die Architektur noch tragfähig ist. Genau dann wird ein Software-Audit sinnvoll.
Ein Software-Audit ist eine strukturierte technische Prüfung einer bestehenden Anwendung. Es geht nicht darum, pauschal schlechten Code zu suchen. Ein gutes Audit beantwortet konkrete Fragen: Wie wartbar ist das System? Welche Sicherheitsrisiken gibt es? Wo entstehen technische Schulden? Welche Modernisierungsschritte sind sinnvoll? Und lohnt es sich, weiterzubauen oder sollte ein Teil neu gedacht werden?
Kurzantwort: Ein Software-Audit prüft Codequalität, Architektur, Sicherheit, Datenmodell, Performance, Betrieb, Tests und Wartbarkeit. Ein kompakter Audit kostet häufig 5.000 bis 15.000 EUR. Ein tiefer technischer Audit mit Code Review, Security-Check, Infrastruktur-Analyse, Interviews und Roadmap liegt oft bei 15.000 bis 40.000 EUR. Bei sehr großen oder regulierten Systemen kann der Aufwand höher sein.
Wann lohnt sich ein Software-Audit?
Ein Audit lohnt sich immer dann, wenn technische Unsicherheit eine geschäftliche Entscheidung blockiert. Typische Situationen sind:
- Eine bestehende Software soll von einer neuen Agentur übernommen werden.
- Eine Web-App oder Plattform wird immer langsamer weiterentwickelt.
- Sicherheits- oder Datenschutzfragen sind unklar.
- Ein Unternehmen plant eine Investition, Übernahme oder technische Due Diligence.
- Ein MVP soll zur produktiven Plattform ausgebaut werden.
- Ein Legacy-System verursacht hohe Wartungskosten.
- Interne Entwickler warnen vor technischer Schuld, aber es fehlt eine neutrale Einschätzung.
- Die Geschäftsführung braucht eine Roadmap mit Aufwand, Risiko und Priorität.
Ein Audit ist besonders wertvoll, bevor große Budgets gebunden werden. Es ist günstiger, Risiken vor einer Modernisierung zu verstehen, als mitten im Projekt zu merken, dass Datenmodell, Tests oder Architektur nicht tragen.
Was wird in einem Software-Audit geprüft?
Der genaue Umfang hängt vom System ab. Eine öffentliche Website braucht andere Prüfpunkte als ein B2B-Kundenportal, eine mobile App oder eine SaaS-Plattform. Typische Bereiche sind:
| Bereich | Worum es geht |
|---|---|
| Codequalität | Lesbarkeit, Struktur, Duplikate, Fehleranfälligkeit, Konventionen |
| Architektur | Trennung von Schichten, Modularität, Abhängigkeiten, Skalierbarkeit |
| Sicherheit | Authentifizierung, Rechte, Input-Validierung, Secrets, bekannte Schwachstellen |
| Datenmodell | Konsistenz, Migrationen, Integrität, Performance, Zukunftsfähigkeit |
| Tests | Abdeckung kritischer Flows, automatisierte Tests, manuelle Risiken |
| Betrieb | Deployment, Monitoring, Backups, Logs, Rollback, Verantwortlichkeiten |
| Performance | Ladezeiten, Datenbankabfragen, API-Latenz, Frontend-Bundles |
| Wartbarkeit | Dokumentation, Setup, Onboarding, technische Schulden |
Das Ergebnis sollte keine lange Liste abstrakter Kritik sein. Ein gutes Audit priorisiert: Was ist kritisch? Was sollte kurzfristig behoben werden? Was gehört auf die Roadmap? Was kann bewusst bleiben?
Code Review: Was gute Codequalität bedeutet
Codequalität ist kein ästhetisches Thema. Sie bestimmt, wie schnell neue Funktionen entstehen, wie sicher Änderungen sind und ob andere Teams das System übernehmen können.
Ein Code Review im Audit prüft unter anderem:
- klare Verantwortlichkeiten in Komponenten, Services und Modulen
- verständliche Benennung und nachvollziehbare Struktur
- Fehlerbehandlung und Randfälle
- unnötige Duplikate
- zu große Dateien oder Funktionen
- direkte Datenbankzugriffe an falschen Stellen
- Vermischung von UI, Geschäftslogik und Datenzugriff
- Abhängigkeit von einzelnen Personen oder undokumentiertem Wissen
Schlechter Code bedeutet nicht automatisch, dass alles neu gebaut werden muss. Oft reicht eine gezielte technische Roadmap: kritische Bereiche stabilisieren, Tests ergänzen, Module entkoppeln und neue Funktionen nur noch nach klareren Regeln bauen.
Architektur prüfen: Trägt das System noch?
Architektur entscheidet, ob Software wachsen kann. Ein System kann in Version 1 gut funktionieren und trotzdem später blockieren, wenn Rollen, Mandanten, Integrationen oder Datenmengen wachsen.
Wichtige Audit-Fragen sind:
- Ist die Anwendung sinnvoll in Frontend, Backend, Daten und Infrastruktur getrennt?
- Gibt es klare Grenzen zwischen Geschäftslogik und Darstellung?
- Sind Schnittstellen dokumentiert und versionierbar?
- Können neue Funktionen ohne große Nebenwirkungen ergänzt werden?
- Ist das System auf mehrere Nutzergruppen, Mandanten oder Rollen vorbereitet?
- Gibt es Bereiche, die bei jedem Release besonders riskant sind?
- Passt die Architektur noch zum heutigen Geschäftsmodell?
Gerade bei Web-App-Entwicklung ist Architektur mehr als Framework-Auswahl. Entscheidend ist, wie Daten, Rechte, Prozesse und Betrieb zusammenspielen.
Security-Audit: Die wichtigsten Risiken
Ein Software-Audit ersetzt keinen vollständigen Penetrationstest, kann aber viele Sicherheitsrisiken früh sichtbar machen. Besonders wichtig sind:
- unsichere Authentifizierung oder Sessions
- fehlende serverseitige Rechteprüfung
- sensible Daten in Logs oder Fehlermeldungen
- unsichere Datei-Uploads
- veraltete Pakete mit bekannten Schwachstellen
- API-Endpunkte ohne ausreichende Autorisierung
- unsichere Secrets oder API-Keys im Repository
- fehlende Rate Limits
- fehlendes Backup- und Recovery-Konzept
Bei Portalen, internen Tools und SaaS-Produkten reicht es nicht, nur den Login zu prüfen. Entscheidend ist, ob jeder Nutzer nur die Daten sehen und verändern kann, die wirklich zu seiner Rolle gehören.
Betrieb und Monitoring prüfen
Viele Risiken zeigen sich erst nach dem Launch. Deshalb gehört Betrieb in ein technisches Audit. Eine Anwendung kann funktional gut wirken und trotzdem unsicher betrieben werden.
Geprüft werden sollte:
- Wie wird deployed?
- Gibt es getrennte Umgebungen für Entwicklung, Staging und Produktion?
- Gibt es automatisierte Builds?
- Werden Fehler erfasst?
- Gibt es Uptime- und Performance-Monitoring?
- Sind Backups vorhanden und getestet?
- Gibt es eine Rollback-Strategie?
- Wer reagiert auf kritische Fehler?
Wenn diese Punkte fehlen, ist das kein Detail. Ohne Betriebskonzept wird jede Weiterentwicklung riskanter. Mehr dazu passt auch zum Thema Software-Wartung.
Was kostet ein Software-Audit?
Die Kosten hängen von Größe, Technologie, Dokumentation, Zugriffen und gewünschter Tiefe ab. Als Orientierung:
| Audit-Typ | Typischer Umfang | Realistischer Korridor |
|---|---|---|
| Quick Check | Repository, Setup, grobe Risiken, Kurzbericht | 3.000 bis 8.000 EUR |
| Technischer Audit | Code, Architektur, Dependencies, Tests, Betrieb, Roadmap | 8.000 bis 20.000 EUR |
| Security- und Architektur-Audit | Rechte, APIs, Infrastruktur, Datenmodell, Risikoanalyse | 15.000 bis 40.000 EUR |
| Due Diligence Audit | technische Bewertung vor Investition, Kauf oder Übernahme | individuell, häufig ab 20.000 EUR |
Ein günstiger Audit ist hilfreich, wenn es um eine erste Einschätzung geht. Für geschäftskritische Entscheidungen sollte der Audit tief genug sein, um Risiken belastbar zu bewerten.
Ablauf eines Software-Audits
Ein strukturierter Ablauf vermeidet oberflächliche Tool-Reports. Typisch ist:
- Ziel und Entscheidungsfrage klären
- Zugriff auf Repository, Dokumentation und Infrastruktur vorbereiten
- lokales Setup oder Staging-System prüfen
- Architektur und Datenmodell analysieren
- kritische Flows im Code nachvollziehen
- Dependencies und Sicherheitsrisiken prüfen
- Tests, CI/CD und Betrieb bewerten
- Interviews mit Produkt- oder Entwicklungsteam führen
- Risiken priorisieren
- Roadmap mit Aufwand und Reihenfolge erstellen
Der wichtigste Punkt ist die Entscheidungsfrage. Ein Audit für eine Übernahme ist anders als ein Audit für eine Modernisierung oder ein Audit vor einer neuen Feature-Roadmap.
Welche Ergebnisse sollte ein Audit liefern?
Ein gutes Ergebnis ist verständlich für Technik und Geschäftsführung. Es sollte nicht nur sagen, was falsch ist, sondern was als Nächstes sinnvoll ist.
Sinnvolle Deliverables sind:
- Management Summary
- technische Risikomatrix
- priorisierte Maßnahmenliste
- Architektur- und Code-Befunde
- Security- und Datenschutz-Hinweise
- Einschätzung zu Wartbarkeit und Weiterentwicklung
- Quick Wins
- mittelfristige Modernisierungs-Roadmap
- Empfehlung: weiterentwickeln, refactoren, modernisieren oder ersetzen
Wichtig ist eine klare Priorisierung. Nicht jedes Problem ist dringend. Ein Audit muss unterscheiden zwischen "kritisch", "wichtig", "später" und "bewusst akzeptierbar".
Audit vs. Relaunch vs. Modernisierung
Ein Audit ist keine Modernisierung. Es ist die Grundlage für eine Entscheidung. Danach gibt es meist drei Wege:
| Ergebnis | Sinnvolle nächste Schritte |
|---|---|
| System ist stabil | Wartung, Tests ergänzen, kleine Verbesserungen |
| System hat technische Schulden | Roadmap für Refactoring, Dokumentation und bessere Tests |
| System blockiert Wachstum | schrittweise Modernisierung, neue Architektur, Migration |
| System ist hohes Risiko | Ersatzstrategie oder kontrollierter Neubau prüfen |
Gerade bei Legacy-Software ist ein Audit der bessere erste Schritt als sofortiger Neubau. Oft kann man Teile stabilisieren, bevor man entscheidet, was ersetzt wird.
Checkliste vor dem Audit
Vor dem Start sollten Unternehmen vorbereiten:
- Zugriff auf Repository und relevante Branches
- technische Dokumentation, falls vorhanden
- Informationen zu Hosting und Deployment
- Liste wichtiger Nutzerflows
- bekannte Bugs und technische Schmerzen
- Architekturdiagramme oder Systemübersichten
- Zugang zu Staging oder Testumgebung
- Informationen zu Datenbank, APIs und Integrationen
- Kontaktperson für fachliche Fragen
- Ziel des Audits: Entscheidung, Übernahme, Modernisierung oder Sicherheit
Je besser diese Informationen vorliegen, desto weniger Zeit geht in Grundlagen verloren und desto mehr Audit-Budget fließt in echte Bewertung.
Wann reicht ein automatisierter Scan nicht aus?
Automatisierte Tools sind hilfreich. Sie finden bekannte Schwachstellen, veraltete Pakete, Linting-Probleme oder einfache Security-Hinweise. Sie verstehen aber nicht, ob eine Geschäftsregel korrekt ist, ob ein Rollenmodell fachlich passt oder ob eine Architektur zur Roadmap passt.
Ein Tool kann melden, dass eine Dependency veraltet ist. Es kann aber nicht zuverlässig entscheiden, ob ein Modul für den nächsten Produktausbau entkoppelt werden sollte. Dafür braucht es technisches Verständnis, Produktkontext und Erfahrung mit Betrieb.
Fazit
Ein Software-Audit ist besonders wertvoll, wenn ein Unternehmen vor einer technischen Entscheidung steht: weiterbauen, modernisieren, übernehmen, investieren oder ersetzen. Es schafft Transparenz über Risiken, Kosten und sinnvolle Reihenfolge.
Der beste Audit endet nicht mit Kritik, sondern mit einer Roadmap. Dann wird aus Unsicherheit ein Plan: Was muss sofort passieren, was verbessert die Wartbarkeit und welche Schritte machen das Produkt langfristig stabiler?
