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, on parle d'analyse dynamique.
L'analyse statique est fréquemment utilisée pour détecter les éléments suivants :
- Vulnérabilité en matière de sécurité.
- Problème de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Le concept fondamental commun à tous les outils d'analyse statique consiste à rechercher dans le code source et à identifier les modèles de codage spécifiques auxquels sont associés des avertissements ou des informations.
Cela peut être aussi simple que « les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Il peut également s'agir de problèmes difficiles à détecter, tels que « une entrée de chaîne non fiable est utilisée dans une instruction SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de manière différente.
- Technique d'analyse du code source pour la création d'un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Les combinaisons mentionnées ci-dessus.
La correspondance d'expressions régulières dans le texte est extrêmement flexible et permet de décrire facilement les règles de correspondance. Cependant, dans de nombreux cas, cela peut entraîner un nombre important de détections erronées, car les règles de correspondance ne tiennent pas compte du contexte du code environnant.
Lors de la comparaison AST, le code source n'est pas traité comme un simple fichier rempli de texte, mais comme un code de programme. Cela permet une comparaison plus concrète et adaptée à la situation, et réduit le nombre de fausses détections signalées pour le code.
Analyse statique dans l'intégration continue
Dans la plupart des cas, l'analyse statique est effectuée au cours du processus d'intégration continue (CI) et génère un rapport sur les problèmes de conformité. L'examen de ce rapport permet d'obtenir une compréhension objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité du code en configurant l'outil d'analyse statique de manière à ne mesurer que certaines parties spécifiques du code et à ne signaler qu'un sous-ensemble de règles.
L'objectivité est déterminée par les règles utilisées. En effet, ces règles ne changent pas au fil du temps dans l'évaluation du code. Il est évident que la combinaison des règles utilisées et leur composition relèvent d'une décision subjective, et différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile d'effectuer une analyse statique dans le cadre de l'intégration continue, mais cela peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant le codage, mais seulement après avoir exécuté le code avec l'outil d'analyse statique. Un autre effet secondaire de l'analyse statique dans le cadre de l'intégration continue est qu'il est plus facile d'ignorer les résultats.
Afin de faciliter l'attention de l'équipe sur les résultats de l'analyse statique, il est généralement possible de définir des seuils métriques dans le processus de compilation, de sorte que la compilation échoue si ces seuils sont dépassés. Par exemple, lorsque de nombreuses règles sont déclenchées.
Analyse statique dans l'IDE
Afin de recevoir des commentaires plus rapidement, de nombreux plug-ins IDE sont disponibles pour exécuter les règles d'analyse statique de l'IDE à la demande ou régulièrement lorsque le code est modifié.
Lorsque les programmeurs écrivent du code, il est souvent possible de configurer les violations de règles afin qu'elles soient affichées sous forme de code souligné dans l'éditeur. Cela permet de vérifier les violations de règles dans l'IDE pendant l'écriture du code et rend plus difficile le non-respect des règles.
Personnellement, je considère que cette approche est utile pour améliorer le codage, en particulier lorsque l'on utilise de nouvelles bibliothèques couvertes par les outils d'analyse statique. Cependant, il peut y avoir un niveau élevé de bruit en cas de fausses détections ou de règles non pertinentes. Il est possible de résoudre ce problème en configurant les outils d'analyse statique pour ignorer certaines règles spécifiques.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles incombe aux programmeurs, qui doivent donc comprendre les causes des violations de règles et les méthodes de correction.
Il existe peu d'outils d'analyse statique dotés d'une fonctionnalité permettant de corriger les violations. En effet, les corrections sont souvent effectuées en fonction de l'équipe, des technologies utilisées et du style de codage convenu.
Règle par défaut
Si des règles par défaut sont fournies avec l'outil d'analyse statique, cela peut entraîner une confiance injustifiée dans la qualité des règles. On pourrait être tenté de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles elles devraient s'appliquer. Les situations dans lesquelles les règles doivent être appliquées peuvent être subtiles et difficiles à identifier.
En utilisant des outils d'analyse statique et en examinant plus en détail les règles et les violations, on peut s'attendre à ce que les programmeurs acquièrent les compétences nécessaires pour détecter et éviter les problèmes dans le contexte d'un domaine spécifique.
Lorsque des règles contextuelles sont requises pour un domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque. De plus, la configuration et l'extension de l'outil peuvent s'avérer complexes.
inconvénient
Ces « désagréments » ne sont pas insurmontables.
- faux positif
- Absence de correction
- Paramètres permettant de passer outre les règles
- Ajout de règles spécifiques au contexte
Cependant, cela est souvent utilisé comme excuse pour éviter l'utilisation d'outils d'analyse statique. Il est regrettable que ce soit le cas, car l'analyse statique peut s'avérer extrêmement utile dans les situations suivantes.
- Mettre l'accent sur une approche plus efficace envers les jeunes développeurs
- Recevoir rapidement des commentaires sur les violations de codage explicites
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs adoptent des pratiques de codage exemplaires (dans le cas où aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie l'utilisation d'outils d'analyse statique exécutés depuis l'IDE, ce qui me permet de recevoir rapidement des commentaires sur le code.
Cela complète le processus d'examen des demandes de tirage et l'intégration continue potentielle du projet.
Je m'efforce de trouver des outils qui me procurent un avantage concurrentiel et améliorent mon flux de travail individuel.
Lorsque vous exécutez un outil dans un IDE, l'interface graphique et l'approche de configuration de base ont tendance à être similaires, ce qui peut vous inciter à vouloir les afficher de la même manière.
Bien que certains outils puissent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, nous avons choisi d'installer plusieurs outils afin de tirer le meilleur parti de leurs avantages.
Les outils d'analyse statique IDE que j'utilise activement lors du codage sont les suivants.
- Inspection IntelliJ intégrée - Modèles de codage courants
- Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- Style de vérification - Modèles de style généraux
- Professeur Secure Code Warrior - Création de règles personnalisées
Je les utilise tous, car ils se complètent et fonctionnent bien ensemble.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette inspection.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Les règles peuvent être activées ou désactivées, et le niveau d'erreur à mettre en évidence dans l'IDE peut également être sélectionné.
Il existe de nombreuses inspections IntelliJ de grande qualité. Je le sais, car je les ai passées en revue pendant que je rédigeais cet article. J'utilise les inspections IntelliJ par défaut, mais je ne les ai pas encore configurées. Pour tirer le meilleur parti des inspections, il est nécessaire de les passer en revue, d'identifier celles qui correspondent à votre style de codage et de définir le niveau d'alerte afin d'être averti dans le code.
L'avantage des inspections IntelliJ réside dans le fait qu'elles sont fournies gratuitement avec l'IDE et qu'elles contribuent à développer la mémoire musculaire de la manière suivante.
- Lorsque je rédige du code, je remarque les avertissements et les erreurs dans le code source.
- En plaçant le curseur sur le code marqué d'un drapeau, vous pouvez identifier les violations des règles.
- Veuillez utiliser les touches Alt+Entrée pour appliquer la solution rapide au problème.
Bug ponctuel
Le plugin IntelliJ Spot Bug utilise l'analyse statique pour signaler les erreurs dans le code.
SpotBugs peut être configuré pour analyser le code à partir des préférences IntelliJ. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'utiliser SpotBugs après avoir écrit et révisé le code, puis j'effectue une « analyse des fichiers de projet contenant des sources de test ».
Cela permet d'identifier les bogues, le code mort et les optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs détecte les problèmes, mais ne fournit pas de solution rapide pour les résoudre.
SpotBugs est facile à configurer et peut servir de deuxième avis objectif utile dans l'IDE.
Sonarint
Le plugin Sonarint.
SonarLint peut être configuré à partir des préférences d'IntelliJ, et vous pouvez sélectionner les règles à appliquer pour la vérification du code.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes du code en cours d'édition.
SonarLint ne fournit pas de solution immédiate, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
SonarLint s'est révélé utile car il avertit des nouvelles fonctionnalités Java reconnues dans les nouvelles versions de Java.
Style de vérification
Le plugin Checkstyle de Z est un outil qui combine des règles de formatage et de qualité du code.
Le plugin CheckStyle comprend les modules « Sun Check » et « Google Check ».
Ces définitions peuvent êtrefacilement trouvées en ligne.
CheckStyle offre une valeur optimale lorsque le projet a pris le temps de créer 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 valider le code dans l'intégration continue.
CheckStyle est fréquemment utilisé comme plugin de défaillance de compilation du processus CI lorsque le nombre de violations CheckStyle dépasse un certain seuil.
Professeur
Nous utilisons une analyse statique basée sur l'arbre syntaxique abstrait (AST) pour la vérification du code et la création de correctifs rapides. Cela nous permet d'identifier très précisément le code problématique.
AST permet à QuickFix de comprendre le code environnant lié à la recette. Par exemple, lorsque vous ajoutez une nouvelle classe au code, l'importation de cette classe n'est ajoutée qu'une seule fois au fichier source et n'est pas ajoutée à chaque remplacement.
Sensei a été conçu pour permettre la création facile de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier le fichier de configuration, toutes les configurations peuvent être effectuées via l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement à quel code elle correspond. De plus, lorsque vous définissez QuickFix, vous pouvez immédiatement comparer l'état avant et après du code. Cela facilite la création de recettes très contextuelles, telles que celles spécifiques à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les corrigent pas. Une utilisation courante de Sensei consiste à reproduire les correspondances trouvées par d'autres outils dans Sensei et à les étendre avec Quick Fix. Cela présente l'avantage que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Nous créons régulièrement des recettes Sensei qui existent déjà dans le jeu d'Intensions d'IntelliJ, car les rapports Intension ne correspondent pas parfaitement au contexte ou parce que les QuickFix fournis par IntelliJ ne correspondent pas aux modèles de code que nous souhaitons utiliser.
Nous ne cherchons pas à remplacer complètement les outils existants, mais à les renforcer.
Sensei est également très utile pour identifier les variantes contextuelles des règles communes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par l'outil d'analyse statique, mais que les règles SQL communes du moteur d'analyse statique continuent de s'appliquer, vous pouvez utiliser Sensei pour créer des variantes spécifiques à la bibliothèque pour ces règles.
Sensei ne fournit pas immédiatement des recettes générales comme les outils d'analyse statique mentionnés précédemment. Son point fort réside dans la possibilité de créer facilement de nouvelles recettes à l'aide de QuickFix, configuré en fonction d'un style de codage ou d'un cas d'utilisation spécifique.
Remarque : actuellement, nous sommes en train de créer un référentiel public de recettes afin de répondre aux cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent en synergie, qui sont configurables et qui peuvent être facilement étendus en fonction d'un contexte spécifique. J'utilise depuis de nombreuses années les outils d'analyse statique des IDE pour identifier les problèmes et approfondir ma compréhension des langages de programmation et des bibliothèques que j'utilise.
Veuillez utiliser tous les outils mentionnés ci-dessus de manière combinée.
- IntelliJ Intentions permet de signaler rapidement les problèmes courants liés au code. Dans la plupart des cas, il est possible d'utiliser les corrections rapides associées.
- SpotBugs identifie les erreurs simples qui auraient pu être négligées et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je n'avais pas remarquées et me suggère d'autres méthodes pour modéliser le code.
- CheckStyle facilite la conformité avec les conventions de codage convenues, y compris dans le cadre de l'intégration continue.
- Sensei vous assiste dans la création de solutions rapides pour renforcer les scénarios courants observés dans les outils d'analyse statique ou pour créer des recettes technologiques et des projets spécifiques difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), puis recherchez « code sécurisé Sensei ».
Les exemples de code et les recettes pour les cas d'utilisation courants se trouvent dans le projet «sensei » du compteSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
En savoir plus sur le professeur
Veuillez découvrir comment l'analyse statique peut contribuer à l'écriture de code en vous référant à cinq approches basées sur l'IDE et à des exemples de plug-ins.
Alan Richardson a plus de 20 ans d'expérience en tant que développeur, testeur et responsable des tests, à tous les niveaux de la hiérarchie des tests.Secure Code Warrior , où il travaille en étroite collaboration avec l'équipe pour améliorer le développement de code sécurisé et de haute qualité. M. Richardson est l'auteur de quatre ouvrages, dont Dear Evil Tester et Java for Testers. Il a également créé des cours de formation en ligne pour aider les développeurs à apprendre les tests techniques Web et Selenium WebDriver avec Java.M. Alan publie des articles et des vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Alan Richardson a plus de 20 ans d'expérience en tant que développeur, testeur et responsable des tests, à tous les niveaux de la hiérarchie des tests.Secure Code Warrior , où il travaille en étroite collaboration avec l'équipe pour améliorer le développement de code sécurisé et de haute qualité. M. Richardson est l'auteur de quatre ouvrages, dont Dear Evil Tester et Java for Testers. Il a également créé des cours de formation en ligne pour aider les développeurs à apprendre les tests techniques Web et Selenium WebDriver avec Java.M. Alan publie des articles et des 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, on parle d'analyse dynamique.
L'analyse statique est fréquemment utilisée pour détecter les éléments suivants :
- Vulnérabilité en matière de sécurité.
- Problème de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Le concept fondamental commun à tous les outils d'analyse statique consiste à rechercher dans le code source et à identifier les modèles de codage spécifiques auxquels sont associés des avertissements ou des informations.
Cela peut être aussi simple que « les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Il peut également s'agir de problèmes difficiles à détecter, tels que « une entrée de chaîne non fiable est utilisée dans une instruction SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de manière différente.
- Technique d'analyse du code source pour la création d'un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Les combinaisons mentionnées ci-dessus.
La correspondance d'expressions régulières dans le texte est extrêmement flexible et permet de décrire facilement les règles de correspondance. Cependant, dans de nombreux cas, cela peut entraîner un nombre important de détections erronées, car les règles de correspondance ne tiennent pas compte du contexte du code environnant.
Lors de la comparaison AST, le code source n'est pas traité comme un simple fichier rempli de texte, mais comme un code de programme. Cela permet une comparaison plus concrète et adaptée à la situation, et réduit le nombre de fausses détections signalées pour le code.
Analyse statique dans l'intégration continue
Dans la plupart des cas, l'analyse statique est effectuée au cours du processus d'intégration continue (CI) et génère un rapport sur les problèmes de conformité. L'examen de ce rapport permet d'obtenir une compréhension objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité du code en configurant l'outil d'analyse statique de manière à ne mesurer que certaines parties spécifiques du code et à ne signaler qu'un sous-ensemble de règles.
L'objectivité est déterminée par les règles utilisées. En effet, ces règles ne changent pas au fil du temps dans l'évaluation du code. Il est évident que la combinaison des règles utilisées et leur composition relèvent d'une décision subjective, et différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile d'effectuer une analyse statique dans le cadre de l'intégration continue, mais cela peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant le codage, mais seulement après avoir exécuté le code avec l'outil d'analyse statique. Un autre effet secondaire de l'analyse statique dans le cadre de l'intégration continue est qu'il est plus facile d'ignorer les résultats.
Afin de faciliter l'attention de l'équipe sur les résultats de l'analyse statique, il est généralement possible de définir des seuils métriques dans le processus de compilation, de sorte que la compilation échoue si ces seuils sont dépassés. Par exemple, lorsque de nombreuses règles sont déclenchées.
Analyse statique dans l'IDE
Afin de recevoir des commentaires plus rapidement, de nombreux plug-ins IDE sont disponibles pour exécuter les règles d'analyse statique de l'IDE à la demande ou régulièrement lorsque le code est modifié.
Lorsque les programmeurs écrivent du code, il est souvent possible de configurer les violations de règles afin qu'elles soient affichées sous forme de code souligné dans l'éditeur. Cela permet de vérifier les violations de règles dans l'IDE pendant l'écriture du code et rend plus difficile le non-respect des règles.
Personnellement, je considère que cette approche est utile pour améliorer le codage, en particulier lorsque l'on utilise de nouvelles bibliothèques couvertes par les outils d'analyse statique. Cependant, il peut y avoir un niveau élevé de bruit en cas de fausses détections ou de règles non pertinentes. Il est possible de résoudre ce problème en configurant les outils d'analyse statique pour ignorer certaines règles spécifiques.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles incombe aux programmeurs, qui doivent donc comprendre les causes des violations de règles et les méthodes de correction.
Il existe peu d'outils d'analyse statique dotés d'une fonctionnalité permettant de corriger les violations. En effet, les corrections sont souvent effectuées en fonction de l'équipe, des technologies utilisées et du style de codage convenu.
Règle par défaut
Si des règles par défaut sont fournies avec l'outil d'analyse statique, cela peut entraîner une confiance injustifiée dans la qualité des règles. On pourrait être tenté de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles elles devraient s'appliquer. Les situations dans lesquelles les règles doivent être appliquées peuvent être subtiles et difficiles à identifier.
En utilisant des outils d'analyse statique et en examinant plus en détail les règles et les violations, on peut s'attendre à ce que les programmeurs acquièrent les compétences nécessaires pour détecter et éviter les problèmes dans le contexte d'un domaine spécifique.
Lorsque des règles contextuelles sont requises pour un domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque. De plus, la configuration et l'extension de l'outil peuvent s'avérer complexes.
inconvénient
Ces « désagréments » ne sont pas insurmontables.
- faux positif
- Absence de correction
- Paramètres permettant de passer outre les règles
- Ajout de règles spécifiques au contexte
Cependant, cela est souvent utilisé comme excuse pour éviter l'utilisation d'outils d'analyse statique. Il est regrettable que ce soit le cas, car l'analyse statique peut s'avérer extrêmement utile dans les situations suivantes.
- Mettre l'accent sur une approche plus efficace envers les jeunes développeurs
- Recevoir rapidement des commentaires sur les violations de codage explicites
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs adoptent des pratiques de codage exemplaires (dans le cas où aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie l'utilisation d'outils d'analyse statique exécutés depuis l'IDE, ce qui me permet de recevoir rapidement des commentaires sur le code.
Cela complète le processus d'examen des demandes de tirage et l'intégration continue potentielle du projet.
Je m'efforce de trouver des outils qui me procurent un avantage concurrentiel et améliorent mon flux de travail individuel.
Lorsque vous exécutez un outil dans un IDE, l'interface graphique et l'approche de configuration de base ont tendance à être similaires, ce qui peut vous inciter à vouloir les afficher de la même manière.
Bien que certains outils puissent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, nous avons choisi d'installer plusieurs outils afin de tirer le meilleur parti de leurs avantages.
Les outils d'analyse statique IDE que j'utilise activement lors du codage sont les suivants.
- Inspection IntelliJ intégrée - Modèles de codage courants
- Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- Style de vérification - Modèles de style généraux
- Professeur Secure Code Warrior - Création de règles personnalisées
Je les utilise tous, car ils se complètent et fonctionnent bien ensemble.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette inspection.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Les règles peuvent être activées ou désactivées, et le niveau d'erreur à mettre en évidence dans l'IDE peut également être sélectionné.
Il existe de nombreuses inspections IntelliJ de grande qualité. Je le sais, car je les ai passées en revue pendant que je rédigeais cet article. J'utilise les inspections IntelliJ par défaut, mais je ne les ai pas encore configurées. Pour tirer le meilleur parti des inspections, il est nécessaire de les passer en revue, d'identifier celles qui correspondent à votre style de codage et de définir le niveau d'alerte afin d'être averti dans le code.
L'avantage des inspections IntelliJ réside dans le fait qu'elles sont fournies gratuitement avec l'IDE et qu'elles contribuent à développer la mémoire musculaire de la manière suivante.
- Lorsque je rédige du code, je remarque les avertissements et les erreurs dans le code source.
- En plaçant le curseur sur le code marqué d'un drapeau, vous pouvez identifier les violations des règles.
- Veuillez utiliser les touches Alt+Entrée pour appliquer la solution rapide au problème.
Bug ponctuel
Le plugin IntelliJ Spot Bug utilise l'analyse statique pour signaler les erreurs dans le code.
SpotBugs peut être configuré pour analyser le code à partir des préférences IntelliJ. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'utiliser SpotBugs après avoir écrit et révisé le code, puis j'effectue une « analyse des fichiers de projet contenant des sources de test ».
Cela permet d'identifier les bogues, le code mort et les optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs détecte les problèmes, mais ne fournit pas de solution rapide pour les résoudre.
SpotBugs est facile à configurer et peut servir de deuxième avis objectif utile dans l'IDE.
Sonarint
Le plugin Sonarint.
SonarLint peut être configuré à partir des préférences d'IntelliJ, et vous pouvez sélectionner les règles à appliquer pour la vérification du code.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes du code en cours d'édition.
SonarLint ne fournit pas de solution immédiate, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
SonarLint s'est révélé utile car il avertit des nouvelles fonctionnalités Java reconnues dans les nouvelles versions de Java.
Style de vérification
Le plugin Checkstyle de Z est un outil qui combine des règles de formatage et de qualité du code.
Le plugin CheckStyle comprend les modules « Sun Check » et « Google Check ».
Ces définitions peuvent êtrefacilement trouvées en ligne.
CheckStyle offre une valeur optimale lorsque le projet a pris le temps de créer 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 valider le code dans l'intégration continue.
CheckStyle est fréquemment utilisé comme plugin de défaillance de compilation du processus CI lorsque le nombre de violations CheckStyle dépasse un certain seuil.
Professeur
Nous utilisons une analyse statique basée sur l'arbre syntaxique abstrait (AST) pour la vérification du code et la création de correctifs rapides. Cela nous permet d'identifier très précisément le code problématique.
AST permet à QuickFix de comprendre le code environnant lié à la recette. Par exemple, lorsque vous ajoutez une nouvelle classe au code, l'importation de cette classe n'est ajoutée qu'une seule fois au fichier source et n'est pas ajoutée à chaque remplacement.
Sensei a été conçu pour permettre la création facile de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier le fichier de configuration, toutes les configurations peuvent être effectuées via l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement à quel code elle correspond. De plus, lorsque vous définissez QuickFix, vous pouvez immédiatement comparer l'état avant et après du code. Cela facilite la création de recettes très contextuelles, telles que celles spécifiques à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les corrigent pas. Une utilisation courante de Sensei consiste à reproduire les correspondances trouvées par d'autres outils dans Sensei et à les étendre avec Quick Fix. Cela présente l'avantage que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Nous créons régulièrement des recettes Sensei qui existent déjà dans le jeu d'Intensions d'IntelliJ, car les rapports Intension ne correspondent pas parfaitement au contexte ou parce que les QuickFix fournis par IntelliJ ne correspondent pas aux modèles de code que nous souhaitons utiliser.
Nous ne cherchons pas à remplacer complètement les outils existants, mais à les renforcer.
Sensei est également très utile pour identifier les variantes contextuelles des règles communes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par l'outil d'analyse statique, mais que les règles SQL communes du moteur d'analyse statique continuent de s'appliquer, vous pouvez utiliser Sensei pour créer des variantes spécifiques à la bibliothèque pour ces règles.
Sensei ne fournit pas immédiatement des recettes générales comme les outils d'analyse statique mentionnés précédemment. Son point fort réside dans la possibilité de créer facilement de nouvelles recettes à l'aide de QuickFix, configuré en fonction d'un style de codage ou d'un cas d'utilisation spécifique.
Remarque : actuellement, nous sommes en train de créer un référentiel public de recettes afin de répondre aux cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent en synergie, qui sont configurables et qui peuvent être facilement étendus en fonction d'un contexte spécifique. J'utilise depuis de nombreuses années les outils d'analyse statique des IDE pour identifier les problèmes et approfondir ma compréhension des langages de programmation et des bibliothèques que j'utilise.
Veuillez utiliser tous les outils mentionnés ci-dessus de manière combinée.
- IntelliJ Intentions permet de signaler rapidement les problèmes courants liés au code. Dans la plupart des cas, il est possible d'utiliser les corrections rapides associées.
- SpotBugs identifie les erreurs simples qui auraient pu être négligées et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je n'avais pas remarquées et me suggère d'autres méthodes pour modéliser le code.
- CheckStyle facilite la conformité avec les conventions de codage convenues, y compris dans le cadre de l'intégration continue.
- Sensei vous assiste dans la création de solutions rapides pour renforcer les scénarios courants observés dans les outils d'analyse statique ou pour créer des recettes technologiques et des projets spécifiques difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), puis recherchez « code sécurisé Sensei ».
Les exemples de code et les recettes pour les cas d'utilisation courants se trouvent dans le projet «sensei » du compteSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
En savoir plus sur le professeur
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, on parle d'analyse dynamique.
L'analyse statique est fréquemment utilisée pour détecter les éléments suivants :
- Vulnérabilité en matière de sécurité.
- Problème de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Le concept fondamental commun à tous les outils d'analyse statique consiste à rechercher dans le code source et à identifier les modèles de codage spécifiques auxquels sont associés des avertissements ou des informations.
Cela peut être aussi simple que « les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Il peut également s'agir de problèmes difficiles à détecter, tels que « une entrée de chaîne non fiable est utilisée dans une instruction SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de manière différente.
- Technique d'analyse du code source pour la création d'un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Les combinaisons mentionnées ci-dessus.
La correspondance d'expressions régulières dans le texte est extrêmement flexible et permet de décrire facilement les règles de correspondance. Cependant, dans de nombreux cas, cela peut entraîner un nombre important de détections erronées, car les règles de correspondance ne tiennent pas compte du contexte du code environnant.
Lors de la comparaison AST, le code source n'est pas traité comme un simple fichier rempli de texte, mais comme un code de programme. Cela permet une comparaison plus concrète et adaptée à la situation, et réduit le nombre de fausses détections signalées pour le code.
Analyse statique dans l'intégration continue
Dans la plupart des cas, l'analyse statique est effectuée au cours du processus d'intégration continue (CI) et génère un rapport sur les problèmes de conformité. L'examen de ce rapport permet d'obtenir une compréhension objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité du code en configurant l'outil d'analyse statique de manière à ne mesurer que certaines parties spécifiques du code et à ne signaler qu'un sous-ensemble de règles.
L'objectivité est déterminée par les règles utilisées. En effet, ces règles ne changent pas au fil du temps dans l'évaluation du code. Il est évident que la combinaison des règles utilisées et leur composition relèvent d'une décision subjective, et différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile d'effectuer une analyse statique dans le cadre de l'intégration continue, mais cela peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant le codage, mais seulement après avoir exécuté le code avec l'outil d'analyse statique. Un autre effet secondaire de l'analyse statique dans le cadre de l'intégration continue est qu'il est plus facile d'ignorer les résultats.
Afin de faciliter l'attention de l'équipe sur les résultats de l'analyse statique, il est généralement possible de définir des seuils métriques dans le processus de compilation, de sorte que la compilation échoue si ces seuils sont dépassés. Par exemple, lorsque de nombreuses règles sont déclenchées.
Analyse statique dans l'IDE
Afin de recevoir des commentaires plus rapidement, de nombreux plug-ins IDE sont disponibles pour exécuter les règles d'analyse statique de l'IDE à la demande ou régulièrement lorsque le code est modifié.
Lorsque les programmeurs écrivent du code, il est souvent possible de configurer les violations de règles afin qu'elles soient affichées sous forme de code souligné dans l'éditeur. Cela permet de vérifier les violations de règles dans l'IDE pendant l'écriture du code et rend plus difficile le non-respect des règles.
Personnellement, je considère que cette approche est utile pour améliorer le codage, en particulier lorsque l'on utilise de nouvelles bibliothèques couvertes par les outils d'analyse statique. Cependant, il peut y avoir un niveau élevé de bruit en cas de fausses détections ou de règles non pertinentes. Il est possible de résoudre ce problème en configurant les outils d'analyse statique pour ignorer certaines règles spécifiques.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles incombe aux programmeurs, qui doivent donc comprendre les causes des violations de règles et les méthodes de correction.
Il existe peu d'outils d'analyse statique dotés d'une fonctionnalité permettant de corriger les violations. En effet, les corrections sont souvent effectuées en fonction de l'équipe, des technologies utilisées et du style de codage convenu.
Règle par défaut
Si des règles par défaut sont fournies avec l'outil d'analyse statique, cela peut entraîner une confiance injustifiée dans la qualité des règles. On pourrait être tenté de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles elles devraient s'appliquer. Les situations dans lesquelles les règles doivent être appliquées peuvent être subtiles et difficiles à identifier.
En utilisant des outils d'analyse statique et en examinant plus en détail les règles et les violations, on peut s'attendre à ce que les programmeurs acquièrent les compétences nécessaires pour détecter et éviter les problèmes dans le contexte d'un domaine spécifique.
Lorsque des règles contextuelles sont requises pour un domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque. De plus, la configuration et l'extension de l'outil peuvent s'avérer complexes.
inconvénient
Ces « désagréments » ne sont pas insurmontables.
- faux positif
- Absence de correction
- Paramètres permettant de passer outre les règles
- Ajout de règles spécifiques au contexte
Cependant, cela est souvent utilisé comme excuse pour éviter l'utilisation d'outils d'analyse statique. Il est regrettable que ce soit le cas, car l'analyse statique peut s'avérer extrêmement utile dans les situations suivantes.
- Mettre l'accent sur une approche plus efficace envers les jeunes développeurs
- Recevoir rapidement des commentaires sur les violations de codage explicites
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs adoptent des pratiques de codage exemplaires (dans le cas où aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie l'utilisation d'outils d'analyse statique exécutés depuis l'IDE, ce qui me permet de recevoir rapidement des commentaires sur le code.
Cela complète le processus d'examen des demandes de tirage et l'intégration continue potentielle du projet.
Je m'efforce de trouver des outils qui me procurent un avantage concurrentiel et améliorent mon flux de travail individuel.
Lorsque vous exécutez un outil dans un IDE, l'interface graphique et l'approche de configuration de base ont tendance à être similaires, ce qui peut vous inciter à vouloir les afficher de la même manière.
Bien que certains outils puissent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, nous avons choisi d'installer plusieurs outils afin de tirer le meilleur parti de leurs avantages.
Les outils d'analyse statique IDE que j'utilise activement lors du codage sont les suivants.
- Inspection IntelliJ intégrée - Modèles de codage courants
- Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- Style de vérification - Modèles de style généraux
- Professeur Secure Code Warrior - Création de règles personnalisées
Je les utilise tous, car ils se complètent et fonctionnent bien ensemble.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette inspection.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Les règles peuvent être activées ou désactivées, et le niveau d'erreur à mettre en évidence dans l'IDE peut également être sélectionné.
Il existe de nombreuses inspections IntelliJ de grande qualité. Je le sais, car je les ai passées en revue pendant que je rédigeais cet article. J'utilise les inspections IntelliJ par défaut, mais je ne les ai pas encore configurées. Pour tirer le meilleur parti des inspections, il est nécessaire de les passer en revue, d'identifier celles qui correspondent à votre style de codage et de définir le niveau d'alerte afin d'être averti dans le code.
L'avantage des inspections IntelliJ réside dans le fait qu'elles sont fournies gratuitement avec l'IDE et qu'elles contribuent à développer la mémoire musculaire de la manière suivante.
- Lorsque je rédige du code, je remarque les avertissements et les erreurs dans le code source.
- En plaçant le curseur sur le code marqué d'un drapeau, vous pouvez identifier les violations des règles.
- Veuillez utiliser les touches Alt+Entrée pour appliquer la solution rapide au problème.
Bug ponctuel
Le plugin IntelliJ Spot Bug utilise l'analyse statique pour signaler les erreurs dans le code.
SpotBugs peut être configuré pour analyser le code à partir des préférences IntelliJ. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'utiliser SpotBugs après avoir écrit et révisé le code, puis j'effectue une « analyse des fichiers de projet contenant des sources de test ».
Cela permet d'identifier les bogues, le code mort et les optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs détecte les problèmes, mais ne fournit pas de solution rapide pour les résoudre.
SpotBugs est facile à configurer et peut servir de deuxième avis objectif utile dans l'IDE.
Sonarint
Le plugin Sonarint.
SonarLint peut être configuré à partir des préférences d'IntelliJ, et vous pouvez sélectionner les règles à appliquer pour la vérification du code.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes du code en cours d'édition.
SonarLint ne fournit pas de solution immédiate, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
SonarLint s'est révélé utile car il avertit des nouvelles fonctionnalités Java reconnues dans les nouvelles versions de Java.
Style de vérification
Le plugin Checkstyle de Z est un outil qui combine des règles de formatage et de qualité du code.
Le plugin CheckStyle comprend les modules « Sun Check » et « Google Check ».
Ces définitions peuvent êtrefacilement trouvées en ligne.
CheckStyle offre une valeur optimale lorsque le projet a pris le temps de créer 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 valider le code dans l'intégration continue.
CheckStyle est fréquemment utilisé comme plugin de défaillance de compilation du processus CI lorsque le nombre de violations CheckStyle dépasse un certain seuil.
Professeur
Nous utilisons une analyse statique basée sur l'arbre syntaxique abstrait (AST) pour la vérification du code et la création de correctifs rapides. Cela nous permet d'identifier très précisément le code problématique.
AST permet à QuickFix de comprendre le code environnant lié à la recette. Par exemple, lorsque vous ajoutez une nouvelle classe au code, l'importation de cette classe n'est ajoutée qu'une seule fois au fichier source et n'est pas ajoutée à chaque remplacement.
Sensei a été conçu pour permettre la création facile de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier le fichier de configuration, toutes les configurations peuvent être effectuées via l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement à quel code elle correspond. De plus, lorsque vous définissez QuickFix, vous pouvez immédiatement comparer l'état avant et après du code. Cela facilite la création de recettes très contextuelles, telles que celles spécifiques à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les corrigent pas. Une utilisation courante de Sensei consiste à reproduire les correspondances trouvées par d'autres outils dans Sensei et à les étendre avec Quick Fix. Cela présente l'avantage que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Nous créons régulièrement des recettes Sensei qui existent déjà dans le jeu d'Intensions d'IntelliJ, car les rapports Intension ne correspondent pas parfaitement au contexte ou parce que les QuickFix fournis par IntelliJ ne correspondent pas aux modèles de code que nous souhaitons utiliser.
Nous ne cherchons pas à remplacer complètement les outils existants, mais à les renforcer.
Sensei est également très utile pour identifier les variantes contextuelles des règles communes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par l'outil d'analyse statique, mais que les règles SQL communes du moteur d'analyse statique continuent de s'appliquer, vous pouvez utiliser Sensei pour créer des variantes spécifiques à la bibliothèque pour ces règles.
Sensei ne fournit pas immédiatement des recettes générales comme les outils d'analyse statique mentionnés précédemment. Son point fort réside dans la possibilité de créer facilement de nouvelles recettes à l'aide de QuickFix, configuré en fonction d'un style de codage ou d'un cas d'utilisation spécifique.
Remarque : actuellement, nous sommes en train de créer un référentiel public de recettes afin de répondre aux cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent en synergie, qui sont configurables et qui peuvent être facilement étendus en fonction d'un contexte spécifique. J'utilise depuis de nombreuses années les outils d'analyse statique des IDE pour identifier les problèmes et approfondir ma compréhension des langages de programmation et des bibliothèques que j'utilise.
Veuillez utiliser tous les outils mentionnés ci-dessus de manière combinée.
- IntelliJ Intentions permet de signaler rapidement les problèmes courants liés au code. Dans la plupart des cas, il est possible d'utiliser les corrections rapides associées.
- SpotBugs identifie les erreurs simples qui auraient pu être négligées et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je n'avais pas remarquées et me suggère d'autres méthodes pour modéliser le code.
- CheckStyle facilite la conformité avec les conventions de codage convenues, y compris dans le cadre de l'intégration continue.
- Sensei vous assiste dans la création de solutions rapides pour renforcer les scénarios courants observés dans les outils d'analyse statique ou pour créer des recettes technologiques et des projets spécifiques difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), puis recherchez « code sécurisé Sensei ».
Les exemples de code et les recettes pour les cas d'utilisation courants se trouvent dans le projet «sensei » du compteSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
En savoir plus sur le professeur
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Afficher le rapportVeuillez réserver une démonstration.
Alan Richardson a plus de 20 ans d'expérience en tant que développeur, testeur et responsable des tests, à tous les niveaux de la hiérarchie des tests.Secure Code Warrior , où il travaille en étroite collaboration avec l'équipe pour améliorer le développement de code sécurisé et de haute qualité. M. Richardson est l'auteur de quatre ouvrages, dont Dear Evil Tester et Java for Testers. Il a également créé des cours de formation en ligne pour aider les développeurs à apprendre les tests techniques Web et Selenium WebDriver avec Java.M. Alan publie des articles et des 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, on parle d'analyse dynamique.
L'analyse statique est fréquemment utilisée pour détecter les éléments suivants :
- Vulnérabilité en matière de sécurité.
- Problème de performance.
- Non-respect des normes.
- Utilisation d'une structure de programmation obsolète.
Comment fonctionne l'outil d'analyse statique ?
Le concept fondamental commun à tous les outils d'analyse statique consiste à rechercher dans le code source et à identifier les modèles de codage spécifiques auxquels sont associés des avertissements ou des informations.
Cela peut être aussi simple que « les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Il peut également s'agir de problèmes difficiles à détecter, tels que « une entrée de chaîne non fiable est utilisée dans une instruction SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de manière différente.
- Technique d'analyse du code source pour la création d'un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Les combinaisons mentionnées ci-dessus.
La correspondance d'expressions régulières dans le texte est extrêmement flexible et permet de décrire facilement les règles de correspondance. Cependant, dans de nombreux cas, cela peut entraîner un nombre important de détections erronées, car les règles de correspondance ne tiennent pas compte du contexte du code environnant.
Lors de la comparaison AST, le code source n'est pas traité comme un simple fichier rempli de texte, mais comme un code de programme. Cela permet une comparaison plus concrète et adaptée à la situation, et réduit le nombre de fausses détections signalées pour le code.
Analyse statique dans l'intégration continue
Dans la plupart des cas, l'analyse statique est effectuée au cours du processus d'intégration continue (CI) et génère un rapport sur les problèmes de conformité. L'examen de ce rapport permet d'obtenir une compréhension objective de la base de code au fil du temps.
Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité du code en configurant l'outil d'analyse statique de manière à ne mesurer que certaines parties spécifiques du code et à ne signaler qu'un sous-ensemble de règles.
L'objectivité est déterminée par les règles utilisées. En effet, ces règles ne changent pas au fil du temps dans l'évaluation du code. Il est évident que la combinaison des règles utilisées et leur composition relèvent d'une décision subjective, et différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile d'effectuer une analyse statique dans le cadre de l'intégration continue, mais cela peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant le codage, mais seulement après avoir exécuté le code avec l'outil d'analyse statique. Un autre effet secondaire de l'analyse statique dans le cadre de l'intégration continue est qu'il est plus facile d'ignorer les résultats.
Afin de faciliter l'attention de l'équipe sur les résultats de l'analyse statique, il est généralement possible de définir des seuils métriques dans le processus de compilation, de sorte que la compilation échoue si ces seuils sont dépassés. Par exemple, lorsque de nombreuses règles sont déclenchées.
Analyse statique dans l'IDE
Afin de recevoir des commentaires plus rapidement, de nombreux plug-ins IDE sont disponibles pour exécuter les règles d'analyse statique de l'IDE à la demande ou régulièrement lorsque le code est modifié.
Lorsque les programmeurs écrivent du code, il est souvent possible de configurer les violations de règles afin qu'elles soient affichées sous forme de code souligné dans l'éditeur. Cela permet de vérifier les violations de règles dans l'IDE pendant l'écriture du code et rend plus difficile le non-respect des règles.
Personnellement, je considère que cette approche est utile pour améliorer le codage, en particulier lorsque l'on utilise de nouvelles bibliothèques couvertes par les outils d'analyse statique. Cependant, il peut y avoir un niveau élevé de bruit en cas de fausses détections ou de règles non pertinentes. Il est possible de résoudre ce problème en configurant les outils d'analyse statique pour ignorer certaines règles spécifiques.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la correction des règles incombe aux programmeurs, qui doivent donc comprendre les causes des violations de règles et les méthodes de correction.
Il existe peu d'outils d'analyse statique dotés d'une fonctionnalité permettant de corriger les violations. En effet, les corrections sont souvent effectuées en fonction de l'équipe, des technologies utilisées et du style de codage convenu.
Règle par défaut
Si des règles par défaut sont fournies avec l'outil d'analyse statique, cela peut entraîner une confiance injustifiée dans la qualité des règles. On pourrait être tenté de croire qu'elles couvrent tous les problèmes auxquels les programmeurs peuvent être confrontés et toutes les situations dans lesquelles elles devraient s'appliquer. Les situations dans lesquelles les règles doivent être appliquées peuvent être subtiles et difficiles à identifier.
En utilisant des outils d'analyse statique et en examinant plus en détail les règles et les violations, on peut s'attendre à ce que les programmeurs acquièrent les compétences nécessaires pour détecter et éviter les problèmes dans le contexte d'un domaine spécifique.
Lorsque des règles contextuelles sont requises pour un domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque. De plus, la configuration et l'extension de l'outil peuvent s'avérer complexes.
inconvénient
Ces « désagréments » ne sont pas insurmontables.
- faux positif
- Absence de correction
- Paramètres permettant de passer outre les règles
- Ajout de règles spécifiques au contexte
Cependant, cela est souvent utilisé comme excuse pour éviter l'utilisation d'outils d'analyse statique. Il est regrettable que ce soit le cas, car l'analyse statique peut s'avérer extrêmement utile dans les situations suivantes.
- Mettre l'accent sur une approche plus efficace envers les jeunes développeurs
- Recevoir rapidement des commentaires sur les violations de codage explicites
- Identifier les problèmes complexes auxquels les programmeurs n'ont jamais été confrontés auparavant.
- Il est important de souligner que les programmeurs adoptent des pratiques de codage exemplaires (dans le cas où aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie l'utilisation d'outils d'analyse statique exécutés depuis l'IDE, ce qui me permet de recevoir rapidement des commentaires sur le code.
Cela complète le processus d'examen des demandes de tirage et l'intégration continue potentielle du projet.
Je m'efforce de trouver des outils qui me procurent un avantage concurrentiel et améliorent mon flux de travail individuel.
Lorsque vous exécutez un outil dans un IDE, l'interface graphique et l'approche de configuration de base ont tendance à être similaires, ce qui peut vous inciter à vouloir les afficher de la même manière.
Bien que certains outils puissent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, nous avons choisi d'installer plusieurs outils afin de tirer le meilleur parti de leurs avantages.
Les outils d'analyse statique IDE que j'utilise activement lors du codage sont les suivants.
- Inspection IntelliJ intégrée - Modèles de codage courants
- Erreurs courantes
- SonarLint - Modèles d'utilisation courants
- Style de vérification - Modèles de style généraux
- Professeur Secure Code Warrior - Création de règles personnalisées
Je les utilise tous, car ils se complètent et fonctionnent bien ensemble.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette inspection.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Les règles peuvent être activées ou désactivées, et le niveau d'erreur à mettre en évidence dans l'IDE peut également être sélectionné.
Il existe de nombreuses inspections IntelliJ de grande qualité. Je le sais, car je les ai passées en revue pendant que je rédigeais cet article. J'utilise les inspections IntelliJ par défaut, mais je ne les ai pas encore configurées. Pour tirer le meilleur parti des inspections, il est nécessaire de les passer en revue, d'identifier celles qui correspondent à votre style de codage et de définir le niveau d'alerte afin d'être averti dans le code.
L'avantage des inspections IntelliJ réside dans le fait qu'elles sont fournies gratuitement avec l'IDE et qu'elles contribuent à développer la mémoire musculaire de la manière suivante.
- Lorsque je rédige du code, je remarque les avertissements et les erreurs dans le code source.
- En plaçant le curseur sur le code marqué d'un drapeau, vous pouvez identifier les violations des règles.
- Veuillez utiliser les touches Alt+Entrée pour appliquer la solution rapide au problème.
Bug ponctuel
Le plugin IntelliJ Spot Bug utilise l'analyse statique pour signaler les erreurs dans le code.
SpotBugs peut être configuré pour analyser le code à partir des préférences IntelliJ. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'utiliser SpotBugs après avoir écrit et révisé le code, puis j'effectue une « analyse des fichiers de projet contenant des sources de test ».
Cela permet d'identifier les bogues, le code mort et les optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs détecte les problèmes, mais ne fournit pas de solution rapide pour les résoudre.
SpotBugs est facile à configurer et peut servir de deuxième avis objectif utile dans l'IDE.
Sonarint
Le plugin Sonarint.
SonarLint peut être configuré à partir des préférences d'IntelliJ, et vous pouvez sélectionner les règles à appliquer pour la vérification du code.
Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes du code en cours d'édition.
SonarLint ne fournit pas de solution immédiate, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
SonarLint s'est révélé utile car il avertit des nouvelles fonctionnalités Java reconnues dans les nouvelles versions de Java.
Style de vérification
Le plugin Checkstyle de Z est un outil qui combine des règles de formatage et de qualité du code.
Le plugin CheckStyle comprend les modules « Sun Check » et « Google Check ».
Ces définitions peuvent êtrefacilement trouvées en ligne.
CheckStyle offre une valeur optimale lorsque le projet a pris le temps de créer 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 valider le code dans l'intégration continue.
CheckStyle est fréquemment utilisé comme plugin de défaillance de compilation du processus CI lorsque le nombre de violations CheckStyle dépasse un certain seuil.
Professeur
Nous utilisons une analyse statique basée sur l'arbre syntaxique abstrait (AST) pour la vérification du code et la création de correctifs rapides. Cela nous permet d'identifier très précisément le code problématique.
AST permet à QuickFix de comprendre le code environnant lié à la recette. Par exemple, lorsque vous ajoutez une nouvelle classe au code, l'importation de cette classe n'est ajoutée qu'une seule fois au fichier source et n'est pas ajoutée à chaque remplacement.
Sensei a été conçu pour permettre la création facile de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier le fichier de configuration, toutes les configurations peuvent être effectuées via l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement à quel code elle correspond. De plus, lorsque vous définissez QuickFix, vous pouvez immédiatement comparer l'état avant et après du code. Cela facilite la création de recettes très contextuelles, telles que celles spécifiques à une équipe, à une technologie ou même à un programmeur individuel.
J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les corrigent pas. Une utilisation courante de Sensei consiste à reproduire les correspondances trouvées par d'autres outils dans Sensei et à les étendre avec Quick Fix. Cela présente l'avantage que les corrections personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Nous créons régulièrement des recettes Sensei qui existent déjà dans le jeu d'Intensions d'IntelliJ, car les rapports Intension ne correspondent pas parfaitement au contexte ou parce que les QuickFix fournis par IntelliJ ne correspondent pas aux modèles de code que nous souhaitons utiliser.
Nous ne cherchons pas à remplacer complètement les outils existants, mais à les renforcer.
Sensei est également très utile pour identifier les variantes contextuelles des règles communes. Par exemple, si vous utilisez une bibliothèque SQL qui n'est pas prise en charge par l'outil d'analyse statique, mais que les règles SQL communes du moteur d'analyse statique continuent de s'appliquer, vous pouvez utiliser Sensei pour créer des variantes spécifiques à la bibliothèque pour ces règles.
Sensei ne fournit pas immédiatement des recettes générales comme les outils d'analyse statique mentionnés précédemment. Son point fort réside dans la possibilité de créer facilement de nouvelles recettes à l'aide de QuickFix, configuré en fonction d'un style de codage ou d'un cas d'utilisation spécifique.
Remarque : actuellement, nous sommes en train de créer un référentiel public de recettes afin de répondre aux cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent en synergie, qui sont configurables et qui peuvent être facilement étendus en fonction d'un contexte spécifique. J'utilise depuis de nombreuses années les outils d'analyse statique des IDE pour identifier les problèmes et approfondir ma compréhension des langages de programmation et des bibliothèques que j'utilise.
Veuillez utiliser tous les outils mentionnés ci-dessus de manière combinée.
- IntelliJ Intentions permet de signaler rapidement les problèmes courants liés au code. Dans la plupart des cas, il est possible d'utiliser les corrections rapides associées.
- SpotBugs identifie les erreurs simples qui auraient pu être négligées et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je n'avais pas remarquées et me suggère d'autres méthodes pour modéliser le code.
- CheckStyle facilite la conformité avec les conventions de codage convenues, y compris dans le cadre de l'intégration continue.
- Sensei vous assiste dans la création de solutions rapides pour renforcer les scénarios courants observés dans les outils d'analyse statique ou pour créer des recettes technologiques et des projets spécifiques difficiles à configurer dans d'autres outils.
---
Veuillez installer Sensei depuis IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), puis recherchez « code sécurisé Sensei ».
Les exemples de code et les recettes pour les cas d'utilisation courants se trouvent dans le projet «sensei » du compteSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
En savoir plus sur le professeur
Table des matières
Alan Richardson a plus de 20 ans d'expérience en tant que développeur, testeur et responsable des tests, à tous les niveaux de la hiérarchie des tests.Secure Code Warrior , où il travaille en étroite collaboration avec l'équipe pour améliorer le développement de code sécurisé et de haute qualité. M. Richardson est l'auteur de quatre ouvrages, dont Dear Evil Tester et Java for Testers. Il a également créé des cours de formation en ligne pour aider les développeurs à apprendre les tests techniques Web et Selenium WebDriver avec Java.M. Alan publie des articles et des vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.[Télécharger]Ressources pour débuter
Sujets et contenu de la formation sur le code sécurisé
Notre contenu, leader dans le secteur, évolue constamment en fonction de l'environnement de développement logiciel en constante mutation, tout en tenant compte du rôle de nos clients. Il couvre tous les sujets, de l'IA à l'injection XQuery, et s'adresse à divers rôles, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Nous vous invitons à consulter le catalogue de contenu pour découvrir son contenu par sujet et par rôle.
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 débuter
Cybermon est de retour : la mission IA consistant à vaincre le boss est désormais disponible à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année sur SCW. Renforcez considérablement le développement sécurisé de l'IA en introduisant des défis de sécurité avancés en matière d'IA/LLM.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la résilience cybernétique (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer en matière de pratiques de sécurité dès la conception, de prévention des vulnérabilités et de développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite prédéfinis et mesurables
Enabler 1 est le premier volet d'une série de dix intitulée « Enablers of Success » (Les catalyseurs de la réussite). Il présente comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et l'accélération des processus afin de faire évoluer le programme à long terme.
