SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

Was ist statische Analyse?

Alan Richardson
Veröffentlicht Feb 01, 2021
Zuletzt aktualisiert am 09. März 2026

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.

Statische Analysen werden in der Regel verwendet, um Folgendes zu überprüfen:

  • Sicherheitslücke.
  • Leistungsprobleme.
  • Nichtbeachtung der Standards.
  • Verwendung veralteter Programmierstrukturen.

Wie funktioniert ein statisches Analysewerkzeug?

Das Grundkonzept aller statischen Analysewerkzeuge besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, die eine bestimmte Warnung oder relevante Informationen enthalten.

Das kann so einfach sein wie „JUnit 5-Testklassen müssen nicht öffentlich sein”. Oder etwas schwer Erkennbares wie „Verwendung nicht vertrauenswürdiger Zeichenfolgen in SQL-Ausführungsanweisungen”.

静态分析工具实现此功能的方式各不相同。

  • Technik zur Quellcodeanalyse zur Erstellung eines abstrakten Syntaxbaums (AST)
  • Text-Reguläre Ausdrücke-Übereinstimmung,
  • Die Kombination der oben genannten Punkte.

Reguläre Ausdrücke in Text sind sehr flexibel und lassen sich leicht schreiben, führen jedoch häufig zu einer Vielzahl von Fehlalarmen. Außerdem berücksichtigen sie den Kontext des umgebenden Codes nicht.

AST-Matching betrachtet den Quellcode als Programmcode und nicht nur als eine Datei voller Text. Dies ermöglicht eine genauere Kontextanpassung und reduziert die Anzahl der Fehlalarme in Bezug auf den Codebericht.

Statische Analyse in der kontinuierlichen Integration

Statische Analysen werden in der Regel im Rahmen der kontinuierlichen Integration (CI) durchgeführt, um Berichte über Konformitätsprobleme zu erstellen, die überprüft werden können, um einen objektiven Überblick über den Code-Bestand über einen bestimmten Zeitraum zu erhalten.

Einige Leute konfigurieren statische Analysewerkzeuge so, dass sie nur bestimmte Teile des Codes messen und nur einen Teil der Regeln melden, um die statische Analyse als objektiven Maßstab für ihre Codequalität zu verwenden.

Die Objektivität wird durch die verwendeten Regeln gewährleistet, da sich deren Bewertung des Codes im Laufe der Zeit nicht ändert. Natürlich ist die Kombination der verwendeten Regeln und deren Konfiguration eine subjektive Entscheidung, und verschiedene Teams entscheiden sich zu unterschiedlichen Zeitpunkten für unterschiedliche Regeln.

Die Durchführung statischer Analysen in CI ist nützlich, kann jedoch zu Verzögerungen bei der Rückmeldung an die Programmierer führen. Die Programmierer erhalten während des Codierens keine Rückmeldung, sondern erst später, wenn sie den Code mit einem statischen Analysewerkzeug ausführen. Ein weiterer Nebeneffekt der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leichter übersehen werden können.

Um dem Team zu helfen, sich stärker auf die Ergebnisse der statischen Analyse zu konzentrieren, können während des Build-Prozesses Schwellenwerte konfiguriert werden, sodass bei Überschreiten dieser Werte (z. B. bei Auslösung vieler Regeln) ein Fehler generiert wird.

Statische Analyse in der IDE

Um schneller Feedback zu erhalten, gibt es zahlreiche IDE-Plugins, die statische Analyseregeln nach Bedarf in der IDE ausführen oder regelmäßig bei Codeänderungen ausführen können.

Wenn Programmierer dann Code schreiben, können sie in der IDE sehen, wenn gegen Regeln verstoßen wird. Um Regelverstöße noch deutlicher hervorzuheben, können diese so konfiguriert werden, dass sie im Editor als unterstrichener Code angezeigt werden.

Ich persönlich halte dies für eine nützliche Methode zur Verbesserung der Codierung, insbesondere bei der Verwendung neuer Bibliotheken, die von statischen Analysewerkzeugen abgedeckt werden. Auch wenn dies zu „Lärm“ in Form von Fehlalarmen oder für Sie uninteressanten Regeln führen kann, lässt sich dieses Problem durch zusätzliche Schritte zur Konfiguration des statischen Analysewerkzeugs beheben, sodass bestimmte Regeln ignoriert werden.

Code gemäß den Regeln der statischen Analyse korrigieren

Bei den meisten statischen Analysewerkzeugen bleibt die Behebung von Regelverstößen den Programmierern überlassen, sodass diese die Ursachen für Regelverstöße kennen und wissen müssen, wie diese zu beheben sind.

Nur wenige statische Analysewerkzeuge bieten auch Funktionen zur Behebung von Verstößen, da die Behebung in der Regel vom Team und den verwendeten Technologien sowie dem vereinbarten Codierungsstil abhängt.

Standardregel

Wenn statische Analysewerkzeuge mit Standardregeln geliefert werden, kann dies zu einem falschen Vertrauen in die Qualität der Regeln führen. Man neigt leicht dazu zu glauben, dass sie alle Probleme abdecken, auf die Programmierer stoßen könnten, sowie alle Situationen, in denen die Regeln angewendet werden sollten. Manchmal sind die Situationen, in denen die Regeln angewendet werden sollten, jedoch sehr subtil und möglicherweise nicht leicht zu erkennen.

Durch den Einsatz statischer Analysewerkzeuge können Programmierer ihre Fähigkeiten zum Erkennen und Vermeiden von Problemen in bestimmten Bereichen weiterentwickeln, indem sie Regeln und Regelverstöße genauer untersuchen.

Wenn Ihre Domäne Kontextregeln erfordert, verfügt das statische Analysewerkzeug möglicherweise über keine Regeln, die mit Ihrer Domäne oder Bibliothek übereinstimmen. Darüber hinaus sind diese Werkzeuge in der Regel schwer zu konfigurieren und zu erweitern.

Ärger

Diese „Sorgen“ sind nicht unüberwindbar:

  • falsch positives Ergebnis
  • Reparaturmangel
  • Konfiguration der Regel ignorieren
  • Kontextspezifische Regeln hinzufügen

Leider werden sie jedoch häufig als Vorwand genutzt, um den Einsatz statischer Analysewerkzeuge von vornherein zu vermeiden. Das ist bedauerlich, denn statische Analysen können sehr nützlich sein und Folgendes leisten:

  • Einführung in bessere Methoden für Anfänger
  • Schnelles Feedback zu offensichtlichen Verstößen gegen die Codierungsrichtlinien
  • Finden Sie unklare Probleme, denen Programmierer zuvor noch nie begegnet sind.
  • Hervorhebung der guten Programmiermethoden der Programmierer (wenn keine Verstöße gemeldet wurden)

IDE-basiertes statisches Analysewerkzeug

Als individueller Mitwirkender an Projekten verwende ich gerne statische Analysewerkzeuge, die in der IDE laufen, damit ich schnell Feedback zum Code erhalte.

Dies ergänzt alle möglichen Pull-Request-Prüfungsprozesse und CI-Integrationen des Projekts.

Ich werde versuchen, Tools zu finden, die mir Vorteile bringen, und meinen persönlichen Arbeitsablauf verbessern.

Wenn die Tools in der IDE ausgeführt werden, kann es verlockend sein, sie abwechselnd anzuzeigen, da sie oft dieselbe grundlegende GUI und dieselben Konfigurationsmethoden verwenden.

Diese Tools können sich in ihren Funktionen oder Regelsätzen überschneiden, aber um den größtmöglichen Nutzen zu erzielen, habe ich mehrere Tools installiert, um ihre Vorteile zu nutzen.

Nachfolgend sind die statischen Analyse-IDE-Tools aufgeführt, die ich beim Programmieren aktiv nutze:

  • Integrierte IntelliJ-Prüfung – Häufige Codierungsmuster
  • SpotBugs – Häufige Fehler
  • SonarLint – Häufige Anwendungsmuster
  • CheckStyle – Häufige Stilvorlagen
  • Secure Code Warrior von Secure Code Warrior – Erstellen benutzerdefinierter Regeln

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

IntelliJ-Prüfung

Wenn Sie IntelliJ verwenden, dann nutzen Sie bereits deren Überprüfungen.

Dies sind statische Analyseregeln, die in der IDE markiert sind. Einige davon verfügen auch über eine QuickFix-Option, mit der der Code überschrieben werden kann, um das Problem zu beheben.

Diese Regeln können aktiviert und deaktiviert werden, und es kann eine Fehlerstufe ausgewählt werden, um den Fehler in der IDE hervorzuheben.

Es gibt viele gute IntelliJ-Prüfungen. Ich weiß das, weil ich sie beim Schreiben dieses Artikels durchgelesen habe. Ich verwende die IntelliJ-Prüfungen als Standard, habe sie aber noch nicht konfiguriert. Um jedoch den vollen Nutzen aus den Prüfungen zu ziehen, sollten Sie sie durchlesen, die für Ihren Programmierstil relevanten Inhalte ermitteln und die Warnstufen so konfigurieren, dass Sie sie in Ihrem Code bemerken.

Die Vorteile der IntelliJ-Prüfungen liegen darin, dass sie in der IDE kostenlos zur Verfügung stehen und dabei helfen, in folgenden Bereichen Muskelgedächtnis aufzubauen:

  • Beim Schreiben von Code auf Warnungen und Fehler im Quellcode achten
  • Bewegen Sie den Mauszeiger über den markierten Code, um zu erfahren, gegen welche Regel verstoßen wurde.
  • Verwenden Sie Alt+Eingabetaste, um eine Schnellkorrektur auf das Problem anzuwenden.


SpotBug

Dieses SpotBug IntelliJ-Plugin verwendet statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

Sie können SpotBugs in den IntelliJ-Einstellungen so konfigurieren, dass es Ihren Code scannt. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detektoren“.

Nachdem ich meinen Code geschrieben und überprüft habe, neige ich dazu, SpotBugs zu verwenden, und dann führe ich „Projektdateien einschließlich Testquellen analysieren“ aus.

Das hilft mir tatsächlich dabei, Fehler, toten Code und offensichtliche Optimierungen zu erkennen. Außerdem zwingt es mich dazu, einige gemeldete Verstöße zu untersuchen, um zu entscheiden, wie ich vorgehen soll.

SpotBugs erkennt Probleme, bietet jedoch keine QuickFix-Maßnahmen zur Behebung dieser Probleme an.

SpotBugs ist einfach zu konfigurieren, und ich habe festgestellt, dass ich in meiner IDE eine objektive zweite Meinung einholen kann.

SonarLint

Dieses SonarLint-Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um auszuwählen, nach welchen Regeln der Code überprüft werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine Schnellkorrekturen, aber die Dokumentation zu den Verstößen ist in der Regel klar und nachvollziehbar.

In der Vergangenheit habe ich festgestellt, dass SonarLint sehr nützlich ist, um mich auf neue Java-Funktionen in neueren Java-Versionen aufmerksam zu machen.

Stil überprüfen

Dieses Plugin im Check-Stil bietet eine Kombination aus Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin ist mit „Sun Checks“ und „Google Checks“ gebündelt.

Die Definitionen dafür sindleicht im Internet zu finden.

CheckStyle bietet den größten Mehrwert, wenn Projekte Zeit in die Erstellung eigener Regelsätze investieren. Anschließend kann das IDE-Plugin so konfiguriert werden, dass es diesen Regelsatz verwendet, und Programmierer können vor dem Einchecken ihres Codes in die CI einen Scan durchführen.

Wenn die Anzahl der CheckStyle-Verstöße den Schwellenwert überschreitet, wird CheckStyle in der Regel als Plugin für den Build-Fehler des CI-Prozesses verwendet.

Lehrer

Der Lehrer verwendet statische Analysen auf Basis abstrakter Syntaxbäume (AST), um Code abzugleichen und QuickFixes zu erstellen, wodurch problematischer Code sehr konkret identifiziert werden kann.

AST ermöglicht QuickFixes in Verbindung mit Formeln, die den umgebenden Code verstehen. Wenn beispielsweise eine neue Klasse zum Code hinzugefügt wird, werden alle Importe dieser Klasse nur einmal zur Quelldatei hinzugefügt und nicht bei jeder Ersetzung.

Sensei , um die Erstellung benutzerdefinierter Übereinstimmungsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht vorhanden oder schwer zu konfigurieren sind.

Alle Konfigurationen können in der GUI vorgenommen werden, ohne dass die Konfigurationsdatei geändert werden muss. Beim Erstellen einer neuen Konfiguration kann die GUI den Code, der zur Konfiguration passt, leicht anzeigen. Beim Definieren von QuickFixes kann der Zustand des Codes vor und nach der Änderung sofort verglichen werden. Dies erleichtert die Erstellung von Rezepten, die genau auf die jeweilige Situation zugeschnitten sind, d. h. auf das Team, die Technologie oder sogar den einzelnen Programmierer.

Ich verwende Sensei . Die meisten statischen Analysewerkzeuge finden zwar Probleme, können diese jedoch nicht beheben.Sensei , die Übereinstimmungssuche anderer Werkzeuge Sensei zu kopieren und diese dann mit Quick Fix zu erweitern. Der Vorteil dabei ist, dass die benutzerdefinierten Korrekturen der Anwendung bereits den Codierungsstandards des Projekts entsprechen.

Ich stelle oft fest, dass Sensei von mir erstellten Sensei bereits in der IntelliJ Intensions-Sammlung vorhanden sind. Das liegt daran, dass die Intension-Berichte nicht ganz mit dem von mir erstellten Kontext übereinstimmen oder dass die von IntelliJ angebotenen QuickFixes nicht mit den von mir gewünschten Codemustern übereinstimmen.

Ich habe die vorhandenen Tools erweitert, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei , wenn Sie Kontextvarianten gängiger Regeln erkennen. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die von statischen Analysewerkzeugen nicht unterstützt wird, aber die gängigen SQL-Regeln in der statischen Analyse-Engine dennoch zutreffen, können Sie Sensei bibliotheksspezifische Varianten dieser Regeln Sensei .

Sensei verfügt nicht über viele vorgefertigte allgemeine Vorlagen wie die erwähnten statischen Analyse-Tools. Sein Vorteil besteht darin, dass Sie ganz einfach neue Vorlagen erstellen und QuickFixes so konfigurieren können, dass sie Ihrem spezifischen Programmierstil und Ihren Anwendungsfällen entsprechen.

Hinweis: Wir entwickeln derzeit ein öffentliches Rezept-Repository, das allgemeine Anwendungsfälle abdeckt, sowie Sie finden es hier.

Zusammenfassung

Ich bevorzuge Tools, die zusammenarbeiten, konfigurierbar und leicht erweiterbar sind, um meinen spezifischen Anforderungen gerecht zu werden. Seit Jahren verwende ich statische Analyse-Tools in meiner IDE, um Probleme zu erkennen und ein besseres Verständnis für die von mir verwendeten Programmiersprachen und Bibliotheken zu erlangen.

Ich werde alle Tools, die ich erwähnen werde, kombiniert einsetzen:

  • IntelliJ Intents kann dabei helfen, häufige Code-Probleme sofort zu erkennen, die oft mit schnellen Korrekturen behoben werden können.
  • SpotBugs entdeckt einfache Fehler, die mir möglicherweise entgangen sind, und macht mich auf Leistungsprobleme aufmerksam.
  • SonarLint hat Java-Funktionen erkannt, die mir unbekannt waren, und mir vorgeschlagen, meinen Code mit anderen Methoden zu modellieren.
  • CheckStyle hilft mir dabei, den vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
  • Sensei , QuickFixes zu erstellen, um die von statischen Analysewerkzeugen erkannten häufigen Szenarien zu verbessern und bestimmte Projekte oder technische Lösungen zu erstellen, die in anderen Werkzeugen möglicherweise schwer zu konfigurieren sind.


---

Verwenden Sie „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows), um Sensei aus IntelliJ zu installieren, und Senseieinfach Senseisensei “.


Beispielcode und gängige Anwendungsfälle finden Sie im Repositorysensei des Secure Code Warrior


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

Erfahren Sie Sensei


Ressourcen anzeigen
Ressourcen anzeigen

Lernen Sie anhand von fünf Beispielen für IDE-basierte Methoden und Plugins die statische Analyse kennen und erfahren Sie, wie sie Ihnen dabei helfen kann, besseren Code zu schreiben.

Interessiert an mehr?

Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.

mehr erfahren

Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.

Demo buchen
Teilen auf:
LinkedIn-MarkenSozialx Logo
作者
Alan Richardson
Veröffentlicht Feb 01, 2021

Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.

Teilen auf:
LinkedIn-MarkenSozialx Logo

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.

Statische Analysen werden in der Regel verwendet, um Folgendes zu überprüfen:

  • Sicherheitslücke.
  • Leistungsprobleme.
  • Nichtbeachtung der Standards.
  • Verwendung veralteter Programmierstrukturen.

Wie funktioniert ein statisches Analysewerkzeug?

Das Grundkonzept aller statischen Analysewerkzeuge besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, die eine bestimmte Warnung oder relevante Informationen enthalten.

Das kann so einfach sein wie „JUnit 5-Testklassen müssen nicht öffentlich sein”. Oder etwas schwer Erkennbares wie „Verwendung nicht vertrauenswürdiger Zeichenfolgen in SQL-Ausführungsanweisungen”.

静态分析工具实现此功能的方式各不相同。

  • Technik zur Quellcodeanalyse zur Erstellung eines abstrakten Syntaxbaums (AST)
  • Text-Reguläre Ausdrücke-Übereinstimmung,
  • Die Kombination der oben genannten Punkte.

Reguläre Ausdrücke in Text sind sehr flexibel und lassen sich leicht schreiben, führen jedoch häufig zu einer Vielzahl von Fehlalarmen. Außerdem berücksichtigen sie den Kontext des umgebenden Codes nicht.

AST-Matching betrachtet den Quellcode als Programmcode und nicht nur als eine Datei voller Text. Dies ermöglicht eine genauere Kontextanpassung und reduziert die Anzahl der Fehlalarme in Bezug auf den Codebericht.

Statische Analyse in der kontinuierlichen Integration

Statische Analysen werden in der Regel im Rahmen der kontinuierlichen Integration (CI) durchgeführt, um Berichte über Konformitätsprobleme zu erstellen, die überprüft werden können, um einen objektiven Überblick über den Code-Bestand über einen bestimmten Zeitraum zu erhalten.

Einige Leute konfigurieren statische Analysewerkzeuge so, dass sie nur bestimmte Teile des Codes messen und nur einen Teil der Regeln melden, um die statische Analyse als objektiven Maßstab für ihre Codequalität zu verwenden.

Die Objektivität wird durch die verwendeten Regeln gewährleistet, da sich deren Bewertung des Codes im Laufe der Zeit nicht ändert. Natürlich ist die Kombination der verwendeten Regeln und deren Konfiguration eine subjektive Entscheidung, und verschiedene Teams entscheiden sich zu unterschiedlichen Zeitpunkten für unterschiedliche Regeln.

Die Durchführung statischer Analysen in CI ist nützlich, kann jedoch zu Verzögerungen bei der Rückmeldung an die Programmierer führen. Die Programmierer erhalten während des Codierens keine Rückmeldung, sondern erst später, wenn sie den Code mit einem statischen Analysewerkzeug ausführen. Ein weiterer Nebeneffekt der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leichter übersehen werden können.

Um dem Team zu helfen, sich stärker auf die Ergebnisse der statischen Analyse zu konzentrieren, können während des Build-Prozesses Schwellenwerte konfiguriert werden, sodass bei Überschreiten dieser Werte (z. B. bei Auslösung vieler Regeln) ein Fehler generiert wird.

Statische Analyse in der IDE

Um schneller Feedback zu erhalten, gibt es zahlreiche IDE-Plugins, die statische Analyseregeln nach Bedarf in der IDE ausführen oder regelmäßig bei Codeänderungen ausführen können.

Wenn Programmierer dann Code schreiben, können sie in der IDE sehen, wenn gegen Regeln verstoßen wird. Um Regelverstöße noch deutlicher hervorzuheben, können diese so konfiguriert werden, dass sie im Editor als unterstrichener Code angezeigt werden.

Ich persönlich halte dies für eine nützliche Methode zur Verbesserung der Codierung, insbesondere bei der Verwendung neuer Bibliotheken, die von statischen Analysewerkzeugen abgedeckt werden. Auch wenn dies zu „Lärm“ in Form von Fehlalarmen oder für Sie uninteressanten Regeln führen kann, lässt sich dieses Problem durch zusätzliche Schritte zur Konfiguration des statischen Analysewerkzeugs beheben, sodass bestimmte Regeln ignoriert werden.

Code gemäß den Regeln der statischen Analyse korrigieren

Bei den meisten statischen Analysewerkzeugen bleibt die Behebung von Regelverstößen den Programmierern überlassen, sodass diese die Ursachen für Regelverstöße kennen und wissen müssen, wie diese zu beheben sind.

Nur wenige statische Analysewerkzeuge bieten auch Funktionen zur Behebung von Verstößen, da die Behebung in der Regel vom Team und den verwendeten Technologien sowie dem vereinbarten Codierungsstil abhängt.

Standardregel

Wenn statische Analysewerkzeuge mit Standardregeln geliefert werden, kann dies zu einem falschen Vertrauen in die Qualität der Regeln führen. Man neigt leicht dazu zu glauben, dass sie alle Probleme abdecken, auf die Programmierer stoßen könnten, sowie alle Situationen, in denen die Regeln angewendet werden sollten. Manchmal sind die Situationen, in denen die Regeln angewendet werden sollten, jedoch sehr subtil und möglicherweise nicht leicht zu erkennen.

Durch den Einsatz statischer Analysewerkzeuge können Programmierer ihre Fähigkeiten zum Erkennen und Vermeiden von Problemen in bestimmten Bereichen weiterentwickeln, indem sie Regeln und Regelverstöße genauer untersuchen.

Wenn Ihre Domäne Kontextregeln erfordert, verfügt das statische Analysewerkzeug möglicherweise über keine Regeln, die mit Ihrer Domäne oder Bibliothek übereinstimmen. Darüber hinaus sind diese Werkzeuge in der Regel schwer zu konfigurieren und zu erweitern.

Ärger

Diese „Sorgen“ sind nicht unüberwindbar:

  • falsch positives Ergebnis
  • Reparaturmangel
  • Konfiguration der Regel ignorieren
  • Kontextspezifische Regeln hinzufügen

Leider werden sie jedoch häufig als Vorwand genutzt, um den Einsatz statischer Analysewerkzeuge von vornherein zu vermeiden. Das ist bedauerlich, denn statische Analysen können sehr nützlich sein und Folgendes leisten:

  • Einführung in bessere Methoden für Anfänger
  • Schnelles Feedback zu offensichtlichen Verstößen gegen die Codierungsrichtlinien
  • Finden Sie unklare Probleme, denen Programmierer zuvor noch nie begegnet sind.
  • Hervorhebung der guten Programmiermethoden der Programmierer (wenn keine Verstöße gemeldet wurden)

IDE-basiertes statisches Analysewerkzeug

Als individueller Mitwirkender an Projekten verwende ich gerne statische Analysewerkzeuge, die in der IDE laufen, damit ich schnell Feedback zum Code erhalte.

Dies ergänzt alle möglichen Pull-Request-Prüfungsprozesse und CI-Integrationen des Projekts.

Ich werde versuchen, Tools zu finden, die mir Vorteile bringen, und meinen persönlichen Arbeitsablauf verbessern.

Wenn die Tools in der IDE ausgeführt werden, kann es verlockend sein, sie abwechselnd anzuzeigen, da sie oft dieselbe grundlegende GUI und dieselben Konfigurationsmethoden verwenden.

Diese Tools können sich in ihren Funktionen oder Regelsätzen überschneiden, aber um den größtmöglichen Nutzen zu erzielen, habe ich mehrere Tools installiert, um ihre Vorteile zu nutzen.

Nachfolgend sind die statischen Analyse-IDE-Tools aufgeführt, die ich beim Programmieren aktiv nutze:

  • Integrierte IntelliJ-Prüfung – Häufige Codierungsmuster
  • SpotBugs – Häufige Fehler
  • SonarLint – Häufige Anwendungsmuster
  • CheckStyle – Häufige Stilvorlagen
  • Secure Code Warrior von Secure Code Warrior – Erstellen benutzerdefinierter Regeln

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

IntelliJ-Prüfung

Wenn Sie IntelliJ verwenden, dann nutzen Sie bereits deren Überprüfungen.

Dies sind statische Analyseregeln, die in der IDE markiert sind. Einige davon verfügen auch über eine QuickFix-Option, mit der der Code überschrieben werden kann, um das Problem zu beheben.

Diese Regeln können aktiviert und deaktiviert werden, und es kann eine Fehlerstufe ausgewählt werden, um den Fehler in der IDE hervorzuheben.

Es gibt viele gute IntelliJ-Prüfungen. Ich weiß das, weil ich sie beim Schreiben dieses Artikels durchgelesen habe. Ich verwende die IntelliJ-Prüfungen als Standard, habe sie aber noch nicht konfiguriert. Um jedoch den vollen Nutzen aus den Prüfungen zu ziehen, sollten Sie sie durchlesen, die für Ihren Programmierstil relevanten Inhalte ermitteln und die Warnstufen so konfigurieren, dass Sie sie in Ihrem Code bemerken.

Die Vorteile der IntelliJ-Prüfungen liegen darin, dass sie in der IDE kostenlos zur Verfügung stehen und dabei helfen, in folgenden Bereichen Muskelgedächtnis aufzubauen:

  • Beim Schreiben von Code auf Warnungen und Fehler im Quellcode achten
  • Bewegen Sie den Mauszeiger über den markierten Code, um zu erfahren, gegen welche Regel verstoßen wurde.
  • Verwenden Sie Alt+Eingabetaste, um eine Schnellkorrektur auf das Problem anzuwenden.


SpotBug

Dieses SpotBug IntelliJ-Plugin verwendet statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

Sie können SpotBugs in den IntelliJ-Einstellungen so konfigurieren, dass es Ihren Code scannt. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detektoren“.

Nachdem ich meinen Code geschrieben und überprüft habe, neige ich dazu, SpotBugs zu verwenden, und dann führe ich „Projektdateien einschließlich Testquellen analysieren“ aus.

Das hilft mir tatsächlich dabei, Fehler, toten Code und offensichtliche Optimierungen zu erkennen. Außerdem zwingt es mich dazu, einige gemeldete Verstöße zu untersuchen, um zu entscheiden, wie ich vorgehen soll.

SpotBugs erkennt Probleme, bietet jedoch keine QuickFix-Maßnahmen zur Behebung dieser Probleme an.

SpotBugs ist einfach zu konfigurieren, und ich habe festgestellt, dass ich in meiner IDE eine objektive zweite Meinung einholen kann.

SonarLint

Dieses SonarLint-Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um auszuwählen, nach welchen Regeln der Code überprüft werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine Schnellkorrekturen, aber die Dokumentation zu den Verstößen ist in der Regel klar und nachvollziehbar.

In der Vergangenheit habe ich festgestellt, dass SonarLint sehr nützlich ist, um mich auf neue Java-Funktionen in neueren Java-Versionen aufmerksam zu machen.

Stil überprüfen

Dieses Plugin im Check-Stil bietet eine Kombination aus Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin ist mit „Sun Checks“ und „Google Checks“ gebündelt.

Die Definitionen dafür sindleicht im Internet zu finden.

CheckStyle bietet den größten Mehrwert, wenn Projekte Zeit in die Erstellung eigener Regelsätze investieren. Anschließend kann das IDE-Plugin so konfiguriert werden, dass es diesen Regelsatz verwendet, und Programmierer können vor dem Einchecken ihres Codes in die CI einen Scan durchführen.

Wenn die Anzahl der CheckStyle-Verstöße den Schwellenwert überschreitet, wird CheckStyle in der Regel als Plugin für den Build-Fehler des CI-Prozesses verwendet.

Lehrer

Der Lehrer verwendet statische Analysen auf Basis abstrakter Syntaxbäume (AST), um Code abzugleichen und QuickFixes zu erstellen, wodurch problematischer Code sehr konkret identifiziert werden kann.

AST ermöglicht QuickFixes in Verbindung mit Formeln, die den umgebenden Code verstehen. Wenn beispielsweise eine neue Klasse zum Code hinzugefügt wird, werden alle Importe dieser Klasse nur einmal zur Quelldatei hinzugefügt und nicht bei jeder Ersetzung.

Sensei , um die Erstellung benutzerdefinierter Übereinstimmungsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht vorhanden oder schwer zu konfigurieren sind.

Alle Konfigurationen können in der GUI vorgenommen werden, ohne dass die Konfigurationsdatei geändert werden muss. Beim Erstellen einer neuen Konfiguration kann die GUI den Code, der zur Konfiguration passt, leicht anzeigen. Beim Definieren von QuickFixes kann der Zustand des Codes vor und nach der Änderung sofort verglichen werden. Dies erleichtert die Erstellung von Rezepten, die genau auf die jeweilige Situation zugeschnitten sind, d. h. auf das Team, die Technologie oder sogar den einzelnen Programmierer.

Ich verwende Sensei . Die meisten statischen Analysewerkzeuge finden zwar Probleme, können diese jedoch nicht beheben.Sensei , die Übereinstimmungssuche anderer Werkzeuge Sensei zu kopieren und diese dann mit Quick Fix zu erweitern. Der Vorteil dabei ist, dass die benutzerdefinierten Korrekturen der Anwendung bereits den Codierungsstandards des Projekts entsprechen.

Ich stelle oft fest, dass Sensei von mir erstellten Sensei bereits in der IntelliJ Intensions-Sammlung vorhanden sind. Das liegt daran, dass die Intension-Berichte nicht ganz mit dem von mir erstellten Kontext übereinstimmen oder dass die von IntelliJ angebotenen QuickFixes nicht mit den von mir gewünschten Codemustern übereinstimmen.

Ich habe die vorhandenen Tools erweitert, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei , wenn Sie Kontextvarianten gängiger Regeln erkennen. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die von statischen Analysewerkzeugen nicht unterstützt wird, aber die gängigen SQL-Regeln in der statischen Analyse-Engine dennoch zutreffen, können Sie Sensei bibliotheksspezifische Varianten dieser Regeln Sensei .

Sensei verfügt nicht über viele vorgefertigte allgemeine Vorlagen wie die erwähnten statischen Analyse-Tools. Sein Vorteil besteht darin, dass Sie ganz einfach neue Vorlagen erstellen und QuickFixes so konfigurieren können, dass sie Ihrem spezifischen Programmierstil und Ihren Anwendungsfällen entsprechen.

Hinweis: Wir entwickeln derzeit ein öffentliches Rezept-Repository, das allgemeine Anwendungsfälle abdeckt, sowie Sie finden es hier.

Zusammenfassung

Ich bevorzuge Tools, die zusammenarbeiten, konfigurierbar und leicht erweiterbar sind, um meinen spezifischen Anforderungen gerecht zu werden. Seit Jahren verwende ich statische Analyse-Tools in meiner IDE, um Probleme zu erkennen und ein besseres Verständnis für die von mir verwendeten Programmiersprachen und Bibliotheken zu erlangen.

Ich werde alle Tools, die ich erwähnen werde, kombiniert einsetzen:

  • IntelliJ Intents kann dabei helfen, häufige Code-Probleme sofort zu erkennen, die oft mit schnellen Korrekturen behoben werden können.
  • SpotBugs entdeckt einfache Fehler, die mir möglicherweise entgangen sind, und macht mich auf Leistungsprobleme aufmerksam.
  • SonarLint hat Java-Funktionen erkannt, die mir unbekannt waren, und mir vorgeschlagen, meinen Code mit anderen Methoden zu modellieren.
  • CheckStyle hilft mir dabei, den vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
  • Sensei , QuickFixes zu erstellen, um die von statischen Analysewerkzeugen erkannten häufigen Szenarien zu verbessern und bestimmte Projekte oder technische Lösungen zu erstellen, die in anderen Werkzeugen möglicherweise schwer zu konfigurieren sind.


---

Verwenden Sie „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows), um Sensei aus IntelliJ zu installieren, und Senseieinfach Senseisensei “.


Beispielcode und gängige Anwendungsfälle finden Sie im Repositorysensei des Secure Code Warrior


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

Erfahren Sie Sensei


Ressourcen anzeigen
Ressourcen anzeigen

Füllen Sie das folgende Formular aus, um den Bericht herunterzuladen.

Wir möchten Ihre Erlaubnis einholen, Ihnen Informationen über unsere Produkte und/oder relevante Themen zur Sicherheit von Codes zuzusenden. Wir werden Ihre personenbezogenen Daten stets mit größter Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Einreichen
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte die „Analyse“-Cookies. Nach Abschluss können Sie diese wieder deaktivieren.

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.

Statische Analysen werden in der Regel verwendet, um Folgendes zu überprüfen:

  • Sicherheitslücke.
  • Leistungsprobleme.
  • Nichtbeachtung der Standards.
  • Verwendung veralteter Programmierstrukturen.

Wie funktioniert ein statisches Analysewerkzeug?

Das Grundkonzept aller statischen Analysewerkzeuge besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, die eine bestimmte Warnung oder relevante Informationen enthalten.

Das kann so einfach sein wie „JUnit 5-Testklassen müssen nicht öffentlich sein”. Oder etwas schwer Erkennbares wie „Verwendung nicht vertrauenswürdiger Zeichenfolgen in SQL-Ausführungsanweisungen”.

静态分析工具实现此功能的方式各不相同。

  • Technik zur Quellcodeanalyse zur Erstellung eines abstrakten Syntaxbaums (AST)
  • Text-Reguläre Ausdrücke-Übereinstimmung,
  • Die Kombination der oben genannten Punkte.

Reguläre Ausdrücke in Text sind sehr flexibel und lassen sich leicht schreiben, führen jedoch häufig zu einer Vielzahl von Fehlalarmen. Außerdem berücksichtigen sie den Kontext des umgebenden Codes nicht.

AST-Matching betrachtet den Quellcode als Programmcode und nicht nur als eine Datei voller Text. Dies ermöglicht eine genauere Kontextanpassung und reduziert die Anzahl der Fehlalarme in Bezug auf den Codebericht.

Statische Analyse in der kontinuierlichen Integration

Statische Analysen werden in der Regel im Rahmen der kontinuierlichen Integration (CI) durchgeführt, um Berichte über Konformitätsprobleme zu erstellen, die überprüft werden können, um einen objektiven Überblick über den Code-Bestand über einen bestimmten Zeitraum zu erhalten.

Einige Leute konfigurieren statische Analysewerkzeuge so, dass sie nur bestimmte Teile des Codes messen und nur einen Teil der Regeln melden, um die statische Analyse als objektiven Maßstab für ihre Codequalität zu verwenden.

Die Objektivität wird durch die verwendeten Regeln gewährleistet, da sich deren Bewertung des Codes im Laufe der Zeit nicht ändert. Natürlich ist die Kombination der verwendeten Regeln und deren Konfiguration eine subjektive Entscheidung, und verschiedene Teams entscheiden sich zu unterschiedlichen Zeitpunkten für unterschiedliche Regeln.

Die Durchführung statischer Analysen in CI ist nützlich, kann jedoch zu Verzögerungen bei der Rückmeldung an die Programmierer führen. Die Programmierer erhalten während des Codierens keine Rückmeldung, sondern erst später, wenn sie den Code mit einem statischen Analysewerkzeug ausführen. Ein weiterer Nebeneffekt der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leichter übersehen werden können.

Um dem Team zu helfen, sich stärker auf die Ergebnisse der statischen Analyse zu konzentrieren, können während des Build-Prozesses Schwellenwerte konfiguriert werden, sodass bei Überschreiten dieser Werte (z. B. bei Auslösung vieler Regeln) ein Fehler generiert wird.

Statische Analyse in der IDE

Um schneller Feedback zu erhalten, gibt es zahlreiche IDE-Plugins, die statische Analyseregeln nach Bedarf in der IDE ausführen oder regelmäßig bei Codeänderungen ausführen können.

Wenn Programmierer dann Code schreiben, können sie in der IDE sehen, wenn gegen Regeln verstoßen wird. Um Regelverstöße noch deutlicher hervorzuheben, können diese so konfiguriert werden, dass sie im Editor als unterstrichener Code angezeigt werden.

Ich persönlich halte dies für eine nützliche Methode zur Verbesserung der Codierung, insbesondere bei der Verwendung neuer Bibliotheken, die von statischen Analysewerkzeugen abgedeckt werden. Auch wenn dies zu „Lärm“ in Form von Fehlalarmen oder für Sie uninteressanten Regeln führen kann, lässt sich dieses Problem durch zusätzliche Schritte zur Konfiguration des statischen Analysewerkzeugs beheben, sodass bestimmte Regeln ignoriert werden.

Code gemäß den Regeln der statischen Analyse korrigieren

Bei den meisten statischen Analysewerkzeugen bleibt die Behebung von Regelverstößen den Programmierern überlassen, sodass diese die Ursachen für Regelverstöße kennen und wissen müssen, wie diese zu beheben sind.

Nur wenige statische Analysewerkzeuge bieten auch Funktionen zur Behebung von Verstößen, da die Behebung in der Regel vom Team und den verwendeten Technologien sowie dem vereinbarten Codierungsstil abhängt.

Standardregel

Wenn statische Analysewerkzeuge mit Standardregeln geliefert werden, kann dies zu einem falschen Vertrauen in die Qualität der Regeln führen. Man neigt leicht dazu zu glauben, dass sie alle Probleme abdecken, auf die Programmierer stoßen könnten, sowie alle Situationen, in denen die Regeln angewendet werden sollten. Manchmal sind die Situationen, in denen die Regeln angewendet werden sollten, jedoch sehr subtil und möglicherweise nicht leicht zu erkennen.

Durch den Einsatz statischer Analysewerkzeuge können Programmierer ihre Fähigkeiten zum Erkennen und Vermeiden von Problemen in bestimmten Bereichen weiterentwickeln, indem sie Regeln und Regelverstöße genauer untersuchen.

Wenn Ihre Domäne Kontextregeln erfordert, verfügt das statische Analysewerkzeug möglicherweise über keine Regeln, die mit Ihrer Domäne oder Bibliothek übereinstimmen. Darüber hinaus sind diese Werkzeuge in der Regel schwer zu konfigurieren und zu erweitern.

Ärger

Diese „Sorgen“ sind nicht unüberwindbar:

  • falsch positives Ergebnis
  • Reparaturmangel
  • Konfiguration der Regel ignorieren
  • Kontextspezifische Regeln hinzufügen

Leider werden sie jedoch häufig als Vorwand genutzt, um den Einsatz statischer Analysewerkzeuge von vornherein zu vermeiden. Das ist bedauerlich, denn statische Analysen können sehr nützlich sein und Folgendes leisten:

  • Einführung in bessere Methoden für Anfänger
  • Schnelles Feedback zu offensichtlichen Verstößen gegen die Codierungsrichtlinien
  • Finden Sie unklare Probleme, denen Programmierer zuvor noch nie begegnet sind.
  • Hervorhebung der guten Programmiermethoden der Programmierer (wenn keine Verstöße gemeldet wurden)

IDE-basiertes statisches Analysewerkzeug

Als individueller Mitwirkender an Projekten verwende ich gerne statische Analysewerkzeuge, die in der IDE laufen, damit ich schnell Feedback zum Code erhalte.

Dies ergänzt alle möglichen Pull-Request-Prüfungsprozesse und CI-Integrationen des Projekts.

Ich werde versuchen, Tools zu finden, die mir Vorteile bringen, und meinen persönlichen Arbeitsablauf verbessern.

Wenn die Tools in der IDE ausgeführt werden, kann es verlockend sein, sie abwechselnd anzuzeigen, da sie oft dieselbe grundlegende GUI und dieselben Konfigurationsmethoden verwenden.

Diese Tools können sich in ihren Funktionen oder Regelsätzen überschneiden, aber um den größtmöglichen Nutzen zu erzielen, habe ich mehrere Tools installiert, um ihre Vorteile zu nutzen.

Nachfolgend sind die statischen Analyse-IDE-Tools aufgeführt, die ich beim Programmieren aktiv nutze:

  • Integrierte IntelliJ-Prüfung – Häufige Codierungsmuster
  • SpotBugs – Häufige Fehler
  • SonarLint – Häufige Anwendungsmuster
  • CheckStyle – Häufige Stilvorlagen
  • Secure Code Warrior von Secure Code Warrior – Erstellen benutzerdefinierter Regeln

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

IntelliJ-Prüfung

Wenn Sie IntelliJ verwenden, dann nutzen Sie bereits deren Überprüfungen.

Dies sind statische Analyseregeln, die in der IDE markiert sind. Einige davon verfügen auch über eine QuickFix-Option, mit der der Code überschrieben werden kann, um das Problem zu beheben.

Diese Regeln können aktiviert und deaktiviert werden, und es kann eine Fehlerstufe ausgewählt werden, um den Fehler in der IDE hervorzuheben.

Es gibt viele gute IntelliJ-Prüfungen. Ich weiß das, weil ich sie beim Schreiben dieses Artikels durchgelesen habe. Ich verwende die IntelliJ-Prüfungen als Standard, habe sie aber noch nicht konfiguriert. Um jedoch den vollen Nutzen aus den Prüfungen zu ziehen, sollten Sie sie durchlesen, die für Ihren Programmierstil relevanten Inhalte ermitteln und die Warnstufen so konfigurieren, dass Sie sie in Ihrem Code bemerken.

Die Vorteile der IntelliJ-Prüfungen liegen darin, dass sie in der IDE kostenlos zur Verfügung stehen und dabei helfen, in folgenden Bereichen Muskelgedächtnis aufzubauen:

  • Beim Schreiben von Code auf Warnungen und Fehler im Quellcode achten
  • Bewegen Sie den Mauszeiger über den markierten Code, um zu erfahren, gegen welche Regel verstoßen wurde.
  • Verwenden Sie Alt+Eingabetaste, um eine Schnellkorrektur auf das Problem anzuwenden.


SpotBug

Dieses SpotBug IntelliJ-Plugin verwendet statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

Sie können SpotBugs in den IntelliJ-Einstellungen so konfigurieren, dass es Ihren Code scannt. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detektoren“.

Nachdem ich meinen Code geschrieben und überprüft habe, neige ich dazu, SpotBugs zu verwenden, und dann führe ich „Projektdateien einschließlich Testquellen analysieren“ aus.

Das hilft mir tatsächlich dabei, Fehler, toten Code und offensichtliche Optimierungen zu erkennen. Außerdem zwingt es mich dazu, einige gemeldete Verstöße zu untersuchen, um zu entscheiden, wie ich vorgehen soll.

SpotBugs erkennt Probleme, bietet jedoch keine QuickFix-Maßnahmen zur Behebung dieser Probleme an.

SpotBugs ist einfach zu konfigurieren, und ich habe festgestellt, dass ich in meiner IDE eine objektive zweite Meinung einholen kann.

SonarLint

Dieses SonarLint-Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um auszuwählen, nach welchen Regeln der Code überprüft werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine Schnellkorrekturen, aber die Dokumentation zu den Verstößen ist in der Regel klar und nachvollziehbar.

In der Vergangenheit habe ich festgestellt, dass SonarLint sehr nützlich ist, um mich auf neue Java-Funktionen in neueren Java-Versionen aufmerksam zu machen.

Stil überprüfen

Dieses Plugin im Check-Stil bietet eine Kombination aus Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin ist mit „Sun Checks“ und „Google Checks“ gebündelt.

Die Definitionen dafür sindleicht im Internet zu finden.

CheckStyle bietet den größten Mehrwert, wenn Projekte Zeit in die Erstellung eigener Regelsätze investieren. Anschließend kann das IDE-Plugin so konfiguriert werden, dass es diesen Regelsatz verwendet, und Programmierer können vor dem Einchecken ihres Codes in die CI einen Scan durchführen.

Wenn die Anzahl der CheckStyle-Verstöße den Schwellenwert überschreitet, wird CheckStyle in der Regel als Plugin für den Build-Fehler des CI-Prozesses verwendet.

Lehrer

Der Lehrer verwendet statische Analysen auf Basis abstrakter Syntaxbäume (AST), um Code abzugleichen und QuickFixes zu erstellen, wodurch problematischer Code sehr konkret identifiziert werden kann.

AST ermöglicht QuickFixes in Verbindung mit Formeln, die den umgebenden Code verstehen. Wenn beispielsweise eine neue Klasse zum Code hinzugefügt wird, werden alle Importe dieser Klasse nur einmal zur Quelldatei hinzugefügt und nicht bei jeder Ersetzung.

Sensei , um die Erstellung benutzerdefinierter Übereinstimmungsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht vorhanden oder schwer zu konfigurieren sind.

Alle Konfigurationen können in der GUI vorgenommen werden, ohne dass die Konfigurationsdatei geändert werden muss. Beim Erstellen einer neuen Konfiguration kann die GUI den Code, der zur Konfiguration passt, leicht anzeigen. Beim Definieren von QuickFixes kann der Zustand des Codes vor und nach der Änderung sofort verglichen werden. Dies erleichtert die Erstellung von Rezepten, die genau auf die jeweilige Situation zugeschnitten sind, d. h. auf das Team, die Technologie oder sogar den einzelnen Programmierer.

Ich verwende Sensei . Die meisten statischen Analysewerkzeuge finden zwar Probleme, können diese jedoch nicht beheben.Sensei , die Übereinstimmungssuche anderer Werkzeuge Sensei zu kopieren und diese dann mit Quick Fix zu erweitern. Der Vorteil dabei ist, dass die benutzerdefinierten Korrekturen der Anwendung bereits den Codierungsstandards des Projekts entsprechen.

Ich stelle oft fest, dass Sensei von mir erstellten Sensei bereits in der IntelliJ Intensions-Sammlung vorhanden sind. Das liegt daran, dass die Intension-Berichte nicht ganz mit dem von mir erstellten Kontext übereinstimmen oder dass die von IntelliJ angebotenen QuickFixes nicht mit den von mir gewünschten Codemustern übereinstimmen.

Ich habe die vorhandenen Tools erweitert, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei , wenn Sie Kontextvarianten gängiger Regeln erkennen. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die von statischen Analysewerkzeugen nicht unterstützt wird, aber die gängigen SQL-Regeln in der statischen Analyse-Engine dennoch zutreffen, können Sie Sensei bibliotheksspezifische Varianten dieser Regeln Sensei .

Sensei verfügt nicht über viele vorgefertigte allgemeine Vorlagen wie die erwähnten statischen Analyse-Tools. Sein Vorteil besteht darin, dass Sie ganz einfach neue Vorlagen erstellen und QuickFixes so konfigurieren können, dass sie Ihrem spezifischen Programmierstil und Ihren Anwendungsfällen entsprechen.

Hinweis: Wir entwickeln derzeit ein öffentliches Rezept-Repository, das allgemeine Anwendungsfälle abdeckt, sowie Sie finden es hier.

Zusammenfassung

Ich bevorzuge Tools, die zusammenarbeiten, konfigurierbar und leicht erweiterbar sind, um meinen spezifischen Anforderungen gerecht zu werden. Seit Jahren verwende ich statische Analyse-Tools in meiner IDE, um Probleme zu erkennen und ein besseres Verständnis für die von mir verwendeten Programmiersprachen und Bibliotheken zu erlangen.

Ich werde alle Tools, die ich erwähnen werde, kombiniert einsetzen:

  • IntelliJ Intents kann dabei helfen, häufige Code-Probleme sofort zu erkennen, die oft mit schnellen Korrekturen behoben werden können.
  • SpotBugs entdeckt einfache Fehler, die mir möglicherweise entgangen sind, und macht mich auf Leistungsprobleme aufmerksam.
  • SonarLint hat Java-Funktionen erkannt, die mir unbekannt waren, und mir vorgeschlagen, meinen Code mit anderen Methoden zu modellieren.
  • CheckStyle hilft mir dabei, den vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
  • Sensei , QuickFixes zu erstellen, um die von statischen Analysewerkzeugen erkannten häufigen Szenarien zu verbessern und bestimmte Projekte oder technische Lösungen zu erstellen, die in anderen Werkzeugen möglicherweise schwer zu konfigurieren sind.


---

Verwenden Sie „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows), um Sensei aus IntelliJ zu installieren, und Senseieinfach Senseisensei “.


Beispielcode und gängige Anwendungsfälle finden Sie im Repositorysensei des Secure Code Warrior


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

Erfahren Sie Sensei


Webinar ansehen
Fangen wir an.
mehr erfahren

Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.

Bericht anzeigenDemo buchen
Ressourcen anzeigen
Teilen auf:
LinkedIn-MarkenSozialx Logo
Interessiert an mehr?

Teilen auf:
LinkedIn-MarkenSozialx Logo
作者
Alan Richardson
Veröffentlicht Feb 01, 2021

Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.

Teilen auf:
LinkedIn-MarkenSozialx Logo

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.

Statische Analysen werden in der Regel verwendet, um Folgendes zu überprüfen:

  • Sicherheitslücke.
  • Leistungsprobleme.
  • Nichtbeachtung der Standards.
  • Verwendung veralteter Programmierstrukturen.

Wie funktioniert ein statisches Analysewerkzeug?

Das Grundkonzept aller statischen Analysewerkzeuge besteht darin, den Quellcode zu durchsuchen, um bestimmte Codierungsmuster zu identifizieren, die eine bestimmte Warnung oder relevante Informationen enthalten.

Das kann so einfach sein wie „JUnit 5-Testklassen müssen nicht öffentlich sein”. Oder etwas schwer Erkennbares wie „Verwendung nicht vertrauenswürdiger Zeichenfolgen in SQL-Ausführungsanweisungen”.

静态分析工具实现此功能的方式各不相同。

  • Technik zur Quellcodeanalyse zur Erstellung eines abstrakten Syntaxbaums (AST)
  • Text-Reguläre Ausdrücke-Übereinstimmung,
  • Die Kombination der oben genannten Punkte.

Reguläre Ausdrücke in Text sind sehr flexibel und lassen sich leicht schreiben, führen jedoch häufig zu einer Vielzahl von Fehlalarmen. Außerdem berücksichtigen sie den Kontext des umgebenden Codes nicht.

AST-Matching betrachtet den Quellcode als Programmcode und nicht nur als eine Datei voller Text. Dies ermöglicht eine genauere Kontextanpassung und reduziert die Anzahl der Fehlalarme in Bezug auf den Codebericht.

Statische Analyse in der kontinuierlichen Integration

Statische Analysen werden in der Regel im Rahmen der kontinuierlichen Integration (CI) durchgeführt, um Berichte über Konformitätsprobleme zu erstellen, die überprüft werden können, um einen objektiven Überblick über den Code-Bestand über einen bestimmten Zeitraum zu erhalten.

Einige Leute konfigurieren statische Analysewerkzeuge so, dass sie nur bestimmte Teile des Codes messen und nur einen Teil der Regeln melden, um die statische Analyse als objektiven Maßstab für ihre Codequalität zu verwenden.

Die Objektivität wird durch die verwendeten Regeln gewährleistet, da sich deren Bewertung des Codes im Laufe der Zeit nicht ändert. Natürlich ist die Kombination der verwendeten Regeln und deren Konfiguration eine subjektive Entscheidung, und verschiedene Teams entscheiden sich zu unterschiedlichen Zeitpunkten für unterschiedliche Regeln.

Die Durchführung statischer Analysen in CI ist nützlich, kann jedoch zu Verzögerungen bei der Rückmeldung an die Programmierer führen. Die Programmierer erhalten während des Codierens keine Rückmeldung, sondern erst später, wenn sie den Code mit einem statischen Analysewerkzeug ausführen. Ein weiterer Nebeneffekt der Durchführung statischer Analysen in CI ist, dass die Ergebnisse leichter übersehen werden können.

Um dem Team zu helfen, sich stärker auf die Ergebnisse der statischen Analyse zu konzentrieren, können während des Build-Prozesses Schwellenwerte konfiguriert werden, sodass bei Überschreiten dieser Werte (z. B. bei Auslösung vieler Regeln) ein Fehler generiert wird.

Statische Analyse in der IDE

Um schneller Feedback zu erhalten, gibt es zahlreiche IDE-Plugins, die statische Analyseregeln nach Bedarf in der IDE ausführen oder regelmäßig bei Codeänderungen ausführen können.

Wenn Programmierer dann Code schreiben, können sie in der IDE sehen, wenn gegen Regeln verstoßen wird. Um Regelverstöße noch deutlicher hervorzuheben, können diese so konfiguriert werden, dass sie im Editor als unterstrichener Code angezeigt werden.

Ich persönlich halte dies für eine nützliche Methode zur Verbesserung der Codierung, insbesondere bei der Verwendung neuer Bibliotheken, die von statischen Analysewerkzeugen abgedeckt werden. Auch wenn dies zu „Lärm“ in Form von Fehlalarmen oder für Sie uninteressanten Regeln führen kann, lässt sich dieses Problem durch zusätzliche Schritte zur Konfiguration des statischen Analysewerkzeugs beheben, sodass bestimmte Regeln ignoriert werden.

Code gemäß den Regeln der statischen Analyse korrigieren

Bei den meisten statischen Analysewerkzeugen bleibt die Behebung von Regelverstößen den Programmierern überlassen, sodass diese die Ursachen für Regelverstöße kennen und wissen müssen, wie diese zu beheben sind.

Nur wenige statische Analysewerkzeuge bieten auch Funktionen zur Behebung von Verstößen, da die Behebung in der Regel vom Team und den verwendeten Technologien sowie dem vereinbarten Codierungsstil abhängt.

Standardregel

Wenn statische Analysewerkzeuge mit Standardregeln geliefert werden, kann dies zu einem falschen Vertrauen in die Qualität der Regeln führen. Man neigt leicht dazu zu glauben, dass sie alle Probleme abdecken, auf die Programmierer stoßen könnten, sowie alle Situationen, in denen die Regeln angewendet werden sollten. Manchmal sind die Situationen, in denen die Regeln angewendet werden sollten, jedoch sehr subtil und möglicherweise nicht leicht zu erkennen.

Durch den Einsatz statischer Analysewerkzeuge können Programmierer ihre Fähigkeiten zum Erkennen und Vermeiden von Problemen in bestimmten Bereichen weiterentwickeln, indem sie Regeln und Regelverstöße genauer untersuchen.

Wenn Ihre Domäne Kontextregeln erfordert, verfügt das statische Analysewerkzeug möglicherweise über keine Regeln, die mit Ihrer Domäne oder Bibliothek übereinstimmen. Darüber hinaus sind diese Werkzeuge in der Regel schwer zu konfigurieren und zu erweitern.

Ärger

Diese „Sorgen“ sind nicht unüberwindbar:

  • falsch positives Ergebnis
  • Reparaturmangel
  • Konfiguration der Regel ignorieren
  • Kontextspezifische Regeln hinzufügen

Leider werden sie jedoch häufig als Vorwand genutzt, um den Einsatz statischer Analysewerkzeuge von vornherein zu vermeiden. Das ist bedauerlich, denn statische Analysen können sehr nützlich sein und Folgendes leisten:

  • Einführung in bessere Methoden für Anfänger
  • Schnelles Feedback zu offensichtlichen Verstößen gegen die Codierungsrichtlinien
  • Finden Sie unklare Probleme, denen Programmierer zuvor noch nie begegnet sind.
  • Hervorhebung der guten Programmiermethoden der Programmierer (wenn keine Verstöße gemeldet wurden)

IDE-basiertes statisches Analysewerkzeug

Als individueller Mitwirkender an Projekten verwende ich gerne statische Analysewerkzeuge, die in der IDE laufen, damit ich schnell Feedback zum Code erhalte.

Dies ergänzt alle möglichen Pull-Request-Prüfungsprozesse und CI-Integrationen des Projekts.

Ich werde versuchen, Tools zu finden, die mir Vorteile bringen, und meinen persönlichen Arbeitsablauf verbessern.

Wenn die Tools in der IDE ausgeführt werden, kann es verlockend sein, sie abwechselnd anzuzeigen, da sie oft dieselbe grundlegende GUI und dieselben Konfigurationsmethoden verwenden.

Diese Tools können sich in ihren Funktionen oder Regelsätzen überschneiden, aber um den größtmöglichen Nutzen zu erzielen, habe ich mehrere Tools installiert, um ihre Vorteile zu nutzen.

Nachfolgend sind die statischen Analyse-IDE-Tools aufgeführt, die ich beim Programmieren aktiv nutze:

  • Integrierte IntelliJ-Prüfung – Häufige Codierungsmuster
  • SpotBugs – Häufige Fehler
  • SonarLint – Häufige Anwendungsmuster
  • CheckStyle – Häufige Stilvorlagen
  • Secure Code Warrior von Secure Code Warrior – Erstellen benutzerdefinierter Regeln

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

IntelliJ-Prüfung

Wenn Sie IntelliJ verwenden, dann nutzen Sie bereits deren Überprüfungen.

Dies sind statische Analyseregeln, die in der IDE markiert sind. Einige davon verfügen auch über eine QuickFix-Option, mit der der Code überschrieben werden kann, um das Problem zu beheben.

Diese Regeln können aktiviert und deaktiviert werden, und es kann eine Fehlerstufe ausgewählt werden, um den Fehler in der IDE hervorzuheben.

Es gibt viele gute IntelliJ-Prüfungen. Ich weiß das, weil ich sie beim Schreiben dieses Artikels durchgelesen habe. Ich verwende die IntelliJ-Prüfungen als Standard, habe sie aber noch nicht konfiguriert. Um jedoch den vollen Nutzen aus den Prüfungen zu ziehen, sollten Sie sie durchlesen, die für Ihren Programmierstil relevanten Inhalte ermitteln und die Warnstufen so konfigurieren, dass Sie sie in Ihrem Code bemerken.

Die Vorteile der IntelliJ-Prüfungen liegen darin, dass sie in der IDE kostenlos zur Verfügung stehen und dabei helfen, in folgenden Bereichen Muskelgedächtnis aufzubauen:

  • Beim Schreiben von Code auf Warnungen und Fehler im Quellcode achten
  • Bewegen Sie den Mauszeiger über den markierten Code, um zu erfahren, gegen welche Regel verstoßen wurde.
  • Verwenden Sie Alt+Eingabetaste, um eine Schnellkorrektur auf das Problem anzuwenden.


SpotBug

Dieses SpotBug IntelliJ-Plugin verwendet statische Analyse, um Sie auf Fehler in Ihrem Code aufmerksam zu machen.

Sie können SpotBugs in den IntelliJ-Einstellungen so konfigurieren, dass es Ihren Code scannt. Die tatsächlich verwendeten Regeln finden Sie auf der Registerkarte „Detektoren“.

Nachdem ich meinen Code geschrieben und überprüft habe, neige ich dazu, SpotBugs zu verwenden, und dann führe ich „Projektdateien einschließlich Testquellen analysieren“ aus.

Das hilft mir tatsächlich dabei, Fehler, toten Code und offensichtliche Optimierungen zu erkennen. Außerdem zwingt es mich dazu, einige gemeldete Verstöße zu untersuchen, um zu entscheiden, wie ich vorgehen soll.

SpotBugs erkennt Probleme, bietet jedoch keine QuickFix-Maßnahmen zur Behebung dieser Probleme an.

SpotBugs ist einfach zu konfigurieren, und ich habe festgestellt, dass ich in meiner IDE eine objektive zweite Meinung einholen kann.

SonarLint

Dieses SonarLint-Plugin.

SonarLint kann in den IntelliJ-Einstellungen konfiguriert werden, um auszuwählen, nach welchen Regeln der Code überprüft werden soll.

Standardmäßig läuft SonarLint in Echtzeit und zeigt Probleme im aktuell bearbeiteten Code an.

SonarLint bietet keine Schnellkorrekturen, aber die Dokumentation zu den Verstößen ist in der Regel klar und nachvollziehbar.

In der Vergangenheit habe ich festgestellt, dass SonarLint sehr nützlich ist, um mich auf neue Java-Funktionen in neueren Java-Versionen aufmerksam zu machen.

Stil überprüfen

Dieses Plugin im Check-Stil bietet eine Kombination aus Formatierungs- und Codequalitätsregeln.

Das CheckStyle-Plugin ist mit „Sun Checks“ und „Google Checks“ gebündelt.

Die Definitionen dafür sindleicht im Internet zu finden.

CheckStyle bietet den größten Mehrwert, wenn Projekte Zeit in die Erstellung eigener Regelsätze investieren. Anschließend kann das IDE-Plugin so konfiguriert werden, dass es diesen Regelsatz verwendet, und Programmierer können vor dem Einchecken ihres Codes in die CI einen Scan durchführen.

Wenn die Anzahl der CheckStyle-Verstöße den Schwellenwert überschreitet, wird CheckStyle in der Regel als Plugin für den Build-Fehler des CI-Prozesses verwendet.

Lehrer

Der Lehrer verwendet statische Analysen auf Basis abstrakter Syntaxbäume (AST), um Code abzugleichen und QuickFixes zu erstellen, wodurch problematischer Code sehr konkret identifiziert werden kann.

AST ermöglicht QuickFixes in Verbindung mit Formeln, die den umgebenden Code verstehen. Wenn beispielsweise eine neue Klasse zum Code hinzugefügt wird, werden alle Importe dieser Klasse nur einmal zur Quelldatei hinzugefügt und nicht bei jeder Ersetzung.

Sensei , um die Erstellung benutzerdefinierter Übereinstimmungsregeln zu vereinfachen, die in anderen Tools möglicherweise nicht vorhanden oder schwer zu konfigurieren sind.

Alle Konfigurationen können in der GUI vorgenommen werden, ohne dass die Konfigurationsdatei geändert werden muss. Beim Erstellen einer neuen Konfiguration kann die GUI den Code, der zur Konfiguration passt, leicht anzeigen. Beim Definieren von QuickFixes kann der Zustand des Codes vor und nach der Änderung sofort verglichen werden. Dies erleichtert die Erstellung von Rezepten, die genau auf die jeweilige Situation zugeschnitten sind, d. h. auf das Team, die Technologie oder sogar den einzelnen Programmierer.

Ich verwende Sensei . Die meisten statischen Analysewerkzeuge finden zwar Probleme, können diese jedoch nicht beheben.Sensei , die Übereinstimmungssuche anderer Werkzeuge Sensei zu kopieren und diese dann mit Quick Fix zu erweitern. Der Vorteil dabei ist, dass die benutzerdefinierten Korrekturen der Anwendung bereits den Codierungsstandards des Projekts entsprechen.

Ich stelle oft fest, dass Sensei von mir erstellten Sensei bereits in der IntelliJ Intensions-Sammlung vorhanden sind. Das liegt daran, dass die Intension-Berichte nicht ganz mit dem von mir erstellten Kontext übereinstimmen oder dass die von IntelliJ angebotenen QuickFixes nicht mit den von mir gewünschten Codemustern übereinstimmen.

Ich habe die vorhandenen Tools erweitert, anstatt zu versuchen, sie vollständig zu ersetzen.

Sensei , wenn Sie Kontextvarianten gängiger Regeln erkennen. Wenn Sie beispielsweise eine SQL-Bibliothek verwenden, die von statischen Analysewerkzeugen nicht unterstützt wird, aber die gängigen SQL-Regeln in der statischen Analyse-Engine dennoch zutreffen, können Sie Sensei bibliotheksspezifische Varianten dieser Regeln Sensei .

Sensei verfügt nicht über viele vorgefertigte allgemeine Vorlagen wie die erwähnten statischen Analyse-Tools. Sein Vorteil besteht darin, dass Sie ganz einfach neue Vorlagen erstellen und QuickFixes so konfigurieren können, dass sie Ihrem spezifischen Programmierstil und Ihren Anwendungsfällen entsprechen.

Hinweis: Wir entwickeln derzeit ein öffentliches Rezept-Repository, das allgemeine Anwendungsfälle abdeckt, sowie Sie finden es hier.

Zusammenfassung

Ich bevorzuge Tools, die zusammenarbeiten, konfigurierbar und leicht erweiterbar sind, um meinen spezifischen Anforderungen gerecht zu werden. Seit Jahren verwende ich statische Analyse-Tools in meiner IDE, um Probleme zu erkennen und ein besseres Verständnis für die von mir verwendeten Programmiersprachen und Bibliotheken zu erlangen.

Ich werde alle Tools, die ich erwähnen werde, kombiniert einsetzen:

  • IntelliJ Intents kann dabei helfen, häufige Code-Probleme sofort zu erkennen, die oft mit schnellen Korrekturen behoben werden können.
  • SpotBugs entdeckt einfache Fehler, die mir möglicherweise entgangen sind, und macht mich auf Leistungsprobleme aufmerksam.
  • SonarLint hat Java-Funktionen erkannt, die mir unbekannt waren, und mir vorgeschlagen, meinen Code mit anderen Methoden zu modellieren.
  • CheckStyle hilft mir dabei, den vereinbarten Codierungsstil einzuhalten, der auch während der CI durchgesetzt wird.
  • Sensei , QuickFixes zu erstellen, um die von statischen Analysewerkzeugen erkannten häufigen Szenarien zu verbessern und bestimmte Projekte oder technische Lösungen zu erstellen, die in anderen Werkzeugen möglicherweise schwer zu konfigurieren sind.


---

Verwenden Sie „Einstellungen\Plugins“ (Mac) oder „Einstellungen\Plugins“ (Windows), um Sensei aus IntelliJ zu installieren, und Senseieinfach Senseisensei “.


Beispielcode und gängige Anwendungsfälle finden Sie im Repositorysensei des Secure Code Warrior


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

Erfahren Sie Sensei


Verzeichnis

PDF herunterladen
Ressourcen anzeigen
Interessiert an mehr?

Alan Richardson verfügt über mehr als zwanzig Jahre Berufserfahrung in der IT-Branche. Er arbeitete als Entwickler und auf jeder Ebene der Testhierarchie, vom Tester bis hin zum Head of Testing. Als Head of Developer Relations bei Secure Code Warrior arbeitet er direkt mit Teams zusammen, um die Entwicklung von hochwertigem, sicherem Code zu verbessern. Alan ist der Autor von vier Büchern, darunter "Dear Evil Tester" und "Java For Testers". Alan hat auch Online-Schulungen courses erstellt, um Menschen beim Erlernen von technischen Web-Tests und Selenium WebDriver mit Java zu helfen. Alan veröffentlicht seine Schriften und Schulungsvideos auf SeleniumSimplified.com, EvilTester.com, JavaForTesters.com und CompendiumDev.co.uk.

mehr erfahren

Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.

Demo buchen下载
Teilen auf:
LinkedIn-MarkenSozialx Logo
Ressourcenzentrum

Ressourcen, die Ihnen den Einstieg erleichtern

Weitere Beiträge
Ressourcenzentrum

Ressourcen, die Ihnen den Einstieg erleichtern

Weitere Beiträge