IntelliJ Inspections von Continuous Integration aus ausführen
IntelliJ Inspections von Continuous Integration aus ausführen
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung innerhalb der IDE, wenn Code als Intentions geschrieben wird. Intentions können stapelweise verwendet werden, um den Code im gesamten Quellcode auf Muster zu untersuchen. Dies kann sogar auf die Befehlszeilenanalyse ausgedehnt oder zur Continuous Integration hinzugefügt werden. Dieser Beitrag behandelt die sofort einsatzbereiten IntelliJ-Funktionen und erweitert sie um benutzerdefinierte Intentions, die in Sensei erstellt wurden.
IntelliJ-Inspektionen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler Fehler, die beim Codieren dynamisch in der IDE gemeldet werden, z.
- Erkennung abstrakter Klassen, die in Interfaces umgewandelt werden können,
- Identifizieren redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung veralteter Methoden,
- usw..
Diese Inspektionen heben Code hervor, der in der IDE als Intention Actions übereinstimmt, denen oft ein QuickFix zugeordnet ist.
Die IDE, die in Echtzeit hervorhebt, wenn der Code mit einer Inspektion übereinstimmt, kann uns helfen, unsere Codierung dynamisch zu verbessern. Nachdem wir das Problem im Code identifiziert haben, können wir mithilfe von IntelliJ Intention Actions zur Schnellkorrektur des Codes bessere Muster verstärken.
Inspektionsprofil
Inspektionen können als Batch innerhalb der IDE, über die Befehlszeile 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-Inspektionsprofile: 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.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Führe einen bestimmten Satz von Sensei-Regeln aus
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Einstellungen aktiviert oder deaktiviert werden. Der Einstellungen-Dialog ist auch eine einfache Möglichkeit, sich über den Umfang der verfügbaren Inspektionen zu informieren.
Mit dem Werkzeugsymbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um bestimmte Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können in der IDE über das Menü `Analyze\ Inspect Code... `ausgeführt werden.
Mit der Analysefunktion können Sie den Umfang steuern, für den die Inspektion ausgeführt wird, z. B. für das gesamte Projekt, einschließlich oder ohne Testquellen, oder für einen bestimmten Satz von Dateien.
Sie können die Inspektionsprofile auch von hier aus verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialogfeld „Inspektionsumfang angeben“ auf [OK] klicken, veranlasst IntelliJ, alle ausgewählten Inspektionen im Profil im definierten Bereich durchzuführen.
IntelliJ meldet die Ergebnisse der Durchführung der Inspektionen auf der Registerkarte `Inspektionsergebnisse`.
Das Sensei Das Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, sodass diese benutzerdefinierten Rezepte so natürlich zu verwenden sind wie die IntelliJ Intention Actions. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mithilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion Analysieren und Prüfen des Codes ist die empfohlene Methode, um Sensei-Rezepte in großen Mengen in einem Projekt auszuführen.
Ein Inspektionsprofil von der Befehlszeile aus ausführen
IntelliJ kann Inspektionen über die Befehlszeile ausfü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 über die Befehlszeile ausführen mit:
öffne -na „IntelliJ IDEA CE.app“
Um eine einfachere Ausführung zu unterstützen, füge ich dies einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#! /bin/sh
öffne -na „IntelliJ IDEA CE.app“ --args „$@“
Ich habe es dann ausführbar gemacht, um den Befehlszeileninspektionsprozess zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offiziellen Intellij-Dokumente beschreiben die allgemeine Form des Inspektionsbefehls als:
Idee inspizieren <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/User/Github/sensei-blog-examples /Users/User/Github/sensei-blog-examples/.idea/inspectionprofiles/senseiprofile.xml /users/user/github.com/sensei-blog-examples/scan-results
Dadurch werden alle Inspektionen ausgeführt, die ich zum `senseiprofile` hinzugefügt habe, und die Ergebnisse werden im Ordner `scan-results` gemeldet.
Prüfergebnisse anzeigen
Wir können diese Ergebnisse aus Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch in IntelliJ selbst anzeigen, indem wir die Funktion `Analysieren\ Offline-Inspektionsergebnisse anzeigen... `verwenden.
Dadurch werden die Ergebnisse in den Tab `Inspektionsergebnisse` geladen.
Dies ist offiziell auf der JetBrains-Website dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies kann während eines Codeüberprüfungsprozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess integriert wurde und die Prüfer den vollständigen Quellkontext aller Inspektionsergebniseinträge überprüfen wollten.
Inspektionsprofile in kontinuierlicher Integration
Wenn wir die Befehlszeileninspektion zu Continuous Integration hinzufügen, möchten wir idealerweise, dass ein Bericht automatisch generiert wird, und es stehen uns eine Reihe von Optionen zur Verfügung.
TeamCity bietet sofort einsatzbereite Unterstützung für Inspektionsprofile in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG-Plugin unterstützt die Befehlszeilenausgabe 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-Tools zu unterstützen, z.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft der Inspektionsprofile in einem CI-Prozess sieht mit der Einführung des JetBrains Qodana-Projekts noch besser 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 Beta-Phase, aber das Sensei-Team überwacht es, sodass es zu einer offiziell unterstützten Plattform für die Ausführung der Sensei-Regeln im Rahmen der Continuous Integration wird.
Summary
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und sie schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mithilfe von Inspektionsprofilen können wir diese in Profilen zusammenfassen, die stapelweise als Aktion „Code analysieren und überprüfen“ ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und überprüfen möchten, ob wir es an einer anderen Stelle in unserem Code übersehen haben.
Inspektionsprofile können von der Befehlszeile aus ausgeführt und sogar in Continuous Integration-Prozesse integriert werden, die ein Modell unterstützen, bei dem „Vertrauen, aber verifiziert“ gilt, um versehentliche Abweichungen zu erkennen.
All dies ist in die IntelliJ-Funktionalität integriert, und JetBrains verbessert seinen kontinuierlichen Integrationsprozess mit der Einführung von Qodana.
Sensei-Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren. Sie werden in Inspektionsprofilen gesammelt, um die Batch-Prüfung durch Inspect Code und die Continuous Integration-Unterstützung zu unterstützen, die von der offiziellen JetBrains Command Line-Ausführungsfunktion bereitgestellt wird.
---
Sie können Sensei von IntelliJ aus mit „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 Befehlszeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository `sensei-blog-examples` im Secure Code Warrior GitHub-Konto. Eine Übung für den Leser besteht darin, ein Profil zu erstellen, das nur den Sensei-Regeln entspricht. Probiere es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Erfahren Sie, wie Sie Sensei- und IntelliJ Intention-Aktionen im Batch-Modus als Inspektionen innerhalb der IDE, über die Befehlszeile und in Continuous Integration ausführen.
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 für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine 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.
IntelliJ Inspections von Continuous Integration aus ausführen
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung innerhalb der IDE, wenn Code als Intentions geschrieben wird. Intentions können stapelweise verwendet werden, um den Code im gesamten Quellcode auf Muster zu untersuchen. Dies kann sogar auf die Befehlszeilenanalyse ausgedehnt oder zur Continuous Integration hinzugefügt werden. Dieser Beitrag behandelt die sofort einsatzbereiten IntelliJ-Funktionen und erweitert sie um benutzerdefinierte Intentions, die in Sensei erstellt wurden.
IntelliJ-Inspektionen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler Fehler, die beim Codieren dynamisch in der IDE gemeldet werden, z.
- Erkennung abstrakter Klassen, die in Interfaces umgewandelt werden können,
- Identifizieren redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung veralteter Methoden,
- usw..
Diese Inspektionen heben Code hervor, der in der IDE als Intention Actions übereinstimmt, denen oft ein QuickFix zugeordnet ist.
Die IDE, die in Echtzeit hervorhebt, wenn der Code mit einer Inspektion übereinstimmt, kann uns helfen, unsere Codierung dynamisch zu verbessern. Nachdem wir das Problem im Code identifiziert haben, können wir mithilfe von IntelliJ Intention Actions zur Schnellkorrektur des Codes bessere Muster verstärken.
Inspektionsprofil
Inspektionen können als Batch innerhalb der IDE, über die Befehlszeile 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-Inspektionsprofile: 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.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Führe einen bestimmten Satz von Sensei-Regeln aus
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Einstellungen aktiviert oder deaktiviert werden. Der Einstellungen-Dialog ist auch eine einfache Möglichkeit, sich über den Umfang der verfügbaren Inspektionen zu informieren.
Mit dem Werkzeugsymbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um bestimmte Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können in der IDE über das Menü `Analyze\ Inspect Code... `ausgeführt werden.
Mit der Analysefunktion können Sie den Umfang steuern, für den die Inspektion ausgeführt wird, z. B. für das gesamte Projekt, einschließlich oder ohne Testquellen, oder für einen bestimmten Satz von Dateien.
Sie können die Inspektionsprofile auch von hier aus verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialogfeld „Inspektionsumfang angeben“ auf [OK] klicken, veranlasst IntelliJ, alle ausgewählten Inspektionen im Profil im definierten Bereich durchzuführen.
IntelliJ meldet die Ergebnisse der Durchführung der Inspektionen auf der Registerkarte `Inspektionsergebnisse`.
Das Sensei Das Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, sodass diese benutzerdefinierten Rezepte so natürlich zu verwenden sind wie die IntelliJ Intention Actions. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mithilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion Analysieren und Prüfen des Codes ist die empfohlene Methode, um Sensei-Rezepte in großen Mengen in einem Projekt auszuführen.
Ein Inspektionsprofil von der Befehlszeile aus ausführen
IntelliJ kann Inspektionen über die Befehlszeile ausfü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 über die Befehlszeile ausführen mit:
öffne -na „IntelliJ IDEA CE.app“
Um eine einfachere Ausführung zu unterstützen, füge ich dies einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#! /bin/sh
öffne -na „IntelliJ IDEA CE.app“ --args „$@“
Ich habe es dann ausführbar gemacht, um den Befehlszeileninspektionsprozess zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offiziellen Intellij-Dokumente beschreiben die allgemeine Form des Inspektionsbefehls als:
Idee inspizieren <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/User/Github/sensei-blog-examples /Users/User/Github/sensei-blog-examples/.idea/inspectionprofiles/senseiprofile.xml /users/user/github.com/sensei-blog-examples/scan-results
Dadurch werden alle Inspektionen ausgeführt, die ich zum `senseiprofile` hinzugefügt habe, und die Ergebnisse werden im Ordner `scan-results` gemeldet.
Prüfergebnisse anzeigen
Wir können diese Ergebnisse aus Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch in IntelliJ selbst anzeigen, indem wir die Funktion `Analysieren\ Offline-Inspektionsergebnisse anzeigen... `verwenden.
Dadurch werden die Ergebnisse in den Tab `Inspektionsergebnisse` geladen.
Dies ist offiziell auf der JetBrains-Website dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies kann während eines Codeüberprüfungsprozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess integriert wurde und die Prüfer den vollständigen Quellkontext aller Inspektionsergebniseinträge überprüfen wollten.
Inspektionsprofile in kontinuierlicher Integration
Wenn wir die Befehlszeileninspektion zu Continuous Integration hinzufügen, möchten wir idealerweise, dass ein Bericht automatisch generiert wird, und es stehen uns eine Reihe von Optionen zur Verfügung.
TeamCity bietet sofort einsatzbereite Unterstützung für Inspektionsprofile in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG-Plugin unterstützt die Befehlszeilenausgabe 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-Tools zu unterstützen, z.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft der Inspektionsprofile in einem CI-Prozess sieht mit der Einführung des JetBrains Qodana-Projekts noch besser 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 Beta-Phase, aber das Sensei-Team überwacht es, sodass es zu einer offiziell unterstützten Plattform für die Ausführung der Sensei-Regeln im Rahmen der Continuous Integration wird.
Summary
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und sie schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mithilfe von Inspektionsprofilen können wir diese in Profilen zusammenfassen, die stapelweise als Aktion „Code analysieren und überprüfen“ ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und überprüfen möchten, ob wir es an einer anderen Stelle in unserem Code übersehen haben.
Inspektionsprofile können von der Befehlszeile aus ausgeführt und sogar in Continuous Integration-Prozesse integriert werden, die ein Modell unterstützen, bei dem „Vertrauen, aber verifiziert“ gilt, um versehentliche Abweichungen zu erkennen.
All dies ist in die IntelliJ-Funktionalität integriert, und JetBrains verbessert seinen kontinuierlichen Integrationsprozess mit der Einführung von Qodana.
Sensei-Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren. Sie werden in Inspektionsprofilen gesammelt, um die Batch-Prüfung durch Inspect Code und die Continuous Integration-Unterstützung zu unterstützen, die von der offiziellen JetBrains Command Line-Ausführungsfunktion bereitgestellt wird.
---
Sie können Sensei von IntelliJ aus mit „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 Befehlszeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository `sensei-blog-examples` im Secure Code Warrior GitHub-Konto. Eine Übung für den Leser besteht darin, ein Profil zu erstellen, das nur den Sensei-Regeln entspricht. Probiere es aus:
https://github.com/securecodewarrior/sensei-blog-examples
IntelliJ Inspections von Continuous Integration aus ausführen
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung innerhalb der IDE, wenn Code als Intentions geschrieben wird. Intentions können stapelweise verwendet werden, um den Code im gesamten Quellcode auf Muster zu untersuchen. Dies kann sogar auf die Befehlszeilenanalyse ausgedehnt oder zur Continuous Integration hinzugefügt werden. Dieser Beitrag behandelt die sofort einsatzbereiten IntelliJ-Funktionen und erweitert sie um benutzerdefinierte Intentions, die in Sensei erstellt wurden.
IntelliJ-Inspektionen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler Fehler, die beim Codieren dynamisch in der IDE gemeldet werden, z.
- Erkennung abstrakter Klassen, die in Interfaces umgewandelt werden können,
- Identifizieren redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung veralteter Methoden,
- usw..
Diese Inspektionen heben Code hervor, der in der IDE als Intention Actions übereinstimmt, denen oft ein QuickFix zugeordnet ist.
Die IDE, die in Echtzeit hervorhebt, wenn der Code mit einer Inspektion übereinstimmt, kann uns helfen, unsere Codierung dynamisch zu verbessern. Nachdem wir das Problem im Code identifiziert haben, können wir mithilfe von IntelliJ Intention Actions zur Schnellkorrektur des Codes bessere Muster verstärken.
Inspektionsprofil
Inspektionen können als Batch innerhalb der IDE, über die Befehlszeile 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-Inspektionsprofile: 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.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Führe einen bestimmten Satz von Sensei-Regeln aus
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Einstellungen aktiviert oder deaktiviert werden. Der Einstellungen-Dialog ist auch eine einfache Möglichkeit, sich über den Umfang der verfügbaren Inspektionen zu informieren.
Mit dem Werkzeugsymbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um bestimmte Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können in der IDE über das Menü `Analyze\ Inspect Code... `ausgeführt werden.
Mit der Analysefunktion können Sie den Umfang steuern, für den die Inspektion ausgeführt wird, z. B. für das gesamte Projekt, einschließlich oder ohne Testquellen, oder für einen bestimmten Satz von Dateien.
Sie können die Inspektionsprofile auch von hier aus verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialogfeld „Inspektionsumfang angeben“ auf [OK] klicken, veranlasst IntelliJ, alle ausgewählten Inspektionen im Profil im definierten Bereich durchzuführen.
IntelliJ meldet die Ergebnisse der Durchführung der Inspektionen auf der Registerkarte `Inspektionsergebnisse`.
Das Sensei Das Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, sodass diese benutzerdefinierten Rezepte so natürlich zu verwenden sind wie die IntelliJ Intention Actions. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mithilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion Analysieren und Prüfen des Codes ist die empfohlene Methode, um Sensei-Rezepte in großen Mengen in einem Projekt auszuführen.
Ein Inspektionsprofil von der Befehlszeile aus ausführen
IntelliJ kann Inspektionen über die Befehlszeile ausfü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 über die Befehlszeile ausführen mit:
öffne -na „IntelliJ IDEA CE.app“
Um eine einfachere Ausführung zu unterstützen, füge ich dies einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#! /bin/sh
öffne -na „IntelliJ IDEA CE.app“ --args „$@“
Ich habe es dann ausführbar gemacht, um den Befehlszeileninspektionsprozess zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offiziellen Intellij-Dokumente beschreiben die allgemeine Form des Inspektionsbefehls als:
Idee inspizieren <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/User/Github/sensei-blog-examples /Users/User/Github/sensei-blog-examples/.idea/inspectionprofiles/senseiprofile.xml /users/user/github.com/sensei-blog-examples/scan-results
Dadurch werden alle Inspektionen ausgeführt, die ich zum `senseiprofile` hinzugefügt habe, und die Ergebnisse werden im Ordner `scan-results` gemeldet.
Prüfergebnisse anzeigen
Wir können diese Ergebnisse aus Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch in IntelliJ selbst anzeigen, indem wir die Funktion `Analysieren\ Offline-Inspektionsergebnisse anzeigen... `verwenden.
Dadurch werden die Ergebnisse in den Tab `Inspektionsergebnisse` geladen.
Dies ist offiziell auf der JetBrains-Website dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies kann während eines Codeüberprüfungsprozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess integriert wurde und die Prüfer den vollständigen Quellkontext aller Inspektionsergebniseinträge überprüfen wollten.
Inspektionsprofile in kontinuierlicher Integration
Wenn wir die Befehlszeileninspektion zu Continuous Integration hinzufügen, möchten wir idealerweise, dass ein Bericht automatisch generiert wird, und es stehen uns eine Reihe von Optionen zur Verfügung.
TeamCity bietet sofort einsatzbereite Unterstützung für Inspektionsprofile in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG-Plugin unterstützt die Befehlszeilenausgabe 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-Tools zu unterstützen, z.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft der Inspektionsprofile in einem CI-Prozess sieht mit der Einführung des JetBrains Qodana-Projekts noch besser 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 Beta-Phase, aber das Sensei-Team überwacht es, sodass es zu einer offiziell unterstützten Plattform für die Ausführung der Sensei-Regeln im Rahmen der Continuous Integration wird.
Summary
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und sie schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mithilfe von Inspektionsprofilen können wir diese in Profilen zusammenfassen, die stapelweise als Aktion „Code analysieren und überprüfen“ ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und überprüfen möchten, ob wir es an einer anderen Stelle in unserem Code übersehen haben.
Inspektionsprofile können von der Befehlszeile aus ausgeführt und sogar in Continuous Integration-Prozesse integriert werden, die ein Modell unterstützen, bei dem „Vertrauen, aber verifiziert“ gilt, um versehentliche Abweichungen zu erkennen.
All dies ist in die IntelliJ-Funktionalität integriert, und JetBrains verbessert seinen kontinuierlichen Integrationsprozess mit der Einführung von Qodana.
Sensei-Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren. Sie werden in Inspektionsprofilen gesammelt, um die Batch-Prüfung durch Inspect Code und die Continuous Integration-Unterstützung zu unterstützen, die von der offiziellen JetBrains Command Line-Ausführungsfunktion bereitgestellt wird.
---
Sie können Sensei von IntelliJ aus mit „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 Befehlszeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository `sensei-blog-examples` im Secure Code Warrior GitHub-Konto. Eine Übung für den Leser besteht darin, ein Profil zu erstellen, das nur den Sensei-Regeln entspricht. Probiere es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine 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.
IntelliJ Inspections von Continuous Integration aus ausführen
IntelliJ IDEA bietet Funktionen zur Verbesserung unserer Codierung innerhalb der IDE, wenn Code als Intentions geschrieben wird. Intentions können stapelweise verwendet werden, um den Code im gesamten Quellcode auf Muster zu untersuchen. Dies kann sogar auf die Befehlszeilenanalyse ausgedehnt oder zur Continuous Integration hinzugefügt werden. Dieser Beitrag behandelt die sofort einsatzbereiten IntelliJ-Funktionen und erweitert sie um benutzerdefinierte Intentions, die in Sensei erstellt wurden.
IntelliJ-Inspektionen
Die Inspektionsfunktion von IntelliJ steuert die Anzeige vieler Fehler, die beim Codieren dynamisch in der IDE gemeldet werden, z.
- Erkennung abstrakter Klassen, die in Interfaces umgewandelt werden können,
- Identifizieren redundanter Klassenfelder, die lokal sein können,
- Warnung vor der Verwendung veralteter Methoden,
- usw..
Diese Inspektionen heben Code hervor, der in der IDE als Intention Actions übereinstimmt, denen oft ein QuickFix zugeordnet ist.
Die IDE, die in Echtzeit hervorhebt, wenn der Code mit einer Inspektion übereinstimmt, kann uns helfen, unsere Codierung dynamisch zu verbessern. Nachdem wir das Problem im Code identifiziert haben, können wir mithilfe von IntelliJ Intention Actions zur Schnellkorrektur des Codes bessere Muster verstärken.
Inspektionsprofil
Inspektionen können als Batch innerhalb der IDE, über die Befehlszeile 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-Inspektionsprofile: 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.
- Nur Checkstyle-Echtzeit-Scan ausführen
- Führe einen bestimmten Satz von Sensei-Regeln aus
- Führen Sie die HTML-Prüfungen durch
Die Inspektionen in einem Profil können in den IntelliJ-Einstellungen aktiviert oder deaktiviert werden. Der Einstellungen-Dialog ist auch eine einfache Möglichkeit, sich über den Umfang der verfügbaren Inspektionen zu informieren.
Mit dem Werkzeugsymbol können Sie ein Profil duplizieren und ein neues Profil erstellen, um bestimmte Regeln zu erfassen.
Ausführen eines Inspektionsprofils in der IDE
Inspektionsprofile können in der IDE über das Menü `Analyze\ Inspect Code... `ausgeführt werden.
Mit der Analysefunktion können Sie den Umfang steuern, für den die Inspektion ausgeführt wird, z. B. für das gesamte Projekt, einschließlich oder ohne Testquellen, oder für einen bestimmten Satz von Dateien.
Sie können die Inspektionsprofile auch von hier aus verwalten, um ein bestimmtes Profil zu erstellen oder zu konfigurieren.
Wenn Sie im Dialogfeld „Inspektionsumfang angeben“ auf [OK] klicken, veranlasst IntelliJ, alle ausgewählten Inspektionen im Profil im definierten Bereich durchzuführen.
IntelliJ meldet die Ergebnisse der Durchführung der Inspektionen auf der Registerkarte `Inspektionsergebnisse`.
Das Sensei Das Plugin von Secure Code Warrior ermöglicht es Ihnen, benutzerdefinierte Code-Matching-Rezepte zu erstellen. Sensei ist eng mit IntelliJ integriert, sodass diese benutzerdefinierten Rezepte so natürlich zu verwenden sind wie die IntelliJ Intention Actions. Das heißt, sie werden als Inspektionen in IntelliJ geladen und können mithilfe von Inspektionsprofilen gruppiert, aktiviert und deaktiviert werden. Das Erstellen eines benutzerdefinierten Inspektionsprofils und die anschließende Verwendung der Funktion Analysieren und Prüfen des Codes ist die empfohlene Methode, um Sensei-Rezepte in großen Mengen in einem Projekt auszuführen.
Ein Inspektionsprofil von der Befehlszeile aus ausführen
IntelliJ kann Inspektionen über die Befehlszeile ausfü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 über die Befehlszeile ausführen mit:
öffne -na „IntelliJ IDEA CE.app“
Um eine einfachere Ausführung zu unterstützen, füge ich dies einem Shell-Befehlsskript hinzu.
vi /usr/local/bin/idea
Der Inhalt des Skripts stammt aus der offiziellen Dokumentation von IntelliJ.
#! /bin/sh
öffne -na „IntelliJ IDEA CE.app“ --args „$@“
Ich habe es dann ausführbar gemacht, um den Befehlszeileninspektionsprozess zu vereinfachen.
chmod 755 /usr/local/bin/idea
Die offiziellen Intellij-Dokumente beschreiben die allgemeine Form des Inspektionsbefehls als:
Idee inspizieren <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/User/Github/sensei-blog-examples /Users/User/Github/sensei-blog-examples/.idea/inspectionprofiles/senseiprofile.xml /users/user/github.com/sensei-blog-examples/scan-results
Dadurch werden alle Inspektionen ausgeführt, die ich zum `senseiprofile` hinzugefügt habe, und die Ergebnisse werden im Ordner `scan-results` gemeldet.
Prüfergebnisse anzeigen
Wir können diese Ergebnisse aus Continuous Integration heraus melden, wie wir später sehen werden.
Wir können sie auch in IntelliJ selbst anzeigen, indem wir die Funktion `Analysieren\ Offline-Inspektionsergebnisse anzeigen... `verwenden.
Dadurch werden die Ergebnisse in den Tab `Inspektionsergebnisse` geladen.
Dies ist offiziell auf der JetBrains-Website dokumentiert:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Dies kann während eines Codeüberprüfungsprozesses verwendet werden, wenn die Befehlszeilenausführung in einen kontinuierlichen Integrationsprozess integriert wurde und die Prüfer den vollständigen Quellkontext aller Inspektionsergebniseinträge überprüfen wollten.
Inspektionsprofile in kontinuierlicher Integration
Wenn wir die Befehlszeileninspektion zu Continuous Integration hinzufügen, möchten wir idealerweise, dass ein Bericht automatisch generiert wird, und es stehen uns eine Reihe von Optionen zur Verfügung.
TeamCity bietet sofort einsatzbereite Unterstützung für Inspektionsprofile in Continuous Integration.
- https://www.jetbrains.com/help/teamcity/inspections.html
Das Jenkins Warnings NG-Plugin unterstützt die Befehlszeilenausgabe 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-Tools zu unterstützen, z.
- https://github.com/bentolor/idea-cli-inspector
Die Zukunft der Inspektionsprofile in einem CI-Prozess sieht mit der Einführung des JetBrains Qodana-Projekts noch besser 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 Beta-Phase, aber das Sensei-Team überwacht es, sodass es zu einer offiziell unterstützten Plattform für die Ausführung der Sensei-Regeln im Rahmen der Continuous Integration wird.
Summary
Intention Actions ermöglichen es uns, Codierungsmuster zu verstärken und sie schnell in der IDE zu korrigieren, wenn wir beim Codieren Fehler machen.
Mithilfe von Inspektionsprofilen können wir diese in Profilen zusammenfassen, die stapelweise als Aktion „Code analysieren und überprüfen“ ausgeführt werden können. Dies kann nützlich sein, wenn wir auf ein Muster stoßen und überprüfen möchten, ob wir es an einer anderen Stelle in unserem Code übersehen haben.
Inspektionsprofile können von der Befehlszeile aus ausgeführt und sogar in Continuous Integration-Prozesse integriert werden, die ein Modell unterstützen, bei dem „Vertrauen, aber verifiziert“ gilt, um versehentliche Abweichungen zu erkennen.
All dies ist in die IntelliJ-Funktionalität integriert, und JetBrains verbessert seinen kontinuierlichen Integrationsprozess mit der Einführung von Qodana.
Sensei-Rezepte werden in IntelliJ geladen, um als native Intention Actions zu fungieren. Sie werden in Inspektionsprofilen gesammelt, um die Batch-Prüfung durch Inspect Code und die Continuous Integration-Unterstützung zu unterstützen, die von der offiziellen JetBrains Command Line-Ausführungsfunktion bereitgestellt wird.
---
Sie können Sensei von IntelliJ aus mit „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 Befehlszeile aus auszuführen, finden Sie das in diesem Beitrag verwendete Projekt im Repository `sensei-blog-examples` im Secure Code Warrior GitHub-Konto. Eine Übung für den Leser besteht darin, ein Profil zu erstellen, das nur den Sensei-Regeln entspricht. Probiere es aus:
https://github.com/securecodewarrior/sensei-blog-examples
Inhaltsverzeichnis
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 für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
