Qu'est-ce que l'analyse statique ?

Qu'est-ce que l'analyse statique ?

L'analyse statique est l'analyse automatisée du code source sans exécution de l'application.

Lorsque l'analyse est effectuée pendant l'exécution du programme, on parle alors d'analyse dynamique.

L'analyse statique est souvent utilisée pour détecter :

• Les vulnérabilités de sécurité.
• Les problèmes de performance.
• Le non-respect des normes.
• L'utilisation de constructions de programmation obsolètes.

Comment fonctionne un outil d'analyse statique ?

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

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

Les outils d'analyse statique varient dans la manière dont ils implémentent cette fonctionnalité.

• technologie d'analyse du code source pour créer un arbre syntaxique abstrait (AST),
• correspondance par expressions régulières textuelles,
• une combinaison des deux.

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

La correspondance par AST traite le code source comme un programme et non simplement comme des fichiers remplis de texte ; cela permet une correspondance plus précise et contextuelle, et peut réduire le nombre de faux positifs signalés.

L'analyse statique dans l'intégration continue

L'analyse statique est souvent effectuée pendant le processus d'intégration continue (CI) pour générer un rapport sur les problèmes de conformité, qui peut être examiné afin d'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 pour qu'il n'analyse que des parties spécifiques du code et ne rapporte qu'un sous-ensemble de règles.

L'objectivité est assurée par les règles utilisées, car leur évaluation du code ne varie pas dans le temps. Bien entendu, la combinaison des règles utilisées et leur configuration restent une décision subjective, et différentes équipes choisissent d'utiliser des règles différentes à des moments différents.

Effectuer l'analyse statique lors de l'intégration continue est utile, mais cela peut retarder le retour d'information pour le développeur. Les programmeurs ne reçoivent pas de feedback pendant qu'ils codent, mais plus tard, lorsque le code est soumis à l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique en CI est que les résultats sont plus faciles à ignorer.

Pour inciter les équipes à accorder plus d'attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil dans le processus de build afin d'interrompre celui-ci si ce seuil est dépassé, par exemple en fonction du nombre de règles déclenchées.

Analyse statique dans l'IDE

Pour obtenir un retour plus rapide, de nombreux plugins d'IDE permettent d'exécuter les règles d'analyse statique à la demande ou périodiquement, au fur et à mesure des modifications du code.

Les violations des règles apparaissent alors directement dans l'IDE pendant que le développeur écrit son code. Pour rendre ces règles plus difficiles à ignorer, il est souvent possible de configurer l'éditeur pour qu'il souligne le code problématique.

Personnellement, je trouve que c'est un excellent moyen d'améliorer mon code, surtout lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien que cela puisse être parfois « bruyant » à cause des faux positifs ou de règles qui ne nous concernent pas, il suffit de prendre le temps de configurer l'outil pour ignorer certaines règles.

Corriger le code à partir des règles d'analyse statique

Avec la plupart des outils d'analyse statique, la correction des violations incombe au développeur, qui doit comprendre la cause de l'erreur et savoir comment la résoudre.

Très peu d'outils d'analyse statique incluent une fonction de correction automatique, car la solution dépend souvent du contexte de l'équipe, de la technologie utilisée et des conventions de codage établies.

Règles par défaut

Une fausse confiance dans la qualité des règles peut apparaître 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 développeur pourrait rencontrer, dans toutes les situations possibles. Or, les circonstances dans lesquelles une règle doit s'appliquer peuvent être subtiles et difficiles à détecter.

L'objectif est qu'en utilisant un outil d'analyse statique et en étudiant plus en détail les règles et les violations, les développeurs acquièrent les compétences nécessaires pour détecter et éviter ces problèmes dans le contexte spécifique de leur domaine.

Lorsque le domaine nécessite des règles contextuelles, il arrive que les outils d'analyse statique ne proposent aucune règle adaptée à votre domaine ou à votre bibliothèque. De plus, ces outils sont souvent complexes à configurer et à étendre.

Désagréments

Aucun de ces « désagréments » n'est insurmontable :

• faux positifs
• absence de corrections automatiques
• configuration nécessaire pour ignorer certaines règles
• ajout de règles spécifiques au contexte

Mais ils servent souvent d'excuses pour éviter d'utiliser des outils d'analyse statique, ce qui est regrettable car l'analyse statique peut s'avérer extrêmement utile pour :

• montrer de meilleures pratiques aux développeurs juniors
• obtenir un retour rapide sur les violations de code évidentes
• identifier des problèmes obscurs que le développeur n'a jamais rencontrés auparavant
• confirmer que le développeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)

Outils d'analyse statique intégrés à l'IDE

En tant que contributeur individuel sur un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent directement dans l'IDE afin d'obtenir un retour rapide sur mon code.

Cela vient compléter tout processus de revue de pull request et d'intégration continue dont le projet pourrait disposer.

J'essaie d'identifier les outils qui me donneront un avantage et amélioreront mon flux de travail individuel.

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

Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'en installe plusieurs afin de profiter de leurs forces respectives.

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

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

Je les utilise tous car ils fonctionnent bien ensemble pour se renforcer et se compléter mutuellement.

Inspections IntelliJ

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

Il s'agit de règles d'analyse statique signalées dans l'IDE. Certaines d'entre elles proposent également des options de correction rapide (QuickFix) pour réécrire le code et résoudre le problème.

Les règles peuvent être activées ou désactivées, et vous pouvez choisir le niveau d'erreur utilisé pour les mettre en évidence dans l'IDE.

Il existe de nombreuses inspections IntelliJ très utiles. Je le sais car je les ai parcourues en écrivant ceci. J'utilise les inspections IntelliJ par défaut sans les avoir configurées, mais pour en tirer pleinement parti, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage et configurer le niveau d'avertissement afin de les remarquer dans votre code.

Ce qui est génial avec les inspections IntelliJ, c'est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à développer le réflexe de :

• remarquer les avertissements et les erreurs dans le code source au fur et à mesure de l'écriture
• survoler le code signalé avec la souris pour connaître les violations de règles
• utiliser alt+entrée pour appliquer une correction rapide (QuickFix) au problème

SpotBugs

Le plugin SpotBugs pour IntelliJ utilise l'analyse statique pour tenter de vous alerter sur les bugs présents dans votre code.

SpotBugs peut être configuré depuis les préférences d'IntelliJ pour analyser votre code ; les règles réellement utilisées se trouvent dans l'onglet Detector.

J'ai tendance à utiliser SpotBugs après avoir écrit et relu mon code, puis j'exécute l'analyse sur les fichiers du projet, y compris les sources de test.

Cela m'aide effectivement à identifier les bugs, le code mort et les optimisations évidentes. Cela me force également à effectuer des recherches sur certaines violations signalées pour m'aider à décider de la marche à suivre.

SpotBugs détecte les problèmes mais ne propose aucune action de correction rapide pour tenter de les résoudre.

SpotBugs est facile à configurer et je trouve qu'il s'agit d'un second avis objectif utile à consulter directement dans mon IDE.

SonarLint

Le plugin SonarLint.

SonarLint peut être configuré depuis les préférences d'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 du code que vous êtes en train d'éditer.

SonarLint ne propose pas de correctifs rapides, mais la documentation associée aux rapports de violation est généralement claire et bien détaillée.

J'ai trouvé SonarLint utile par le passé pour m'alerter sur de nouvelles fonctionnalités Java dont j'avais connaissance dans les versions plus récentes de Java.

CheckStyle

Le plugin CheckStyle propose un mélange de règles de formatage et de qualité de code.

Le plugin CheckStyle est fourni avec les jeux de règles « Sun Checks » et « Google Checks ».

Leurs définitions peuvent être facilement trouvées en ligne.

CheckStyle apporte une valeur ajoutée maximale lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin IDE peut alors être configuré pour utiliser cet ensemble de règles et les développeurs peuvent effectuer une analyse avant de soumettre le code à l'intégration continue (CI).

CheckStyle est très souvent utilisé comme plugin de blocage de build pour les processus CI lorsque le nombre de violations dépasse un certain seuil.

Sensei

Sensei utilise l'analyse statique basée sur un arbre de syntaxe abstraite (AST) pour faire correspondre le code et créer des correctifs rapides (QuickFixes), ce qui permet une identification très précise du code problématique.

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

Sensei a été créé pour faciliter la construction de règles de correspondance personnalisées qui pourraient ne pas exister, ou qui seraient difficiles à configurer, dans d'autres outils.

Plutôt que de modifier un fichier de configuration, toute la configuration peut être effectuée via l'interface graphique. Lors de la création de nouvelles recettes, l'interface permet de voir facilement quel code la recette fait correspondre. Et lors de la définition des correctifs rapides, l'état du code avant et après peut être comparé immédiatement. Cela facilite la création de recettes très contextuelles, c'est-à-dire uniques aux équipes, à la technologie, voire aux développeurs individuels.

J'utilise Sensei en combinaison avec d'autres outils d'analyse statique ; par exemple, la plupart des outils d'analyse statique trouvent des problèmes, mais ne les corrigent pas. Un cas d'utilisation courant pour Sensei consiste à reproduire la recherche de correspondance de l'autre outil dans Sensei et à l'étendre avec un correctif rapide. Cela présente l'avantage que le correctif personnalisé appliqué respecte déjà les normes de codage de votre projet.

Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans l'ensemble des intentions IntelliJ, parce que le rapport d'intention ne correspond pas tout à fait au contexte que j'ai créé ou parce que le correctif rapide fourni par IntelliJ ne correspond pas au modèle de code que je souhaite utiliser.

J'augmente les outils existants plutôt que d'essayer de les remplacer complètement.

Sensei peut é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 communes du moteur d'analyse statique s'appliquent toujours, vous pouvez créer des variantes de ces règles spécifiques à la bibliothèque en utilisant Sensei.

Contrairement aux outils d'analyse statique mentionnés, Sensei n'est pas livré avec une multitude de recettes génériques. Sa force réside dans la facilité avec laquelle vous pouvez créer vos propres recettes, accompagnées de QuickFixes configurés selon votre style de codage et vos cas d'usage spécifiques.

REMARQUE : nous travaillons sur un dépôt public de recettes pour couvrir les cas d'usage courants, et vous pouvez le consulter ici.

Résumé

Je privilégie les outils complémentaires, configurables et facilement extensibles pour répondre à mes besoins. J'utilise depuis des années des outils d'analyse statique dans mon IDE pour identifier les problèmes et approfondir mes connaissances sur les langages et bibliothèques que j'emploie.

J'utilise l'ensemble de ces outils de manière combinée :

• Les intentions d'IntelliJ permettent de signaler les problèmes de code courants dès l'installation, souvent avec des QuickFixes associés.
• SpotBugs détecte les bugs simples qui auraient pu m'échapper et m'alerte sur les problèmes de performance.
• SonarLint identifie des fonctionnalités Java que je ne connaissais pas et me suggère d'autres façons de structurer mon code.
• CheckStyle m'aide à respecter un style de codage convenu, également appliqué lors de l'intégration continue.
• Sensei me permet de créer des QuickFixes pour enrichir les scénarios courants détectés par les outils d'analyse statique et de concevoir des recettes spécifiques à un projet ou une technologie, souvent difficiles à configurer ailleurs.

---

Installez Sensei directement depuis IntelliJ via « Preferences \ Plugins » (Mac) ou « Settings \ Plugins » (Windows), puis recherchez simplement « sensei secure code ».

Vous trouverez un dépôt contenant des exemples de code et des recettes pour les cas d'usage courants sur le compte GitHub de Secure Code Warrior, dans le projet `sensei-blog-examples`.

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

En savoir plus sur Sensei