Was ist statische Analyse?

Was ist statische Analyse?

Statische Analyse ist die automatisierte Analyse des Quellcodes, ohne die Anwendung auszuführen.

Wenn die Analyse während der Programmausführung durchgeführt wird, wird sie als dynamische Analyse bezeichnet.

Die statische Analyse wird häufig verwendet, um Folgendes zu erkennen:

• Sicherheitslücken.
• Leistungsprobleme.
• Nichteinhaltung von Standards.
• Verwendung von veralteten Programmierkonstrukten.

Wie funktioniert ein Tool zur statischen Analyse?

Das grundlegende Konzept, das allen statischen Analysetools gemeinsam ist, besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, denen eine Warnung oder Information zugeordnet ist.

Dies könnte so einfach sein wie „JUnit 5-Testklassen müssen nicht 'öffentlich' sein“. Oder etwas, das komplex zu identifizieren ist, wie „Nicht vertrauenswürdige Zeichenketteneingabe, die in einer SQL-Ausführungsanweisung verwendet wird“.

Statische Analysetools unterscheiden sich in der Art und Weise, wie sie diese Funktionalität implementieren.

• Quellcode-Parsing-Technologie zur Erstellung eines abstrakten Syntaxbaums (AST),
• Textabgleich mit regulären Ausdrücken,
• eine Kombination der oben genannten.

Der Abgleich regulärer Ausdrücke auf Text ist sehr flexibel, es lassen sich leicht Regeln zum Abgleichen schreiben, kann aber oft zu vielen falsch positiven Ergebnissen führen, und die Abgleichsregeln kennen den umgebenden Codekontext nicht.

Der AST-Matching behandelt den Quellcode als Programmcode und nicht nur als mit Text gefüllte Dateien. Dies ermöglicht einen spezifischeren, kontextbezogenen Abgleich und kann die Anzahl der falsch positiven Ergebnisse reduzieren, die gegen den Code gemeldet werden.

Statische Analyse in kontinuierlicher Integration

Statische Analysen werden häufig während des Continuous Integration (CI) -Prozesses durchgeführt, um einen Bericht über Compliance-Probleme zu erstellen, der überprüft werden kann, um einen objektiven Überblick über die Codebasis im Laufe der Zeit zu erhalten.

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

Die Objektivität wird durch die verwendeten Regeln gewährleistet, da sich diese in ihrer Bewertung des Codes im Laufe der Zeit nicht ändern. Es liegt auf der Hand, dass die Kombination der verwendeten Regeln und ihrer Konfiguration eine subjektive Entscheidung ist, und verschiedene Teams entscheiden sich dafür, zu unterschiedlichen Zeiten unterschiedliche Regeln zu verwenden.

Es ist nützlich, die statische Analyse in CI durchführen zu lassen, kann aber die Rückmeldung an den Programmierer verzögern. Programmierer erhalten beim Programmieren kein Feedback, sondern später, wenn der Code das Statische Analysetool durchläuft. Ein weiterer Nebeneffekt der Ausführung der statischen Analyse in CI ist, dass die Ergebnisse leichter zu ignorieren sind.

Um Teams dazu zu bringen, den Ergebnissen der statischen Analyse mehr Aufmerksamkeit zu schenken, ist es in der Regel möglich, im Build-Prozess eine Schwellenwertmetrik zu konfigurieren, sodass der Build fehlschlägt, wenn die Metrik überschritten wird, z. B. eine Reihe von ausgelösten Regeln.

Statische Analyse in der IDE

Um schneller 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 Regelverstöße können dann in der IDE angezeigt werden, während der Programmierer Code schreibt. Um das Ignorieren der Regeln zu erschweren, können die Verstöße oft so konfiguriert werden, dass sie im Editor als unterstrichener Code dargestellt werden.

Ich persönlich finde dies eine nützliche Methode, um meine Codierung zu verbessern, insbesondere wenn ich mit einer neuen Bibliothek arbeite, die vom Static Analysis Tool abgedeckt wird. Allerdings kann es bei falsch positiven Ergebnissen oder Regeln, an denen Sie nicht interessiert sind, „laut“ sein. Dies wird jedoch gelöst, indem Sie den zusätzlichen Schritt unternehmen, um das Tool für die statische Analyse so zu konfigurieren, dass bestimmte Regeln ignoriert werden.

Korrigieren von Code auf der Grundlage statischer Analyseregeln

Bei den meisten Tools für die statische Analyse bleibt die Behebung der Regel dem Programmierer überlassen, sodass er die Ursache der Regelverletzung verstehen und wissen muss, wie sie behoben werden kann.

Nur sehr wenige statische Analysetools bieten auch die Möglichkeit, die Verstöße zu beheben, da die Behebung häufig vom Team, der verwendeten Technologie und den vereinbarten Codierungsstilen abhängt.

Standardregeln

Falsches Vertrauen in die Qualität der Regeln kann entstehen, wenn die Tools der statischen Analyse mit Standardregeln ausgestattet sind. Es ist verlockend zu glauben, dass sie alle Probleme abdecken, auf die ein Programmierer stoßen könnte, und alle Umstände, unter denen die Regel gelten sollte. Manchmal sind die Umstände, unter denen eine Regel gelten sollte, subtil und möglicherweise nicht leicht zu erkennen.

Es besteht die Hoffnung, dass Programmierer durch die Verwendung eines Tools zur statischen Analyse und einer genaueren Untersuchung der Regeln und Verstöße die Fähigkeit entwickeln, das Problem im Kontext ihrer spezifischen Domäne zu erkennen und zu vermeiden.

Wenn für die Domain Kontextregeln erforderlich sind, haben die Tools für die statische Analyse möglicherweise keine Regeln, die Ihrer Domain oder Bibliothek entsprechen, und außerdem können die Tools oft schwierig zu konfigurieren und zu erweitern sein.

Ärgernisse

Keines dieser „Ärgernisse“ ist unüberwindbar:

• falsch positive
• Mangel an Korrekturen
• Konfiguration zum Ignorieren von Regeln
• Hinzufügen von kontextspezifischen Regeln

Sie werden jedoch häufig als Ausreden verwendet, um die Verwendung von Tools für statische Analysen von vornherein zu vermeiden, was schade ist, da die Verwendung der statischen Analyse äußerst nützlich sein kann, um:

• bessere Ansätze für Nachwuchsentwickler hervorheben
• erhalten Sie schnelles Feedback zu eindeutigen Codierungsverstößen
• Identifizieren Sie obskure Probleme, auf die der Programmierer noch nie gestoßen ist
• bekräftigen, dass der Programmierer einen guten Codierungsansatz gewählt hat (sofern keine Verstöße gemeldet werden)

IDE-basierte statische Analysetools

Als einzelner Mitwirkender an einem Projekt verwende ich gerne statische Analysetools, die in der IDE ausgeführt werden, sodass ich schnelles Feedback zu meinem Code erhalte.

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

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

Wenn Tools in der IDE ausgeführt werden, kann es verlockend sein, sie synonym zu betrachten, da sie in der Regel dieselbe grundlegende GUI und denselben Konfigurationsansatz verwenden.

Die Tools haben möglicherweise überlappende Funktionen oder Regelsätze, aber um den größtmöglichen Nutzen zu erzielen, installiere ich mehrere Tools, um ihre Stärken zu nutzen.

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

• die eingebauten IntelliJ Inspections — gängige Codierungsmuster
• SpotBugs — häufige Fehler
• SonarLint — allgemeine Nutzungsmuster
• CheckStyle - gängige Stilmuster
• Sensei von Secure Code Warrior — Erstellung benutzerdefinierter Regeln

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

IntelliJ-Inspektionen

Wenn Sie IntelliJ verwenden, verwenden Sie bereits deren Inspektionen.

Dies sind Regeln für statische Analysen, die in der IDE gekennzeichnet sind. Einige von ihnen verfügen auch über QuickFix-Optionen, mit denen der Code neu geschrieben werden kann, um das Problem zu beheben.

Die Regeln können ein- und ausgeschaltet werden, und Sie können die Fehlerstufe auswählen, mit der sie in der IDE hervorgehoben werden.

Es gibt viele gute IntelliJ-Inspektionen. Ich weiß das, weil ich sie durchgelesen habe, während ich das schreibe. Ich verwende die IntelliJ Inspections als Standardwerte 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 in der IDE enthalten sind und dabei helfen, das Muskelgedächtnis aufzubauen von:

• Erkennen von Warnungen und Fehlern in der Quelle, während Sie Code schreiben
• Bewegen Sie den Mauszeiger über den markierten Code, um die Regelverstöße zu erfahren
• Verwenden Sie Alt+Enter, um einen QuickFix für das Problem anzuwenden

Bugs erkennen

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

SpotBugs können in den IntelliJ-Einstellungen so konfiguriert werden, dass Ihr Code gescannt wird. 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 Option „Projektdateien einschließlich Testquellen analysieren“ aus.

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

SpotBugs findet Probleme, bietet aber keine QuickFix-Aktionen an, um zu versuchen, die Probleme zu lösen.

SpotBugs ist einfach zu konfigurieren und ich halte es für eine nützliche objektive zweite Meinung, die ich in meiner IDE einholen kann.

Sonar Lint

Das Sonar Lint Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um auszuwählen, anhand welcher Regeln der Code validiert wird.

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

SonarLint bietet keine schnellen Lösungen, aber die mit den Verstoßberichten verbundene Dokumentation ist in der Regel 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.

Stil überprüfen

Das Stil überprüfen Das Plugin bietet eine Mischung aus Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin wird im Paket mit „Sun Checks“ und „Google Checks“ geliefert.

Die Definitionen dieser können leicht sein online gefunden.

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

CheckStyle wird sehr oft als Build-Failing-Plugin für CI-Prozesse verwendet, 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 einem Rezept zugeordnet sind, den umgebenden Code zu verstehen, z. B. wenn dem Code eine neue Klasse hinzugefügt wird, jeder Import für diese Klasse nur einmal zur Quelldatei hinzugefügt wird und nicht für jeden Ersatz.

Sensei wurde entwickelt, um es einfach zu machen, benutzerdefinierte Abgleichsregeln zu erstellen, die in anderen Tools möglicherweise nicht existieren oder schwer zu konfigurieren wären.

Anstatt eine Konfigurationsdatei zu ändern, kann die gesamte Konfiguration in der GUI durchgeführt werden. Beim Erstellen neuer Rezepte lässt sich anhand der GUI leicht erkennen, zu welchem Code das Rezept passt. Und bei der Definition der QuickFixes kann der Vorher- und Nachher-Status des Codes sofort verglichen werden. Dies macht es einfacher, sehr kontextbezogene Rezepte zu erstellen, d. h. sie sind spezifisch für Teams, Technologien und sogar einzelne Programmierer.

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

In regelmäßigen Abständen erstelle ich Sensei-Rezepte, die bereits im IntelliJ Intensions-Set enthalten sind, weil der Intension-Bericht nicht ganz dem Kontext entspricht, den ich erstellt habe, oder weil der von IntelliJ bereitgestellte QuickFix nicht dem Codemuster entspricht, das ich verwenden möchte.

Ich ergänze die vorhandenen 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, z. B. wenn Sie eine SQL-Bibliothek verwenden, die vom Static Analysis Tool nicht unterstützt wird, die allgemeinen SQL-Regeln in der Static Analysis Engine jedoch weiterhin gelten, dann können Sie mit Sensei bibliotheksspezifische Varianten dieser Regeln erstellen.

Sensei bietet nicht viele generische Rezepte wie die genannten Tools zur statischen Analyse. Seine Stärke besteht darin, das Erstellen neuer Rezepte zu vereinfachen, komplett mit QuickFixes, die so konfiguriert sind, dass sie zu Ihrem spezifischen Codierungsstil und Ihren Anwendungsfällen passen.

HINWEIS: Wir arbeiten an einem öffentlichen Archiv mit Rezepten, um generische Anwendungsfälle abzudecken, und du findest es hier.

Zusammenfassung

Ich neige dazu, Tools auszuwählen, die zusammenarbeiten, konfigurierbar sind und leicht zu erweitern sind, um meinem spezifischen Kontext gerecht zu werden. Ich verwende seit Jahren statische Analysetools in der IDE, um Probleme zu identifizieren und mehr über die von mir verwendeten Programmiersprachen und Bibliotheken zu erfahren.

Ich verwende alle genannten Tools in Kombination:

• IntelliJ Intentions hilft dabei, häufig auftretende Codeprobleme sofort zu erkennen, häufig mit zugehörigen QuickFixes.
• SpotBugs findet einfache Fehler, die ich vielleicht übersehen habe, und warnt mich vor Leistungsproblemen.
• SonarLint identifiziert Java-Funktionen, von denen ich nichts wusste, und fordert mich auf, meinen Code zusätzlich zu modellieren.
• CheckStyle hilft mir dabei, einen vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
• Sensei hilft mir bei der Erstellung von QuickFixes zur Erweiterung gängiger Szenarien, die mit Tools für statische Analysen gefunden werden, und um spezifische Projekt- oder Technologierezepte zu erstellen, die in einem anderen Tool schwer zu konfigurieren sind.

---

Installieren Sie Sensei von IntelliJ aus mit „Preferences\ Plugins“ (Mac) oder „Settings\ Plugins“ (Windows) und suchen Sie dann einfach nach „Sensei Secure Code“.

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

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

Erfahre mehr über Sensei