Ausführen von IntelliJ-Inspektionen aus der kontinuierlichen Integration
Ausführen von IntelliJ-Inspektionen aus der kontinuierlichen Integration
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung, innerhalb der IDE beim Schreiben von Code als Intentions. Intentions können im Batch verwendet werden, um den Code auf Muster im gesamten Quellcode zu untersuchen und sogar auf die Befehlszeilenanalyse erweitert oder zur kontinuierlichen Integration hinzugefügt werden. Dieser Beitrag befasst sich mit der IntelliJ-Out-of-the-Box-Funktionalität und der Erweiterung mit benutzerdefinierten Intentions, die in Sensei erstellt wurden.
IntelliJ-Prüfungen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler der Fehler, die dynamisch in der IDE beim Codieren gemeldet werden, z. B.
- Erkennung von abstrakten Klassen, die in Interfaces umgewandelt werden können,
- Identifizierung redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung von veralteten Methoden,
- usw.
Diese Inspektionen markieren in der IDE übereinstimmenden Code als Intention Actions, die oft einen zugehörigen QuickFix haben.
Die Echtzeit-IDE, die hervorhebt, wenn Code mit einer Inspection übereinstimmt, kann uns helfen, unseren Code dynamisch zu verbessern. Nachdem das Problem im Code identifiziert wurde, kann die Verwendung von IntelliJ Intention Actions zum QuickFixen des Codes bessere Muster verstärken.
Inspektionen Profil
Inspektionen können als Batch aus der IDE, von der Kommandozeile oder in einem kontinuierlichen Integrationsprozess ausgeführt werden.
Der Schlüssel zur Arbeit mit IntelliJ-Inspektionen als Batch ist die Verwendung eines Inspektionsprofils.
IntelliJ hat zwei Standard-Prüfprofile: eines, das im Projekt gespeichert ist, und eines, das in der IDE gespeichert ist.
Neue Inspektionsprofile können erstellt werden, um bestimmte Plugins oder Anwendungsfälle zu konfigurieren, z. B.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Ausführen eines bestimmten Satzes von Sensei Regeln
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Voreinstellungen aktiviert oder deaktiviert werden. Das Dialogfeld "Einstellungen" ist auch eine einfache Möglichkeit, den Umfang der verfügbaren Inspektionen kennenzulernen.
Mit dem "Werkzeug"-Symbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um einen bestimmten Satz von Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können aus der IDE heraus über das Menü "Analysieren" "Code inspizieren" ausgeführt werden.
Mit der Funktion "Analysieren" können Sie den Umfang der Inspektion steuern, z. B. das gesamte Projekt, einschließlich oder ausschließlich der Testquellen, oder eine bestimmte Gruppe von Dateien.
Von hier aus können Sie auch die Inspektionsprofile verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialog "Inspektionsumfang festlegen" auf [OK] klicken, veranlasst IntelliJ die Ausführung aller ausgewählten Inspektionen im Profil über den definierten Umfang.
IntelliJ meldet die Ergebnisse der ausgeführten Inspektionen auf der Registerkarte "Inspektionsergebnisse".
Das Sensei Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, so dass diese benutzerdefinierten Rezepte so natürlich wie die IntelliJ Intention Actions verwendet werden können. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mit Hilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion "Analyze Inspect Code" ist der empfohlene Weg, um Sensei Rezepte in einem Projekt in großen Mengen auszuführen.
Ausführen eines Prüfprofils über die Befehlszeile
IntelliJ hat die Möglichkeit, Inspektionen von der Kommandozeile auszuführen, wie von JetBrains dokumentiert:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Ich verwende hauptsächlich macOS und kann eine einzelne Instanz von IntelliJ von der Kommandozeile aus starten mit:
open -na "IntelliJ IDEA CE.app"
Um die Ausführung zu erleichtern, füge ich dies zu einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Ich habe dann diese ausführbare Datei erstellt, um den Prozess der Befehlszeileninspektion zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offizielle intellij-Dokumentation beschreibt die allgemeine Form des Inspektionsbefehls wie folgt:
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
In der Praxis qualifiziere ich die Pfade vollständig und benötige keine Optionen:
idea inspect /Benutzer/Benutzer/GitHub/sensei-blog-examples /Benutzer/Benutzer/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Benutzer/Benutzer/GitHub/sensei-blog-examples/scan-results
Dies führt alle Inspektionen aus, die ich zum `senseiprofile` hinzugefügt habe und meldet die Ergebnisse im Ordner `scan-results`.
Anzeigen der Inspektionsergebnisse
Wir können diese Ergebnisse aus der Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch innerhalb von IntelliJ selbst anzeigen, indem wir die Funktion "Analyse" verwenden, um Offline-Inspektionsergebnisse anzuzeigen...
Dadurch werden die Ergebnisse in die Registerkarte "Inspektionsergebnisse" geladen.
Dies ist offiziell auf der JetBrains-Seite dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies könnte während eines Code-Review-Prozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess eingebunden ist und die Reviewer den vollständigen Quellkontext eines beliebigen Eintrags des Inspektionsergebnisses überprüfen möchten.
Prüfprofile in der kontinuierlichen Integration
Wenn wir die Befehlszeileninspektion in die kontinuierliche Integration einbinden, wollen wir idealerweise, dass ein Bericht automatisch generiert wird, und es gibt eine Reihe von Optionen, die uns zur Verfügung stehen.
TeamCity bietet out of the box Unterstützung für Inspection Profiles in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG Plugin unterstützt die Kommandozeilenausgabe von IntelliJ Inspections als eines der Berichtsformate.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Community-Projekte wie `idea CLI Inspector` existieren, um die Verwendung von Inspektionsprofilen in anderen CI-Werkzeugen zu unterstützen, z.B.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft von Inspection Profiles in einem CI-Prozess sieht mit der Einführung des Qodana-Projekts von JetBrains noch rosiger aus. Das Qodana-Projekt ist eine Headless-Version von IntelliJ mit offiziellen Github-Aktionen und Docker-Images.
- https://github.com/JetBrains/Qodana
Qodana befindet sich derzeit in der Betaphase, aber das Team von Sensei überwacht es, damit es eine offiziell unterstützte Plattform für die Ausführung von Sensei Regeln als Teil der kontinuierlichen Integration wird.
Zusammenfassung
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mit Inspection Profiles können wir diese in Profilen sammeln, die im Batch als Aktion "Analyze and Inspect Code" ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und doppelt überprüfen wollen, ob wir es irgendwo anders in unserem Code übersehen haben.
Inspection Profiles können von der Kommandozeile aus ausgeführt und sogar in Continuous-Integration-Prozesse eingebunden werden, die ein "Trust, but Verify"-Modell unterstützen und jeden versehentlichen Ausrutscher abfangen.
Alle oben genannten Funktionen sind in IntelliJ integriert und JetBrains verbessern ihren Continuous Integration Prozess mit der Einführung von Qodana.
Sensei Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren und in Inspection Profiles gesammelt zu werden, um die Batch-Prüfung durch Inspect Code und die Unterstützung der kontinuierlichen Integration durch die offizielle JetBrains Command Line Ausführungsfunktionalität zu unterstützen.
---
Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.
Wenn Sie versuchen möchten, ein Projekt in IntelliJ von der Kommandozeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior . Eine Übung für den Leser ist es, ein Profil zu erstellen, das nur die Sensei Regeln ausführt. Probieren Sie es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Lernen Sie, wie Sie Sensei und IntelliJ Intention Actions im Batch-Modus als Inspektionen innerhalb der IDE, von der Kommandozeile und in der kontinuierlichen Integration ausführen können.
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.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
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.
Ausführen von IntelliJ-Inspektionen aus der kontinuierlichen Integration
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung, innerhalb der IDE beim Schreiben von Code als Intentions. Intentions können im Batch verwendet werden, um den Code auf Muster im gesamten Quellcode zu untersuchen und sogar auf die Befehlszeilenanalyse erweitert oder zur kontinuierlichen Integration hinzugefügt werden. Dieser Beitrag befasst sich mit der IntelliJ-Out-of-the-Box-Funktionalität und der Erweiterung mit benutzerdefinierten Intentions, die in Sensei erstellt wurden.
IntelliJ-Prüfungen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler der Fehler, die dynamisch in der IDE beim Codieren gemeldet werden, z. B.
- Erkennung von abstrakten Klassen, die in Interfaces umgewandelt werden können,
- Identifizierung redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung von veralteten Methoden,
- usw.
Diese Inspektionen markieren in der IDE übereinstimmenden Code als Intention Actions, die oft einen zugehörigen QuickFix haben.
Die Echtzeit-IDE, die hervorhebt, wenn Code mit einer Inspection übereinstimmt, kann uns helfen, unseren Code dynamisch zu verbessern. Nachdem das Problem im Code identifiziert wurde, kann die Verwendung von IntelliJ Intention Actions zum QuickFixen des Codes bessere Muster verstärken.
Inspektionen Profil
Inspektionen können als Batch aus der IDE, von der Kommandozeile oder in einem kontinuierlichen Integrationsprozess ausgeführt werden.
Der Schlüssel zur Arbeit mit IntelliJ-Inspektionen als Batch ist die Verwendung eines Inspektionsprofils.
IntelliJ hat zwei Standard-Prüfprofile: eines, das im Projekt gespeichert ist, und eines, das in der IDE gespeichert ist.
Neue Inspektionsprofile können erstellt werden, um bestimmte Plugins oder Anwendungsfälle zu konfigurieren, z. B.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Ausführen eines bestimmten Satzes von Sensei Regeln
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Voreinstellungen aktiviert oder deaktiviert werden. Das Dialogfeld "Einstellungen" ist auch eine einfache Möglichkeit, den Umfang der verfügbaren Inspektionen kennenzulernen.
Mit dem "Werkzeug"-Symbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um einen bestimmten Satz von Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können aus der IDE heraus über das Menü "Analysieren" "Code inspizieren" ausgeführt werden.
Mit der Funktion "Analysieren" können Sie den Umfang der Inspektion steuern, z. B. das gesamte Projekt, einschließlich oder ausschließlich der Testquellen, oder eine bestimmte Gruppe von Dateien.
Von hier aus können Sie auch die Inspektionsprofile verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialog "Inspektionsumfang festlegen" auf [OK] klicken, veranlasst IntelliJ die Ausführung aller ausgewählten Inspektionen im Profil über den definierten Umfang.
IntelliJ meldet die Ergebnisse der ausgeführten Inspektionen auf der Registerkarte "Inspektionsergebnisse".
Das Sensei Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, so dass diese benutzerdefinierten Rezepte so natürlich wie die IntelliJ Intention Actions verwendet werden können. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mit Hilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion "Analyze Inspect Code" ist der empfohlene Weg, um Sensei Rezepte in einem Projekt in großen Mengen auszuführen.
Ausführen eines Prüfprofils über die Befehlszeile
IntelliJ hat die Möglichkeit, Inspektionen von der Kommandozeile auszuführen, wie von JetBrains dokumentiert:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Ich verwende hauptsächlich macOS und kann eine einzelne Instanz von IntelliJ von der Kommandozeile aus starten mit:
open -na "IntelliJ IDEA CE.app"
Um die Ausführung zu erleichtern, füge ich dies zu einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Ich habe dann diese ausführbare Datei erstellt, um den Prozess der Befehlszeileninspektion zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offizielle intellij-Dokumentation beschreibt die allgemeine Form des Inspektionsbefehls wie folgt:
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
In der Praxis qualifiziere ich die Pfade vollständig und benötige keine Optionen:
idea inspect /Benutzer/Benutzer/GitHub/sensei-blog-examples /Benutzer/Benutzer/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Benutzer/Benutzer/GitHub/sensei-blog-examples/scan-results
Dies führt alle Inspektionen aus, die ich zum `senseiprofile` hinzugefügt habe und meldet die Ergebnisse im Ordner `scan-results`.
Anzeigen der Inspektionsergebnisse
Wir können diese Ergebnisse aus der Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch innerhalb von IntelliJ selbst anzeigen, indem wir die Funktion "Analyse" verwenden, um Offline-Inspektionsergebnisse anzuzeigen...
Dadurch werden die Ergebnisse in die Registerkarte "Inspektionsergebnisse" geladen.
Dies ist offiziell auf der JetBrains-Seite dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies könnte während eines Code-Review-Prozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess eingebunden ist und die Reviewer den vollständigen Quellkontext eines beliebigen Eintrags des Inspektionsergebnisses überprüfen möchten.
Prüfprofile in der kontinuierlichen Integration
Wenn wir die Befehlszeileninspektion in die kontinuierliche Integration einbinden, wollen wir idealerweise, dass ein Bericht automatisch generiert wird, und es gibt eine Reihe von Optionen, die uns zur Verfügung stehen.
TeamCity bietet out of the box Unterstützung für Inspection Profiles in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG Plugin unterstützt die Kommandozeilenausgabe von IntelliJ Inspections als eines der Berichtsformate.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Community-Projekte wie `idea CLI Inspector` existieren, um die Verwendung von Inspektionsprofilen in anderen CI-Werkzeugen zu unterstützen, z.B.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft von Inspection Profiles in einem CI-Prozess sieht mit der Einführung des Qodana-Projekts von JetBrains noch rosiger aus. Das Qodana-Projekt ist eine Headless-Version von IntelliJ mit offiziellen Github-Aktionen und Docker-Images.
- https://github.com/JetBrains/Qodana
Qodana befindet sich derzeit in der Betaphase, aber das Team von Sensei überwacht es, damit es eine offiziell unterstützte Plattform für die Ausführung von Sensei Regeln als Teil der kontinuierlichen Integration wird.
Zusammenfassung
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mit Inspection Profiles können wir diese in Profilen sammeln, die im Batch als Aktion "Analyze and Inspect Code" ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und doppelt überprüfen wollen, ob wir es irgendwo anders in unserem Code übersehen haben.
Inspection Profiles können von der Kommandozeile aus ausgeführt und sogar in Continuous-Integration-Prozesse eingebunden werden, die ein "Trust, but Verify"-Modell unterstützen und jeden versehentlichen Ausrutscher abfangen.
Alle oben genannten Funktionen sind in IntelliJ integriert und JetBrains verbessern ihren Continuous Integration Prozess mit der Einführung von Qodana.
Sensei Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren und in Inspection Profiles gesammelt zu werden, um die Batch-Prüfung durch Inspect Code und die Unterstützung der kontinuierlichen Integration durch die offizielle JetBrains Command Line Ausführungsfunktionalität zu unterstützen.
---
Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.
Wenn Sie versuchen möchten, ein Projekt in IntelliJ von der Kommandozeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior . Eine Übung für den Leser ist es, ein Profil zu erstellen, das nur die Sensei Regeln ausführt. Probieren Sie es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Ausführen von IntelliJ-Inspektionen aus der kontinuierlichen Integration
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung, innerhalb der IDE beim Schreiben von Code als Intentions. Intentions können im Batch verwendet werden, um den Code auf Muster im gesamten Quellcode zu untersuchen und sogar auf die Befehlszeilenanalyse erweitert oder zur kontinuierlichen Integration hinzugefügt werden. Dieser Beitrag befasst sich mit der IntelliJ-Out-of-the-Box-Funktionalität und der Erweiterung mit benutzerdefinierten Intentions, die in Sensei erstellt wurden.
IntelliJ-Prüfungen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler der Fehler, die dynamisch in der IDE beim Codieren gemeldet werden, z. B.
- Erkennung von abstrakten Klassen, die in Interfaces umgewandelt werden können,
- Identifizierung redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung von veralteten Methoden,
- usw.
Diese Inspektionen markieren in der IDE übereinstimmenden Code als Intention Actions, die oft einen zugehörigen QuickFix haben.
Die Echtzeit-IDE, die hervorhebt, wenn Code mit einer Inspection übereinstimmt, kann uns helfen, unseren Code dynamisch zu verbessern. Nachdem das Problem im Code identifiziert wurde, kann die Verwendung von IntelliJ Intention Actions zum QuickFixen des Codes bessere Muster verstärken.
Inspektionen Profil
Inspektionen können als Batch aus der IDE, von der Kommandozeile oder in einem kontinuierlichen Integrationsprozess ausgeführt werden.
Der Schlüssel zur Arbeit mit IntelliJ-Inspektionen als Batch ist die Verwendung eines Inspektionsprofils.
IntelliJ hat zwei Standard-Prüfprofile: eines, das im Projekt gespeichert ist, und eines, das in der IDE gespeichert ist.
Neue Inspektionsprofile können erstellt werden, um bestimmte Plugins oder Anwendungsfälle zu konfigurieren, z. B.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Ausführen eines bestimmten Satzes von Sensei Regeln
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Voreinstellungen aktiviert oder deaktiviert werden. Das Dialogfeld "Einstellungen" ist auch eine einfache Möglichkeit, den Umfang der verfügbaren Inspektionen kennenzulernen.
Mit dem "Werkzeug"-Symbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um einen bestimmten Satz von Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können aus der IDE heraus über das Menü "Analysieren" "Code inspizieren" ausgeführt werden.
Mit der Funktion "Analysieren" können Sie den Umfang der Inspektion steuern, z. B. das gesamte Projekt, einschließlich oder ausschließlich der Testquellen, oder eine bestimmte Gruppe von Dateien.
Von hier aus können Sie auch die Inspektionsprofile verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialog "Inspektionsumfang festlegen" auf [OK] klicken, veranlasst IntelliJ die Ausführung aller ausgewählten Inspektionen im Profil über den definierten Umfang.
IntelliJ meldet die Ergebnisse der ausgeführten Inspektionen auf der Registerkarte "Inspektionsergebnisse".
Das Sensei Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, so dass diese benutzerdefinierten Rezepte so natürlich wie die IntelliJ Intention Actions verwendet werden können. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mit Hilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion "Analyze Inspect Code" ist der empfohlene Weg, um Sensei Rezepte in einem Projekt in großen Mengen auszuführen.
Ausführen eines Prüfprofils über die Befehlszeile
IntelliJ hat die Möglichkeit, Inspektionen von der Kommandozeile auszuführen, wie von JetBrains dokumentiert:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Ich verwende hauptsächlich macOS und kann eine einzelne Instanz von IntelliJ von der Kommandozeile aus starten mit:
open -na "IntelliJ IDEA CE.app"
Um die Ausführung zu erleichtern, füge ich dies zu einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Ich habe dann diese ausführbare Datei erstellt, um den Prozess der Befehlszeileninspektion zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offizielle intellij-Dokumentation beschreibt die allgemeine Form des Inspektionsbefehls wie folgt:
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
In der Praxis qualifiziere ich die Pfade vollständig und benötige keine Optionen:
idea inspect /Benutzer/Benutzer/GitHub/sensei-blog-examples /Benutzer/Benutzer/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Benutzer/Benutzer/GitHub/sensei-blog-examples/scan-results
Dies führt alle Inspektionen aus, die ich zum `senseiprofile` hinzugefügt habe und meldet die Ergebnisse im Ordner `scan-results`.
Anzeigen der Inspektionsergebnisse
Wir können diese Ergebnisse aus der Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch innerhalb von IntelliJ selbst anzeigen, indem wir die Funktion "Analyse" verwenden, um Offline-Inspektionsergebnisse anzuzeigen...
Dadurch werden die Ergebnisse in die Registerkarte "Inspektionsergebnisse" geladen.
Dies ist offiziell auf der JetBrains-Seite dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies könnte während eines Code-Review-Prozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess eingebunden ist und die Reviewer den vollständigen Quellkontext eines beliebigen Eintrags des Inspektionsergebnisses überprüfen möchten.
Prüfprofile in der kontinuierlichen Integration
Wenn wir die Befehlszeileninspektion in die kontinuierliche Integration einbinden, wollen wir idealerweise, dass ein Bericht automatisch generiert wird, und es gibt eine Reihe von Optionen, die uns zur Verfügung stehen.
TeamCity bietet out of the box Unterstützung für Inspection Profiles in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG Plugin unterstützt die Kommandozeilenausgabe von IntelliJ Inspections als eines der Berichtsformate.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Community-Projekte wie `idea CLI Inspector` existieren, um die Verwendung von Inspektionsprofilen in anderen CI-Werkzeugen zu unterstützen, z.B.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft von Inspection Profiles in einem CI-Prozess sieht mit der Einführung des Qodana-Projekts von JetBrains noch rosiger aus. Das Qodana-Projekt ist eine Headless-Version von IntelliJ mit offiziellen Github-Aktionen und Docker-Images.
- https://github.com/JetBrains/Qodana
Qodana befindet sich derzeit in der Betaphase, aber das Team von Sensei überwacht es, damit es eine offiziell unterstützte Plattform für die Ausführung von Sensei Regeln als Teil der kontinuierlichen Integration wird.
Zusammenfassung
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mit Inspection Profiles können wir diese in Profilen sammeln, die im Batch als Aktion "Analyze and Inspect Code" ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und doppelt überprüfen wollen, ob wir es irgendwo anders in unserem Code übersehen haben.
Inspection Profiles können von der Kommandozeile aus ausgeführt und sogar in Continuous-Integration-Prozesse eingebunden werden, die ein "Trust, but Verify"-Modell unterstützen und jeden versehentlichen Ausrutscher abfangen.
Alle oben genannten Funktionen sind in IntelliJ integriert und JetBrains verbessern ihren Continuous Integration Prozess mit der Einführung von Qodana.
Sensei Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren und in Inspection Profiles gesammelt zu werden, um die Batch-Prüfung durch Inspect Code und die Unterstützung der kontinuierlichen Integration durch die offizielle JetBrains Command Line Ausführungsfunktionalität zu unterstützen.
---
Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.
Wenn Sie versuchen möchten, ein Projekt in IntelliJ von der Kommandozeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior . Eine Übung für den Leser ist es, ein Profil zu erstellen, das nur die Sensei Regeln ausführt. Probieren Sie es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
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.
Ausführen von IntelliJ-Inspektionen aus der kontinuierlichen Integration
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung, innerhalb der IDE beim Schreiben von Code als Intentions. Intentions können im Batch verwendet werden, um den Code auf Muster im gesamten Quellcode zu untersuchen und sogar auf die Befehlszeilenanalyse erweitert oder zur kontinuierlichen Integration hinzugefügt werden. Dieser Beitrag befasst sich mit der IntelliJ-Out-of-the-Box-Funktionalität und der Erweiterung mit benutzerdefinierten Intentions, die in Sensei erstellt wurden.
IntelliJ-Prüfungen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler der Fehler, die dynamisch in der IDE beim Codieren gemeldet werden, z. B.
- Erkennung von abstrakten Klassen, die in Interfaces umgewandelt werden können,
- Identifizierung redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung von veralteten Methoden,
- usw.
Diese Inspektionen markieren in der IDE übereinstimmenden Code als Intention Actions, die oft einen zugehörigen QuickFix haben.
Die Echtzeit-IDE, die hervorhebt, wenn Code mit einer Inspection übereinstimmt, kann uns helfen, unseren Code dynamisch zu verbessern. Nachdem das Problem im Code identifiziert wurde, kann die Verwendung von IntelliJ Intention Actions zum QuickFixen des Codes bessere Muster verstärken.
Inspektionen Profil
Inspektionen können als Batch aus der IDE, von der Kommandozeile oder in einem kontinuierlichen Integrationsprozess ausgeführt werden.
Der Schlüssel zur Arbeit mit IntelliJ-Inspektionen als Batch ist die Verwendung eines Inspektionsprofils.
IntelliJ hat zwei Standard-Prüfprofile: eines, das im Projekt gespeichert ist, und eines, das in der IDE gespeichert ist.
Neue Inspektionsprofile können erstellt werden, um bestimmte Plugins oder Anwendungsfälle zu konfigurieren, z. B.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Ausführen eines bestimmten Satzes von Sensei Regeln
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Voreinstellungen aktiviert oder deaktiviert werden. Das Dialogfeld "Einstellungen" ist auch eine einfache Möglichkeit, den Umfang der verfügbaren Inspektionen kennenzulernen.
Mit dem "Werkzeug"-Symbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um einen bestimmten Satz von Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können aus der IDE heraus über das Menü "Analysieren" "Code inspizieren" ausgeführt werden.
Mit der Funktion "Analysieren" können Sie den Umfang der Inspektion steuern, z. B. das gesamte Projekt, einschließlich oder ausschließlich der Testquellen, oder eine bestimmte Gruppe von Dateien.
Von hier aus können Sie auch die Inspektionsprofile verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialog "Inspektionsumfang festlegen" auf [OK] klicken, veranlasst IntelliJ die Ausführung aller ausgewählten Inspektionen im Profil über den definierten Umfang.
IntelliJ meldet die Ergebnisse der ausgeführten Inspektionen auf der Registerkarte "Inspektionsergebnisse".
Das Sensei Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, so dass diese benutzerdefinierten Rezepte so natürlich wie die IntelliJ Intention Actions verwendet werden können. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mit Hilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion "Analyze Inspect Code" ist der empfohlene Weg, um Sensei Rezepte in einem Projekt in großen Mengen auszuführen.
Ausführen eines Prüfprofils über die Befehlszeile
IntelliJ hat die Möglichkeit, Inspektionen von der Kommandozeile auszuführen, wie von JetBrains dokumentiert:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Ich verwende hauptsächlich macOS und kann eine einzelne Instanz von IntelliJ von der Kommandozeile aus starten mit:
open -na "IntelliJ IDEA CE.app"
Um die Ausführung zu erleichtern, füge ich dies zu einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Ich habe dann diese ausführbare Datei erstellt, um den Prozess der Befehlszeileninspektion zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offizielle intellij-Dokumentation beschreibt die allgemeine Form des Inspektionsbefehls wie folgt:
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
In der Praxis qualifiziere ich die Pfade vollständig und benötige keine Optionen:
idea inspect /Benutzer/Benutzer/GitHub/sensei-blog-examples /Benutzer/Benutzer/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Benutzer/Benutzer/GitHub/sensei-blog-examples/scan-results
Dies führt alle Inspektionen aus, die ich zum `senseiprofile` hinzugefügt habe und meldet die Ergebnisse im Ordner `scan-results`.
Anzeigen der Inspektionsergebnisse
Wir können diese Ergebnisse aus der Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch innerhalb von IntelliJ selbst anzeigen, indem wir die Funktion "Analyse" verwenden, um Offline-Inspektionsergebnisse anzuzeigen...
Dadurch werden die Ergebnisse in die Registerkarte "Inspektionsergebnisse" geladen.
Dies ist offiziell auf der JetBrains-Seite dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies könnte während eines Code-Review-Prozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess eingebunden ist und die Reviewer den vollständigen Quellkontext eines beliebigen Eintrags des Inspektionsergebnisses überprüfen möchten.
Prüfprofile in der kontinuierlichen Integration
Wenn wir die Befehlszeileninspektion in die kontinuierliche Integration einbinden, wollen wir idealerweise, dass ein Bericht automatisch generiert wird, und es gibt eine Reihe von Optionen, die uns zur Verfügung stehen.
TeamCity bietet out of the box Unterstützung für Inspection Profiles in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG Plugin unterstützt die Kommandozeilenausgabe von IntelliJ Inspections als eines der Berichtsformate.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Community-Projekte wie `idea CLI Inspector` existieren, um die Verwendung von Inspektionsprofilen in anderen CI-Werkzeugen zu unterstützen, z.B.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft von Inspection Profiles in einem CI-Prozess sieht mit der Einführung des Qodana-Projekts von JetBrains noch rosiger aus. Das Qodana-Projekt ist eine Headless-Version von IntelliJ mit offiziellen Github-Aktionen und Docker-Images.
- https://github.com/JetBrains/Qodana
Qodana befindet sich derzeit in der Betaphase, aber das Team von Sensei überwacht es, damit es eine offiziell unterstützte Plattform für die Ausführung von Sensei Regeln als Teil der kontinuierlichen Integration wird.
Zusammenfassung
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mit Inspection Profiles können wir diese in Profilen sammeln, die im Batch als Aktion "Analyze and Inspect Code" ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und doppelt überprüfen wollen, ob wir es irgendwo anders in unserem Code übersehen haben.
Inspection Profiles können von der Kommandozeile aus ausgeführt und sogar in Continuous-Integration-Prozesse eingebunden werden, die ein "Trust, but Verify"-Modell unterstützen und jeden versehentlichen Ausrutscher abfangen.
Alle oben genannten Funktionen sind in IntelliJ integriert und JetBrains verbessern ihren Continuous Integration Prozess mit der Einführung von Qodana.
Sensei Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren und in Inspection Profiles gesammelt zu werden, um die Batch-Prüfung durch Inspect Code und die Unterstützung der kontinuierlichen Integration durch die offizielle JetBrains Command Line Ausführungsfunktionalität zu unterstützen.
---
Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.
Wenn Sie versuchen möchten, ein Projekt in IntelliJ von der Kommandozeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior . Eine Übung für den Leser ist es, ein Profil zu erstellen, das nur die Sensei Regeln ausführt. Probieren Sie es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Inhaltsübersicht
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.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
DigitalOcean verringert Sicherheitsverschuldung mit Secure Code Warrior
DigitalOceans Einsatz von Secure Code Warrior hat die Sicherheitsverschuldung deutlich reduziert, so dass sich die Teams stärker auf Innovation und Produktivität konzentrieren können. Die verbesserte Sicherheit hat die Produktqualität und den Wettbewerbsvorteil des Unternehmens gestärkt. Mit Blick auf die Zukunft wird der SCW Trust Score dem Unternehmen helfen, seine Sicherheitspraktiken weiter zu verbessern und Innovationen voranzutreiben.
Ressourcen für den Einstieg
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
.png)
Die Vorteile eines Benchmarking der Sicherheitskompetenzen von Entwicklern
Der zunehmende Fokus auf sicheren Code und Secure-by-Design-Prinzipien erfordert, dass Entwickler von Beginn des SDLC an in Cybersicherheit geschult werden, wobei Tools wie Secure Code Warrior's Trust Score dabei helfen, ihre Fortschritte zu messen und zu verbessern.
Wesentlicher Erfolg für Enterprise Secure-by-Design-Initiativen
Unser jüngstes Forschungspapier „Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise“ ist das Ergebnis einer umfassenden Analyse echter Secure-by-Design-Initiativen auf Unternehmensebene und der Ableitung von Best-Practice-Ansätzen auf Grundlage datengesteuerter Erkenntnisse.
Vertiefung: Navigieren durch die kritische CUPS-Schwachstelle in GNU-Linux-Systemen
Entdecken Sie die neuesten Sicherheitsprobleme, mit denen Linux-Benutzer konfrontiert sind, indem wir die jüngsten hochgradigen Sicherheitslücken im Common UNIX Printing System (CUPS) untersuchen. Erfahren Sie, wie diese Probleme zu einer möglichen Remote Code Execution (RCE) führen können und was Sie tun können, um Ihre Systeme zu schützen.
