Statische Codeanalyse: was sie findet, was sie übersieht, welche Werkzeuge passen

Statische Codeanalyse untersucht Quelltext, ohne ihn auszuführen. Sie findet zuverlässig strukturelle Fehler — Typfehler, unerreichbaren Code, unsichere Muster, Duplikate — und findet grundsätzlich nicht, ob die Fachlogik richtig ist. Ihr Wert liegt darin, dass sie die günstigste Prüfschicht überhaupt ist: kein Testlauf, keine Umgebung, Ergebnis in Sekunden.

Was ist statische Codeanalyse?

Ein Werkzeug liest den Quelltext und leitet daraus Aussagen ab, ohne das Programm zu starten. Es baut ein Modell des Codes auf — welche Typen fließen wohin, welche Pfade sind erreichbar, welche Werte können null sein — und meldet Widersprüche.

Der Gegenbegriff ist die dynamische Analyse, die das Programm ausführt und beobachtet: Tests, Profiling, Laufzeitüberwachung. Beide sehen unterschiedliche Dinge. Die statische Analyse sieht alle Pfade, aber nur strukturell. Die dynamische Analyse sieht echtes Verhalten, aber nur auf den Pfaden, die tatsächlich durchlaufen wurden.

Welche Fehler findet statische Analyse — und welche nicht?

Findet zuverlässig	Findet nicht
Typfehler und falsche Signaturen	ob die Fachlogik richtig ist
Nicht behandelte Null-Werte	ob eine Berechtigungsprüfung fehlt, die es fachlich bräuchte
Unerreichbaren und toten Code	Fehler, die erst aus Daten entstehen
Bekannte unsichere Muster (Injection, unsichere Deserialisierung)	Zeitabhängige Fehler und Wettlaufsituationen
Duplikate und übergroße Funktionen	ob eine Architekturentscheidung tragfähig ist

Die rechte Spalte ist der Grund, warum statische Analyse ein Baustein bleibt und kein Ersatz. Sie erklärt auch, warum ein grünes Analyseergebnis für KI-generierten Code wenig Beruhigung bietet: Die typischen Lücken generierten Codes — die fehlende Berechtigungsprüfung, die unbedachte Fachregel — stehen sämtlich rechts.

Welche Werkzeuge passen zu welchem Stack?

Nahezu jeder verbreitete Stack hat einen etablierten Satz freier Werkzeuge; ein Kauf ist selten der Einstieg. Üblich ist eine Kombination aus drei Rollen.

• Typ- und Logikprüfer. Analysiert Datenflüsse und Typen tief. In der PHP-Welt etwa PHPStan, im TypeScript-Umfeld der Compiler selbst mit strengen Einstellungen.
• Regel- und Stilprüfer (Linter). Setzt Konventionen durch und meldet riskante Muster — ESLint für JavaScript und TypeScript, vergleichbare Werkzeuge in anderen Sprachen.
• Sicherheitsprüfer. Spezialisierte Regelwerke für bekannte Schwachstellenmuster, ergänzt um eine Abhängigkeitsprüfung gegen Schwachstellendatenbanken.

Plattformen wie SonarQube bündeln diese Rollen und ergänzen das, was einzelne Werkzeuge nicht liefern: einen Verlauf über die Zeit und eine Schwellenlogik, an der ein Build scheitern kann. Genau dafür wurde der Begriff Quality Gate geprägt — mehr dazu im Beitrag Was ist ein Quality Gate.

Wie führe ich statische Analyse in einem bestehenden Projekt ein?

Mit einer eingefrorenen Ausgangslage — sonst meldet der erste Lauf tausende Befunde und das Werkzeug wird abgeschaltet. Das ist der häufigste Grund, warum Einführungen scheitern.

• Schritt 1: Basislinie erzeugen und einchecken. Alle vorhandenen Befunde werden als bekannt markiert. Das Werkzeug meldet ab jetzt nur Neues.
• Schritt 2: Auf neuen Code scharf stellen. Für geänderte Zeilen gilt die volle Strenge, für den Bestand die Basislinie. Jede Änderung verbessert damit den Stand ein Stück.
• Schritt 3: Strenge stufenweise erhöhen. Analysewerkzeuge haben Stufen. Beginnen Sie niedrig, steigern Sie, wenn die Basislinie schrumpft.
• Schritt 4: In die Pipeline hängen. Erst wenn Schritt 1 bis 3 stehen. Ein Werkzeug, das sofort blockiert, wird umgangen statt genutzt.

Die Basislinie gehört in die Versionsverwaltung. Nur so ist sichtbar, wenn sie wächst — und ein Wachstum der Basislinie ist genau das Signal, das Sie sehen wollen.

Warum ist statische Analyse bei KI-Code besonders lohnend?

Weil sie mit dem Volumen skaliert und der menschliche Review das nicht tut. Wenn eine KI in einer Stunde erzeugt, wofür früher ein Tag nötig war, wächst der Prüfbedarf im selben Maß. Eine Prüfung, die Sekunden kostet und bei jeder Änderung läuft, ist die einzige, die dabei mithält.

Sie greift außerdem genau bei einem der belegten Problemmuster: Duplikaterkennung. Nach GitClear stieg der Anteil kopierten Codes von 9,4 Prozent (2022) auf 15,7 Prozent (erstes Halbjahr 2026). Duplikate sind für ein statisches Werkzeug leicht zu finden und für einen Menschen im Diff praktisch unsichtbar, weil die zweite Kopie in einer anderen Datei steht.

Häufige Fragen zur statischen Codeanalyse

Ersetzt statische Analyse Tests?

Nein, sie prüft eine andere Frage. Die statische Analyse prüft, ob der Code strukturell in Ordnung ist; Tests prüfen, ob er das Richtige tut. Ein Projekt braucht beides.

Was mache ich mit Fehlalarmen?

Gezielt und begründet unterdrücken, an der betroffenen Stelle, mit einem Kommentar, warum. Eine Regel global abzuschalten, weil sie an einer Stelle stört, verliert alle anderen Fundstellen mit.

Wie lange dauert die Einführung?

Die technische Einrichtung inklusive Basislinie ist meist an einem Tag erledigt. Die eigentliche Arbeit ist die Vereinbarung, welche Regeln gelten sollen — dafür sollten Sie ein Team-Gespräch einplanen, keine Konfigurationsdatei.

Lohnt sich das auch für kleine Projekte?

Gerade dort, weil die Einrichtung klein bleibt und die Basislinie kurz ist. Der Aufwand wächst mit der Projektgröße, der Nutzen beginnt sofort.

Ein Analysewerkzeug, das läuft, aber nichts blockiert, ist eine Meinungsäußerung. Code Guardian behandelt die Analyse als Gate: sie gehört zum Ablauf und nicht zu den Dingen, die man auch überspringen kann, wenn es eilig ist.

Quellen

• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (Copy/Paste-Anteil).
• OWASP Top 10:2025 (Muster, die statische Sicherheitsregeln abdecken).

Stand: 27. Juli 2026. Werkzeugnennungen sind Einordnungen nach Rolle im Prüfaufbau, keine Produktempfehlung.