Static Analysis (SAST)

Tools:

• SonarQube: Der Marktführer. Zeigt bunte Dashboards ("Technical Debt: 5 Tage").
• ESLint: Für JavaScript. Findet Syntaxfehler.
• Bandit (Python) / Gosec (Go): Findet Security-Issues. In GitHub Actions:

- name: Run SonarScanner
  run: sonar-scanner

Wenn der Scanner "Critical Bugs" findet, wird der Pull Request blockiert.

1. Abstract Syntax Tree (AST)

Wie versteht das Tool den Code? Es kompiliert ihn nicht zu Binärcode, sondern zu einem AST (Baumstruktur). if (x > 5) wird zu: IfStatement -> BinaryExpression(x, >, 5). Der Analyzer klettert durch diesen Baum. Regel: "Suche alle BinaryExpression, wo links password steht und rechts ein String ("1234")". Treffer -> "Hardcoded Password".

2. Taint Analysis (Data Flow)

Komplexer. Das Tool verfolgt eine Variable durch 50 Funktionen. "User Input kommt in Funktion A rein (source)." "Wird an Funktion B übergeben." "Landet in SQL Query in Funktion C (sink)." Wurde es zwischendurch sanitisiert (escape())? Nein? -> SQL Injection. Ja? -> False Positive vermeiden. Das ist extrem rechenintensiv.

3. False Positives

Das größte Problem. SAST schreit oft "Fehler!", wo keiner ist. Entwickler ignorieren dann irgendwann alle Warnungen ("Alarm Fatigue"). Lösung:

• Regeln tunen (Strictness runter).
• Baseline setzen ("Alle alten Bugs ignorieren, nur neue anzeigen -> 'Ratchet'").
• Inline Suppression: // nosonar: Sicherheit hier okay, weil...

1. Custom Rule Engines und XPath

Oft reichen Standardregeln nicht aus ("In unserer Firma darf Funktion X nie ohne Logger Y aufgerufen werden"). Moderne SAST-Tools erlauben die Definition eigener Regeln. Da der Code als DOM (Document Object Model)-ähnlicher Baum (AST, Abstract Syntax Tree) vorliegt, nutzt man oft XPath oder spezialisierte Abfragesprachen (wie bei CodeQL), um Muster zu suchen. Beispiel: //MethodInvocation[@Name='execute'][not(preceding-sibling::CheckPermission)]. Dieser Befehl findet alle Ausführungen, vor denen keine Berechtigungsprüfung stattfand. Das macht SAST von einer bloßen Fehler-Suche zu einer mächtigen Waffe für das Einhalten von Firmen-Architektur-Standards.

2. False Negatives: Die unsichtbare Gefahr

Während False Positives (falscher Alarm) nerven, sind False Negatives (übersehene Fehler) tödlich. Kein SAST-Tool findet alles. Warum?

• Indirection: Wenn Code zur Laufzeit dynamisch geladen wird (Reflection in Java, eval() in JS), "sieht" der statische Scanner den Pfad nicht.
• Halting Problem: Es ist mathematisch bewiesen, dass ein Programm nicht alle Eigenschaften eines anderen Programms ohne Ausführung perfekt vorhersagen kann. Man sagt daher: "SAST findet die niedrig hängenden Früchte zuverlässig, aber für komplexe Logik-Lücken braucht man weiterhin manuelle Code Reviews und Dynamic Analysis/DAST an der laufenden Anwendung."

3. Incremental Scanning & IDE Integration

Früher dauerte ein voller Scan eines Millionen-Zeilen-Projekts 10 Stunden. Das ist für moderne Agile Software Development Sprints zu langsam. Moderne Tools nutzen Incremental Analysis: Es wird nur der Teil des AST neu berechnet, der sich seit dem letzten Commit geändert hat. Zusammen mit LSP (Language Server Protocol) Integration wird die statische Analyse zum "Tippassistenten": Der Entwickler bekommt schon während des Schreibens eine rote Unterstreichung mit der Warnung: "Achtung, das ist eine potenzielle SQL Injection!". Das ist die ultimative Form von "Shift Left", da der Fehler nie das Terminal des Entwicklers verlässt.