静的解析とは

静的解析とは

静的分析は、アプリケーションを実行せずにソースコードを自動的に分析することです。

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

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

• Sicherheitslücken.
• パフォーマンスの問題。
• Verstoß gegen die Norm.
• Verwendung veralteter Programmierstrukturen.

Wie funktioniert ein statisches Analyse-Tool?

Das grundlegende Konzept, das allen statischen Analysewerkzeugen gemeinsam ist, besteht darin, den Quellcode zu durchsuchen und bestimmte Codierungsmuster zu identifizieren, mit denen Warnungen oder Informationen verknüpft sind.

Dies kann etwas Einfaches sein, wie beispielsweise „JUnit 5-Testklassen müssen nicht öffentlich sein“. Oder es kann etwas Schwierigeres sein, wie beispielsweise „Unzuverlässige Zeichenfolgen werden in SQL-Anweisungen verwendet“.

静的解析ツールは、この機能の実装方法が異なります。

• Technik zur Analyse von Quellcode zur Erstellung abstrakter Syntaxbäume (AST)
• Text-Reguläre-Ausdrücke-Matching,
• Die oben genannte Kombination.

Die Übereinstimmung regulärer Ausdrücke in Texten ist sehr flexibel und ermöglicht eine einfache Beschreibung der Übereinstimmungsregeln. In vielen Fällen kann es jedoch zu zahlreichen Fehlfunden kommen, da die Übereinstimmungsregeln den Kontext des umgebenden Codes nicht berücksichtigen.

Bei der AST-Abgleichung wird der Quellcode nicht als reine Textdatei, sondern als Programmcode behandelt. Dadurch wird ein konkreterer und situationsgerechterer Abgleich möglich, wodurch die Anzahl der falsch gemeldeten Fehler im Code reduziert werden kann.

Statische Analyse bei der kontinuierlichen Integration

In vielen Fällen wird die statische Analyse während des Continuous-Integration-Prozesses (CI) durchgeführt und erzeugt einen Bericht über Compliance-Probleme. Durch die Überprüfung dieses Berichts kann die Codebasis im Laufe der Zeit objektiv erfasst werden.

Einige Personen verwenden statische Analysen als objektives Maß für die Codequalität, indem sie statische Analyse-Tools so konfigurieren, dass nur bestimmte Teile des Codes gemessen und nur Teilmengen der Regeln gemeldet werden.

Die Objektivität wird durch die verwendeten Regeln bestimmt. Diese Regeln ändern sich im Laufe der Zeit nicht bei der Bewertung des Codes. Es ist offensichtlich, dass die Kombination der verwendeten Regeln und ihre Zusammensetzung eine subjektive Entscheidung sind, und verschiedene Teams entscheiden sich dafür, zu unterschiedlichen Zeitpunkten unterschiedliche Regeln zu verwenden.

Die Durchführung statischer Analysen in CI ist zwar praktisch, kann jedoch zu Verzögerungen beim Feedback an die Programmierer führen. Die Programmierer erhalten während des Codierens kein Feedback, sondern erst später, wenn der Code mit dem statischen Analyse-Tool ausgeführt wird. Ein weiterer Nebeneffekt der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leicht ignoriert werden können.

Um es dem Team zu erleichtern, sich auf die Ergebnisse der statischen Analyse zu konzentrieren, können Sie in der Regel im Build-Prozess Schwellenwertmetriken festlegen, sodass der Build fehlschlägt, wenn die Metriken überschritten werden. Dies ist beispielsweise der Fall, wenn zahlreiche Regeln ausgelöst werden.

Statische Analyse in IDE

Um schneller Feedback zu erhalten, stehen zahlreiche IDE-Plugins zur Verfügung, die die statischen Analyseregeln der IDE auf Abruf oder regelmäßig bei Codeänderungen ausführen.

Wenn Programmierer Code schreiben, können sie Regelverstöße in der IDE erkennen. Um Regelverstöße zu verhindern, können diese oft so konfiguriert werden, dass sie im Editor als unterstrichener Code dargestellt werden.

Persönlich halte ich dies für eine nützliche Methode zur Verbesserung der Codierung. Dies gilt insbesondere für die Verwendung neuer Bibliotheken, die von statischen Analyse-Tools abgedeckt werden. Allerdings kann es zu „viel Rauschen” kommen, wenn es Fehlalarme oder uninteressante Regeln gibt. Dieses Problem lässt sich jedoch durch einen zusätzlichen Schritt beheben, indem man das statische Analyse-Tool so konfiguriert, dass bestimmte Regeln ignoriert werden.

Code-Korrektur basierend auf statischen Analyseregeln

Bei den meisten statischen Analysewerkzeugen obliegt die Korrektur von Regeln den Programmierern, sodass diese die Ursachen für Regelverstöße und die entsprechenden Korrekturmaßnahmen verstehen müssen.

Es gibt nur wenige statische Analyse-Tools, die über Funktionen zur Korrektur von Verstößen verfügen. Dies liegt daran, dass Korrekturen in den meisten Fällen auf das jeweilige Team, die verwendete Technologie und den vereinbarten Codierungsstil abgestimmt sind.

デフォルトルール

Wenn in einem statischen Analyse-Tool Standardregeln vorhanden sind, kann dies zu einem falschen Vertrauen in die Qualität dieser Regeln führen. Man neigt dazu zu glauben, dass sie alle Probleme abdecken, auf die Programmierer stoßen könnten, und alle Situationen, in denen diese Regeln angewendet werden sollten. Die Situationen, in denen Regeln angewendet werden sollten, sind jedoch subtil und nicht immer leicht zu erkennen.

Durch die Verwendung statischer Analysewerkzeuge und die detailliertere Untersuchung von Regeln und Verstößen wird erwartet, dass Programmierer die Fähigkeit erwerben, Probleme im Kontext bestimmter Domänen zu erkennen und zu vermeiden.

Wenn für eine Domäne Kontextregeln erforderlich sind, kann es vorkommen, dass das Static Analysis-Tool keine Regeln enthält, die mit der Domäne oder Bibliothek übereinstimmen, und dass die Konfiguration und Erweiterung des Tools schwierig ist.

Ärger

Diese „Unannehmlichkeiten“ sind allesamt nicht unüberwindbar.

• falsch positiv
• Mangel an Korrekturen
• Einstellungen, die Regeln ignorieren
• Hinzufügen kontextspezifischer Regeln

Es wird jedoch häufig als Ausrede verwendet, um die Verwendung statischer Analysewerkzeuge zu vermeiden. Das ist bedauerlich, da statische Analysen in folgenden Fällen sehr nützlich sein können:

• Bessere Ansätze für junge Entwickler hervorheben
• Schnelles Feedback zu eindeutigen Verstößen gegen die Codierungsregeln
• Identifizieren Sie unklare Probleme, denen Programmierer bisher noch nicht begegnet sind.
• プログラマーが優れたコーディング手法を採用していることを強調する (違反が報告されていない場合)

IDE-basiertes statisches Analyse-Tool

Als individueller Mitwirkender an Projekten nutze ich gerne statische Analyse-Tools, die innerhalb der IDE ausgeführt werden, um schnell Feedback zum Code zu erhalten.

これにより、プルリクエストレビュープロセスや、プロジェクトが持つ可能性のあるCI統合が補完されます。

Ich versuche, Tools zu finden, die mir einen Vorteil verschaffen und meine individuellen Arbeitsabläufe verbessern.

Wenn Sie das Tool in einer IDE ausführen, möchten Sie möglicherweise, dass es genauso angezeigt wird, da die grundlegende GUI und der Konfigurationsansatz in der Regel identisch sind.

ツールには重複する機能やルールセットがある場合がありますが、その利点を最大限に活用するために複数のツールをインストールしています。

Die folgenden statischen Analyse-IDE-Tools verwende ich beim Codieren aktiv.

• Eingebaute IntelliJ-Inspektion – Allgemeine Codierungsmuster
• Spot Bug – Häufige Fehler
• SonarLint – Allgemeine Verwendung
• チェックスタイル-一般的なスタイルパターン
• Secure Code Warrior-Lehrer – Erstellung benutzerdefinierter Regeln

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

IntelliJ-Inspektion

Wenn Sie IntelliJ verwenden, nutzen Sie diese Inspektion bereits.

これらは IDE でフラグが付けられた静的分析ルールです。その中には、問題に対処するためにコードを書き換える QuickFix オプションがあるものもあります。

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

IntelliJ verfügt über viele hervorragende Inspektionsfunktionen. Ich weiß das, weil ich sie mir während des Schreibens dieses Artikels angesehen habe. Ich verwende die IntelliJ-Inspektionen standardmäßig, habe sie jedoch noch nicht konfiguriert. Um das Potenzial der Inspektionen voll auszuschöpfen, muss man sie sich ansehen, diejenigen identifizieren, die für den eigenen Codierungsstil relevant sind, und die Warnstufen so einstellen, dass sie im Code auffallen.

Das Tolle an den IntelliJ-Inspektionen ist, dass sie kostenlos in der IDE enthalten sind und dabei helfen, das folgende Muskelgedächtnis aufzubauen.

• Beim Schreiben von Code werden Warnungen und Fehler in der Quelle bemerkt.
• フラグの付いたコードにカーソルを合わせると、ルール違反がわかります
• Verwenden Sie die Tastenkombination Alt+Eingabetaste, um eine Schnellkorrektur für das Problem anzuwenden.

Spot Bug

Das SpotBug IntelliJ-Plugin warnt mithilfe statischer Analyse vor Fehlern im Code.

SpotBugs kann in den IntelliJ-Einstellungen so konfiguriert werden, dass es den Code scannt. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detector“.

Ich neige dazu, SpotBugs nach dem Schreiben und Überprüfen von Code zu verwenden und anschließend die „Analyse von Projektdateien einschließlich Testquellcode“ durchzuführen.

Dies hilft dabei, Fehler, toten Code und offensichtliche Optimierungen zu identifizieren. Außerdem müssen einige der markierten Verstöße untersucht werden, um zu entscheiden, was zu tun ist.

SpotBugs erkennt Probleme, bietet jedoch keine Schnellkorrekturen zur Behebung dieser Probleme an.

SpotBugs lässt sich einfach konfigurieren und ist meiner Meinung nach als objektive zweite Meinung in der IDE sehr nützlich.

Sonarint

ザの ソナーリント プラグイン。

SonarLint kann über die IntelliJ-Einstellungen konfiguriert werden, um die Regeln auszuwählen, nach denen der Code überprüft werden soll.

Standardmäßig wird SonarLint in Echtzeit ausgeführt und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine schnellen Lösungen, aber die Berichte über Verstöße sind in der Regel klar und gut dokumentiert.

SonarLint war nützlich, da es Warnungen zu neuen Java-Funktionen ausgab, die in neueren Java-Versionen erkannt wurden.

Check-Stil

Das Checkstyle-Plugin kombiniert Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin enthält die Funktionen „Sun Check“ und „Google Check“.

これらの定義は簡単にできます オンラインで見つけました。

CheckStyle bietet den größten Nutzen, wenn ein Projekt im Laufe der Zeit einen eigenen Regelsatz erstellt hat. Auf diese Weise kann das IDE-Plugin so konfiguriert werden, dass es diesen Regelsatz verwendet, und Programmierer können vor dem Commit ihres Codes in die CI einen Scan durchführen.

CheckStyle wird häufig als Plugin für den Build-Fehler des CI-Prozesses verwendet, wenn die Anzahl der CheckStyle-Verstöße einen Schwellenwert überschreitet.

先生

先生 コードの照合とクイックフィックスの作成に抽象構文木 (AST) に基づく静的解析を使用します。これにより、問題のあるコードを非常に具体的に特定できます。

Mit AST können Sie die QuickFixes im Zusammenhang mit dem Rezept verstehen, indem Sie den umgebenden Code betrachten. Wenn Sie beispielsweise eine neue Klasse zum Code hinzufügen, wird der Import dieser Klasse nur einmal zur Quelldatei hinzugefügt und nicht bei jeder Ersetzung erneut hinzugefügt.

Sensei wurde entwickelt, um benutzerdefinierte Abgleichregeln, die in anderen Tools nicht vorhanden oder schwierig zu konfigurieren sind, einfach erstellen zu können.

Anstatt die Konfigurationsdatei zu bearbeiten, können Sie alle Einstellungen über die GUI vornehmen. Wenn Sie ein neues Rezept erstellen, können Sie in der GUI leicht überprüfen, mit welchem Code das Rezept übereinstimmt. Wenn Sie QuickFix definieren, können Sie außerdem sofort den Zustand vor und nach der Codeänderung vergleichen. Auf diese Weise können Sie ganz einfach sehr kontextbezogene Rezepte erstellen, die auf Ihr Team, Ihre Technologie oder sogar auf einzelne Programmierer zugeschnitten sind.

Ich verwende Sensei in Kombination mit anderen statischen Analyse-Tools. Die meisten statischen Analyse-Tools erkennen beispielsweise Probleme, beheben diese jedoch nicht. Ein gängiges Anwendungsbeispiel für Sensei ist die Replikation der Übereinstimmungssuche anderer Tools mit Sensei und deren Erweiterung mit Quick Fixes. Dies hat den Vorteil, dass die angewendeten benutzerdefinierten Korrekturen bereits den Codierungsstandards des Projekts entsprechen.

Da die von Intension Reports erstellten Kontexte nicht vollständig übereinstimmen oder die von IntelliJ angebotenen QuickFixes nicht mit den gewünschten Codemustern übereinstimmen, werden regelmäßig Sensei-Rezepte erstellt, die bereits im Intensions-Set von IntelliJ vorhanden sind.

Es soll nicht darum gehen, die bestehenden Tools vollständig zu ersetzen, sondern sie zu ergänzen.

Sensei ist auch sehr nützlich, um Kontextvarianten gemeinsamer Regeln zu identifizieren. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die vom statischen Analyse-Tool nicht unterstützt wird, aber die gemeinsamen SQL-Regeln der statischen Analyse-Engine weiterhin gelten, können Sie mit Sensei bibliotheksspezifische Varianten dieser Regeln erstellen.

Sensei bietet nicht wie die zuvor erwähnten statischen Analyse-Tools sofort allgemeine Rezepte an. Seine Stärke liegt darin, dass mit QuickFix, das für bestimmte Codierungsstile und Anwendungsfälle konfiguriert ist, auf einfache Weise neue Rezepte erstellt werden können.

注:現在、一般的なユースケースに対応するために、レシピの公開リポジトリを作成中です。 Sie finden es hier.

サマリー

Ich neige dazu, Tools zu wählen, die zusammenarbeiten, konfigurierbar sind und sich leicht an bestimmte Kontexte anpassen lassen. Ich verwende seit vielen Jahren statische Analyse-Tools in IDEs, um Probleme zu identifizieren und mein Verständnis der verwendeten Programmiersprachen und Bibliotheken zu vertiefen.

Alle oben genannten Tools werden kombiniert verwendet.

• IntelliJ Intentions hilft dabei, häufig auftretende Code-Probleme sofort zu melden. In vielen Fällen wird eine entsprechende Schnellkorrektur verwendet.
• SpotBugs findet einfache Fehler, die Sie möglicherweise übersehen haben, und informiert Sie über Leistungsprobleme.
• SonarLint identifiziert Java-Funktionen, die mir nicht aufgefallen sind, und zeigt mir andere Möglichkeiten zur Modellierung von Code auf.
• CheckStyle hilft dabei, die vereinbarten Codierungsstandards einzuhalten, die auch während der CI gelten.
• Sensei hilft Ihnen dabei, allgemeine Szenarien, die mit statischen Analysewerkzeugen erkannt werden, zu ergänzen und schnelle Lösungen für bestimmte Projekte und Technologiekonzepte zu entwickeln, die mit anderen Werkzeugen nur schwer zu realisieren sind.

---

Installieren Sie Sensei über „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows) in IntelliJ und suchen Sie nach „senseiセキュアコード“.

Beispielcode und Rezepte für allgemeine Anwendungsfälle finden Sie im Repositorysensei desSecure Code Warrior .

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

Mehr über den Lehrer erfahren