Was ist statische Analyse?

Was ist statische Analyse?

Die statische Analyse ist eine automatische Analyse des Quellcodes, ohne die Anwendung auszuführen.

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

Die statische Analyse wird hauptsächlich zum Erkennen der folgenden Punkte verwendet:

• Sicherheitslücke.
• Leistungsproblem.
• Nicht konform mit den Standards.
• Verwendung einer veralteten Programmierstruktur.

Wie funktioniert ein statisches Analysewerkzeug?

Das grundlegende Konzept, das allen statischen Analysewerkzeugen gemeinsam ist, besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, die relevante Warnungen oder Informationen enthalten.

Dies kann so einfach sein wie „JUnit 5-Testklassen müssen nicht öffentlich sein“ oder so komplex wie „unzuverlässige Zeichenfolgen, die in SQL-Ausführungsbefehlen verwendet werden“.

Statische Analyse-Tools implementieren diese Funktion auf unterschiedliche Weise.

• Technik zum Parsen von Quellcode zur Erstellung abstrakter Syntaxbäume (AST)
• Text-Reguläre-Ausdrücke-Matching,
• Das ist die Kombination.

Reguläre Ausdrücke für Text sind sehr flexibel und lassen sich leicht erstellen, können jedoch häufig zu vielen Fehlalarmen führen, und die Übereinstimmungsregeln ignorieren den Kontext des umgebenden Codes.

AST-Matching behandelt den Quellcode nicht nur als mit Text gefüllte Datei, sondern als Programmcode, wodurch eine genauere und kontextbezogene Übereinstimmung möglich ist und die Anzahl der Fehlalarme in Bezug auf den Code reduziert werden kann.

Statische Analyse bei kontinuierlicher Integration

Statische Analysen werden häufig während des Continuous-Integration-Prozesses (CI) durchgeführt, um Berichte zu Compliance-Problemen zu erstellen. Durch die Überprüfung dieser Berichte kann die Codebasis im Laufe der Zeit objektiv erfasst werden.

Einige Benutzer verwenden statische Analysewerkzeuge als objektives Maß für die Codequalität, indem sie diese so konfigurieren, dass sie nur bestimmte Teile des Codes messen und nur über eine Teilmenge der Regeln berichten.

Da sich die Code-Bewertung auch nach einiger Zeit nicht ändert, ist die Objektivität gemäß den verwendeten Regeln gewährleistet. Die Kombination der verwendeten Regeln und deren Zusammensetzung ist eindeutig eine subjektive Entscheidung, und jedes Team entscheidet sich je nach Zeitpunkt für unterschiedliche Regeln.

Die Durchführung statischer Analysen in CI ist zwar nützlich, kann jedoch zu Verzögerungen beim Feedback an die Programmierer führen. Die Programmierer erhalten kein Feedback während des Codierens, sondern erst später, wenn sie den Code mit statischen Analysewerkzeugen ausführen. Ein weiterer Nachteil der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leicht ignoriert werden können.

Um das Team dazu anzuregen, den Ergebnissen der statischen Analyse mehr Aufmerksamkeit zu schenken, ist es in der Regel möglich, im Build-Prozess Schwellenwertindikatoren zu konfigurieren, die bei Überschreitung (z. B. Anzahl der ausgelösten Regeln) zu einem Fehlschlagen des Builds führen.

Statische Analyse in der IDE

Es gibt viele IDE-Plugins, die statische Analyseregeln in der IDE nach Bedarf oder bei Codeänderungen regelmäßig ausführen, um schneller Feedback zu erhalten.

Dann kann der Programmierer beim Schreiben des Codes in der IDE Regelverstöße erkennen. Um es schwieriger zu machen, die Regeln zu ignorieren, können Verstöße so konfiguriert werden, dass sie im Editor als unterstrichener Code dargestellt werden.

Ich persönlich halte dies für eine nützliche Methode zur Verbesserung der Codierung. Dies gilt insbesondere für die Arbeit mit neuen Bibliotheken, die von statischen Analysewerkzeugen behandelt werden. Es kann zwar zu Fehlalarmen oder uninteressanten Regeln kommen, die zu „starken Störungen“ führen können. Dieses Problem lässt sich jedoch durch einen zusätzlichen Schritt beheben, indem das statische Analysewerkzeug so konfiguriert wird, dass bestimmte Regeln ignoriert werden.

Code-Änderungen basierend auf statischen Analyseregeln

Bei den meisten statischen Analysewerkzeugen obliegt die Änderung der Regeln dem Programmierer, sodass dieser die Ursachen für Regelverstöße und die Methoden zu deren Behebung verstehen muss.

Es gibt nur wenige statische Analysewerkzeuge, die Funktionen zur Korrektur von Verstößen enthalten. Denn Korrekturen werden häufig vom Team, den verwendeten Technologien und dem vereinbarten Codierungsstil bestimmt.

Grundregeln

Wenn statische Analysewerkzeuge mit Standardregeln geliefert werden, kann dies zu einer falschen Sicherheit hinsichtlich der Qualität dieser Regeln führen. Es ist leicht zu glauben, dass sie alle Probleme abdecken, mit denen Programmierer konfrontiert werden können, und alle Situationen, in denen diese Regeln angewendet werden sollten. Manchmal sind die Situationen, in denen Regeln angewendet werden müssen, jedoch subtil und nicht leicht zu erkennen.

Durch die Verwendung statischer Analysewerkzeuge zur genaueren Untersuchung von Regeln und Verstößen können Programmierer Techniken entwickeln, um Probleme im Kontext bestimmter Bereiche zu erkennen und zu verhindern.

Wenn für eine Domäne Kontextregeln erforderlich sind, kann es sein, dass das statische Analyse-Tool keine Regeln enthält, die mit der Domäne oder Bibliothek übereinstimmen, und dass es schwierig ist, das Tool zu konfigurieren und zu erweitern.

성가심

Es gibt nichts, was man nicht überwinden könnte.

• Fehlmeldung
• Mangelnde Korrekturen
• Konfiguration zum Umgehen von Regeln
• Hinzufügen von kontextbezogenen Regeln

Es ist jedoch bedauerlich, dass dies oft als Vorwand dafür dient, statische Analysewerkzeuge gar nicht erst einzusetzen, da diese bei richtiger Anwendung sehr nützlich sein können, wie im Folgenden beschrieben wird.

• Bessere Ansätze für Junior-Entwickler hervorheben
• Schnelles Feedback zu eindeutigen Verstößen gegen die Codierungsregeln
• Der Programmierer identifiziert ein unklares Problem, das er zuvor noch nicht erlebt hat.
• Betonen Sie, dass der Programmierer den richtigen Ansatz für die Codierung gewählt hat (sofern keine Verstöße gemeldet wurden).

IDE-basiertes statisches Analysewerkzeug

Als individueller Mitwirkender an diesem Projekt nutze ich gerne statische Analysewerkzeuge, die innerhalb der IDE ausgeführt werden, da ich so schnell Feedback zum Code erhalten kann.

Dies ergänzt alle Pull-Request-Prüfungsprozesse und CI-Integrationen, die in einem Projekt vorkommen können.

Ich bin auf der Suche nach Tools, mit denen ich mir einen Vorteil verschaffen kann, und versuche, meinen persönlichen Arbeitsablauf zu verbessern.

Wenn das Tool in der IDE ausgeführt wird, möchten Sie möglicherweise zwischen den Tools wechseln, da die Standard-GUI und der Konfigurationsansatz identisch sind.

Die Tools können sich in ihren Funktionen oder Regelwerken überschneiden, aber um ihre Vorteile optimal zu nutzen, werden mehrere Tools installiert.

Die folgenden statischen Analyse-IDE-Tools werden beim Codieren aktiv verwendet.

• Interne IntelliJ-Prüfung – Allgemeine Codierungsmuster
• Spot Bug – Häufige Fehler
• Sonarint – Allgemeine Anwendungsmuster
• Checkstyle – Allgemeine Stilvorlagen
• Secure Code Warrior Sensei Benutzerdefinierte Regeln erstellen

Weil sie gut zusammenpassen und sich gegenseitig ergänzen, verwenden wir sie alle.

IntelliJ-Inspektion

Wenn Sie IntelliJ verwenden, nutzen Sie diese Überprüfung bereits.

Dies sind statische Analyseregeln, die in der IDE mit einem Flag gekennzeichnet sind. Einige davon verfügen auch über eine QuickFix-Option, mit der der Code zur Behebung des Problems neu geschrieben werden kann.

Sie können Regeln festlegen oder aufheben und den Fehlergrad auswählen, der bei der Hervorhebung in der IDE verwendet werden soll.

Es gibt viele hervorragende IntelliJ-Prüfungsfunktionen. Ich weiß das, weil ich den gesamten Inhalt gelesen habe, während ich diesen Artikel geschrieben habe. Ich verwende IntelliJ Inspections als Standard und habe sie noch nicht konfiguriert. Um die Prüfungen jedoch optimal nutzen zu können, müssen Sie sie sorgfältig lesen, die für Ihren Programmierstil relevanten Punkte identifizieren und die Warnstufen so konfigurieren, dass sie in Ihrem Code überprüft werden können.

Das Gute an IntelliJ Inspecing ist, dass es kostenlos mit der IDE mitgeliefert wird und dabei hilft, Muskelgedächtnis aufzubauen.

• Überprüfen Sie beim Schreiben von Code die Warnungen und Fehler der Quelle.
• Wenn Sie den Mauszeiger über den mit einer Flagge markierten Code bewegen, können Sie feststellen, ob eine Regelverletzung vorliegt.
• Verwenden Sie Alt+Enter, um QuickFix für das Problem anzuwenden.

Spot Bug

Das Spot Bug IntelliJ-Plugin verwendet statische Analyse, um Fehler im Code zu melden.

Sie können SpotBugs in den IntelliJ-Grundeinstellungen konfigurieren, um Ihren Code zu scannen. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detector“.

Ich neige dazu, nach dem Schreiben und Überprüfen des Codes SpotBugs zu verwenden. Anschließend führe ich die „Analyse der Projektdateien einschließlich Testquellen“ durch.

Auf diese Weise können Sie Fehler, Dead Code und offensichtliche Optimierungen identifizieren. Außerdem sollten Sie einige der gemeldeten Verstöße untersuchen, um zu entscheiden, welche Maßnahmen zu ergreifen sind.

SpotBugs findet Probleme, bietet jedoch keine QuickFix-Maßnahmen zur Lösung dieser Probleme an.

SpotBugs ist einfach zu konfigurieren und bietet meiner Meinung nach eine objektive zweite Meinung, die ich in meiner IDE berücksichtigen kann.

Sonar Lint

더 소나 린트 플러그인.

In den IntelliJ-Grundeinstellungen können Sie SonarLint konfigurieren, um Regeln für die Validierung Ihres Codes auszuwählen.

Grundsätzlich wird SonarLint in Echtzeit ausgeführt und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine Schnellkorrekturfunktion, aber die Dokumente zu den Verstoßberichten sind in der Regel klar und gut dokumentiert.

SonarLint hat sich in der Vergangenheit als nützlich erwiesen, um neue Java-Funktionen bekannt zu machen, die in der neuesten Java-Version verfügbar sind.

Check-Stil

Das Check-Style -Plugin bietet eine Mischung aus Formatierungs- und Codequalitätsregeln.

Das Checkstyle-Plugin wird zusammen mit „Sun Check“ und „Google Check“ bereitgestellt.

Die Definition dieser Begriffe kann einfach sein. Online gefunden.

CheckStyle bietet den größten Mehrwert, wenn ein Projekt Zeit in die Erstellung eines eigenen Regelwerks investiert hat. Dann kann das IDE-Plugin so konfiguriert werden, dass es dieses Regelwerk verwendet, und Programmierer können vor dem Commit des Codes in die CI einen Scan durchführen.

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

선생

Da für die Code-Übereinstimmung und die Erstellung von QuickFixes eine statische Analyse auf Basis von AST (Abstract Syntax Tree) verwendet wird, können problematische Codes sehr konkret identifiziert werden.

Mit AST können QuickFixes, die sich auf Rezepte beziehen, den umgebenden Code verstehen. Wenn Sie beispielsweise eine neue Klasse zum Code hinzufügen, wird der Import für diese Klasse nur einmal zur Quelldatei hinzugefügt und nicht zu jeder Ersetzung.

Sensei wurde entwickelt, um benutzerdefinierte Abgleichregeln, die in anderen Tools nicht vorhanden oder schwer zu erstellen sind, einfach zu erstellen.

Anstatt die Konfigurationsdatei zu bearbeiten, können Sie alle Konfigurationen über die GUI vornehmen. Wenn Sie die GUI zum Erstellen neuer Rezepte verwenden, können Sie leicht den Code überprüfen, der mit dem Rezept übereinstimmt. Außerdem können Sie beim Definieren von QuickFixs sofort den vorherigen und den nachherigen Zustand des Codes vergleichen. So können Sie ganz einfach kontextspezifische Rezepte erstellen (z. B. Rezepte, die nur für bestimmte Teams, Technologien oder sogar einzelne Programmierer verfügbar sind).

Ich verwende Sensei zusammen mit anderen statischen Analysewerkzeugen. Die meisten statischen Analysewerkzeuge finden beispielsweise Probleme, können diese aber nicht lösen. Ein typischer Anwendungsfall für Sensei ist das Duplizieren der Suchergebnisse anderer Werkzeuge in Sensei und deren Erweiterung mit Quick Fix. Dies hat den Vorteil, dass die angewendeten benutzerdefinierten Korrekturen bereits den Codierungsstandards des Projekts entsprechen.

Manchmal erstelle ich Sensei , die bereits im IntelliJ-Intentionssatz enthalten sind, weil der Intentionsbericht nicht vollständig mit dem von mir erstellten Kontext übereinstimmt oder weil die von IntelliJ bereitgestellte Schnellkorrektur nicht mit dem gewünschten Codemuster übereinstimmt.

Ich ziehe es vor, bestehende Werkzeuge zu ergänzen, anstatt sie vollständig zu ersetzen.

Sensei kann auch sehr nützlich sein, wenn es darum geht, situationsspezifische Abweichungen von allgemeinen Regeln zu identifizieren. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die von statischen Analysewerkzeugen nicht unterstützt wird, aber die allgemeinen SQL-Regeln der statischen Analyse-Engine dennoch gelten, können Sie mit Sensei eine bibliotheksspezifische Abweichung dieser Regel erstellen.

Sensei bietet nicht viele allgemeine Rezepte wie die zuvor erwähnten statischen Analysewerkzeuge. Die Stärke von Sensei liegt darin, dass sich leicht neue Rezepte mit QuickFixes erstellen lassen, die auf bestimmte Codierungsstile und Anwendungsfälle zugeschnitten sind.

Hinweis: Wir entwickeln derzeit einen öffentlichen Speicherort für Rezepte, um allgemeine Anwendungsfälle abzudecken. Sie finden es hier.

Zusammenfassung

Ich neige dazu, Tools zu wählen, die zusammenarbeiten, konfigurierbar sind und sich leicht an bestimmte Situationen anpassen lassen. Ich verwende seit Jahren statische Analyse-Tools in der IDE, die mir dabei helfen, Probleme zu identifizieren und mehr über die von mir verwendeten Programmiersprachen und Bibliotheken zu erfahren.

Alle zuvor genannten Werkzeuge werden kombiniert verwendet.

• IntelliJ Intentions hilft Ihnen dabei, häufige Code-Probleme sofort zu erkennen, indem es häufig verwendete QuickFixes einsetzt.
• SpotBugs findet einfache Fehler, die ich möglicherweise übersehen habe, und informiert mich über Leistungsprobleme.
• SonarLint identifiziert mir unbekannte Java-Funktionen und zeigt mir zusätzliche Möglichkeiten zur Modellierung von Code auf.
• Mit CheckStyle können Sie auch während der CI vereinbarte Coding-Styles einhalten.
• Sensei hilft Ihnen dabei, QuickFixes zu erstellen, um häufige Szenarien zu ergänzen, die von statischen Analysewerkzeugen erkannt werden, und spezifische Projekt- oder Technikrezepte zu erstellen, die mit anderen Werkzeugen nur schwer zu konfigurieren sind.

---

Installieren Sie Sensei in IntelliJ über „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows) und suchen Sie dann nach „Sensei-Sicherheitscode“.

Beispiele für Anwendungsfälle und Rezeptsammlungen finden Sie Secure Code Warrior unter dem Projektsensei“.

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

Mehr über Sensei erfahren