Was ist statische Analyse?

Was ist statische Analyse?

Statische Analyse ist die automatisierte Analyse von Quellcode, ohne dass die Anwendung ausgeführt wird.

Wenn die Analyse während der Programmausführung durchgeführt wird, spricht man von einer dynamischen Analyse.

Die statische Analyse wird häufig zur Erkennung verwendet:

• Sicherheitsschwachstellen.
• Leistungsprobleme.
• Nichteinhaltung von Normen.
• Verwendung von veralteten Programmierkonstrukten.

Wie funktioniert ein Werkzeug zur statischen Analyse?

Das Grundkonzept, das allen Werkzeugen für die statische Analyse gemeinsam ist, besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, mit denen eine Art von Warnung oder Information verbunden ist.

Dies könnte so einfach sein wie "JUnit 5-Testklassen müssen nicht 'public' sein". Oder etwas Komplexes wie "Untrusted String input being used in an SQL execution statement".

Statische Analyse-Tools unterscheiden sich darin, wie sie diese Funktionalität implementieren.

• Quellcode-Parsing-Technologie, um einen Abstract Syntax Tree (AST) zu erstellen,
• Text Regular Expression Matching,
• eine Kombination aus den oben genannten Möglichkeiten.

Der Abgleich mit regulären Ausdrücken auf Text ist sehr flexibel, es ist einfach, Regeln für den Abgleich zu schreiben, aber es kann oft zu einer Menge falsch positiver Ergebnisse führen und die Abgleichsregeln kennen den umgebenden Code-Kontext nicht.

Der AST-Abgleich behandelt den Quellcode als Programmcode und nicht nur als Dateien, die mit Text gefüllt sind. Dies ermöglicht einen spezifischeren, kontextbezogenen Abgleich und kann die Anzahl der falsch-positiven Meldungen für den Code reduzieren.

Statische Analyse in der kontinuierlichen Integration

Die statische Analyse wird häufig während des Continous Integration (CI)-Prozesses durchgeführt, um einen Bericht über Compliance-Probleme zu erstellen, der überprüft werden kann, um eine objektive Ansicht der Code-Basis im Laufe der Zeit zu erhalten.

Manche Leute verwenden die statische Analyse als objektives Maß für ihre Codequalität, indem sie das statische Analysewerkzeug so konfigurieren, dass es nur bestimmte Teile des Codes misst und nur über eine Teilmenge von Regeln berichtet.

Die Objektivität ist durch die verwendeten Regeln gegeben, da diese sich in ihrer Bewertung des Codes im Laufe der Zeit nicht verändern. Natürlich ist die Kombination der verwendeten Regeln und ihre Konfiguration eine subjektive Entscheidung und verschiedene Teams entscheiden sich dafür, zu verschiedenen Zeiten unterschiedliche Regeln zu verwenden.

Die Durchführung der statischen Analyse in CI ist nützlich, kann aber das Feedback an den Programmierer verzögern. Programmierer erhalten kein Feedback während des Codierens, sondern erst später, wenn der Code durch das Static Analysis-Tool gelaufen ist. Ein weiterer Nebeneffekt der Ausführung der statischen Analyse in CI ist, dass die Ergebnisse leichter zu ignorieren sind.

Um die Teams dazu zu bringen, den Ergebnissen der statischen Analyse mehr Aufmerksamkeit zu schenken, ist es in der Regel möglich, eine Schwellenwert-Metrik im Build-Prozess zu konfigurieren, um den Build fehlschlagen zu lassen, wenn die Metrik überschritten wird, z.B. wenn eine Anzahl von Regeln ausgelöst wird.

Statische Analyse in der IDE

Um schnelleres Feedback zu erhalten, gibt es viele IDE-Plugins, die die Regeln der statischen Analyse in der IDE bei Bedarf oder in regelmäßigen Abständen ausführen, wenn sich der Code ändert.

Die Regelverletzungen können dann in der IDE gesehen werden, während der Programmierer Code schreibt, und um die Regeln schwerer zu ignorieren, können die Verletzungen oft so konfiguriert werden, dass sie als unterstrichener Code im Editor dargestellt werden.

Ich persönlich finde dies eine nützliche Methode, um mein Coding zu verbessern, besonders wenn ich mit einer neuen Bibliothek arbeite, die vom Static Analysis Tool abgedeckt wird. Allerdings kann es "verrauscht" sein mit falsch-positiven Ergebnissen oder Regeln, an denen man nicht interessiert ist. Aber das wird gelöst, indem man den zusätzlichen Schritt unternimmt, das Static Analysis Tool so zu konfigurieren, dass bestimmte Regeln ignoriert werden.

Code auf der Grundlage von Regeln der statischen Analyse korrigieren

Bei den meisten Werkzeugen für die statische Analyse wird die Behebung der Regel dem Programmierer überlassen, d. h. er muss die Ursache der Regelverletzung verstehen und wissen, wie er sie beheben kann.

Nur sehr wenige statische Analysewerkzeuge bieten auch die Möglichkeit, die Verstöße zu beheben, weil die Behebung so oft kontextabhängig vom Team und der verwendeten Technologie sowie den vereinbarten Codierungsstilen ist.

Standardregeln

Falsches Vertrauen in die Qualität der Regeln kann entstehen, wenn die Werkzeuge für die statische Analyse mit Standardregeln geliefert werden. Es ist verlockend zu glauben, dass sie alle Probleme abdecken, die einem Programmierer begegnen könnten, und alle Umstände, unter denen die Regel gelten sollte. Manchmal können die Umstände, unter denen eine Regel angewendet werden sollte, subtil sein und sind möglicherweise nicht leicht zu erkennen.

Die Hoffnung ist, dass Programmierer durch die Verwendung eines Werkzeugs für die statische Analyse und die genauere Untersuchung der Regeln und Verstöße die Fähigkeit entwickeln, das Problem im Kontext ihrer spezifischen Domäne zu erkennen und zu vermeiden.

Wenn die Domäne kontextabhängige Regeln erfordert, verfügen die Werkzeuge für die statische Analyse möglicherweise nicht über Regeln, die zu Ihrer Domäne oder Bibliothek passen, und außerdem sind die Werkzeuge oft schwierig zu konfigurieren und zu erweitern.

Belästigungen

Keines dieser "Ärgernisse" ist unüberwindbar:

• Falschmeldungen
• fehlende Fixes
• Konfiguration zum Ignorieren von Regeln
• Hinzufügen von kontextspezifischen Regeln

Aber sie werden oft als Ausrede benutzt, um den Einsatz von Statik-Analyse-Tools überhaupt zu vermeiden, was schade ist, weil der Einsatz von Statik-Analyse enorm nützlich sein kann, als eine Möglichkeit,:

• bessere Ansätze für Junior-Entwickler aufzeigen
• schnelles Feedback zu eindeutigen Kodierverstößen erhalten
• unklare Probleme identifizieren, auf die der Programmierer noch nicht gestoßen ist
• bestätigen, dass der Programmierer einen guten Kodierungsansatz gewählt hat (wenn keine Verstöße gemeldet werden)

IDE-basierte Werkzeuge für die statische Analyse

Als einzelner Mitarbeiter an einem Projekt verwende ich gerne Tools für die statische Analyse, die innerhalb der IDE ausgeführt werden, damit ich schnelles Feedback zu meinem Code erhalte.

Dies ergänzt jeden Pull-Request-Überprüfungsprozess und die CI-Integration, die ein Projekt haben kann.

Ich versuche, Tools zu identifizieren, die mir einen Vorteil verschaffen und meinen individuellen Workflow verbessern.

Wenn Werkzeuge in der IDE laufen, kann es verlockend sein, sie als austauschbar zu betrachten, da sie in der Regel die gleiche grundlegende Benutzeroberfläche und den gleichen Konfigurationsansatz haben.

Die Tools können sich in ihrer Funktionalität oder ihren Regelsätzen überschneiden, aber um einen maximalen Vorteil zu erzielen, installiere ich mehrere Tools, um die Stärken der einzelnen Tools zu nutzen.

Die IDE-Tools für die statische Analyse, die ich beim Codieren aktiv verwende, sind unten aufgeführt:

• die eingebauten IntelliJ Inspections - häufige Codierungsmuster
• SpotBugs - häufige Fehler
• SonarLint - häufige Verwendungsmuster
• CheckStyle - allgemeine Stilmuster
• Sensei von Secure Code Warrior - Erstellung eigener Regeln

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

IntelliJ-Prüfungen

Wenn Sie IntelliJ verwenden, dann verwenden Sie bereits deren Inspektionen.

Dies sind Regeln für die statische Analyse, die in der IDE gekennzeichnet werden. Einige von ihnen haben auch QuickFix-Optionen, um den Code neu zu schreiben, um das Problem zu beheben.

Die Regeln können ein- und ausgeschaltet werden, und es kann die Fehlerstufe gewählt werden, mit der sie in der IDE hervorgehoben werden sollen.

Es gibt eine Menge guter IntelliJ Inspektionen. Ich weiß das, weil ich sie durchgelesen habe, während ich dies schrieb. Ich verwende die IntelliJ Inspections als Standard und habe sie nicht konfiguriert, aber um den vollen Nutzen aus den Inspections zu ziehen, sollten Sie sie durchlesen, diejenigen identifizieren, die für Ihren Codierungsstil relevant sind, und die Warnstufe so konfigurieren, dass Sie sie im Code bemerken.

Das Tolle an den IntelliJ Inspections ist, dass sie kostenlos mit der IDE mitgeliefert werden und helfen, das Muskelgedächtnis von:

• Warnungen und Fehler im Quelltext beim Schreiben von Code bemerken
• Bewegen Sie die Maus über markierten Code, um die Regelverletzungen zu erfahren
• mit alt+enter einen QuickFix für das Problem anwenden

SpotBugs

Das SpotBugs IntelliJ-Plugin verwendet die statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

SpotBugs kann in den IntelliJ-Voreinstellungen konfiguriert werden, um Ihren Code zu scannen, die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte "Detector".

Ich neige dazu, SpotBugs zu verwenden, nachdem ich meinen Code geschrieben und überprüft habe, dann führe ich die Funktion 'Analyze Project Files Including Test Sources' aus.

Dies hilft mir, Fehler, toten Code und offensichtliche Optimierungen zu identifizieren. Es zwingt mich auch dazu, einige der markierten Verstöße zu untersuchen, um zu entscheiden, was zu tun ist.

SpotBugs findet zwar Probleme, bietet aber keine QuickFix-Aktionen an, um zu versuchen, die Probleme zu beheben.

SpotBugs ist einfach zu konfigurieren und ich finde, dass es eine nützliche objektive zweite Meinung ist, die ich in meiner IDE zu Rate ziehen kann.

SonarLint

Das SonarLint-Plugin.

SonarLint kann in den IntelliJ-Voreinstellungen konfiguriert werden, um auszuwählen, gegen welche Regeln der Code validiert werden soll.

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

SonarLint bietet keine schnellen Lösungen an, aber die Dokumentation, die mit den Verletzungsberichten verbunden ist, ist normalerweise klar und gut dokumentiert.

Ich habe SonarLint in der Vergangenheit als nützlich empfunden, um mich auf neue Java-Funktionen aufmerksam zu machen, die mir in den neueren Versionen von Java bekannt waren.

CheckStyle

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

Das CheckStyle-Plugin wird zusammen mit 'Sun Checks' und 'Google Checks' ausgeliefert.

Die Definitionen dieser können leicht online gefunden werden.

CheckStyle bringt den größten Mehrwert, wenn ein Projekt die Zeit damit verbracht hat, sein eigenes Ruleset zu erstellen. Dann kann das IDE-Plugin so konfiguriert werden, dass es dieses Ruleset verwendet, und die Programmierer können einen Scan durchführen, bevor sie den Code an CI übergeben.

CheckStyle wird sehr häufig als Build-Failing-Plugin für CI-Prozesse eingesetzt, wenn die Anzahl der CheckStyle-Verstöße einen Schwellenwert überschreitet.

Sensei

Sensei verwendet eine statische Analyse, die auf einem abstrakten Syntaxbaum (AST) basiert, um Code abzugleichen und QuickFixes zu erstellen; dies ermöglicht eine sehr spezifische Identifizierung von Code mit Problemen.

Der AST ermöglicht es QuickFixes, die mit einem Rezept verbunden sind, den umgebenden Code zu verstehen, z. B. wenn eine neue Klasse in den Code eingefügt wird, wird jeder Import für diese Klasse nur einmal in die Quelldatei eingefügt und nicht für jede Ersetzung.

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

Anstatt eine Konfigurationsdatei zu ändern, kann die gesamte Konfiguration in der GUI vorgenommen werden. Bei der Erstellung neuer Rezepte ist in der GUI leicht zu erkennen, zu welchem Code das Rezept passt. Und bei der Definition der QuickFixes kann der Vorher- und Nachher-Zustand des Codes sofort verglichen werden. Das macht es einfacher, sehr kontextbezogene Rezepte zu erstellen, d.h. einzigartig für Teams oder Technologien und sogar für einzelne Programmierer.

Ich verwende Sensei in Kombination mit anderen Tools für die statische Analyse, z. B. finden die meisten Tools für die statische Analyse Probleme, beheben sie aber nicht. Ein häufiger Anwendungsfall für Sensei ist, die passende Suche des anderen Tools in Sensei zu replizieren und mit einem Quick Fix zu erweitern. Dies hat den Vorteil, dass die angewandte benutzerdefinierte Korrektur bereits die Codierungsstandards für Ihr Projekt erfüllt.

Ich ertappe mich regelmäßig dabei, dass ich Sensei Rezepte erstelle, die bereits im IntelliJ Intensions-Set existieren, weil der Intension-Bericht nicht ganz zu dem von mir erstellten Kontext passt oder weil der von IntelliJ bereitgestellte QuickFix nicht zu dem Codemuster passt, das ich verwenden möchte.

Ich ergänze die vorhandenen Werkzeuge, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei kann auch sehr nützlich sein, wenn Sie eine kontextabhängige Variante einer allgemeinen Regel identifizieren, z. B. wenn Sie eine SQL-Bibliothek verwenden, die vom Static Analysis-Tool nicht unterstützt wird, aber die allgemeinen SQL-Regeln in der Static Analysis-Engine trotzdem gelten, dann können Sie mit Sensei bibliotheksspezifische Varianten dieser Regeln erstellen.

Sensei kommt nicht mit vielen generischen Rezepten wie die erwähnten Static Analysis Tools, seine Stärke liegt in der einfachen Erstellung neuer Rezepte, komplett mit QuickFixes, die so konfiguriert sind, dass sie zu Ihrem spezifischen Codierungsstil und Ihren Anwendungsfällen passen.

HINWEIS: Wir arbeiten an einem öffentlichen Repository mit Rezepten, die allgemeine Anwendungsfälle abdecken. Sie können es hier finden.

Zusammenfassung

Ich neige dazu, Tools auszuwählen, die zusammenarbeiten, konfigurierbar sind und sich leicht erweitern lassen, um meinem spezifischen Kontext gerecht zu werden. Ich verwende seit Jahren Werkzeuge zur statischen Analyse in der IDE, um Probleme zu identifizieren und mehr über die verwendeten Programmiersprachen und Bibliotheken zu erfahren.

Ich verwende alle genannten Werkzeuge in Kombination:

• IntelliJ Intentions hilft, häufige Code-Probleme sofort zu erkennen, oft mit zugehörigen QuickFixes.
• SpotBugs findet einfache Bugs, die ich vielleicht übersehen habe, und macht mich auf Leistungsprobleme aufmerksam.
• SonarLint identifiziert Java-Funktionen, die ich nicht kannte, und weist mich auf zusätzliche Möglichkeiten zur Modellierung meines Codes hin.
• CheckStyle hilft mir, einen vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
• Sensei hilft mir bei der Erstellung von QuickFixes, um häufige Szenarien zu ergänzen, die von Werkzeugen für die statische Analyse gefunden werden, und um spezifische Projekt- oder Technologierezepte zu erstellen, die in einem anderen Werkzeug schwer zu konfigurieren sind.

---

Installieren Sie Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) und suchen Sie dann einfach nach "sensei secure code".

Sie finden ein Repository mit Beispielcode und Rezepten für häufige Anwendungsfälle im Secure Code Warrior GitHub-Konto, im Projekt `sensei-blog-examples`.

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

Erfahren Sie mehr über Sensei