Qu'est-ce que l'analyse statique ?
Qu'est-ce que l'analyse statique ?
L'analyse statique consiste à analyser automatiquement le code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est appelée analyse dynamique.
L'analyse statique est généralement utilisée pour détecter :
- Faille de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Tous les outils d'analyse statique ont pour principe de base la recherche dans le code source de modèles de codage spécifiques qui peuvent être associés à des avertissements ou à des informations pertinentes.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être « publiques ». » Ou bien quelque chose de plus complexe, tel que « Utilisation de chaînes de caractères non fiables dans les instructions SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source utilisée pour créer un arbre syntaxique abstrait (AST).
- Correspondance d'expressions régulières dans le texte,
- La combinaison des éléments ci-dessus.
Les expressions régulières sur le texte sont très flexibles et faciles à utiliser pour créer des règles de correspondance, mais elles génèrent souvent de nombreux faux positifs et ne tiennent pas compte du contexte du code environnant.
AST matching considère le code source comme du code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance contextuelle plus précise et réduit le nombre de faux positifs dans les rapports de code.
Analyse statique dans l'intégration continue
L'analyse statique est généralement effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. Ces rapports peuvent être examinés afin d'obtenir une compréhension objective du code source sur une période donnée.
Certaines personnes configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent qu'une partie des règles, utilisant ainsi l'analyse statique comme mesure objective de la qualité de leur code.
L'objectivité est assurée par les règles utilisées, car celles-ci n'évoluent pas au fil du temps dans leur évaluation du code. Il est évident que les règles utilisées et leur configuration constituent un choix subjectif, et différentes équipes peuvent opter pour des règles différentes à différents moments.
L'exécution d'analyses statiques dans la CI est utile, mais peut retarder la transmission des commentaires aux programmeurs. Les programmeurs ne reçoivent pas de commentaires pendant qu'ils codent, mais seulement lorsqu'ils exécutent le code ultérieurement à l'aide d'outils d'analyse statique. Un autre effet secondaire de l'exécution d'analyses statiques dans la CI est que les résultats sont plus susceptibles d'être ignorés.
Afin d'aider l'équipe à accorder davantage d'attention aux résultats de l'analyse statique, il est généralement possible de configurer des seuils pendant le processus de compilation, de manière à générer un échec lorsque ces seuils sont dépassés (par exemple, lorsque de nombreuses règles sont déclenchées).
Analyse statique dans l'IDE
Afin d'obtenir un retour plus rapide, il existe de nombreux plug-ins IDE qui peuvent exécuter des règles d'analyse statique dans l'IDE selon les besoins, ou exécuter régulièrement des règles d'analyse statique lorsque le code est modifié.
Ensuite, lorsque les programmeurs écrivent du code, les violations des règles peuvent être observées dans l'IDE. Afin de rendre les règles plus difficiles à ignorer, les violations peuvent généralement être configurées pour apparaître sous forme de code souligné dans l'éditeur.
Je considère personnellement qu'il s'agit d'une méthode utile pour améliorer le codage, en particulier lorsque de nouvelles bibliothèques sont couvertes par des outils d'analyse statique. Bien que cela puisse générer des alertes indésirables, des faux positifs ou des règles qui ne vous intéressent pas, ce problème peut être résolu en prenant des mesures supplémentaires pour configurer l'outil d'analyse statique afin qu'il ignore certaines règles.
Révision du code conformément aux règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles est laissée aux programmeurs, qui doivent donc comprendre les raisons des violations et la manière de les corriger.
Il est rare que les outils d'analyse statique incluent également des fonctionnalités de correction des violations, car la correction dépend généralement de l'équipe et des technologies utilisées, ainsi que du style de codage convenu.
Règles par défaut
Lorsque les outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire une confiance erronée dans la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles ces règles devraient s'appliquer. Parfois, les situations dans lesquelles les règles devraient s'appliquer peuvent être subtiles et difficiles à détecter.
Nous espérons qu'en utilisant des outils d'analyse statique pour étudier plus en détail les règles et les violations, les programmeurs pourront développer des compétences leur permettant de détecter et d'éviter les problèmes dans des domaines spécifiques.
Lorsque votre domaine nécessite des règles contextuelles, il est possible que les outils d'analyse statique ne disposent d'aucune règle correspondant à votre domaine ou à votre bibliothèque. De plus, ces outils sont généralement difficiles à configurer et à étendre.
inquiétude
Ces « difficultés » ne sont pas insurmontables :
- faux positif
- Absence de réparation
- Configuration des règles de suppression
- Ajouter des règles spécifiques au contexte
Cependant, ils sont souvent utilisés comme prétexte pour éviter d'utiliser des outils d'analyse statique dès le début, ce qui est regrettable, car l'analyse statique peut s'avérer très utile et permet de :
- Présenter les meilleures pratiques aux développeurs débutants
- Recevez rapidement des commentaires sur les violations manifestes des règles de codage.
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs ont adopté de bonnes pratiques de codage (aucune infraction n'a été signalée).
Outil d'analyse statique basé sur l'IDE
En tant que contributeur individuel au projet, j'apprécie d'utiliser des outils d'analyse statique fonctionnant dans l'IDE, ce qui me permet d'obtenir rapidement des commentaires sur le code.
Ceci complète tout processus d'examen des demandes d'extraction et toute intégration CI que le projet pourrait avoir.
Je m'efforcerai d'identifier les outils qui peuvent m'apporter un avantage et d'améliorer mon processus de travail personnel.
Lorsque les outils fonctionnent dans l'IDE, il peut être tentant de les examiner alternativement, car ils utilisent souvent la même interface graphique et les mêmes méthodes de configuration de base.
Ces outils peuvent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, mais afin d'en tirer le meilleur parti, j'ai installé plusieurs outils pour exploiter leurs avantages respectifs.
Ci-dessous se trouve une liste des outils d'analyse statique IDE que j'utilise activement lors du codage :
- Vérification IntelliJ intégrée - Modèles de codage courants
- SpotBugs - Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- CheckStyle - Modèles de style courants
- Secure Code Warrior de Secure Code Warrior - Création de règles personnalisées
La raison pour laquelle je les utilise est qu'ils fonctionnent bien ensemble, se complètent et se renforcent mutuellement.
Vérification IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà leurs vérifications.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles disposent également d'une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Ces règles peuvent être activées ou désactivées, et il est également possible de sélectionner le niveau d'erreur à utiliser pour mettre en évidence l'erreur dans l'IDE.
Il existe de nombreux contrôles IntelliJ pertinents. Je le sais car je les ai tous parcourus lors de la rédaction de cet article. J'utilise les contrôles IntelliJ par défaut, mais je ne les ai pas encore configurés. Cependant, pour tirer pleinement parti de ces contrôles, il est recommandé de les parcourir afin d'identifier ceux qui correspondent à votre style de codage et de configurer le niveau d'alerte de manière à ce qu'ils soient visibles dans votre code.
Les avantages des vérifications IntelliJ résident dans le fait qu'elles sont fournies gratuitement dans l'IDE et qu'elles contribuent à développer la mémoire musculaire dans les domaines suivants :
- Veuillez prêter attention aux avertissements et aux erreurs dans le code source lors de la rédaction du code.
- Veuillez placer votre souris sur le code marqué pour comprendre la violation de la règle.
- Veuillez utiliser Alt+Entrée pour appliquer une correction rapide au problème.
SpotBug
Ce plugin SpotBug IntelliJ utilise l'analyse statique pour tenter de vous signaler les erreurs dans votre code.
Vous pouvez configurer SpotBugs dans les préférences d'IntelliJ pour analyser votre code. Les règles effectivement utilisées se trouvent dans l'onglet Détecteurs.
Après avoir rédigé et révisé mon code, je préfère utiliser SpotBugs, puis j'exécute « Analyser les fichiers du projet, y compris les sources de test ».
Cela m'aide effectivement à identifier les erreurs, le code mort et les optimisations évidentes. Cela m'oblige également à examiner certaines violations signalées afin de m'aider à déterminer la marche à suivre.
SpotBugs identifie les problèmes, mais ne propose aucune opération QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer, et j'ai constaté qu'il est possible de consulter un deuxième avis objectif dans mon IDE.
SonarLint
Ce plugin SonarLint.
Il est possible de configurer SonarLint dans les préférences d'IntelliJ afin de sélectionner les règles selon lesquelles le code sera vérifié.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes détectés dans le code que vous êtes en train de modifier.
SonarLint ne propose pas de corrections rapides, mais la documentation relative aux rapports d'infractions est généralement claire et vérifiable.
Par le passé, j'ai constaté que SonarLint était particulièrement utile pour attirer mon attention sur les nouvelles fonctionnalités Java découvertes dans les versions récentes de Java.
Vérifier le style
Ce plugin de style Check fournit une combinaison de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec les modules « Sun Checks » et « Google Checks ».
Ces définitions sontfacilement accessibles sur Internet.
CheckStyle apporte une valeur ajoutée optimale lorsque le projet consacre du temps à la création de son propre ensemble de règles. Il est alors possible de configurer le plugin IDE pour qu'il utilise cet ensemble de règles, et les programmeurs peuvent effectuer une analyse avant de soumettre le code à l'intégration continue.
Lorsque le nombre d'infractions CheckStyle dépasse le seuil défini, CheckStyle est généralement utilisé comme plugin d'échec de compilation dans le processus CI.
Professeur
Les enseignants utilisent l'analyse statique basée sur l'arbre syntaxique abstrait (AST) pour comparer le code et créer des QuickFixes, ce qui permet d'identifier très précisément le code problématique.
AST permet aux QuickFixes associés aux recettes de comprendre le code environnant. Par exemple, lorsque vous ajoutez une nouvelle classe au code, toute importation de cette classe ne sera ajoutée qu'une seule fois au fichier source, plutôt que d'être remplacée à chaque fois.
Sensei pour faciliter la création de règles de correspondance personnalisées, qui peuvent être absentes ou difficiles à configurer dans d'autres outils.
Il n'est pas nécessaire de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création d'une nouvelle recette, l'interface graphique permet de visualiser facilement le code correspondant à la recette. Lors de la définition des QuickFixes, il est possible de comparer immédiatement l'état avant et après du code. Cela facilite la création de recettes très contextuelles, propres à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei . Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne peuvent pas les corriger.Sensei Sensei les recherches de correspondance Sensei , puis à les étendre à l'aide de Quick Fix. L'avantage de cette approche est que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il m'arrive fréquemment de constater que Sensei que j'ai créées existent déjà dans la collection IntelliJ Intensions. Cela est dû au fait que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé, ou que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
J'ai élargi les outils existants plutôt que de tenter de les remplacer complètement.
Sensei lorsque vous identifiez des variantes contextuelles de règles courantes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par les outils d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique restent applicables, vous pouvez utiliser Sensei des variantes spécifiques à la bibliothèque de ces règles.
Sensei ne propose pas autant de recettes génériques prêtes à l'emploi que les outils d'analyse statique mentionnés précédemment. Son avantage réside dans la facilité avec laquelle il est possible de créer de nouvelles recettes et de configurer des QuickFixes afin de les adapter à votre style de codage et à vos cas d'utilisation spécifiques.
Veuillez noter que nous sommes en train de développer un référentiel public de recettes couvrant les cas d'utilisation courants, ainsi que vous pouvez le trouver ici.
Résumé
Je privilégie les outils collaboratifs, configurables et facilement extensibles afin de répondre aux besoins spécifiques de mon environnement. Depuis plusieurs années, j'utilise des outils d'analyse statique dans mon IDE pour m'aider à identifier les problèmes et approfondir ma connaissance des langages de programmation et des bibliothèques que j'utilise.
J'utiliserai tous les outils mentionnés ci-dessous :
- IntelliJ Intents permet de détecter immédiatement les problèmes courants dans le code, généralement accompagnés de corrections rapides pertinentes.
- SpotBugs identifie les erreurs simples que je pourrais omettre et attire mon attention sur les problèmes de performance.
- SonarLint a identifié des fonctionnalités Java dont je n'avais pas connaissance et m'a suggéré d'utiliser d'autres méthodes pour modéliser mon code.
- CheckStyle peut m'aider à respecter le style de codage convenu, qui est également appliqué de manière stricte pendant la CI.
- Sensei créer des QuickFixes afin d'améliorer les scénarios courants détectés par les outils d'analyse statique et à créer des projets ou des solutions techniques spécifiques qui peuvent être difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Senseipoursensei ».
Vous pouvez trouver des exemples de code et un référentiel de recettes d'utilisation courante dans le projet «sensei » du compte Secure Code Warrior
https://github.com/securecodewarrior/sensei-blog-examples
Découvrez l'analyse statique et comment elle peut vous aider à écrire un meilleur code grâce à cinq exemples de méthodes et de plug-ins basés sur l'IDE.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Qu'est-ce que l'analyse statique ?
L'analyse statique consiste à analyser automatiquement le code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est appelée analyse dynamique.
L'analyse statique est généralement utilisée pour détecter :
- Faille de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Tous les outils d'analyse statique ont pour principe de base la recherche dans le code source de modèles de codage spécifiques qui peuvent être associés à des avertissements ou à des informations pertinentes.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être « publiques ». » Ou bien quelque chose de plus complexe, tel que « Utilisation de chaînes de caractères non fiables dans les instructions SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source utilisée pour créer un arbre syntaxique abstrait (AST).
- Correspondance d'expressions régulières dans le texte,
- La combinaison des éléments ci-dessus.
Les expressions régulières sur le texte sont très flexibles et faciles à utiliser pour créer des règles de correspondance, mais elles génèrent souvent de nombreux faux positifs et ne tiennent pas compte du contexte du code environnant.
AST matching considère le code source comme du code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance contextuelle plus précise et réduit le nombre de faux positifs dans les rapports de code.
Analyse statique dans l'intégration continue
L'analyse statique est généralement effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. Ces rapports peuvent être examinés afin d'obtenir une compréhension objective du code source sur une période donnée.
Certaines personnes configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent qu'une partie des règles, utilisant ainsi l'analyse statique comme mesure objective de la qualité de leur code.
L'objectivité est assurée par les règles utilisées, car celles-ci n'évoluent pas au fil du temps dans leur évaluation du code. Il est évident que les règles utilisées et leur configuration constituent un choix subjectif, et différentes équipes peuvent opter pour des règles différentes à différents moments.
L'exécution d'analyses statiques dans la CI est utile, mais peut retarder la transmission des commentaires aux programmeurs. Les programmeurs ne reçoivent pas de commentaires pendant qu'ils codent, mais seulement lorsqu'ils exécutent le code ultérieurement à l'aide d'outils d'analyse statique. Un autre effet secondaire de l'exécution d'analyses statiques dans la CI est que les résultats sont plus susceptibles d'être ignorés.
Afin d'aider l'équipe à accorder davantage d'attention aux résultats de l'analyse statique, il est généralement possible de configurer des seuils pendant le processus de compilation, de manière à générer un échec lorsque ces seuils sont dépassés (par exemple, lorsque de nombreuses règles sont déclenchées).
Analyse statique dans l'IDE
Afin d'obtenir un retour plus rapide, il existe de nombreux plug-ins IDE qui peuvent exécuter des règles d'analyse statique dans l'IDE selon les besoins, ou exécuter régulièrement des règles d'analyse statique lorsque le code est modifié.
Ensuite, lorsque les programmeurs écrivent du code, les violations des règles peuvent être observées dans l'IDE. Afin de rendre les règles plus difficiles à ignorer, les violations peuvent généralement être configurées pour apparaître sous forme de code souligné dans l'éditeur.
Je considère personnellement qu'il s'agit d'une méthode utile pour améliorer le codage, en particulier lorsque de nouvelles bibliothèques sont couvertes par des outils d'analyse statique. Bien que cela puisse générer des alertes indésirables, des faux positifs ou des règles qui ne vous intéressent pas, ce problème peut être résolu en prenant des mesures supplémentaires pour configurer l'outil d'analyse statique afin qu'il ignore certaines règles.
Révision du code conformément aux règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles est laissée aux programmeurs, qui doivent donc comprendre les raisons des violations et la manière de les corriger.
Il est rare que les outils d'analyse statique incluent également des fonctionnalités de correction des violations, car la correction dépend généralement de l'équipe et des technologies utilisées, ainsi que du style de codage convenu.
Règles par défaut
Lorsque les outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire une confiance erronée dans la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles ces règles devraient s'appliquer. Parfois, les situations dans lesquelles les règles devraient s'appliquer peuvent être subtiles et difficiles à détecter.
Nous espérons qu'en utilisant des outils d'analyse statique pour étudier plus en détail les règles et les violations, les programmeurs pourront développer des compétences leur permettant de détecter et d'éviter les problèmes dans des domaines spécifiques.
Lorsque votre domaine nécessite des règles contextuelles, il est possible que les outils d'analyse statique ne disposent d'aucune règle correspondant à votre domaine ou à votre bibliothèque. De plus, ces outils sont généralement difficiles à configurer et à étendre.
inquiétude
Ces « difficultés » ne sont pas insurmontables :
- faux positif
- Absence de réparation
- Configuration des règles de suppression
- Ajouter des règles spécifiques au contexte
Cependant, ils sont souvent utilisés comme prétexte pour éviter d'utiliser des outils d'analyse statique dès le début, ce qui est regrettable, car l'analyse statique peut s'avérer très utile et permet de :
- Présenter les meilleures pratiques aux développeurs débutants
- Recevez rapidement des commentaires sur les violations manifestes des règles de codage.
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs ont adopté de bonnes pratiques de codage (aucune infraction n'a été signalée).
Outil d'analyse statique basé sur l'IDE
En tant que contributeur individuel au projet, j'apprécie d'utiliser des outils d'analyse statique fonctionnant dans l'IDE, ce qui me permet d'obtenir rapidement des commentaires sur le code.
Ceci complète tout processus d'examen des demandes d'extraction et toute intégration CI que le projet pourrait avoir.
Je m'efforcerai d'identifier les outils qui peuvent m'apporter un avantage et d'améliorer mon processus de travail personnel.
Lorsque les outils fonctionnent dans l'IDE, il peut être tentant de les examiner alternativement, car ils utilisent souvent la même interface graphique et les mêmes méthodes de configuration de base.
Ces outils peuvent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, mais afin d'en tirer le meilleur parti, j'ai installé plusieurs outils pour exploiter leurs avantages respectifs.
Ci-dessous se trouve une liste des outils d'analyse statique IDE que j'utilise activement lors du codage :
- Vérification IntelliJ intégrée - Modèles de codage courants
- SpotBugs - Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- CheckStyle - Modèles de style courants
- Secure Code Warrior de Secure Code Warrior - Création de règles personnalisées
La raison pour laquelle je les utilise est qu'ils fonctionnent bien ensemble, se complètent et se renforcent mutuellement.
Vérification IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà leurs vérifications.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles disposent également d'une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Ces règles peuvent être activées ou désactivées, et il est également possible de sélectionner le niveau d'erreur à utiliser pour mettre en évidence l'erreur dans l'IDE.
Il existe de nombreux contrôles IntelliJ pertinents. Je le sais car je les ai tous parcourus lors de la rédaction de cet article. J'utilise les contrôles IntelliJ par défaut, mais je ne les ai pas encore configurés. Cependant, pour tirer pleinement parti de ces contrôles, il est recommandé de les parcourir afin d'identifier ceux qui correspondent à votre style de codage et de configurer le niveau d'alerte de manière à ce qu'ils soient visibles dans votre code.
Les avantages des vérifications IntelliJ résident dans le fait qu'elles sont fournies gratuitement dans l'IDE et qu'elles contribuent à développer la mémoire musculaire dans les domaines suivants :
- Veuillez prêter attention aux avertissements et aux erreurs dans le code source lors de la rédaction du code.
- Veuillez placer votre souris sur le code marqué pour comprendre la violation de la règle.
- Veuillez utiliser Alt+Entrée pour appliquer une correction rapide au problème.
SpotBug
Ce plugin SpotBug IntelliJ utilise l'analyse statique pour tenter de vous signaler les erreurs dans votre code.
Vous pouvez configurer SpotBugs dans les préférences d'IntelliJ pour analyser votre code. Les règles effectivement utilisées se trouvent dans l'onglet Détecteurs.
Après avoir rédigé et révisé mon code, je préfère utiliser SpotBugs, puis j'exécute « Analyser les fichiers du projet, y compris les sources de test ».
Cela m'aide effectivement à identifier les erreurs, le code mort et les optimisations évidentes. Cela m'oblige également à examiner certaines violations signalées afin de m'aider à déterminer la marche à suivre.
SpotBugs identifie les problèmes, mais ne propose aucune opération QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer, et j'ai constaté qu'il est possible de consulter un deuxième avis objectif dans mon IDE.
SonarLint
Ce plugin SonarLint.
Il est possible de configurer SonarLint dans les préférences d'IntelliJ afin de sélectionner les règles selon lesquelles le code sera vérifié.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes détectés dans le code que vous êtes en train de modifier.
SonarLint ne propose pas de corrections rapides, mais la documentation relative aux rapports d'infractions est généralement claire et vérifiable.
Par le passé, j'ai constaté que SonarLint était particulièrement utile pour attirer mon attention sur les nouvelles fonctionnalités Java découvertes dans les versions récentes de Java.
Vérifier le style
Ce plugin de style Check fournit une combinaison de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec les modules « Sun Checks » et « Google Checks ».
Ces définitions sontfacilement accessibles sur Internet.
CheckStyle apporte une valeur ajoutée optimale lorsque le projet consacre du temps à la création de son propre ensemble de règles. Il est alors possible de configurer le plugin IDE pour qu'il utilise cet ensemble de règles, et les programmeurs peuvent effectuer une analyse avant de soumettre le code à l'intégration continue.
Lorsque le nombre d'infractions CheckStyle dépasse le seuil défini, CheckStyle est généralement utilisé comme plugin d'échec de compilation dans le processus CI.
Professeur
Les enseignants utilisent l'analyse statique basée sur l'arbre syntaxique abstrait (AST) pour comparer le code et créer des QuickFixes, ce qui permet d'identifier très précisément le code problématique.
AST permet aux QuickFixes associés aux recettes de comprendre le code environnant. Par exemple, lorsque vous ajoutez une nouvelle classe au code, toute importation de cette classe ne sera ajoutée qu'une seule fois au fichier source, plutôt que d'être remplacée à chaque fois.
Sensei pour faciliter la création de règles de correspondance personnalisées, qui peuvent être absentes ou difficiles à configurer dans d'autres outils.
Il n'est pas nécessaire de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création d'une nouvelle recette, l'interface graphique permet de visualiser facilement le code correspondant à la recette. Lors de la définition des QuickFixes, il est possible de comparer immédiatement l'état avant et après du code. Cela facilite la création de recettes très contextuelles, propres à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei . Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne peuvent pas les corriger.Sensei Sensei les recherches de correspondance Sensei , puis à les étendre à l'aide de Quick Fix. L'avantage de cette approche est que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il m'arrive fréquemment de constater que Sensei que j'ai créées existent déjà dans la collection IntelliJ Intensions. Cela est dû au fait que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé, ou que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
J'ai élargi les outils existants plutôt que de tenter de les remplacer complètement.
Sensei lorsque vous identifiez des variantes contextuelles de règles courantes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par les outils d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique restent applicables, vous pouvez utiliser Sensei des variantes spécifiques à la bibliothèque de ces règles.
Sensei ne propose pas autant de recettes génériques prêtes à l'emploi que les outils d'analyse statique mentionnés précédemment. Son avantage réside dans la facilité avec laquelle il est possible de créer de nouvelles recettes et de configurer des QuickFixes afin de les adapter à votre style de codage et à vos cas d'utilisation spécifiques.
Veuillez noter que nous sommes en train de développer un référentiel public de recettes couvrant les cas d'utilisation courants, ainsi que vous pouvez le trouver ici.
Résumé
Je privilégie les outils collaboratifs, configurables et facilement extensibles afin de répondre aux besoins spécifiques de mon environnement. Depuis plusieurs années, j'utilise des outils d'analyse statique dans mon IDE pour m'aider à identifier les problèmes et approfondir ma connaissance des langages de programmation et des bibliothèques que j'utilise.
J'utiliserai tous les outils mentionnés ci-dessous :
- IntelliJ Intents permet de détecter immédiatement les problèmes courants dans le code, généralement accompagnés de corrections rapides pertinentes.
- SpotBugs identifie les erreurs simples que je pourrais omettre et attire mon attention sur les problèmes de performance.
- SonarLint a identifié des fonctionnalités Java dont je n'avais pas connaissance et m'a suggéré d'utiliser d'autres méthodes pour modéliser mon code.
- CheckStyle peut m'aider à respecter le style de codage convenu, qui est également appliqué de manière stricte pendant la CI.
- Sensei créer des QuickFixes afin d'améliorer les scénarios courants détectés par les outils d'analyse statique et à créer des projets ou des solutions techniques spécifiques qui peuvent être difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Senseipoursensei ».
Vous pouvez trouver des exemples de code et un référentiel de recettes d'utilisation courante dans le projet «sensei » du compte Secure Code Warrior
https://github.com/securecodewarrior/sensei-blog-examples
Qu'est-ce que l'analyse statique ?
L'analyse statique consiste à analyser automatiquement le code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est appelée analyse dynamique.
L'analyse statique est généralement utilisée pour détecter :
- Faille de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Tous les outils d'analyse statique ont pour principe de base la recherche dans le code source de modèles de codage spécifiques qui peuvent être associés à des avertissements ou à des informations pertinentes.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être « publiques ». » Ou bien quelque chose de plus complexe, tel que « Utilisation de chaînes de caractères non fiables dans les instructions SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source utilisée pour créer un arbre syntaxique abstrait (AST).
- Correspondance d'expressions régulières dans le texte,
- La combinaison des éléments ci-dessus.
Les expressions régulières sur le texte sont très flexibles et faciles à utiliser pour créer des règles de correspondance, mais elles génèrent souvent de nombreux faux positifs et ne tiennent pas compte du contexte du code environnant.
AST matching considère le code source comme du code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance contextuelle plus précise et réduit le nombre de faux positifs dans les rapports de code.
Analyse statique dans l'intégration continue
L'analyse statique est généralement effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. Ces rapports peuvent être examinés afin d'obtenir une compréhension objective du code source sur une période donnée.
Certaines personnes configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent qu'une partie des règles, utilisant ainsi l'analyse statique comme mesure objective de la qualité de leur code.
L'objectivité est assurée par les règles utilisées, car celles-ci n'évoluent pas au fil du temps dans leur évaluation du code. Il est évident que les règles utilisées et leur configuration constituent un choix subjectif, et différentes équipes peuvent opter pour des règles différentes à différents moments.
L'exécution d'analyses statiques dans la CI est utile, mais peut retarder la transmission des commentaires aux programmeurs. Les programmeurs ne reçoivent pas de commentaires pendant qu'ils codent, mais seulement lorsqu'ils exécutent le code ultérieurement à l'aide d'outils d'analyse statique. Un autre effet secondaire de l'exécution d'analyses statiques dans la CI est que les résultats sont plus susceptibles d'être ignorés.
Afin d'aider l'équipe à accorder davantage d'attention aux résultats de l'analyse statique, il est généralement possible de configurer des seuils pendant le processus de compilation, de manière à générer un échec lorsque ces seuils sont dépassés (par exemple, lorsque de nombreuses règles sont déclenchées).
Analyse statique dans l'IDE
Afin d'obtenir un retour plus rapide, il existe de nombreux plug-ins IDE qui peuvent exécuter des règles d'analyse statique dans l'IDE selon les besoins, ou exécuter régulièrement des règles d'analyse statique lorsque le code est modifié.
Ensuite, lorsque les programmeurs écrivent du code, les violations des règles peuvent être observées dans l'IDE. Afin de rendre les règles plus difficiles à ignorer, les violations peuvent généralement être configurées pour apparaître sous forme de code souligné dans l'éditeur.
Je considère personnellement qu'il s'agit d'une méthode utile pour améliorer le codage, en particulier lorsque de nouvelles bibliothèques sont couvertes par des outils d'analyse statique. Bien que cela puisse générer des alertes indésirables, des faux positifs ou des règles qui ne vous intéressent pas, ce problème peut être résolu en prenant des mesures supplémentaires pour configurer l'outil d'analyse statique afin qu'il ignore certaines règles.
Révision du code conformément aux règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles est laissée aux programmeurs, qui doivent donc comprendre les raisons des violations et la manière de les corriger.
Il est rare que les outils d'analyse statique incluent également des fonctionnalités de correction des violations, car la correction dépend généralement de l'équipe et des technologies utilisées, ainsi que du style de codage convenu.
Règles par défaut
Lorsque les outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire une confiance erronée dans la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles ces règles devraient s'appliquer. Parfois, les situations dans lesquelles les règles devraient s'appliquer peuvent être subtiles et difficiles à détecter.
Nous espérons qu'en utilisant des outils d'analyse statique pour étudier plus en détail les règles et les violations, les programmeurs pourront développer des compétences leur permettant de détecter et d'éviter les problèmes dans des domaines spécifiques.
Lorsque votre domaine nécessite des règles contextuelles, il est possible que les outils d'analyse statique ne disposent d'aucune règle correspondant à votre domaine ou à votre bibliothèque. De plus, ces outils sont généralement difficiles à configurer et à étendre.
inquiétude
Ces « difficultés » ne sont pas insurmontables :
- faux positif
- Absence de réparation
- Configuration des règles de suppression
- Ajouter des règles spécifiques au contexte
Cependant, ils sont souvent utilisés comme prétexte pour éviter d'utiliser des outils d'analyse statique dès le début, ce qui est regrettable, car l'analyse statique peut s'avérer très utile et permet de :
- Présenter les meilleures pratiques aux développeurs débutants
- Recevez rapidement des commentaires sur les violations manifestes des règles de codage.
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs ont adopté de bonnes pratiques de codage (aucune infraction n'a été signalée).
Outil d'analyse statique basé sur l'IDE
En tant que contributeur individuel au projet, j'apprécie d'utiliser des outils d'analyse statique fonctionnant dans l'IDE, ce qui me permet d'obtenir rapidement des commentaires sur le code.
Ceci complète tout processus d'examen des demandes d'extraction et toute intégration CI que le projet pourrait avoir.
Je m'efforcerai d'identifier les outils qui peuvent m'apporter un avantage et d'améliorer mon processus de travail personnel.
Lorsque les outils fonctionnent dans l'IDE, il peut être tentant de les examiner alternativement, car ils utilisent souvent la même interface graphique et les mêmes méthodes de configuration de base.
Ces outils peuvent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, mais afin d'en tirer le meilleur parti, j'ai installé plusieurs outils pour exploiter leurs avantages respectifs.
Ci-dessous se trouve une liste des outils d'analyse statique IDE que j'utilise activement lors du codage :
- Vérification IntelliJ intégrée - Modèles de codage courants
- SpotBugs - Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- CheckStyle - Modèles de style courants
- Secure Code Warrior de Secure Code Warrior - Création de règles personnalisées
La raison pour laquelle je les utilise est qu'ils fonctionnent bien ensemble, se complètent et se renforcent mutuellement.
Vérification IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà leurs vérifications.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles disposent également d'une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Ces règles peuvent être activées ou désactivées, et il est également possible de sélectionner le niveau d'erreur à utiliser pour mettre en évidence l'erreur dans l'IDE.
Il existe de nombreux contrôles IntelliJ pertinents. Je le sais car je les ai tous parcourus lors de la rédaction de cet article. J'utilise les contrôles IntelliJ par défaut, mais je ne les ai pas encore configurés. Cependant, pour tirer pleinement parti de ces contrôles, il est recommandé de les parcourir afin d'identifier ceux qui correspondent à votre style de codage et de configurer le niveau d'alerte de manière à ce qu'ils soient visibles dans votre code.
Les avantages des vérifications IntelliJ résident dans le fait qu'elles sont fournies gratuitement dans l'IDE et qu'elles contribuent à développer la mémoire musculaire dans les domaines suivants :
- Veuillez prêter attention aux avertissements et aux erreurs dans le code source lors de la rédaction du code.
- Veuillez placer votre souris sur le code marqué pour comprendre la violation de la règle.
- Veuillez utiliser Alt+Entrée pour appliquer une correction rapide au problème.
SpotBug
Ce plugin SpotBug IntelliJ utilise l'analyse statique pour tenter de vous signaler les erreurs dans votre code.
Vous pouvez configurer SpotBugs dans les préférences d'IntelliJ pour analyser votre code. Les règles effectivement utilisées se trouvent dans l'onglet Détecteurs.
Après avoir rédigé et révisé mon code, je préfère utiliser SpotBugs, puis j'exécute « Analyser les fichiers du projet, y compris les sources de test ».
Cela m'aide effectivement à identifier les erreurs, le code mort et les optimisations évidentes. Cela m'oblige également à examiner certaines violations signalées afin de m'aider à déterminer la marche à suivre.
SpotBugs identifie les problèmes, mais ne propose aucune opération QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer, et j'ai constaté qu'il est possible de consulter un deuxième avis objectif dans mon IDE.
SonarLint
Ce plugin SonarLint.
Il est possible de configurer SonarLint dans les préférences d'IntelliJ afin de sélectionner les règles selon lesquelles le code sera vérifié.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes détectés dans le code que vous êtes en train de modifier.
SonarLint ne propose pas de corrections rapides, mais la documentation relative aux rapports d'infractions est généralement claire et vérifiable.
Par le passé, j'ai constaté que SonarLint était particulièrement utile pour attirer mon attention sur les nouvelles fonctionnalités Java découvertes dans les versions récentes de Java.
Vérifier le style
Ce plugin de style Check fournit une combinaison de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec les modules « Sun Checks » et « Google Checks ».
Ces définitions sontfacilement accessibles sur Internet.
CheckStyle apporte une valeur ajoutée optimale lorsque le projet consacre du temps à la création de son propre ensemble de règles. Il est alors possible de configurer le plugin IDE pour qu'il utilise cet ensemble de règles, et les programmeurs peuvent effectuer une analyse avant de soumettre le code à l'intégration continue.
Lorsque le nombre d'infractions CheckStyle dépasse le seuil défini, CheckStyle est généralement utilisé comme plugin d'échec de compilation dans le processus CI.
Professeur
Les enseignants utilisent l'analyse statique basée sur l'arbre syntaxique abstrait (AST) pour comparer le code et créer des QuickFixes, ce qui permet d'identifier très précisément le code problématique.
AST permet aux QuickFixes associés aux recettes de comprendre le code environnant. Par exemple, lorsque vous ajoutez une nouvelle classe au code, toute importation de cette classe ne sera ajoutée qu'une seule fois au fichier source, plutôt que d'être remplacée à chaque fois.
Sensei pour faciliter la création de règles de correspondance personnalisées, qui peuvent être absentes ou difficiles à configurer dans d'autres outils.
Il n'est pas nécessaire de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création d'une nouvelle recette, l'interface graphique permet de visualiser facilement le code correspondant à la recette. Lors de la définition des QuickFixes, il est possible de comparer immédiatement l'état avant et après du code. Cela facilite la création de recettes très contextuelles, propres à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei . Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne peuvent pas les corriger.Sensei Sensei les recherches de correspondance Sensei , puis à les étendre à l'aide de Quick Fix. L'avantage de cette approche est que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il m'arrive fréquemment de constater que Sensei que j'ai créées existent déjà dans la collection IntelliJ Intensions. Cela est dû au fait que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé, ou que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
J'ai élargi les outils existants plutôt que de tenter de les remplacer complètement.
Sensei lorsque vous identifiez des variantes contextuelles de règles courantes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par les outils d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique restent applicables, vous pouvez utiliser Sensei des variantes spécifiques à la bibliothèque de ces règles.
Sensei ne propose pas autant de recettes génériques prêtes à l'emploi que les outils d'analyse statique mentionnés précédemment. Son avantage réside dans la facilité avec laquelle il est possible de créer de nouvelles recettes et de configurer des QuickFixes afin de les adapter à votre style de codage et à vos cas d'utilisation spécifiques.
Veuillez noter que nous sommes en train de développer un référentiel public de recettes couvrant les cas d'utilisation courants, ainsi que vous pouvez le trouver ici.
Résumé
Je privilégie les outils collaboratifs, configurables et facilement extensibles afin de répondre aux besoins spécifiques de mon environnement. Depuis plusieurs années, j'utilise des outils d'analyse statique dans mon IDE pour m'aider à identifier les problèmes et approfondir ma connaissance des langages de programmation et des bibliothèques que j'utilise.
J'utiliserai tous les outils mentionnés ci-dessous :
- IntelliJ Intents permet de détecter immédiatement les problèmes courants dans le code, généralement accompagnés de corrections rapides pertinentes.
- SpotBugs identifie les erreurs simples que je pourrais omettre et attire mon attention sur les problèmes de performance.
- SonarLint a identifié des fonctionnalités Java dont je n'avais pas connaissance et m'a suggéré d'utiliser d'autres méthodes pour modéliser mon code.
- CheckStyle peut m'aider à respecter le style de codage convenu, qui est également appliqué de manière stricte pendant la CI.
- Sensei créer des QuickFixes afin d'améliorer les scénarios courants détectés par les outils d'analyse statique et à créer des projets ou des solutions techniques spécifiques qui peuvent être difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Senseipoursensei ».
Vous pouvez trouver des exemples de code et un référentiel de recettes d'utilisation courante dans le projet «sensei » du compte Secure Code Warrior
https://github.com/securecodewarrior/sensei-blog-examples
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez consulter le rapport.Veuillez réserver une démonstration.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Qu'est-ce que l'analyse statique ?
L'analyse statique consiste à analyser automatiquement le code source sans exécuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est appelée analyse dynamique.
L'analyse statique est généralement utilisée pour détecter :
- Faille de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Tous les outils d'analyse statique ont pour principe de base la recherche dans le code source de modèles de codage spécifiques qui peuvent être associés à des avertissements ou à des informations pertinentes.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être « publiques ». » Ou bien quelque chose de plus complexe, tel que « Utilisation de chaînes de caractères non fiables dans les instructions SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source utilisée pour créer un arbre syntaxique abstrait (AST).
- Correspondance d'expressions régulières dans le texte,
- La combinaison des éléments ci-dessus.
Les expressions régulières sur le texte sont très flexibles et faciles à utiliser pour créer des règles de correspondance, mais elles génèrent souvent de nombreux faux positifs et ne tiennent pas compte du contexte du code environnant.
AST matching considère le code source comme du code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance contextuelle plus précise et réduit le nombre de faux positifs dans les rapports de code.
Analyse statique dans l'intégration continue
L'analyse statique est généralement effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. Ces rapports peuvent être examinés afin d'obtenir une compréhension objective du code source sur une période donnée.
Certaines personnes configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent qu'une partie des règles, utilisant ainsi l'analyse statique comme mesure objective de la qualité de leur code.
L'objectivité est assurée par les règles utilisées, car celles-ci n'évoluent pas au fil du temps dans leur évaluation du code. Il est évident que les règles utilisées et leur configuration constituent un choix subjectif, et différentes équipes peuvent opter pour des règles différentes à différents moments.
L'exécution d'analyses statiques dans la CI est utile, mais peut retarder la transmission des commentaires aux programmeurs. Les programmeurs ne reçoivent pas de commentaires pendant qu'ils codent, mais seulement lorsqu'ils exécutent le code ultérieurement à l'aide d'outils d'analyse statique. Un autre effet secondaire de l'exécution d'analyses statiques dans la CI est que les résultats sont plus susceptibles d'être ignorés.
Afin d'aider l'équipe à accorder davantage d'attention aux résultats de l'analyse statique, il est généralement possible de configurer des seuils pendant le processus de compilation, de manière à générer un échec lorsque ces seuils sont dépassés (par exemple, lorsque de nombreuses règles sont déclenchées).
Analyse statique dans l'IDE
Afin d'obtenir un retour plus rapide, il existe de nombreux plug-ins IDE qui peuvent exécuter des règles d'analyse statique dans l'IDE selon les besoins, ou exécuter régulièrement des règles d'analyse statique lorsque le code est modifié.
Ensuite, lorsque les programmeurs écrivent du code, les violations des règles peuvent être observées dans l'IDE. Afin de rendre les règles plus difficiles à ignorer, les violations peuvent généralement être configurées pour apparaître sous forme de code souligné dans l'éditeur.
Je considère personnellement qu'il s'agit d'une méthode utile pour améliorer le codage, en particulier lorsque de nouvelles bibliothèques sont couvertes par des outils d'analyse statique. Bien que cela puisse générer des alertes indésirables, des faux positifs ou des règles qui ne vous intéressent pas, ce problème peut être résolu en prenant des mesures supplémentaires pour configurer l'outil d'analyse statique afin qu'il ignore certaines règles.
Révision du code conformément aux règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles est laissée aux programmeurs, qui doivent donc comprendre les raisons des violations et la manière de les corriger.
Il est rare que les outils d'analyse statique incluent également des fonctionnalités de correction des violations, car la correction dépend généralement de l'équipe et des technologies utilisées, ainsi que du style de codage convenu.
Règles par défaut
Lorsque les outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire une confiance erronée dans la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles ces règles devraient s'appliquer. Parfois, les situations dans lesquelles les règles devraient s'appliquer peuvent être subtiles et difficiles à détecter.
Nous espérons qu'en utilisant des outils d'analyse statique pour étudier plus en détail les règles et les violations, les programmeurs pourront développer des compétences leur permettant de détecter et d'éviter les problèmes dans des domaines spécifiques.
Lorsque votre domaine nécessite des règles contextuelles, il est possible que les outils d'analyse statique ne disposent d'aucune règle correspondant à votre domaine ou à votre bibliothèque. De plus, ces outils sont généralement difficiles à configurer et à étendre.
inquiétude
Ces « difficultés » ne sont pas insurmontables :
- faux positif
- Absence de réparation
- Configuration des règles de suppression
- Ajouter des règles spécifiques au contexte
Cependant, ils sont souvent utilisés comme prétexte pour éviter d'utiliser des outils d'analyse statique dès le début, ce qui est regrettable, car l'analyse statique peut s'avérer très utile et permet de :
- Présenter les meilleures pratiques aux développeurs débutants
- Recevez rapidement des commentaires sur les violations manifestes des règles de codage.
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs ont adopté de bonnes pratiques de codage (aucune infraction n'a été signalée).
Outil d'analyse statique basé sur l'IDE
En tant que contributeur individuel au projet, j'apprécie d'utiliser des outils d'analyse statique fonctionnant dans l'IDE, ce qui me permet d'obtenir rapidement des commentaires sur le code.
Ceci complète tout processus d'examen des demandes d'extraction et toute intégration CI que le projet pourrait avoir.
Je m'efforcerai d'identifier les outils qui peuvent m'apporter un avantage et d'améliorer mon processus de travail personnel.
Lorsque les outils fonctionnent dans l'IDE, il peut être tentant de les examiner alternativement, car ils utilisent souvent la même interface graphique et les mêmes méthodes de configuration de base.
Ces outils peuvent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, mais afin d'en tirer le meilleur parti, j'ai installé plusieurs outils pour exploiter leurs avantages respectifs.
Ci-dessous se trouve une liste des outils d'analyse statique IDE que j'utilise activement lors du codage :
- Vérification IntelliJ intégrée - Modèles de codage courants
- SpotBugs - Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- CheckStyle - Modèles de style courants
- Secure Code Warrior de Secure Code Warrior - Création de règles personnalisées
La raison pour laquelle je les utilise est qu'ils fonctionnent bien ensemble, se complètent et se renforcent mutuellement.
Vérification IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà leurs vérifications.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles disposent également d'une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Ces règles peuvent être activées ou désactivées, et il est également possible de sélectionner le niveau d'erreur à utiliser pour mettre en évidence l'erreur dans l'IDE.
Il existe de nombreux contrôles IntelliJ pertinents. Je le sais car je les ai tous parcourus lors de la rédaction de cet article. J'utilise les contrôles IntelliJ par défaut, mais je ne les ai pas encore configurés. Cependant, pour tirer pleinement parti de ces contrôles, il est recommandé de les parcourir afin d'identifier ceux qui correspondent à votre style de codage et de configurer le niveau d'alerte de manière à ce qu'ils soient visibles dans votre code.
Les avantages des vérifications IntelliJ résident dans le fait qu'elles sont fournies gratuitement dans l'IDE et qu'elles contribuent à développer la mémoire musculaire dans les domaines suivants :
- Veuillez prêter attention aux avertissements et aux erreurs dans le code source lors de la rédaction du code.
- Veuillez placer votre souris sur le code marqué pour comprendre la violation de la règle.
- Veuillez utiliser Alt+Entrée pour appliquer une correction rapide au problème.
SpotBug
Ce plugin SpotBug IntelliJ utilise l'analyse statique pour tenter de vous signaler les erreurs dans votre code.
Vous pouvez configurer SpotBugs dans les préférences d'IntelliJ pour analyser votre code. Les règles effectivement utilisées se trouvent dans l'onglet Détecteurs.
Après avoir rédigé et révisé mon code, je préfère utiliser SpotBugs, puis j'exécute « Analyser les fichiers du projet, y compris les sources de test ».
Cela m'aide effectivement à identifier les erreurs, le code mort et les optimisations évidentes. Cela m'oblige également à examiner certaines violations signalées afin de m'aider à déterminer la marche à suivre.
SpotBugs identifie les problèmes, mais ne propose aucune opération QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer, et j'ai constaté qu'il est possible de consulter un deuxième avis objectif dans mon IDE.
SonarLint
Ce plugin SonarLint.
Il est possible de configurer SonarLint dans les préférences d'IntelliJ afin de sélectionner les règles selon lesquelles le code sera vérifié.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes détectés dans le code que vous êtes en train de modifier.
SonarLint ne propose pas de corrections rapides, mais la documentation relative aux rapports d'infractions est généralement claire et vérifiable.
Par le passé, j'ai constaté que SonarLint était particulièrement utile pour attirer mon attention sur les nouvelles fonctionnalités Java découvertes dans les versions récentes de Java.
Vérifier le style
Ce plugin de style Check fournit une combinaison de règles de formatage et de qualité du code.
Le plugin CheckStyle est fourni avec les modules « Sun Checks » et « Google Checks ».
Ces définitions sontfacilement accessibles sur Internet.
CheckStyle apporte une valeur ajoutée optimale lorsque le projet consacre du temps à la création de son propre ensemble de règles. Il est alors possible de configurer le plugin IDE pour qu'il utilise cet ensemble de règles, et les programmeurs peuvent effectuer une analyse avant de soumettre le code à l'intégration continue.
Lorsque le nombre d'infractions CheckStyle dépasse le seuil défini, CheckStyle est généralement utilisé comme plugin d'échec de compilation dans le processus CI.
Professeur
Les enseignants utilisent l'analyse statique basée sur l'arbre syntaxique abstrait (AST) pour comparer le code et créer des QuickFixes, ce qui permet d'identifier très précisément le code problématique.
AST permet aux QuickFixes associés aux recettes de comprendre le code environnant. Par exemple, lorsque vous ajoutez une nouvelle classe au code, toute importation de cette classe ne sera ajoutée qu'une seule fois au fichier source, plutôt que d'être remplacée à chaque fois.
Sensei pour faciliter la création de règles de correspondance personnalisées, qui peuvent être absentes ou difficiles à configurer dans d'autres outils.
Il n'est pas nécessaire de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création d'une nouvelle recette, l'interface graphique permet de visualiser facilement le code correspondant à la recette. Lors de la définition des QuickFixes, il est possible de comparer immédiatement l'état avant et après du code. Cela facilite la création de recettes très contextuelles, propres à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei . Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne peuvent pas les corriger.Sensei Sensei les recherches de correspondance Sensei , puis à les étendre à l'aide de Quick Fix. L'avantage de cette approche est que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il m'arrive fréquemment de constater que Sensei que j'ai créées existent déjà dans la collection IntelliJ Intensions. Cela est dû au fait que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé, ou que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
J'ai élargi les outils existants plutôt que de tenter de les remplacer complètement.
Sensei lorsque vous identifiez des variantes contextuelles de règles courantes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par les outils d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique restent applicables, vous pouvez utiliser Sensei des variantes spécifiques à la bibliothèque de ces règles.
Sensei ne propose pas autant de recettes génériques prêtes à l'emploi que les outils d'analyse statique mentionnés précédemment. Son avantage réside dans la facilité avec laquelle il est possible de créer de nouvelles recettes et de configurer des QuickFixes afin de les adapter à votre style de codage et à vos cas d'utilisation spécifiques.
Veuillez noter que nous sommes en train de développer un référentiel public de recettes couvrant les cas d'utilisation courants, ainsi que vous pouvez le trouver ici.
Résumé
Je privilégie les outils collaboratifs, configurables et facilement extensibles afin de répondre aux besoins spécifiques de mon environnement. Depuis plusieurs années, j'utilise des outils d'analyse statique dans mon IDE pour m'aider à identifier les problèmes et approfondir ma connaissance des langages de programmation et des bibliothèques que j'utilise.
J'utiliserai tous les outils mentionnés ci-dessous :
- IntelliJ Intents permet de détecter immédiatement les problèmes courants dans le code, généralement accompagnés de corrections rapides pertinentes.
- SpotBugs identifie les erreurs simples que je pourrais omettre et attire mon attention sur les problèmes de performance.
- SonarLint a identifié des fonctionnalités Java dont je n'avais pas connaissance et m'a suggéré d'utiliser d'autres méthodes pour modéliser mon code.
- CheckStyle peut m'aider à respecter le style de codage convenu, qui est également appliqué de manière stricte pendant la CI.
- Sensei créer des QuickFixes afin d'améliorer les scénarios courants détectés par les outils d'analyse statique et à créer des projets ou des solutions techniques spécifiques qui peuvent être difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Senseipoursensei ».
Vous pouvez trouver des exemples de code et un référentiel de recettes d'utilisation courante dans le projet «sensei » du compte Secure Code Warrior
https://github.com/securecodewarrior/sensei-blog-examples
Table des matières
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Formation sur les codes de sécurité : thèmes et contenu
Notre contenu de pointe évolue constamment pour s'adapter au paysage changeant du développement logiciel, tout en tenant compte de votre rôle. Les sujets abordés couvrent tout, de l'IA à l'injection XQuery, et s'adressent à divers postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu par thème et par rôle de ce que notre catalogue de contenu a à offrir.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : la mission AI pour vaincre le boss est désormais disponible sur demande.
Cybermon 2025 : la campagne « Vaincre le boss » est désormais disponible toute l'année dans SCW. La guerre de sécurité avancée de l'IA/LLM tribale, le renforcement de l'IA de sécurité à grande échelle.
Interprétation de la loi sur la résilience des réseaux : que signifie la sécurité par le biais de la conception et du développement de logiciels ?
Comprenez les exigences de la loi européenne sur la résilience des réseaux (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent s'y préparer grâce à des pratiques de conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facteur déterminant 1 : des critères de réussite clairs et mesurables
Le catalyseur n° 1 constitue le premier volet de notre série en dix parties consacrée aux facteurs de réussite. Il démontre comment relier la sécurité du code aux résultats opérationnels, tels que la réduction des risques et l'accélération de la maturité des programmes à long terme.
