Qu'est-ce que l'analyse statique ?

Qu'est-ce que l'analyse statique ?

L'analyse statique est l'analyse automatique du code source sans exécuter l'application.

Lorsque l'analyse est effectuée pendant l'exécution du programme, elle est connue sous le nom d'analyse dynamique.

L'analyse statique est fréquemment employée pour détecter :

• Vulnérabilités de sécurité.
• Problèmes de performance.
• Non-respect des normes.
• Utilisation de structures de programmation qui ne sont plus d'actualité.

Comment fonctionne un outil d'analyse statique ?

Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source afin d'identifier des modèles de codage spécifiques associés à un type d'avertissement ou d'information.

Cela pourrait être aussi simple que « les classes de test de JUnit 5 n'ont pas besoin d'être « publiques » ». Ou quelque chose de complexe à identifier, comme « une entrée de chaîne non fiable utilisée dans une instruction d'exécution SQL ».

La manière dont les outils d'analyse statique implémentent cette fonctionnalité varie.

• technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
• correspondance de texte avec des expressions régulières,
• une combinaison des éléments susmentionnés.

La correspondance d'expressions régulières sur du texte est très flexible, il est facile d'écrire des règles de correspondance, mais elle peut souvent entraîner de nombreux faux positifs et les règles de correspondance ignorent le contexte de code environnant.

La correspondance AST traite le code source comme du code de programme, et pas seulement comme des fichiers remplis de texte. Cela permet une correspondance contextuelle plus spécifique et peut réduire le nombre de faux positifs signalés par rapport au code.

Analyse statique dans le cadre de l'intégration continue

L'analyse statique est fréquemment réalisée au cours du processus d'intégration continue (CI) afin de générer un rapport sur les problèmes de conformité qui peut être examiné pour obtenir une vue objective de la base de code au fil du temps.

Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique pour ne mesurer que des parties spécifiques du code et ne générer des rapports que sur un sous-ensemble de règles.

L'objectivité est garantie par les règles utilisées, car celles-ci ne varient pas dans leur évaluation du code au fil du temps. Il est évident que la combinaison des règles utilisées et leur configuration constituent une décision subjective, et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.

L'exécution de l'analyse statique dans CI est utile mais peut retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de feedback lorsqu'ils codent, ils le reçoivent plus tard lorsque le code est exécuté via l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique dans CI est que les résultats sont plus faciles à ignorer.

Afin d'encourager les équipes à accorder davantage d'attention aux résultats de l'analyse statique, il est généralement possible de configurer une métrique de seuil dans le processus de génération pour qu'il échoue si la métrique est dépassée, par exemple si un certain nombre de règles sont déclenchées.

Analyse statique dans l'environnement de développement intégré

Afin de recevoir des commentaires plus rapidement, de nombreux plugins de l'EDI exécutent les règles d'analyse statique dans l'EDI à la demande ou périodiquement à mesure que le code change.

Les violations de règles peuvent alors être détectées dans l'EDI pendant que le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.

Personnellement, je considère que c'est un moyen efficace d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être « bruyant » avec des faux positifs ou des règles qui ne vous intéressent pas. Cependant, ce problème est résolu en prenant la mesure supplémentaire de configurer l'outil d'analyse statique pour ignorer certaines règles.

Modifier le code conformément aux règles d'analyse statique

Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur. Il est donc nécessaire de comprendre la cause de la violation de la règle et comment la corriger.

Très peu d'outils d'analyse statique permettent également de corriger les violations, car la correction dépend souvent du contexte de l'équipe, de la technologie utilisée et des styles de codage convenus.

Règles par défaut

Une confiance injustifiée dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont fournis avec des règles par défaut. Il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur peut rencontrer et toutes les circonstances dans lesquelles ces règles devraient s'appliquer. Parfois, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.

L'espoir est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.

Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas disposer de règles correspondant à votre domaine ou à votre bibliothèque. De plus, ces outils peuvent souvent être difficiles à configurer et à développer.

Inconvénients

Aucun de ces « inconvénients » n'est insurmontable :

• faux positifs
• absence de solutions
• configuration pour contourner les règles
• Ajout de règles spécifiques au contexte

Cependant, ils sont fréquemment utilisés comme prétextes pour éviter d'utiliser les outils d'analyse statique en premier lieu, ce qui est regrettable car l'utilisation de l'analyse statique peut être extrêmement utile pour :

• mettre en évidence les meilleures approches pour les développeurs débutants
• Recevoir rapidement des commentaires sur les violations de codage évidentes
• identifier les problèmes complexes que le programmeur n'a jamais rencontrés auparavant
• confirmer que le programmeur a adopté une approche de codage appropriée (lorsqu'aucune violation n'est signalée)

Outils d'analyse statique basés sur l'IDE

En tant que contributeur individuel à un projet, j'apprécie d'utiliser les outils d'analyse statique qui s'exécutent depuis l'EDI afin d'obtenir rapidement des commentaires sur mon code.

Ceci complète tout processus de révision des pull requests et l'intégration CI qu'un projet peut avoir.

Je m'efforce d'identifier les outils qui me procureront un avantage et amélioreront mon flux de travail individuel.

Lorsque les outils s'exécutent dans l'EDI, étant donné qu'ils ont tendance à partager la même interface graphique de base et la même approche de configuration, il peut être tentant de les considérer comme interchangeables.

Les outils peuvent présenter des fonctionnalités ou des ensembles de règles qui se recoupent, mais pour en tirer le meilleur parti, j'installe plusieurs outils afin de tirer parti de leurs points forts.

Les outils IDE d'analyse statique que j'utilise activement lors du codage sont répertoriés ci-dessous :

• Inspections IntelliJ intégrées - modèles de codage courants
• SpotBugs - Erreurs courantes
• SonarLint - Modèles d'utilisation courants
• CheckStyle - modèles de style courants
• Sensei Secure Code Warrior Création de règles personnalisées

Je les utilise tous car ils fonctionnent bien ensemble, se complétant et se renforçant mutuellement.

Inspections IntelliJ

Si vous utilisez IntelliJ, vous utilisez déjà ses inspections.

Il s'agit de règles d'analyse statique qui sont signalées dans l'EDI. Certaines d'entre elles disposent également d'options QuickFix pour réécrire le code afin de résoudre le problème.

Les règles peuvent être activées ou désactivées, et il est possible de sélectionner le niveau d'erreur utilisé pour les mettre en évidence dans l'EDI.

Il existe de nombreuses inspections IntelliJ de qualité. J'en suis conscient car je les ai consultées lors de la rédaction de cet article. J'utilise les inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des inspections, il est nécessaire de les examiner, d'identifier celles qui correspondent à votre style de codage et de configurer le niveau d'avertissement de manière à ce que vous les remarquiez 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 :

• en notant les avertissements et les erreurs dans le code source lorsque vous écrivez du code
• Veuillez passer votre souris sur le code marqué pour identifier les violations des règles.
• En utilisant Alt+Entrée pour appliquer une correction rapide au problème.

Identifiez les erreurs

Identifiez les bogues Le plugin IntelliJ utilise l'analyse statique pour tenter de vous avertir des bogues dans votre code.

SpotBugs peut être configuré à partir des préférences d'IntelliJ pour analyser votre code. Les règles réelles utilisées se trouvent dans l'onglet Détecteur.

J'ai l'habitude d'utiliser SpotBugs après avoir rédigé et révisé mon code, puis j'exécute la commande « Analyser les fichiers de projet, y compris les sources de test ».

Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à effectuer des recherches sur certaines des violations signalées afin de m'aider à déterminer la marche à suivre.

SpotBugs identifiera les problèmes mais ne proposera aucune solution QuickFix pour tenter de les résoudre.

SpotBugs est facile à configurer et je considère qu'il s'agit d'un deuxième avis objectif utile à consulter dans mon IDE.

Sonar Lint

Le plug-in Sonar Lint.

SonarLint peut être configuré à partir des préférences IntelliJ pour sélectionner les règles selon lesquelles le code est validé.

Par défaut, SonarLint s'exécute en temps réel et affiche les problèmes liés au code actuel que vous modifiez.

SonarLint ne fournit pas de solutions immédiates, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.

J'ai trouvé SonarLint utile par le passé pour m'avertir des nouvelles fonctionnalités de Java dont j'avais connaissance dans les nouvelles versions de Java.

Veuillez vérifier le style

Vérifiez le style. Le plugin propose un ensemble de règles de formatage et de qualité du code.

Le plugin CheckStyle est fourni avec « Sun Checks » et « Google Checks ».

Les définitions de ces termes peuvent être facilement trouvées en ligne.

CheckStyle apporte le plus de valeur lorsqu'un projet a consacré du temps à créer son propre ensemble de règles. Ensuite, le plugin IDE peut être configuré pour utiliser cet ensemble de règles et les programmeurs peuvent effectuer une analyse avant de valider le code dans CI.

CheckStyle est fréquemment utilisé comme plugin d'échec de construction pour les processus CI lorsque le nombre de violations de CheckStyle dépasse un seuil.

Maître

Senseï utilise une analyse statique basée sur un arbre de syntaxe abstrait (AST) pour faire correspondre le code et créer des QuickFix, ce qui permet une identification très spécifique du code présentant des problèmes.

L'AST permet aux QuickFIX associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.

Sensei été conçu pour simplifier la création de règles de correspondance personnalisées qui peuvent ne pas exister ou qui seraient difficiles à configurer dans d'autres outils.

Au lieu de modifier un fichier de configuration, toutes les configurations peuvent être effectuées dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code correspond la recette. De plus, lors de la définition des QuickFix, l'état avant et après du code peut être comparé immédiatement. Cela facilite la création de recettes très contextuelles, c'est-à-dire propres aux équipes, à la technologie et même aux programmeurs individuels.

J'utilise Sensei combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique identifient les problèmes, mais ne les résolvent pas. Une utilisation courante de Sensei à reproduire la recherche correspondante de l'autre outil dans Sensei à l'étendre à l'aide d'une solution rapide. Cela présente l'avantage que le correctif personnalisé appliqué répond déjà aux normes de codage de votre projet.

Je me retrouve régulièrement à créer des recettes Sensei existent déjà dans le set IntelliJ Intensions, soit parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé, soit parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.

Je complète les outils existants, plutôt que de tenter de les remplacer complètement.

Sensei également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune. Par exemple, si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL courantes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.

Sensei propose pas un grand nombre de recettes génériques, telles que les outils d'analyse statique mentionnés, mais sa force réside dans le fait qu'il facilite la création de nouvelles recettes, avec des QuickFix configurés pour correspondre à votre style de codage et à vos cas d'utilisation spécifiques.

REMARQUE : nous travaillons actuellement sur un référentiel public de recettes afin de couvrir les cas d'utilisation génériques, et vous pouvez le consulter ici.

Curriculum vitae

J'ai tendance à sélectionner des outils qui fonctionnent ensemble, qui sont configurables et faciles à développer afin de répondre à mon contexte spécifique. J'utilise les outils d'analyse statique de l'EDI depuis plusieurs années pour m'aider à identifier les problèmes et à approfondir mes connaissances sur les langages de programmation et les bibliothèques que j'utilise.

J'utilise tous les outils mentionnés en combinaison :

• IntelliJ Intentions permet de signaler les problèmes courants liés au code dès le début, souvent avec des solutions rapides associées.
• SpotBugs identifie les bogues simples que j'aurais pu omettre et m'informe en cas de problèmes de performances.
• SonarLint identifie les fonctionnalités de Java dont je n'avais pas connaissance et me suggère d'autres méthodes pour structurer mon code.
• CheckStyle m'assiste dans le respect d'un style de codage convenu qui est également appliqué pendant l'intégration continue.
• Sensei dans la création de QuickFix afin de compléter les scénarios courants détectés par les outils d'analyse statique et de générer des recettes de projets ou de technologies spécifiques qui peuvent être difficiles à configurer dans un autre outil.

---

Veuillez installer Sensei IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « code sécurisé Sensei

Vous pouvez trouver un référentiel d'exemples de code et de recettes pour les cas d'utilisation courants sur le compte GitHub de Secure Code Warrior, dans le cadre du projet `sensei`.

https://github.com/securecodewarrior/sensei-blog-examples

Pour en savoir plus sur Sensei