Was ist statische Analyse?

Was ist statische Analyse?

Statische Analyse ist die automatisierte Untersuchung von Quellcode, ohne die Anwendung dabei auszuführen.

Wird die Analyse während der Programmausführung durchgeführt, spricht man von dynamischer Analyse.

Statische Analyse wird häufig eingesetzt, um Folgendes zu erkennen:

• Sicherheitslücken.
• Performance-Probleme.
• Nichteinhaltung von Standards.
• Verwendung veralteter Programmierkonstrukte.

Wie funktioniert ein Tool zur statischen Analyse?

Das grundlegende Konzept aller Tools zur statischen Analyse besteht darin, den Quellcode nach spezifischen Codemustern zu durchsuchen, die mit einer Warnung oder Information verknüpft sind.

Dies kann so einfach sein wie „JUnit-5-Testklassen müssen nicht 'public' sein“. Oder etwas Komplexeres, wie das Erkennen von „nicht vertrauenswürdigen String-Eingaben, die in einer SQL-Ausführungsanweisung verwendet werden“.

Tools zur statischen Analyse unterscheiden sich in der Art und Weise, wie sie diese Funktionalität implementieren.

• Quellcode-Parsing-Technologie zur Erstellung eines abstrakten Syntaxbaums (AST),
• textbasierter Abgleich mittels regulärer Ausdrücke,
• eine Kombination aus beidem.

Der Abgleich mittels regulärer Ausdrücke auf Textebene ist sehr flexibel und einfach zu schreiben, führt jedoch oft zu vielen Fehlalarmen, da die Regeln den umgebenden Codekontext nicht berücksichtigen.

Der AST-Abgleich behandelt den Quellcode als Programmcode und nicht nur als Textdateien. Dies ermöglicht einen präziseren, kontextbezogenen Abgleich und kann die Anzahl der gemeldeten Fehlalarme reduzieren.

Statische Analyse in der Continuous Integration

Statische Analyse wird häufig während des Continuous-Integration-Prozesses (CI) durchgeführt, um einen Bericht über Compliance-Probleme zu erstellen, der eine objektive Sicht auf die Codebasis im Zeitverlauf ermöglicht.

Manche nutzen die statische Analyse als objektives Maß für ihre Codequalität, indem sie das Tool so konfigurieren, dass nur bestimmte Teile des Codes gemessen und nur eine Teilmenge der Regeln ausgewertet wird.

Die Objektivität ergibt sich aus den verwendeten Regeln, da diese ihre Bewertung des Codes im Zeitverlauf nicht ändern. Natürlich ist die Kombination der verwendeten Regeln und deren Konfiguration eine subjektive Entscheidung, und verschiedene Teams wählen zu unterschiedlichen Zeiten unterschiedliche Regeln.

Die Durchführung der statischen Analyse in der CI ist nützlich, kann aber das Feedback an den Programmierer verzögern. Programmierer erhalten kein direktes Feedback während des Codierens, sondern erst später, wenn der Code das Analyse-Tool durchläuft. Ein weiterer Nebeneffekt der statischen Analyse in der CI ist, dass die Ergebnisse leichter ignoriert werden können.

Damit Teams den Ergebnissen der statischen Analyse mehr Aufmerksamkeit schenken, lässt sich im Build-Prozess meist ein Schwellenwert konfigurieren, der den Build fehlschlagen lässt, sobald dieser überschritten wird – etwa bei einer bestimmten Anzahl ausgelöster Regelverstöße.

Statische Analyse in der IDE

Für schnelleres Feedback gibt es zahlreiche IDE-Plugins, die die Regeln der statischen Analyse bei Bedarf oder automatisch bei Codeänderungen ausführen.

Die Regelverstöße werden dem Programmierer direkt während des Schreibens in der IDE angezeigt. Um die Regeln noch deutlicher hervorzuheben, lassen sie sich oft so konfigurieren, dass Verstöße im Editor unterstrichen dargestellt werden.

Ich persönlich finde dies sehr hilfreich, um meinen Programmierstil zu verbessern, besonders bei der Arbeit mit neuen Bibliotheken, die vom Tool abgedeckt werden. Auch wenn es durch Fehlalarme oder irrelevante Regeln manchmal etwas „rauschig“ sein kann, lässt sich dies leicht beheben, indem man sich die Zeit nimmt, das Tool entsprechend zu konfigurieren und bestimmte Regeln zu ignorieren.

Code-Korrektur basierend auf statischen Analyseregeln

Bei den meisten Tools für statische Analyse liegt die Korrektur beim Programmierer; er muss den Grund für den Regelverstoß verstehen und wissen, wie er ihn behebt.

Nur wenige Tools bieten automatische Korrekturmöglichkeiten, da die Lösung oft stark vom Kontext des Teams, der verwendeten Technologie und den vereinbarten Coding-Standards abhängt.

Standardregeln

Wenn statische Analysetools mit Standardregeln geliefert werden, kann ein trügerisches Gefühl von Sicherheit entstehen. Man neigt dazu zu glauben, dass damit alle potenziellen Probleme und Anwendungsszenarien abgedeckt sind. Dabei können die Umstände, unter denen eine Regel greifen sollte, oft subtil und schwer zu erkennen sein.

Die Hoffnung ist, dass Programmierer durch den Einsatz solcher Tools und die intensive Auseinandersetzung mit den Regeln und Verstößen die Fähigkeit entwickeln, diese Probleme im Kontext ihres spezifischen Fachbereichs selbst zu erkennen und zu vermeiden.

Wenn der Fachbereich kontextspezifische Regeln erfordert, bieten statische Analysetools oft keine passenden Vorgaben für die verwendete Bibliothek oder Domäne. Zudem sind diese Tools häufig schwer zu konfigurieren und zu erweitern.

Ärgernisse

Keines dieser „Ärgernisse“ ist unüberwindbar:

• Fehlalarme
• fehlende automatische Korrekturen
• Konfigurationsaufwand zum Ignorieren von Regeln
• Hinzufügen kontextspezifischer Regeln

Sie werden jedoch oft als Ausrede genutzt, um den Einsatz statischer Analysetools von vornherein zu vermeiden. Das ist schade, denn statische Analyse ist enorm nützlich, um:

• Junior-Entwicklern bessere Ansätze aufzuzeigen
• schnelles Feedback zu eindeutigen Coding-Verstößen zu erhalten
• versteckte Probleme zu identifizieren, die dem Programmierer bisher nicht begegnet sind
• zu bestätigen, dass der Programmierer einen guten Coding-Stil verfolgt (wenn keine Verstöße gemeldet werden)

IDE-basierte Tools für statische Analyse

Als einzelner Mitwirkender an einem Projekt nutze ich gerne Tools für statische Analyse, die direkt in der IDE laufen, um schnelles Feedback zu meinem Code zu erhalten.

Dies ergänzt jeden Pull-Request-Review-Prozess und die CI-Integration, die ein Projekt möglicherweise bereits nutzt.

Ich versuche, Tools zu finden, die mir einen Vorsprung verschaffen und meinen individuellen Arbeitsablauf verbessern.

Wenn Tools in der IDE laufen, kann man sie leicht für austauschbar halten, da sie meist dieselbe grundlegende Benutzeroberfläche und Konfigurationslogik verwenden.

Die Tools haben zwar teilweise überschneidende Funktionen oder Regelsätze, aber um den größtmöglichen Nutzen zu erzielen, installiere ich mehrere, um ihre jeweiligen Stärken gezielt einzusetzen.

Die statischen Analyse-Tools für die IDE, die ich beim Programmieren aktiv nutze, sind hier aufgelistet:

• die integrierten IntelliJ-Inspections – für allgemeine Codierungsmuster
• SpotBugs – für häufige Fehler
• SonarLint – für gängige Nutzungsmuster
• CheckStyle – für allgemeine Stilvorgaben
• Sensei von Secure Code Warrior – für die Erstellung eigener Regeln

Ich verwende sie alle, weil sie gut zusammenarbeiten und sich gegenseitig ergänzen.

IntelliJ-Inspections

Wenn Sie IntelliJ nutzen, verwenden Sie bereits deren Inspections.

Dies sind Regeln zur statischen Analyse, die direkt in der IDE markiert werden. Einige bieten zudem QuickFix-Optionen an, um den Code automatisch zu korrigieren.

Die Regeln lassen sich ein- und ausschalten, und man kann den Fehlergrad festlegen, mit dem sie in der IDE hervorgehoben werden sollen.

Es gibt viele nützliche IntelliJ-Inspections. Das weiß ich, weil ich sie beim Schreiben dieses Textes durchgegangen bin. Ich verwende die IntelliJ-Inspections in der Standardeinstellung und habe sie nicht weiter konfiguriert. Um jedoch den vollen Nutzen daraus zu ziehen, sollten Sie sie durchsehen, die für Ihren Programmierstil relevanten auswählen und die Warnstufe so anpassen, dass sie Ihnen im Code auch wirklich auffallen.

Das Großartige an den IntelliJ-Inspections ist, dass sie kostenlos in der IDE enthalten sind und dabei helfen, folgende Routine zu entwickeln:

• Warnungen und Fehler im Quellcode direkt beim Schreiben bemerken
• mit der Maus über markierten Code fahren, um die Regelverstöße zu verstehen
• Alt+Enter nutzen, um einen QuickFix für das Problem anzuwenden

SpotBugs

Das SpotBugs-IntelliJ-Plugin nutzt statische Analyse, um Sie auf Fehler in Ihrem Code hinzuweisen.

SpotBugs kann über die IntelliJ-Einstellungen konfiguriert werden, um Ihren Code zu scannen; die tatsächlich verwendeten Regeln finden Sie im Reiter „Detector“.

Ich verwende SpotBugs meist, nachdem ich meinen Code geschrieben und überprüft habe, und führe dann die Funktion „Analyze Project Files Including Test Sources“ aus.

Das hilft mir dabei, Fehler, toten Code und offensichtliche Optimierungsmöglichkeiten zu finden. Zudem zwingt es mich dazu, mich mit einigen der markierten Verstöße auseinanderzusetzen, um zu entscheiden, wie ich weiter vorgehe.

SpotBugs findet zwar Probleme, bietet aber keine QuickFix-Aktionen zur automatischen Behebung an.

SpotBugs ist einfach zu konfigurieren und ich empfinde es als nützliche, objektive zweite Meinung, die ich in meiner IDE hinzuziehen kann.

SonarLint

Das SonarLint-Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um festzulegen, anhand welcher Regeln der Code validiert werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme für den Code an, den Sie gerade bearbeiten.

SonarLint bietet zwar keine Schnellkorrekturen (Quick Fixes), aber die Dokumentation zu den gemeldeten Verstößen ist in der Regel klar und gut verständlich.

Ich fand SonarLint in der Vergangenheit hilfreich, um mich auf neue Java-Funktionen aufmerksam zu machen, die mir in den neueren Java-Versionen noch nicht bekannt waren.

CheckStyle

Das CheckStyle-Plugin bietet eine Mischung aus Formatierungs- und Code-Qualitätsregeln.

Das CheckStyle-Plugin wird mit den „Sun Checks“ und „Google Checks“ ausgeliefert.

Die Definitionen dazu sind leicht online zu finden.

CheckStyle entfaltet seinen größten Nutzen, wenn ein Projekt Zeit in die Erstellung eines eigenen Regelwerks investiert hat. Das IDE-Plugin kann dann so konfiguriert werden, dass es dieses Regelwerk verwendet, und Entwickler können einen Scan durchführen, bevor sie den Code in die CI einchecken.

CheckStyle wird sehr häufig als Plugin verwendet, das den Build-Prozess in der CI fehlschlagen lässt, wenn die Anzahl der CheckStyle-Verstöße einen bestimmten Schwellenwert überschreitet.

Sensei

Sensei nutzt eine statische Analyse auf Basis eines abstrakten Syntaxbaums (AST), um Code abzugleichen und QuickFixes zu erstellen. Dies ermöglicht eine sehr präzise Identifizierung von fehlerhaftem Code.

Der AST ermöglicht es QuickFixes, die mit einem Rezept verknüpft sind, den umgebenden Code zu verstehen. Wenn beispielsweise eine neue Klasse in den Code eingefügt wird, wird der Import für diese Klasse nur einmal in die Quelldatei eingefügt und nicht bei jeder Ersetzung.

Sensei wurde entwickelt, um die Erstellung benutzerdefinierter Abgleichsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht existieren oder nur schwer zu konfigurieren wären.

Anstatt eine Konfigurationsdatei zu bearbeiten, kann die gesamte Konfiguration über die grafische Benutzeroberfläche erfolgen. Beim Erstellen neuer Rezepte zeigt die GUI deutlich, welcher Code durch das Rezept abgedeckt wird. Bei der Definition von QuickFixes lässt sich der Zustand des Codes vor und nach der Anwendung sofort vergleichen. Dies erleichtert die Erstellung hochgradig kontextbezogener Rezepte, die speziell auf Teams, Technologien oder sogar einzelne Entwickler zugeschnitten sind.

Ich verwende Sensei in Kombination mit anderen Tools zur statischen Analyse. Die meisten dieser Tools finden zwar Probleme, beheben sie aber nicht. Ein häufiger Anwendungsfall für Sensei ist es, die Suchmuster anderer Tools in Sensei zu replizieren und sie um einen QuickFix zu erweitern. Dies hat den Vorteil, dass die angewendete benutzerdefinierte Korrektur bereits den Codierungsstandards Ihres Projekts entspricht.

Hin und wieder ertappe ich mich dabei, Sensei-Rezepte zu erstellen, die bereits im IntelliJ-Intensions-Set enthalten sind. Das liegt daran, dass die Intension-Meldung nicht ganz zu dem von mir erstellten Kontext passt oder der von IntelliJ bereitgestellte QuickFix nicht dem Codemuster entspricht, das ich verwenden möchte.

Ich ergänze bestehende Tools, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei kann auch sehr nützlich sein, wenn Sie eine kontextuelle Variante einer allgemeinen Regel identifizieren. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die vom Tool zur statischen Analyse nicht unterstützt wird, die allgemeinen SQL-Regeln der Analyse-Engine aber dennoch gelten, können Sie mit Sensei bibliotheksspezifische Varianten dieser Regeln erstellen.

Sensei wird nicht mit einer Vielzahl generischer Rezepte geliefert wie die genannten statischen Analysetools. Seine Stärke liegt darin, dass es einfach ist, neue Rezepte zu erstellen, komplett mit QuickFixes, die genau auf Ihren Programmierstil und Ihre Anwendungsfälle zugeschnitten sind.

HINWEIS: Wir arbeiten an einem öffentlichen Repository mit Rezepten für allgemeine Anwendungsfälle, das Sie hier finden.

Zusammenfassung

Ich wähle bevorzugt Tools, die gut zusammenarbeiten, konfigurierbar sind und sich leicht an meinen spezifischen Kontext anpassen lassen. Seit Jahren nutze ich statische Analysetools in der IDE, um Probleme zu erkennen und mehr über die von mir verwendeten Programmiersprachen und Bibliotheken zu erfahren.

Ich verwende alle genannten Tools in Kombination:

• IntelliJ Intentions erkennt gängige Codeprobleme direkt nach der Installation, oft mit passenden QuickFixes.
• SpotBugs findet einfache Fehler, die ich übersehen haben könnte, und weist mich auf Performance-Probleme hin.
• SonarLint zeigt mir Java-Funktionen auf, die ich noch nicht kannte, und schlägt alternative Möglichkeiten zur Modellierung meines Codes vor.
• CheckStyle hilft mir, einen vereinbarten Programmierstil einzuhalten, der auch während der CI durchgesetzt wird.
• Sensei unterstützt mich dabei, QuickFixes zu erstellen, um häufige Szenarien aus statischen Analysetools zu ergänzen und projektspezifische Rezepte zu entwickeln, die in anderen Tools nur schwer konfigurierbar sind.

---

Installieren Sie Sensei direkt in IntelliJ über „Einstellungen \ Plugins“ (Mac) oder „Einstellungen \ Plugins“ (Windows) und suchen Sie einfach nach „sensei secure code“.

Ein Repository mit Beispielcode und Rezepten für gängige Anwendungsfälle finden Sie im GitHub-Account von Secure Code Warrior im Projekt `sensei-blog-examples`.

https://github.com/securecodewarrior/sensei-blog-examples

Erfahren Sie mehr über Sensei