Exécution d'inspections IntelliJ à partir d'une intégration continue
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
Apprenez à exécuter les actions d'intention de Sensei et IntelliJ en mode batch sous forme d'inspections dans l'EDI, à partir de la ligne de commande et en intégration continue.
Alan Richardson possède plus de vingt ans d'expérience professionnelle en informatique. Il a travaillé en tant que développeur et a occupé tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs chez Secure Code Warrior, il travaille directement avec les équipes, pour améliorer le développement d'un code sécurisé de qualité. Alan est l'auteur de quatre livres, dont « Dear Evil Tester » et « Java For Testers ». Alan a également créé des cours de formation en ligne pour aider les utilisateurs à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses vidéos d'écriture et de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Alan Richardson possède plus de vingt ans d'expérience professionnelle en informatique. Il a travaillé en tant que développeur et a occupé tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs chez Secure Code Warrior, il travaille directement avec les équipes, pour améliorer le développement d'un code sécurisé de qualité. Alan est l'auteur de quatre livres, dont « Dear Evil Tester » et « Java For Testers ». Alan a également créé des cours de formation en ligne pour aider les utilisateurs à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses vidéos d'écriture et de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et 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 untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchen
Alan Richardson possède plus de vingt ans d'expérience professionnelle en informatique. Il a travaillé en tant que développeur et a occupé tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs chez Secure Code Warrior, il travaille directement avec les équipes, pour améliorer le développement d'un code sécurisé de qualité. Alan est l'auteur de quatre livres, dont « Dear Evil Tester » et « Java For Testers ». Alan a également créé des cours de formation en ligne pour aider les utilisateurs à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses vidéos d'écriture et de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et 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
Inhaltsverzeichnis
Alan Richardson possède plus de vingt ans d'expérience professionnelle en informatique. Il a travaillé en tant que développeur et a occupé tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs chez Secure Code Warrior, il travaille directement avec les équipes, pour améliorer le développement d'un code sécurisé de qualité. Alan est l'auteur de quatre livres, dont « Dear Evil Tester » et « Java For Testers ». Alan a également créé des cours de formation en ligne pour aider les utilisateurs à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses vidéos d'écriture et de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert 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, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.
