Was ein Codebase-Health-Audit wirklich untersucht

Jedes System häuft Schulden an. Das ist kein moralisches Versagen — es ist eine natürliche Konsequenz aus der Softwareentwicklung unter realen Bedingungen. Deadlines rücken näher. Anforderungen ändern sich. Der Entwickler, der die Datenbank entworfen hat, ist vor zwei Jahren gegangen. Was bleibt, ist ein System, das meistens funktioniert, aber niemand kann mit Sicherheit sagen, wo die Risiken liegen.

Ein Codebase-Health-Audit ist das Gegenmittel für diese Ungewissheit. Es handelt sich um eine systematische, evidenzbasierte Untersuchung der Architektur, Sicherheitslage, Abhängigkeitskette und betrieblichen Merkmale Ihres Systems. Das Ergebnis ist kein generischer Bericht — es ist eine priorisierte Sanierungs-Roadmap, die Ihnen sagt, was Sie zuerst beheben müssen und warum.

Was wir untersuchen

1. Architektur und Komplexität

Die erste Frage: Wie ist dieses System strukturiert und wie viel Widerstand wird es gegen Änderungen leisten?

Wir messen:

• Zyklomatische Komplexität — wie viele unabhängige Pfade durch jede Funktion existieren. Funktionen mit einer Komplexität von über 15 sind schwer zu testen, schwer zu ändern und enthalten überproportional häufig Bugs.
• Modulkopplung — wie eng verschiedene Teile des Systems voneinander abhängen. Hohe Kopplung bedeutet, dass sich Änderungen unvorhersehbar auswirken.
• Toter Code — Funktionen, Klassen und Dateien, die existieren, aber nie aufgerufen werden. Toter Code ist nicht harmlos — er überfrachtet Suchergebnisse, verwirrt neue Entwickler und wird gelegentlich versehentlich reaktiviert.
• Abhängigkeitstiefe — wie viele Ebenen tief ein Funktionsaufruf geht, bevor er die Datenbank oder einen externen Dienst erreicht. Tiefe Call-Stacks sind fragil und schwer zu debuggen.

Eingesetzte Tools: PHPStan, ESLint mit Komplexitätsregeln, SonarQube, maßgeschneiderte statische Analyse-Skripte.

2. Testabdeckung und -qualität

Die Testabdeckung ist eine der am meisten missverstandenen Metriken in der Softwareentwicklung. 80 % Abdeckung bedeuten nichts, wenn die Tests nicht die wichtigen Pfade abdecken.

Wir betrachten:

• Abdeckungsgrad auf geschäftskritischen Pfaden — dem Code, der Geld, Authentifizierung, Datenmutation und externe Integrationen verarbeitet.
• Testqualität — überprüfen die Tests tatsächlich aussagekräftige Ergebnisse oder stellen sie nur sicher, dass Funktionen keine Ausnahmen (Exceptions) werfen?
• Testinfrastruktur — können Sie die Test-Suite lokal in unter 5 Minuten ausführen? Wenn nicht, werden Entwickler sie nicht ausführen, und sie verliert ihren Nutzen.
• Fehlende Testkategorien — Integrationstests, End-to-End-Tests, Lasttests. Unit-Tests allein fangen nicht die Bugs ab, die die Produktion zum Absturz bringen.

3. Abhängigkeitskette

Jede Bibliothek von Drittanbietern, die Ihre Anwendung verwendet, ist Code, den Sie nicht geschrieben haben, nicht kontrollieren und wahrscheinlich nicht überwachen.

Wir prüfen:

• Bekannte CVEs — unter Verwendung von Tools wie npm audit, composer audit, pip-audit oder Snyk, um jede Abhängigkeit mit der National Vulnerability Database abzugleichen.
• End-of-life-Abhängigkeiten — Bibliotheken, die nicht mehr gewartet werden. Keine neuen Releases bedeutet keine Sicherheitspatches.
• Phantom-Abhängigkeiten — Bibliotheken, die installiert, aber nie importiert werden. Sie vergrößern die Angriffsfläche, ohne einen Mehrwert zu bieten.
• Lizenzkonformität — GPL-, AGPL- und SSPL-Abhängigkeiten können rechtliche Auswirkungen auf kommerzielle Software haben. Die meisten Teams überprüfen das nicht.

4. Sicherheitslage

Hier kommt mein Hintergrund im IT-Audit bei EY direkt zum Tragen. Ich weiß, worauf Compliance-Auditoren achten, weil ich drei Jahre lang einer war.

Wir überprüfen:

• OWASP Top 10 — SQL-Injection, XSS, fehlerhafte Authentifizierung, unsichere Deserialisierung und die anderen sieben Schwachstellen, die den Großteil der Exploits in der realen Welt ausmachen.
• Secrets-Management — sind Anmeldeinformationen fest im Code hinterlegt (hardcoded)? In Git committet? In Umgebungsvariablen ohne Rotation gespeichert? Für Entwickler zugänglich, die sie nicht benötigen?
• Authentifizierung und Sitzungsmanagement — Token-Speicherung, Ablauf von Sitzungen, Passwort-Hashing-Algorithmen, MFA-Unterstützung.
• Sicherheits-Header — CSP, HSTS, X-Frame-Options, Referrer-Policy. Fehlende Header sind in den meisten Anwendungen der Sicherheits-Fix mit dem geringsten Aufwand und der höchsten Wirkung.
• Fehlerbehandlung in der Produktion — Stack-Traces, ausführliche Fehlermeldungen und Debugging-Endpunkte, die für das öffentliche Internet zugänglich sind.

5. Infrastruktur und Deployment

Wie der Code vom Rechner eines Entwicklers in die Produktion gelangt, ist genauso wichtig wie der Code selbst.

Wir prüfen:

• CI/CD-Pipeline — existiert sie? Führt sie Tests aus? Erzwingt sie Linting? Kann ein einzelner Entwickler im Alleingang in die Produktion deployen?
• Umgebungsparität — verwenden Staging und Produktion dieselbe Datenbankversion, dieselbe Laufzeitumgebung, dieselbe Konfiguration? Abweichungen hier verursachen Bugs, die nur in der Produktion auftreten.
• Backup und Wiederherstellung — wann hat zuletzt jemand die Wiederherstellung einer Datenbank getestet? Nicht "Existieren Backups?", sondern "Können Sie tatsächlich aus ihnen wiederherstellen?"
• Monitoring und Alerting — wenn die Anwendung am Samstag um 3 Uhr morgens einen Fehler wirft, weiß das jemand? Wie lange dauert es, bis es bemerkt wird?

Wie das Ergebnis aussieht

Das Endprodukt ist kein 40-seitiges PDF, das niemand liest. Es ist eine strukturierte Sanierungs-Roadmap:

Jeder Befund wird mit Beweisen, einer Risikobewertung und einer konkreten Lösung mit Aufwandsschätzung belegt. Die Executive Summary umfasst eine Seite — entworfen für den CTO oder VP Engineering, um sie in fünf Minuten zu lesen und eine Entscheidung zu treffen.

Wann Sie ein Audit benötigen

• Vor einem Compliance-Audit. SOC 2, ISO 27001, PCI DSS — alle erfordern dokumentierte Beweise für Sicherheitskontrollen. Ein Audit vor dem offiziellen Audit gibt Ihnen Zeit, die Dinge zu beheben, die sonst gefunden würden.
• Nach der Übernahme eines Unternehmens. M&A Due Diligence für Technologieunternehmen sollte eine Codebase-Bewertung umfassen. Die technischen Schulden des Systems sind ein Posten in der Bilanz, ob Sie sie messen oder nicht.
• Wenn ein wichtiger Entwickler geht. Wenn die Person, die "das System versteht", weg ist, brauchen Sie jemanden, der dokumentiert, was tatsächlich läuft, bevor es zu einer Blackbox wird.
• Vor der Skalierung. Wenn Sie im Begriff sind, Ihre Nutzerbasis zu verdoppeln, die Hochsaison erreichen oder in neue Märkte expandieren, müssen Sie wissen, was unter Last brechen wird.

Wenn Ihr System in den letzten 12 Monaten — oder überhaupt jemals — kein formelles Audit hatte, ist ein System-Audit unser Startpunkt. 30 Minuten Gespräch, kein Pitch-Deck, nur eine ehrliche Einschätzung dessen, was Sie am Laufen haben und was eine Behebung mit sich bringen würde.