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 principalement utilisée pour détecter les éléments suivants :
- Vulnérabilité de sécurité.
- Problème de performance.
- Non-conformité aux 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 à analyser le code source afin d'identifier des modèles de codage spécifiques pouvant nécessiter une attention particulière.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Ou cela peut être aussi complexe à identifier que « Entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source pour générer un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Il s'agit de la combinaison ci-dessus.
Les expressions régulières pour le texte sont très flexibles et faciles à écrire, mais elles peuvent souvent entraîner de nombreux faux positifs et ignorent le contexte du code environnant.
La correspondance AST traite le code source non seulement comme un fichier rempli de texte, mais également comme un code de programme, ce qui permet une correspondance plus précise et adaptée au contexte, et réduit le nombre de faux positifs signalés pour le code.
Analyse statique dans l'intégration continue
L'analyse statique est fréquemment effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. L'examen de ces rapports permet d'évaluer objectivement la base de code au fil du temps.
Certains utilisateurs configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent que les sous-ensembles de règles, afin de les utiliser comme mesure objective de la qualité du code.
L'objectivité est garantie par les règles utilisées, car l'évaluation du code ne change pas avec le temps. Il est clair que la combinaison des règles utilisées et de leur composition relève d'une décision subjective, et chaque équipe choisit d'utiliser des règles différentes selon le moment.
Bien que l'analyse statique dans CI soit utile, elle peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant qu'ils codent, mais seulement plus tard, lorsqu'ils exécutent le code à l'aide d'un outil d'analyse statique. Un autre inconvénient de l'analyse statique dans CI est qu'il est facile d'ignorer les résultats.
Il est généralement possible de configurer des indicateurs de seuil dans le processus de compilation afin que l'équipe puisse accorder davantage d'attention aux résultats de l'analyse statique lorsque les indicateurs sont dépassés (par exemple, le nombre de règles déclenchées), ce qui entraîne l'échec de la compilation.
Analyse statique dans l'IDE
Il existe de nombreux plug-ins IDE qui exécutent des règles d'analyse statique dans l'IDE de manière périodique, selon les besoins ou lorsque le code est modifié, afin d'obtenir un retour plus rapide.
Ainsi, lorsque le programmeur écrit du code, l'IDE peut détecter les violations de règles. Afin de rendre plus difficile le non-respect des règles, il est possible de configurer les violations pour qu'elles soient affichées sous forme de code souligné dans l'éditeur.
Je considère personnellement que cette approche est utile pour améliorer le codage, en particulier lorsque l'on travaille avec de nouvelles bibliothèques prises en charge par les outils d'analyse statique. Il est possible que des faux positifs ou des règles non pertinentes génèrent un certain bruit. Cependant, ce problème peut être résolu en configurant l'outil d'analyse statique pour ignorer certaines règles spécifiques, ce qui nécessite une étape supplémentaire.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la modification des règles incombe au programmeur. Par conséquent, le programmeur doit comprendre la cause de la violation des règles et la méthode de correction.
Il existe peu d'outils d'analyse statique permettant de corriger les violations. En effet, les corrections sont souvent déterminées par l'équipe, les technologies utilisées et le style de codage convenu.
Règles de base
Lorsque des outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire en erreur quant à la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels un programmeur peut être confronté et toutes les situations dans lesquelles elles doivent être appliquées. Parfois, les situations dans lesquelles les règles doivent être appliquées sont subtiles et difficiles à détecter.
Nous espérons que l'utilisation d'outils d'analyse statique pour examiner plus en détail les règles et les violations permettra aux programmeurs de développer des techniques pour détecter et prévenir les problèmes dans le contexte de domaines spécifiques.
Si des règles contextuelles sont requises pour le domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque, et qu'il soit également difficile de configurer et d'étendre l'outil.
성가심
Il n'y a rien d'insurmontable parmi ces « désagréments ».
- Faux positif
- Modifications insuffisantes
- Configuration pour contourner les règles
- Ajouter des règles contextuelles
Cependant, il est regrettable que cet argument soit souvent utilisé comme prétexte pour ne pas utiliser d'outils d'analyse statique, car ceux-ci peuvent s'avérer extrêmement utiles de différentes manières.
- Mettre l'accent sur une approche plus efficace pour les développeurs juniors
- Obtention rapide de commentaires sur les violations de codage évidentes
- Le programmeur identifie des problèmes complexes qu'il n'a jamais rencontrés auparavant.
- Veuillez souligner que le programmeur a adopté une approche de codage appropriée (si aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie particulièrement les outils d'analyse statique fonctionnant dans l'IDE, car ils me permettent d'obtenir rapidement des commentaires sur le code.
Cela complète tous les processus d'examen des demandes de pull et l'intégration CI qui peuvent être présents dans le projet.
Je m'efforce de trouver des outils qui me permettent de prendre l'avantage et d'améliorer mon flux de travail personnel.
Lorsque l'outil est exécuté dans l'IDE, l'interface graphique et l'approche de configuration étant identiques, il peut être souhaitable de comparer les différents outils.
Les outils peuvent comporter des fonctionnalités ou des ensembles de règles qui se recoupent, mais il est conseillé d'installer plusieurs outils afin de tirer pleinement parti de leurs avantages.
Les outils d'analyse statique IDE que nous utilisons activement lors du codage sont les suivants :
- Vérification IntelliJ intégrée - Modèles de codage courants
- Spot Bug - Erreurs courantes
- Sonarint - Utilisation habituelle
- Style de vérification - Modèle de style général
- Sensei de Secure Code Warrior Sensei Création de règles personnalisées
Ils sont tous utilisés car ils se complètent et se renforcent mutuellement.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette vérification.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent également une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Il est possible de définir ou de désactiver des règles et de sélectionner le niveau d'erreur à utiliser lors de la mise en évidence dans l'IDE.
Il existe de nombreuses fonctionnalités d'inspection IntelliJ remarquables. Je le sais, car j'ai lu toutes les informations à ce sujet pendant que je rédigeais cet article. J'utilise IntelliJ Inspections par défaut et je ne l'ai pas encore configuré. Cependant, pour tirer le meilleur parti de l'inspection, il est nécessaire de lire attentivement les informations, d'identifier les éléments liés à votre style de codage et de configurer le niveau d'alerte afin de pouvoir les vérifier dans le code.
L'avantage d'IntelliJ Inspecing est qu'il est fourni gratuitement avec l'IDE et qu'il contribue à développer la mémoire musculaire de la manière suivante.
- Vérification des avertissements et des erreurs dans le code source lors de l'écriture du code.
- En plaçant votre souris sur le code marqué d'un drapeau, vous pouvez déterminer s'il y a violation des règles.
- Veuillez utiliser Alt+Entrée pour appliquer QuickFix au problème.
Spot Bug
Le plugin Spot Bugs pour IntelliJ identifie les erreurs dans le code à l'aide d'une analyse statique.
Vous pouvez configurer SpotBugs dans les paramètres par défaut d'IntelliJ afin de pouvoir analyser le code. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'écrire et de réviser le code, puis d'utiliser SpotBugs. Ensuite, je procède à l'analyse des fichiers du projet, y compris les sources de test.
Cette approche facilite l'identification des bogues, du code mort et des optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs identifie les problèmes, mais ne fournit pas de solution QuickFix pour les résoudre.
SpotBugs est facile à configurer et constitue, à mon avis, un avis objectif et secondaire que l'on peut consulter dans mon IDE.
Sona Lint
Plug-in Sonar Lint.
Dans les paramètres par défaut d'IntelliJ, il est possible de configurer SonarLint afin de sélectionner les règles de validation du code.
Par défaut, SonarLint s'exécute en temps réel et signale les problèmes dans le code en cours d'édition.
SonarLint ne fournit pas de fonctionnalité de correction rapide, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
Nous avons constaté que SonarLint est utile pour identifier les nouvelles fonctionnalités Java connues dans les versions récentes de Java.
Style de vérification
Le plugin Check Style fournit un ensemble de règles relatives au formatage et à la qualité du code.
Le plugin Checkstyle est fourni avec Sun Check et Google Check.
Leur définition peut être simple. Trouvé en ligne.
CheckStyle apporte le plus de valeur ajoutée 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 dans le processus CI lorsque le nombre de violations CheckStyle dépasse un seuil défini.
Monsieur
Nous utilisons une analyse statique basée sur l'AST (arbre syntaxique abstrait) pour la correspondance de code et la génération de QuickFixs, ce qui nous permet d'identifier très précisément les codes problématiques.
AST permet aux QuickFixs liés aux recettes de comprendre le code environnant. 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 faciliter la création de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement le code correspondant à la recette. De plus, lorsque vous définissez des QuickFixs, vous pouvez comparer instantanément l'état antérieur et l'état postérieur du code. Vous pouvez ainsi créer facilement des recettes adaptées à chaque situation (par exemple, des recettes uniques réservées à une équipe, à une technologie ou même à un programmeur individuel).
J'utilise Sensei en complément d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résolvent pas. Une utilisation courante de Sensei consiste à reproduire les recherches de correspondance d'autres outils dans Sensei et à les étendre à Quick Fix. Cela présente l'avantage que les modifications personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il arrive parfois que je crée Sensei qui existent déjà dans l'ensemble d'intentions IntelliJ, car le rapport d'intention ne correspond pas parfaitement au contexte que j'ai créé ou parce que la correction rapide fournie par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je préfère renforcer les outils existants plutôt que de les remplacer complètement.
Sensei peut également s'avérer très utile pour identifier les variations contextuelles des règles communes. 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 générales du moteur d'analyse statique s'appliquent toujours, vous pouvez utiliser Sensei pour créer une variante de ces règles spécifique à la bibliothèque.
Sensei ne fournit pas autant de recettes générales que les outils d'analyse statique mentionnés précédemment. La force de Sensei réside dans sa capacité à créer facilement de nouvelles recettes avec des QuickFix configurées pour s'adapter à des styles de codage et des cas d'utilisation spécifiques.
Remarque : nous développons actuellement un référentiel public de recettes afin de couvrir les cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent ensemble, qui sont configurables et qui peuvent être facilement adaptés à des situations spécifiques. J'utilise depuis plusieurs années les outils d'analyse statique de l'IDE, qui m'aident à identifier les problèmes et à mieux comprendre les langages de programmation et les bibliothèques que j'utilise.
Nous utilisons tous les outils mentionnés précédemment de manière combinée.
- Les intentions IntelliJ permettent généralement d'identifier rapidement les problèmes courants liés au code à l'aide de QuickFix.
- SpotBugs identifie les erreurs mineures que j'aurais pu manquer et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je ne connaissais pas et me fournit des méthodes supplémentaires pour modéliser le code.
- L'utilisation de CheckStyle permet de respecter le style de codage convenu, qui s'applique également pendant l'intégration continue.
- Sensei permet de créer des QuickFixs afin de compléter les scénarios courants détectés par les outils d'analyse statique et de créer des recettes techniques ou des projets spécifiques difficiles à configurer avec d'autres outils.
---
Dans IntelliJ, veuillez installer Sensei à l'aide de « Préférences\Plug-ins » (Mac) ou « Paramètres\Plug-ins » (Windows), puis recherchez le « code de sécurité Sensei ».
Vous trouverez des exemples de code et des recettes pour des cas d'utilisation courants dans le projet «sensei » du compte Secure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
Découvrez l'analyse statique et apprenez à écrire un meilleur code grâce à l'analyse statique à travers cinq approches basées sur l'IDE et des exemples de plug-ins.
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 est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez prendre rendez-vous pour 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, on parle d'analyse dynamique.
L'analyse statique est principalement utilisée pour détecter les éléments suivants :
- Vulnérabilité de sécurité.
- Problème de performance.
- Non-conformité aux 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 à analyser le code source afin d'identifier des modèles de codage spécifiques pouvant nécessiter une attention particulière.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Ou cela peut être aussi complexe à identifier que « Entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source pour générer un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Il s'agit de la combinaison ci-dessus.
Les expressions régulières pour le texte sont très flexibles et faciles à écrire, mais elles peuvent souvent entraîner de nombreux faux positifs et ignorent le contexte du code environnant.
La correspondance AST traite le code source non seulement comme un fichier rempli de texte, mais également comme un code de programme, ce qui permet une correspondance plus précise et adaptée au contexte, et réduit le nombre de faux positifs signalés pour le code.
Analyse statique dans l'intégration continue
L'analyse statique est fréquemment effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. L'examen de ces rapports permet d'évaluer objectivement la base de code au fil du temps.
Certains utilisateurs configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent que les sous-ensembles de règles, afin de les utiliser comme mesure objective de la qualité du code.
L'objectivité est garantie par les règles utilisées, car l'évaluation du code ne change pas avec le temps. Il est clair que la combinaison des règles utilisées et de leur composition relève d'une décision subjective, et chaque équipe choisit d'utiliser des règles différentes selon le moment.
Bien que l'analyse statique dans CI soit utile, elle peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant qu'ils codent, mais seulement plus tard, lorsqu'ils exécutent le code à l'aide d'un outil d'analyse statique. Un autre inconvénient de l'analyse statique dans CI est qu'il est facile d'ignorer les résultats.
Il est généralement possible de configurer des indicateurs de seuil dans le processus de compilation afin que l'équipe puisse accorder davantage d'attention aux résultats de l'analyse statique lorsque les indicateurs sont dépassés (par exemple, le nombre de règles déclenchées), ce qui entraîne l'échec de la compilation.
Analyse statique dans l'IDE
Il existe de nombreux plug-ins IDE qui exécutent des règles d'analyse statique dans l'IDE de manière périodique, selon les besoins ou lorsque le code est modifié, afin d'obtenir un retour plus rapide.
Ainsi, lorsque le programmeur écrit du code, l'IDE peut détecter les violations de règles. Afin de rendre plus difficile le non-respect des règles, il est possible de configurer les violations pour qu'elles soient affichées sous forme de code souligné dans l'éditeur.
Je considère personnellement que cette approche est utile pour améliorer le codage, en particulier lorsque l'on travaille avec de nouvelles bibliothèques prises en charge par les outils d'analyse statique. Il est possible que des faux positifs ou des règles non pertinentes génèrent un certain bruit. Cependant, ce problème peut être résolu en configurant l'outil d'analyse statique pour ignorer certaines règles spécifiques, ce qui nécessite une étape supplémentaire.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la modification des règles incombe au programmeur. Par conséquent, le programmeur doit comprendre la cause de la violation des règles et la méthode de correction.
Il existe peu d'outils d'analyse statique permettant de corriger les violations. En effet, les corrections sont souvent déterminées par l'équipe, les technologies utilisées et le style de codage convenu.
Règles de base
Lorsque des outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire en erreur quant à la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels un programmeur peut être confronté et toutes les situations dans lesquelles elles doivent être appliquées. Parfois, les situations dans lesquelles les règles doivent être appliquées sont subtiles et difficiles à détecter.
Nous espérons que l'utilisation d'outils d'analyse statique pour examiner plus en détail les règles et les violations permettra aux programmeurs de développer des techniques pour détecter et prévenir les problèmes dans le contexte de domaines spécifiques.
Si des règles contextuelles sont requises pour le domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque, et qu'il soit également difficile de configurer et d'étendre l'outil.
성가심
Il n'y a rien d'insurmontable parmi ces « désagréments ».
- Faux positif
- Modifications insuffisantes
- Configuration pour contourner les règles
- Ajouter des règles contextuelles
Cependant, il est regrettable que cet argument soit souvent utilisé comme prétexte pour ne pas utiliser d'outils d'analyse statique, car ceux-ci peuvent s'avérer extrêmement utiles de différentes manières.
- Mettre l'accent sur une approche plus efficace pour les développeurs juniors
- Obtention rapide de commentaires sur les violations de codage évidentes
- Le programmeur identifie des problèmes complexes qu'il n'a jamais rencontrés auparavant.
- Veuillez souligner que le programmeur a adopté une approche de codage appropriée (si aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie particulièrement les outils d'analyse statique fonctionnant dans l'IDE, car ils me permettent d'obtenir rapidement des commentaires sur le code.
Cela complète tous les processus d'examen des demandes de pull et l'intégration CI qui peuvent être présents dans le projet.
Je m'efforce de trouver des outils qui me permettent de prendre l'avantage et d'améliorer mon flux de travail personnel.
Lorsque l'outil est exécuté dans l'IDE, l'interface graphique et l'approche de configuration étant identiques, il peut être souhaitable de comparer les différents outils.
Les outils peuvent comporter des fonctionnalités ou des ensembles de règles qui se recoupent, mais il est conseillé d'installer plusieurs outils afin de tirer pleinement parti de leurs avantages.
Les outils d'analyse statique IDE que nous utilisons activement lors du codage sont les suivants :
- Vérification IntelliJ intégrée - Modèles de codage courants
- Spot Bug - Erreurs courantes
- Sonarint - Utilisation habituelle
- Style de vérification - Modèle de style général
- Sensei de Secure Code Warrior Sensei Création de règles personnalisées
Ils sont tous utilisés car ils se complètent et se renforcent mutuellement.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette vérification.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent également une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Il est possible de définir ou de désactiver des règles et de sélectionner le niveau d'erreur à utiliser lors de la mise en évidence dans l'IDE.
Il existe de nombreuses fonctionnalités d'inspection IntelliJ remarquables. Je le sais, car j'ai lu toutes les informations à ce sujet pendant que je rédigeais cet article. J'utilise IntelliJ Inspections par défaut et je ne l'ai pas encore configuré. Cependant, pour tirer le meilleur parti de l'inspection, il est nécessaire de lire attentivement les informations, d'identifier les éléments liés à votre style de codage et de configurer le niveau d'alerte afin de pouvoir les vérifier dans le code.
L'avantage d'IntelliJ Inspecing est qu'il est fourni gratuitement avec l'IDE et qu'il contribue à développer la mémoire musculaire de la manière suivante.
- Vérification des avertissements et des erreurs dans le code source lors de l'écriture du code.
- En plaçant votre souris sur le code marqué d'un drapeau, vous pouvez déterminer s'il y a violation des règles.
- Veuillez utiliser Alt+Entrée pour appliquer QuickFix au problème.
Spot Bug
Le plugin Spot Bugs pour IntelliJ identifie les erreurs dans le code à l'aide d'une analyse statique.
Vous pouvez configurer SpotBugs dans les paramètres par défaut d'IntelliJ afin de pouvoir analyser le code. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'écrire et de réviser le code, puis d'utiliser SpotBugs. Ensuite, je procède à l'analyse des fichiers du projet, y compris les sources de test.
Cette approche facilite l'identification des bogues, du code mort et des optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs identifie les problèmes, mais ne fournit pas de solution QuickFix pour les résoudre.
SpotBugs est facile à configurer et constitue, à mon avis, un avis objectif et secondaire que l'on peut consulter dans mon IDE.
Sona Lint
Plug-in Sonar Lint.
Dans les paramètres par défaut d'IntelliJ, il est possible de configurer SonarLint afin de sélectionner les règles de validation du code.
Par défaut, SonarLint s'exécute en temps réel et signale les problèmes dans le code en cours d'édition.
SonarLint ne fournit pas de fonctionnalité de correction rapide, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
Nous avons constaté que SonarLint est utile pour identifier les nouvelles fonctionnalités Java connues dans les versions récentes de Java.
Style de vérification
Le plugin Check Style fournit un ensemble de règles relatives au formatage et à la qualité du code.
Le plugin Checkstyle est fourni avec Sun Check et Google Check.
Leur définition peut être simple. Trouvé en ligne.
CheckStyle apporte le plus de valeur ajoutée 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 dans le processus CI lorsque le nombre de violations CheckStyle dépasse un seuil défini.
Monsieur
Nous utilisons une analyse statique basée sur l'AST (arbre syntaxique abstrait) pour la correspondance de code et la génération de QuickFixs, ce qui nous permet d'identifier très précisément les codes problématiques.
AST permet aux QuickFixs liés aux recettes de comprendre le code environnant. 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 faciliter la création de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement le code correspondant à la recette. De plus, lorsque vous définissez des QuickFixs, vous pouvez comparer instantanément l'état antérieur et l'état postérieur du code. Vous pouvez ainsi créer facilement des recettes adaptées à chaque situation (par exemple, des recettes uniques réservées à une équipe, à une technologie ou même à un programmeur individuel).
J'utilise Sensei en complément d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résolvent pas. Une utilisation courante de Sensei consiste à reproduire les recherches de correspondance d'autres outils dans Sensei et à les étendre à Quick Fix. Cela présente l'avantage que les modifications personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il arrive parfois que je crée Sensei qui existent déjà dans l'ensemble d'intentions IntelliJ, car le rapport d'intention ne correspond pas parfaitement au contexte que j'ai créé ou parce que la correction rapide fournie par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je préfère renforcer les outils existants plutôt que de les remplacer complètement.
Sensei peut également s'avérer très utile pour identifier les variations contextuelles des règles communes. 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 générales du moteur d'analyse statique s'appliquent toujours, vous pouvez utiliser Sensei pour créer une variante de ces règles spécifique à la bibliothèque.
Sensei ne fournit pas autant de recettes générales que les outils d'analyse statique mentionnés précédemment. La force de Sensei réside dans sa capacité à créer facilement de nouvelles recettes avec des QuickFix configurées pour s'adapter à des styles de codage et des cas d'utilisation spécifiques.
Remarque : nous développons actuellement un référentiel public de recettes afin de couvrir les cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent ensemble, qui sont configurables et qui peuvent être facilement adaptés à des situations spécifiques. J'utilise depuis plusieurs années les outils d'analyse statique de l'IDE, qui m'aident à identifier les problèmes et à mieux comprendre les langages de programmation et les bibliothèques que j'utilise.
Nous utilisons tous les outils mentionnés précédemment de manière combinée.
- Les intentions IntelliJ permettent généralement d'identifier rapidement les problèmes courants liés au code à l'aide de QuickFix.
- SpotBugs identifie les erreurs mineures que j'aurais pu manquer et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je ne connaissais pas et me fournit des méthodes supplémentaires pour modéliser le code.
- L'utilisation de CheckStyle permet de respecter le style de codage convenu, qui s'applique également pendant l'intégration continue.
- Sensei permet de créer des QuickFixs afin de compléter les scénarios courants détectés par les outils d'analyse statique et de créer des recettes techniques ou des projets spécifiques difficiles à configurer avec d'autres outils.
---
Dans IntelliJ, veuillez installer Sensei à l'aide de « Préférences\Plug-ins » (Mac) ou « Paramètres\Plug-ins » (Windows), puis recherchez le « code de sécurité Sensei ».
Vous trouverez des exemples de code et des recettes pour des cas d'utilisation courants 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, on parle d'analyse dynamique.
L'analyse statique est principalement utilisée pour détecter les éléments suivants :
- Vulnérabilité de sécurité.
- Problème de performance.
- Non-conformité aux 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 à analyser le code source afin d'identifier des modèles de codage spécifiques pouvant nécessiter une attention particulière.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Ou cela peut être aussi complexe à identifier que « Entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source pour générer un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Il s'agit de la combinaison ci-dessus.
Les expressions régulières pour le texte sont très flexibles et faciles à écrire, mais elles peuvent souvent entraîner de nombreux faux positifs et ignorent le contexte du code environnant.
La correspondance AST traite le code source non seulement comme un fichier rempli de texte, mais également comme un code de programme, ce qui permet une correspondance plus précise et adaptée au contexte, et réduit le nombre de faux positifs signalés pour le code.
Analyse statique dans l'intégration continue
L'analyse statique est fréquemment effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. L'examen de ces rapports permet d'évaluer objectivement la base de code au fil du temps.
Certains utilisateurs configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent que les sous-ensembles de règles, afin de les utiliser comme mesure objective de la qualité du code.
L'objectivité est garantie par les règles utilisées, car l'évaluation du code ne change pas avec le temps. Il est clair que la combinaison des règles utilisées et de leur composition relève d'une décision subjective, et chaque équipe choisit d'utiliser des règles différentes selon le moment.
Bien que l'analyse statique dans CI soit utile, elle peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant qu'ils codent, mais seulement plus tard, lorsqu'ils exécutent le code à l'aide d'un outil d'analyse statique. Un autre inconvénient de l'analyse statique dans CI est qu'il est facile d'ignorer les résultats.
Il est généralement possible de configurer des indicateurs de seuil dans le processus de compilation afin que l'équipe puisse accorder davantage d'attention aux résultats de l'analyse statique lorsque les indicateurs sont dépassés (par exemple, le nombre de règles déclenchées), ce qui entraîne l'échec de la compilation.
Analyse statique dans l'IDE
Il existe de nombreux plug-ins IDE qui exécutent des règles d'analyse statique dans l'IDE de manière périodique, selon les besoins ou lorsque le code est modifié, afin d'obtenir un retour plus rapide.
Ainsi, lorsque le programmeur écrit du code, l'IDE peut détecter les violations de règles. Afin de rendre plus difficile le non-respect des règles, il est possible de configurer les violations pour qu'elles soient affichées sous forme de code souligné dans l'éditeur.
Je considère personnellement que cette approche est utile pour améliorer le codage, en particulier lorsque l'on travaille avec de nouvelles bibliothèques prises en charge par les outils d'analyse statique. Il est possible que des faux positifs ou des règles non pertinentes génèrent un certain bruit. Cependant, ce problème peut être résolu en configurant l'outil d'analyse statique pour ignorer certaines règles spécifiques, ce qui nécessite une étape supplémentaire.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la modification des règles incombe au programmeur. Par conséquent, le programmeur doit comprendre la cause de la violation des règles et la méthode de correction.
Il existe peu d'outils d'analyse statique permettant de corriger les violations. En effet, les corrections sont souvent déterminées par l'équipe, les technologies utilisées et le style de codage convenu.
Règles de base
Lorsque des outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire en erreur quant à la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels un programmeur peut être confronté et toutes les situations dans lesquelles elles doivent être appliquées. Parfois, les situations dans lesquelles les règles doivent être appliquées sont subtiles et difficiles à détecter.
Nous espérons que l'utilisation d'outils d'analyse statique pour examiner plus en détail les règles et les violations permettra aux programmeurs de développer des techniques pour détecter et prévenir les problèmes dans le contexte de domaines spécifiques.
Si des règles contextuelles sont requises pour le domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque, et qu'il soit également difficile de configurer et d'étendre l'outil.
성가심
Il n'y a rien d'insurmontable parmi ces « désagréments ».
- Faux positif
- Modifications insuffisantes
- Configuration pour contourner les règles
- Ajouter des règles contextuelles
Cependant, il est regrettable que cet argument soit souvent utilisé comme prétexte pour ne pas utiliser d'outils d'analyse statique, car ceux-ci peuvent s'avérer extrêmement utiles de différentes manières.
- Mettre l'accent sur une approche plus efficace pour les développeurs juniors
- Obtention rapide de commentaires sur les violations de codage évidentes
- Le programmeur identifie des problèmes complexes qu'il n'a jamais rencontrés auparavant.
- Veuillez souligner que le programmeur a adopté une approche de codage appropriée (si aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie particulièrement les outils d'analyse statique fonctionnant dans l'IDE, car ils me permettent d'obtenir rapidement des commentaires sur le code.
Cela complète tous les processus d'examen des demandes de pull et l'intégration CI qui peuvent être présents dans le projet.
Je m'efforce de trouver des outils qui me permettent de prendre l'avantage et d'améliorer mon flux de travail personnel.
Lorsque l'outil est exécuté dans l'IDE, l'interface graphique et l'approche de configuration étant identiques, il peut être souhaitable de comparer les différents outils.
Les outils peuvent comporter des fonctionnalités ou des ensembles de règles qui se recoupent, mais il est conseillé d'installer plusieurs outils afin de tirer pleinement parti de leurs avantages.
Les outils d'analyse statique IDE que nous utilisons activement lors du codage sont les suivants :
- Vérification IntelliJ intégrée - Modèles de codage courants
- Spot Bug - Erreurs courantes
- Sonarint - Utilisation habituelle
- Style de vérification - Modèle de style général
- Sensei de Secure Code Warrior Sensei Création de règles personnalisées
Ils sont tous utilisés car ils se complètent et se renforcent mutuellement.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette vérification.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent également une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Il est possible de définir ou de désactiver des règles et de sélectionner le niveau d'erreur à utiliser lors de la mise en évidence dans l'IDE.
Il existe de nombreuses fonctionnalités d'inspection IntelliJ remarquables. Je le sais, car j'ai lu toutes les informations à ce sujet pendant que je rédigeais cet article. J'utilise IntelliJ Inspections par défaut et je ne l'ai pas encore configuré. Cependant, pour tirer le meilleur parti de l'inspection, il est nécessaire de lire attentivement les informations, d'identifier les éléments liés à votre style de codage et de configurer le niveau d'alerte afin de pouvoir les vérifier dans le code.
L'avantage d'IntelliJ Inspecing est qu'il est fourni gratuitement avec l'IDE et qu'il contribue à développer la mémoire musculaire de la manière suivante.
- Vérification des avertissements et des erreurs dans le code source lors de l'écriture du code.
- En plaçant votre souris sur le code marqué d'un drapeau, vous pouvez déterminer s'il y a violation des règles.
- Veuillez utiliser Alt+Entrée pour appliquer QuickFix au problème.
Spot Bug
Le plugin Spot Bugs pour IntelliJ identifie les erreurs dans le code à l'aide d'une analyse statique.
Vous pouvez configurer SpotBugs dans les paramètres par défaut d'IntelliJ afin de pouvoir analyser le code. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'écrire et de réviser le code, puis d'utiliser SpotBugs. Ensuite, je procède à l'analyse des fichiers du projet, y compris les sources de test.
Cette approche facilite l'identification des bogues, du code mort et des optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs identifie les problèmes, mais ne fournit pas de solution QuickFix pour les résoudre.
SpotBugs est facile à configurer et constitue, à mon avis, un avis objectif et secondaire que l'on peut consulter dans mon IDE.
Sona Lint
Plug-in Sonar Lint.
Dans les paramètres par défaut d'IntelliJ, il est possible de configurer SonarLint afin de sélectionner les règles de validation du code.
Par défaut, SonarLint s'exécute en temps réel et signale les problèmes dans le code en cours d'édition.
SonarLint ne fournit pas de fonctionnalité de correction rapide, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
Nous avons constaté que SonarLint est utile pour identifier les nouvelles fonctionnalités Java connues dans les versions récentes de Java.
Style de vérification
Le plugin Check Style fournit un ensemble de règles relatives au formatage et à la qualité du code.
Le plugin Checkstyle est fourni avec Sun Check et Google Check.
Leur définition peut être simple. Trouvé en ligne.
CheckStyle apporte le plus de valeur ajoutée 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 dans le processus CI lorsque le nombre de violations CheckStyle dépasse un seuil défini.
Monsieur
Nous utilisons une analyse statique basée sur l'AST (arbre syntaxique abstrait) pour la correspondance de code et la génération de QuickFixs, ce qui nous permet d'identifier très précisément les codes problématiques.
AST permet aux QuickFixs liés aux recettes de comprendre le code environnant. 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 faciliter la création de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement le code correspondant à la recette. De plus, lorsque vous définissez des QuickFixs, vous pouvez comparer instantanément l'état antérieur et l'état postérieur du code. Vous pouvez ainsi créer facilement des recettes adaptées à chaque situation (par exemple, des recettes uniques réservées à une équipe, à une technologie ou même à un programmeur individuel).
J'utilise Sensei en complément d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résolvent pas. Une utilisation courante de Sensei consiste à reproduire les recherches de correspondance d'autres outils dans Sensei et à les étendre à Quick Fix. Cela présente l'avantage que les modifications personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il arrive parfois que je crée Sensei qui existent déjà dans l'ensemble d'intentions IntelliJ, car le rapport d'intention ne correspond pas parfaitement au contexte que j'ai créé ou parce que la correction rapide fournie par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je préfère renforcer les outils existants plutôt que de les remplacer complètement.
Sensei peut également s'avérer très utile pour identifier les variations contextuelles des règles communes. 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 générales du moteur d'analyse statique s'appliquent toujours, vous pouvez utiliser Sensei pour créer une variante de ces règles spécifique à la bibliothèque.
Sensei ne fournit pas autant de recettes générales que les outils d'analyse statique mentionnés précédemment. La force de Sensei réside dans sa capacité à créer facilement de nouvelles recettes avec des QuickFix configurées pour s'adapter à des styles de codage et des cas d'utilisation spécifiques.
Remarque : nous développons actuellement un référentiel public de recettes afin de couvrir les cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent ensemble, qui sont configurables et qui peuvent être facilement adaptés à des situations spécifiques. J'utilise depuis plusieurs années les outils d'analyse statique de l'IDE, qui m'aident à identifier les problèmes et à mieux comprendre les langages de programmation et les bibliothèques que j'utilise.
Nous utilisons tous les outils mentionnés précédemment de manière combinée.
- Les intentions IntelliJ permettent généralement d'identifier rapidement les problèmes courants liés au code à l'aide de QuickFix.
- SpotBugs identifie les erreurs mineures que j'aurais pu manquer et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je ne connaissais pas et me fournit des méthodes supplémentaires pour modéliser le code.
- L'utilisation de CheckStyle permet de respecter le style de codage convenu, qui s'applique également pendant l'intégration continue.
- Sensei permet de créer des QuickFixs afin de compléter les scénarios courants détectés par les outils d'analyse statique et de créer des recettes techniques ou des projets spécifiques difficiles à configurer avec d'autres outils.
---
Dans IntelliJ, veuillez installer Sensei à l'aide de « Préférences\Plug-ins » (Mac) ou « Paramètres\Plug-ins » (Windows), puis recherchez le « code de sécurité Sensei ».
Vous trouverez des exemples de code et des recettes pour des cas d'utilisation courants 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 est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Consulter le rapportVeuillez prendre rendez-vous pour 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, on parle d'analyse dynamique.
L'analyse statique est principalement utilisée pour détecter les éléments suivants :
- Vulnérabilité de sécurité.
- Problème de performance.
- Non-conformité aux 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 à analyser le code source afin d'identifier des modèles de codage spécifiques pouvant nécessiter une attention particulière.
Cela peut être aussi simple que « Les classes de test JUnit 5 n'ont pas besoin d'être publiques ». Ou cela peut être aussi complexe à identifier que « Entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».
Les outils d'analyse statique implémentent cette fonctionnalité de différentes manières.
- Technique d'analyse syntaxique du code source pour générer un arbre syntaxique abstrait (AST)
- Correspondance d'expressions régulières de texte,
- Il s'agit de la combinaison ci-dessus.
Les expressions régulières pour le texte sont très flexibles et faciles à écrire, mais elles peuvent souvent entraîner de nombreux faux positifs et ignorent le contexte du code environnant.
La correspondance AST traite le code source non seulement comme un fichier rempli de texte, mais également comme un code de programme, ce qui permet une correspondance plus précise et adaptée au contexte, et réduit le nombre de faux positifs signalés pour le code.
Analyse statique dans l'intégration continue
L'analyse statique est fréquemment effectuée au cours du processus d'intégration continue (CI) afin de générer des rapports sur les problèmes de conformité. L'examen de ces rapports permet d'évaluer objectivement la base de code au fil du temps.
Certains utilisateurs configurent les outils d'analyse statique pour qu'ils mesurent uniquement certaines parties du code et ne signalent que les sous-ensembles de règles, afin de les utiliser comme mesure objective de la qualité du code.
L'objectivité est garantie par les règles utilisées, car l'évaluation du code ne change pas avec le temps. Il est clair que la combinaison des règles utilisées et de leur composition relève d'une décision subjective, et chaque équipe choisit d'utiliser des règles différentes selon le moment.
Bien que l'analyse statique dans CI soit utile, elle peut entraîner un retard dans le retour d'information aux programmeurs. Les programmeurs ne reçoivent pas de retour d'information pendant qu'ils codent, mais seulement plus tard, lorsqu'ils exécutent le code à l'aide d'un outil d'analyse statique. Un autre inconvénient de l'analyse statique dans CI est qu'il est facile d'ignorer les résultats.
Il est généralement possible de configurer des indicateurs de seuil dans le processus de compilation afin que l'équipe puisse accorder davantage d'attention aux résultats de l'analyse statique lorsque les indicateurs sont dépassés (par exemple, le nombre de règles déclenchées), ce qui entraîne l'échec de la compilation.
Analyse statique dans l'IDE
Il existe de nombreux plug-ins IDE qui exécutent des règles d'analyse statique dans l'IDE de manière périodique, selon les besoins ou lorsque le code est modifié, afin d'obtenir un retour plus rapide.
Ainsi, lorsque le programmeur écrit du code, l'IDE peut détecter les violations de règles. Afin de rendre plus difficile le non-respect des règles, il est possible de configurer les violations pour qu'elles soient affichées sous forme de code souligné dans l'éditeur.
Je considère personnellement que cette approche est utile pour améliorer le codage, en particulier lorsque l'on travaille avec de nouvelles bibliothèques prises en charge par les outils d'analyse statique. Il est possible que des faux positifs ou des règles non pertinentes génèrent un certain bruit. Cependant, ce problème peut être résolu en configurant l'outil d'analyse statique pour ignorer certaines règles spécifiques, ce qui nécessite une étape supplémentaire.
Modification du code basée sur des règles d'analyse statique
Dans la plupart des outils d'analyse statique, la modification des règles incombe au programmeur. Par conséquent, le programmeur doit comprendre la cause de la violation des règles et la méthode de correction.
Il existe peu d'outils d'analyse statique permettant de corriger les violations. En effet, les corrections sont souvent déterminées par l'équipe, les technologies utilisées et le style de codage convenu.
Règles de base
Lorsque des outils d'analyse statique sont fournis avec des règles par défaut, cela peut induire en erreur quant à la qualité de ces règles. Il est facile de croire qu'elles couvrent tous les problèmes auxquels un programmeur peut être confronté et toutes les situations dans lesquelles elles doivent être appliquées. Parfois, les situations dans lesquelles les règles doivent être appliquées sont subtiles et difficiles à détecter.
Nous espérons que l'utilisation d'outils d'analyse statique pour examiner plus en détail les règles et les violations permettra aux programmeurs de développer des techniques pour détecter et prévenir les problèmes dans le contexte de domaines spécifiques.
Si des règles contextuelles sont requises pour le domaine, il est possible que l'outil d'analyse statique ne dispose pas de règles correspondant au domaine ou à la bibliothèque, et qu'il soit également difficile de configurer et d'étendre l'outil.
성가심
Il n'y a rien d'insurmontable parmi ces « désagréments ».
- Faux positif
- Modifications insuffisantes
- Configuration pour contourner les règles
- Ajouter des règles contextuelles
Cependant, il est regrettable que cet argument soit souvent utilisé comme prétexte pour ne pas utiliser d'outils d'analyse statique, car ceux-ci peuvent s'avérer extrêmement utiles de différentes manières.
- Mettre l'accent sur une approche plus efficace pour les développeurs juniors
- Obtention rapide de commentaires sur les violations de codage évidentes
- Le programmeur identifie des problèmes complexes qu'il n'a jamais rencontrés auparavant.
- Veuillez souligner que le programmeur a adopté une approche de codage appropriée (si aucune violation n'a été signalée).
Outil d'analyse statique basé sur IDE
En tant que contributeur individuel au projet, j'apprécie particulièrement les outils d'analyse statique fonctionnant dans l'IDE, car ils me permettent d'obtenir rapidement des commentaires sur le code.
Cela complète tous les processus d'examen des demandes de pull et l'intégration CI qui peuvent être présents dans le projet.
Je m'efforce de trouver des outils qui me permettent de prendre l'avantage et d'améliorer mon flux de travail personnel.
Lorsque l'outil est exécuté dans l'IDE, l'interface graphique et l'approche de configuration étant identiques, il peut être souhaitable de comparer les différents outils.
Les outils peuvent comporter des fonctionnalités ou des ensembles de règles qui se recoupent, mais il est conseillé d'installer plusieurs outils afin de tirer pleinement parti de leurs avantages.
Les outils d'analyse statique IDE que nous utilisons activement lors du codage sont les suivants :
- Vérification IntelliJ intégrée - Modèles de codage courants
- Spot Bug - Erreurs courantes
- Sonarint - Utilisation habituelle
- Style de vérification - Modèle de style général
- Sensei de Secure Code Warrior Sensei Création de règles personnalisées
Ils sont tous utilisés car ils se complètent et se renforcent mutuellement.
Inspection IntelliJ
Si vous utilisez IntelliJ, vous utilisez déjà cette vérification.
Il s'agit de règles d'analyse statique marquées dans l'IDE. Certaines d'entre elles proposent également une option QuickFix permettant de réécrire le code afin de résoudre le problème.
Il est possible de définir ou de désactiver des règles et de sélectionner le niveau d'erreur à utiliser lors de la mise en évidence dans l'IDE.
Il existe de nombreuses fonctionnalités d'inspection IntelliJ remarquables. Je le sais, car j'ai lu toutes les informations à ce sujet pendant que je rédigeais cet article. J'utilise IntelliJ Inspections par défaut et je ne l'ai pas encore configuré. Cependant, pour tirer le meilleur parti de l'inspection, il est nécessaire de lire attentivement les informations, d'identifier les éléments liés à votre style de codage et de configurer le niveau d'alerte afin de pouvoir les vérifier dans le code.
L'avantage d'IntelliJ Inspecing est qu'il est fourni gratuitement avec l'IDE et qu'il contribue à développer la mémoire musculaire de la manière suivante.
- Vérification des avertissements et des erreurs dans le code source lors de l'écriture du code.
- En plaçant votre souris sur le code marqué d'un drapeau, vous pouvez déterminer s'il y a violation des règles.
- Veuillez utiliser Alt+Entrée pour appliquer QuickFix au problème.
Spot Bug
Le plugin Spot Bugs pour IntelliJ identifie les erreurs dans le code à l'aide d'une analyse statique.
Vous pouvez configurer SpotBugs dans les paramètres par défaut d'IntelliJ afin de pouvoir analyser le code. Les règles effectivement utilisées se trouvent dans l'onglet Detector.
J'ai l'habitude d'écrire et de réviser le code, puis d'utiliser SpotBugs. Ensuite, je procède à l'analyse des fichiers du projet, y compris les sources de test.
Cette approche facilite l'identification des bogues, du code mort et des optimisations évidentes. Il est également nécessaire d'examiner certaines des violations signalées afin de déterminer les mesures à prendre.
SpotBugs identifie les problèmes, mais ne fournit pas de solution QuickFix pour les résoudre.
SpotBugs est facile à configurer et constitue, à mon avis, un avis objectif et secondaire que l'on peut consulter dans mon IDE.
Sona Lint
Plug-in Sonar Lint.
Dans les paramètres par défaut d'IntelliJ, il est possible de configurer SonarLint afin de sélectionner les règles de validation du code.
Par défaut, SonarLint s'exécute en temps réel et signale les problèmes dans le code en cours d'édition.
SonarLint ne fournit pas de fonctionnalité de correction rapide, mais les documents relatifs aux rapports d'infraction sont généralement clairs et bien documentés.
Nous avons constaté que SonarLint est utile pour identifier les nouvelles fonctionnalités Java connues dans les versions récentes de Java.
Style de vérification
Le plugin Check Style fournit un ensemble de règles relatives au formatage et à la qualité du code.
Le plugin Checkstyle est fourni avec Sun Check et Google Check.
Leur définition peut être simple. Trouvé en ligne.
CheckStyle apporte le plus de valeur ajoutée 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 dans le processus CI lorsque le nombre de violations CheckStyle dépasse un seuil défini.
Monsieur
Nous utilisons une analyse statique basée sur l'AST (arbre syntaxique abstrait) pour la correspondance de code et la génération de QuickFixs, ce qui nous permet d'identifier très précisément les codes problématiques.
AST permet aux QuickFixs liés aux recettes de comprendre le code environnant. 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 faciliter la création de règles de correspondance personnalisées qui n'existent pas dans d'autres outils ou qui sont difficiles à configurer.
Au lieu de modifier les fichiers de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lorsque vous créez une nouvelle recette, l'interface graphique vous permet de vérifier facilement le code correspondant à la recette. De plus, lorsque vous définissez des QuickFixs, vous pouvez comparer instantanément l'état antérieur et l'état postérieur du code. Vous pouvez ainsi créer facilement des recettes adaptées à chaque situation (par exemple, des recettes uniques réservées à une équipe, à une technologie ou même à un programmeur individuel).
J'utilise Sensei en complément d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique détectent les problèmes, mais ne les résolvent pas. Une utilisation courante de Sensei consiste à reproduire les recherches de correspondance d'autres outils dans Sensei et à les étendre à Quick Fix. Cela présente l'avantage que les modifications personnalisées appliquées sont déjà conformes aux normes de codage du projet.
Il arrive parfois que je crée Sensei qui existent déjà dans l'ensemble d'intentions IntelliJ, car le rapport d'intention ne correspond pas parfaitement au contexte que j'ai créé ou parce que la correction rapide fournie par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.
Je préfère renforcer les outils existants plutôt que de les remplacer complètement.
Sensei peut également s'avérer très utile pour identifier les variations contextuelles des règles communes. 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 générales du moteur d'analyse statique s'appliquent toujours, vous pouvez utiliser Sensei pour créer une variante de ces règles spécifique à la bibliothèque.
Sensei ne fournit pas autant de recettes générales que les outils d'analyse statique mentionnés précédemment. La force de Sensei réside dans sa capacité à créer facilement de nouvelles recettes avec des QuickFix configurées pour s'adapter à des styles de codage et des cas d'utilisation spécifiques.
Remarque : nous développons actuellement un référentiel public de recettes afin de couvrir les cas d'utilisation courants. Vous pouvez le trouver ici.
Résumé
J'ai tendance à privilégier les outils qui fonctionnent ensemble, qui sont configurables et qui peuvent être facilement adaptés à des situations spécifiques. J'utilise depuis plusieurs années les outils d'analyse statique de l'IDE, qui m'aident à identifier les problèmes et à mieux comprendre les langages de programmation et les bibliothèques que j'utilise.
Nous utilisons tous les outils mentionnés précédemment de manière combinée.
- Les intentions IntelliJ permettent généralement d'identifier rapidement les problèmes courants liés au code à l'aide de QuickFix.
- SpotBugs identifie les erreurs mineures que j'aurais pu manquer et signale les problèmes de performance.
- SonarLint identifie les fonctionnalités Java que je ne connaissais pas et me fournit des méthodes supplémentaires pour modéliser le code.
- L'utilisation de CheckStyle permet de respecter le style de codage convenu, qui s'applique également pendant l'intégration continue.
- Sensei permet de créer des QuickFixs afin de compléter les scénarios courants détectés par les outils d'analyse statique et de créer des recettes techniques ou des projets spécifiques difficiles à configurer avec d'autres outils.
---
Dans IntelliJ, veuillez installer Sensei à l'aide de « Préférences\Plug-ins » (Mac) ou « Paramètres\Plug-ins » (Windows), puis recherchez le « code de sécurité Sensei ».
Vous trouverez des exemples de code et des recettes pour des cas d'utilisation courants 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 est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez prendre rendez-vous pour une démonstration.TéléchargerRessources utiles pour débuter
Thèmes et contenus de la formation sur les codes de sécurité
Le contenu le plus pertinent du secteur évolue constamment pour s'adapter à l'environnement de développement logiciel en constante évolution, en tenant compte du rôle des clients. Des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité, tous les rôles sont couverts, de l'IA à l'injection XQuery. Veuillez consulter le catalogue de contenu pour découvrir ce qui est proposé par thème 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 utiles pour débuter
Cybermon est de retour : la mission IA de défaite du boss est désormais disponible à la demande.
Cybermon 2025 Bit The Boss est désormais disponible toute l'année sur SCW. Renforcez le développement de l'IA de sécurité à grande échelle en déployant des défis de sécurité IA/LLM avancés.
Explication de la loi sur la cyber-résilience : l'importance de la conception sécurisée dans le développement de logiciels
Découvrez les exigences de la loi européenne sur la résilience des réseaux et des services (CRA), son champ d'application et comment votre équipe d'ingénieurs peut se préparer en toute sécurité grâce à la conception, aux pratiques, à la prévention des vulnérabilités et à la mise en place d'un environnement de développement.
Facteur de réussite n° 1 : des critères de réussite clairement définis et mesurables
Enabler 1 présente une série de dix articles consacrés aux facteurs de réussite, en démontrant comment le codage sécurisé peut améliorer les performances commerciales, notamment en accélérant la réduction des risques et des coûts pour la maturité des programmes à long terme.
