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écuter l'application.
Lorsque l'analyse est effectuée pendant l'exécution du programme, on parle d'analyse dynamique.
L'analyse statique est souvent utilisée pour détecter :
- Vulnérabilités en matière de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de concepts de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source des schémas de codage spécifiques auxquels est associée une sorte d'avertissement ou d'information.
Cela peut être aussi simple que "Les classes de test de JUnit 5 n'ont pas besoin d'être 'publiques'". Ou quelque chose de plus complexe à identifier comme "Une entrée de chaîne non fiable est utilisée dans une instruction d'exécution SQL".
Les outils d'analyse statique varient dans la manière dont ils mettent en œuvre cette fonctionnalité.
- pour créer un arbre syntaxique abstrait (AST),
- la recherche d'expressions régulières dans le texte,
- une combinaison de ce qui précède.
La recherche d'expressions régulières dans le texte est très souple, il est facile d'écrire des règles de correspondance, mais elle peut souvent donner lieu à un grand nombre de faux positifs et les règles de correspondance ne tiennent pas compte du contexte du code environnant.
La correspondance AST traite le code source comme un code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance plus spécifique et contextuelle et peut réduire le nombre de faux positifs signalés par rapport au code.
L'analyse statique dans l'intégration continue
L'analyse statique est souvent 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é 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 d'analyse statique de manière à ce qu'il ne mesure que des parties spécifiques du code et ne rende compte que d'un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées puisqu'elles ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et leur configuration est une décision subjective et que différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile que l'analyse statique soit effectuée dans le cadre de l'IC, mais cela risque de retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de retour d'information lorsqu'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 IC est qu'il est plus facile d'ignorer les résultats.
Pour aider les équipes à prêter davantage attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil métrique dans le processus de construction, afin de faire échouer la construction si le seuil est dépassé, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'IDE
Pour recevoir un retour d'information plus rapidement, il existe de nombreux plugins IDE qui exécutent les règles d'analyse statique dans l'IDE à la demande, ou périodiquement lorsque le code est modifié.
Les violations de règles sont alors visibles dans l'IDE lorsque 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 trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien qu'il puisse être "bruyant" avec des faux positifs ou des règles qui ne vous intéressent pas, cela peut être résolu en prenant une mesure supplémentaire pour configurer l'outil d'analyse statique afin d'ignorer les règles. Mais vous pouvez résoudre ce problème en prenant la peine de configurer l'outil d'analyse statique pour qu'il ignore certaines règles.
Correction du code sur la base des règles de l'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur, qui doit donc comprendre la cause de la violation de la règle et la manière de la corriger.
Très peu d'outils d'analyse statique offrent également la possibilité de corriger les violations, car la correction est souvent liée au contexte de l'équipe, à la technologie utilisée et aux styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont livrés avec des règles par défaut, il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur pourrait rencontrer, et toutes les circonstances dans lesquelles une règle devrait s'appliquer. Parfois, les circonstances dans lesquelles une règle devrait s'appliquer peuvent être subtiles et ne pas être faciles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en recherchant 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 proposer de règles correspondant à votre domaine ou à votre bibliothèque et, en outre, les outils peuvent souvent être difficiles à configurer et à développer.
Gênes
Aucun de ces "inconvénients" n'est insurmontable :
- faux positifs
- l'absence de correctifs
- configuration pour ignorer les règles
- ajouter des règles spécifiques au contexte
Mais elles sont souvent utilisées comme excuses pour éviter d'utiliser les outils d'analyse statique, ce qui est dommage car l'analyse statique peut être extrêmement utile, en tant que moyen d'améliorer la qualité de l'information :
- mettre en évidence de meilleures approches pour les développeurs débutants
- obtenir un retour d'information rapide sur les violations claires du code
- identifier des problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- renforcer le fait que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur les IDE
En tant que contributeur individuel à un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent à partir de l'IDE afin de recevoir rapidement un retour d'information sur mon code.
Cela complète le processus d'examen des demandes d'extraction et l'intégration de l'IC qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront une longueur d'avance et qui amélioreront mon flux de travail individuel.
Lorsque des outils fonctionnent dans l'IDE, il peut être tentant de les considérer comme interchangeables, car ils ont tendance à partager la même interface graphique de base et la même approche de configuration.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, 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 énumérés ci-dessous :
- les inspections intégrées d'IntelliJ - les modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei à partir de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble et se complètent mutuellement.
IntelliJ Inspections
Si vous utilisez IntelliJ, vous utilisez déjà leurs inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'IDE. Certaines d'entre elles ont également des options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles peuvent être configurées pour être activées ou désactivées, et pour choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'IDE.
Il y a beaucoup de bonnes inspections IntelliJ. Je le sais parce que je les ai lues pendant que j'écrivais ces lignes. J'utilise les Inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des Inspections, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage, et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à construire la mémoire musculaire de l'utilisateur :
- remarquer les avertissements et les erreurs dans le code source au fur et à mesure que vous écrivez le code
- le passage de la souris sur le code signalé pour connaître les violations des règles
- utiliser alt+enter pour appliquer une solution rapide au problème
SpotBugs
Le plugin SpotBugs IntelliJ utilise l'analyse statique pour essayer de vous alerter sur les bogues dans votre code.
SpotBugs peut être configuré à partir des Préférences d'IntelliJ pour analyser votre code, les règles utilisées peuvent être trouvées dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis je lance l'option "Analyser les fichiers du projet, y compris les sources de test".
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider de ce qu'il faut faire.
SpotBugs détecte les problèmes mais ne propose pas d'actions QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je le considère comme un second avis objectif utile à consulter dans mon IDE.
SonarLint
Le plugin SonarLint.
SonarLint peut être configuré à partir des préférences d'IntelliJ pour sélectionner les règles sur lesquelles le code est validé.
Par défaut, SonarLint fonctionne en temps réel et affiche les problèmes liés au code que vous êtes en train d'éditer.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile dans le passé pour m'alerter sur les nouvelles fonctionnalités de Java que je connaissais 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 "Sun Checks" et "Google Checks".
Vous pouvez facilement en trouver la définition en ligne.
CheckStyle apporte la plus grande valeur ajoutée lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin de l'IDE peut alors être configuré pour utiliser ce jeu de règles et les programmeurs peuvent effectuer une analyse, avant de livrer le code à l'IC.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus de CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
Sensei
Sensei utilise l'analyse statique basée sur un arbre syntaxique abstrait (AST) pour faire correspondre le code et pour créer des corrections rapides, 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 a été créé pour faciliter l'élaboration de règles de correspondance personnalisées qui n'existent pas 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 dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code la recette correspond. Et lors de la définition des QuickFixes, l'état avant et après du code peut être comparé immédiatement. Il est ainsi plus facile de créer des recettes très contextuelles, c'est-à-dire propres à une équipe, à une technologie ou même à un programmeur.
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 résolvent pas. Un cas d'utilisation courant de Sensei est de reproduire la recherche correspondante de l'autre outil dans Sensei, et de l'étendre avec une correction rapide. L'avantage est que la correction personnalisée appliquée répond déjà aux normes de codage de votre projet.
Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans le jeu IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je veux utiliser.
Je renforce les outils existants, plutôt que de tenter 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 alors créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei n'est pas livré avec un grand nombre de recettes génériques comme les outils d'analyse statique mentionnés, sa force est de rendre facile la création de nouvelles recettes, avec des QuickFixes configurés pour correspondre à votre style de codage spécifique et à vos cas d'utilisation.
NOTE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques. vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à étendre pour répondre à mon contexte spécifique. J'utilise des outils d'analyse statique dans l'IDE depuis des années pour m'aider à identifier les problèmes et en apprendre davantage 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 de code les plus courants dès la sortie de la boîte, souvent avec des solutions rapides associées.
- SpotBugs trouve des bogues simples que j'aurais pu manquer et me signale des problèmes de performance.
- SonarLint identifie des fonctionnalités Java dont je n'étais pas conscient et m'incite à trouver d'autres façons de modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant l'IC.
- Sensei m'aide à créer des QuickFixes pour améliorer les scénarios courants trouvés par les outils d'analyse statique et à créer des recettes spécifiques à un projet ou à une technologie qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis recherchez simplement "sensei secure code".
Vous pouvez trouver un dépôt de code d'exemple et de recettes pour des cas d'utilisation courants sur le compte GitHub Secure Code Warrior , dans le projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Apprenez l'analyse statique et comment elle peut vous aider à écrire un meilleur code avec des exemples de 5 approches et plugins basés sur l'IDE.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez 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 est l'analyse automatisée du 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 souvent utilisée pour détecter :
- Vulnérabilités en matière de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de concepts de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source des schémas de codage spécifiques auxquels est associée une sorte d'avertissement ou d'information.
Cela peut être aussi simple que "Les classes de test de JUnit 5 n'ont pas besoin d'être 'publiques'". Ou quelque chose de plus complexe à identifier comme "Une entrée de chaîne non fiable est utilisée dans une instruction d'exécution SQL".
Les outils d'analyse statique varient dans la manière dont ils mettent en œuvre cette fonctionnalité.
- pour créer un arbre syntaxique abstrait (AST),
- la recherche d'expressions régulières dans le texte,
- une combinaison de ce qui précède.
La recherche d'expressions régulières dans le texte est très souple, il est facile d'écrire des règles de correspondance, mais elle peut souvent donner lieu à un grand nombre de faux positifs et les règles de correspondance ne tiennent pas compte du contexte du code environnant.
La correspondance AST traite le code source comme un code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance plus spécifique et contextuelle et peut réduire le nombre de faux positifs signalés par rapport au code.
L'analyse statique dans l'intégration continue
L'analyse statique est souvent 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é 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 d'analyse statique de manière à ce qu'il ne mesure que des parties spécifiques du code et ne rende compte que d'un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées puisqu'elles ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et leur configuration est une décision subjective et que différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile que l'analyse statique soit effectuée dans le cadre de l'IC, mais cela risque de retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de retour d'information lorsqu'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 IC est qu'il est plus facile d'ignorer les résultats.
Pour aider les équipes à prêter davantage attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil métrique dans le processus de construction, afin de faire échouer la construction si le seuil est dépassé, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'IDE
Pour recevoir un retour d'information plus rapidement, il existe de nombreux plugins IDE qui exécutent les règles d'analyse statique dans l'IDE à la demande, ou périodiquement lorsque le code est modifié.
Les violations de règles sont alors visibles dans l'IDE lorsque 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 trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien qu'il puisse être "bruyant" avec des faux positifs ou des règles qui ne vous intéressent pas, cela peut être résolu en prenant une mesure supplémentaire pour configurer l'outil d'analyse statique afin d'ignorer les règles. Mais vous pouvez résoudre ce problème en prenant la peine de configurer l'outil d'analyse statique pour qu'il ignore certaines règles.
Correction du code sur la base des règles de l'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur, qui doit donc comprendre la cause de la violation de la règle et la manière de la corriger.
Très peu d'outils d'analyse statique offrent également la possibilité de corriger les violations, car la correction est souvent liée au contexte de l'équipe, à la technologie utilisée et aux styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont livrés avec des règles par défaut, il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur pourrait rencontrer, et toutes les circonstances dans lesquelles une règle devrait s'appliquer. Parfois, les circonstances dans lesquelles une règle devrait s'appliquer peuvent être subtiles et ne pas être faciles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en recherchant 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 proposer de règles correspondant à votre domaine ou à votre bibliothèque et, en outre, les outils peuvent souvent être difficiles à configurer et à développer.
Gênes
Aucun de ces "inconvénients" n'est insurmontable :
- faux positifs
- l'absence de correctifs
- configuration pour ignorer les règles
- ajouter des règles spécifiques au contexte
Mais elles sont souvent utilisées comme excuses pour éviter d'utiliser les outils d'analyse statique, ce qui est dommage car l'analyse statique peut être extrêmement utile, en tant que moyen d'améliorer la qualité de l'information :
- mettre en évidence de meilleures approches pour les développeurs débutants
- obtenir un retour d'information rapide sur les violations claires du code
- identifier des problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- renforcer le fait que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur les IDE
En tant que contributeur individuel à un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent à partir de l'IDE afin de recevoir rapidement un retour d'information sur mon code.
Cela complète le processus d'examen des demandes d'extraction et l'intégration de l'IC qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront une longueur d'avance et qui amélioreront mon flux de travail individuel.
Lorsque des outils fonctionnent dans l'IDE, il peut être tentant de les considérer comme interchangeables, car ils ont tendance à partager la même interface graphique de base et la même approche de configuration.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, 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 énumérés ci-dessous :
- les inspections intégrées d'IntelliJ - les modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei à partir de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble et se complètent mutuellement.
IntelliJ Inspections
Si vous utilisez IntelliJ, vous utilisez déjà leurs inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'IDE. Certaines d'entre elles ont également des options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles peuvent être configurées pour être activées ou désactivées, et pour choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'IDE.
Il y a beaucoup de bonnes inspections IntelliJ. Je le sais parce que je les ai lues pendant que j'écrivais ces lignes. J'utilise les Inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des Inspections, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage, et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à construire la mémoire musculaire de l'utilisateur :
- remarquer les avertissements et les erreurs dans le code source au fur et à mesure que vous écrivez le code
- le passage de la souris sur le code signalé pour connaître les violations des règles
- utiliser alt+enter pour appliquer une solution rapide au problème
SpotBugs
Le plugin SpotBugs IntelliJ utilise l'analyse statique pour essayer de vous alerter sur les bogues dans votre code.
SpotBugs peut être configuré à partir des Préférences d'IntelliJ pour analyser votre code, les règles utilisées peuvent être trouvées dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis je lance l'option "Analyser les fichiers du projet, y compris les sources de test".
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider de ce qu'il faut faire.
SpotBugs détecte les problèmes mais ne propose pas d'actions QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je le considère comme un second avis objectif utile à consulter dans mon IDE.
SonarLint
Le plugin SonarLint.
SonarLint peut être configuré à partir des préférences d'IntelliJ pour sélectionner les règles sur lesquelles le code est validé.
Par défaut, SonarLint fonctionne en temps réel et affiche les problèmes liés au code que vous êtes en train d'éditer.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile dans le passé pour m'alerter sur les nouvelles fonctionnalités de Java que je connaissais 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 "Sun Checks" et "Google Checks".
Vous pouvez facilement en trouver la définition en ligne.
CheckStyle apporte la plus grande valeur ajoutée lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin de l'IDE peut alors être configuré pour utiliser ce jeu de règles et les programmeurs peuvent effectuer une analyse, avant de livrer le code à l'IC.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus de CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
Sensei
Sensei utilise l'analyse statique basée sur un arbre syntaxique abstrait (AST) pour faire correspondre le code et pour créer des corrections rapides, 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 a été créé pour faciliter l'élaboration de règles de correspondance personnalisées qui n'existent pas 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 dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code la recette correspond. Et lors de la définition des QuickFixes, l'état avant et après du code peut être comparé immédiatement. Il est ainsi plus facile de créer des recettes très contextuelles, c'est-à-dire propres à une équipe, à une technologie ou même à un programmeur.
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 résolvent pas. Un cas d'utilisation courant de Sensei est de reproduire la recherche correspondante de l'autre outil dans Sensei, et de l'étendre avec une correction rapide. L'avantage est que la correction personnalisée appliquée répond déjà aux normes de codage de votre projet.
Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans le jeu IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je veux utiliser.
Je renforce les outils existants, plutôt que de tenter 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 alors créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei n'est pas livré avec un grand nombre de recettes génériques comme les outils d'analyse statique mentionnés, sa force est de rendre facile la création de nouvelles recettes, avec des QuickFixes configurés pour correspondre à votre style de codage spécifique et à vos cas d'utilisation.
NOTE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques. vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à étendre pour répondre à mon contexte spécifique. J'utilise des outils d'analyse statique dans l'IDE depuis des années pour m'aider à identifier les problèmes et en apprendre davantage 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 de code les plus courants dès la sortie de la boîte, souvent avec des solutions rapides associées.
- SpotBugs trouve des bogues simples que j'aurais pu manquer et me signale des problèmes de performance.
- SonarLint identifie des fonctionnalités Java dont je n'étais pas conscient et m'incite à trouver d'autres façons de modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant l'IC.
- Sensei m'aide à créer des QuickFixes pour améliorer les scénarios courants trouvés par les outils d'analyse statique et à créer des recettes spécifiques à un projet ou à une technologie qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis recherchez simplement "sensei secure code".
Vous pouvez trouver un dépôt de code d'exemple et de recettes pour des cas d'utilisation courants sur le compte GitHub Secure Code Warrior , dans le projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Qu'est-ce que l'analyse statique ?
L'analyse statique est l'analyse automatisée du 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 souvent utilisée pour détecter :
- Vulnérabilités en matière de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de concepts de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source des schémas de codage spécifiques auxquels est associée une sorte d'avertissement ou d'information.
Cela peut être aussi simple que "Les classes de test de JUnit 5 n'ont pas besoin d'être 'publiques'". Ou quelque chose de plus complexe à identifier comme "Une entrée de chaîne non fiable est utilisée dans une instruction d'exécution SQL".
Les outils d'analyse statique varient dans la manière dont ils mettent en œuvre cette fonctionnalité.
- pour créer un arbre syntaxique abstrait (AST),
- la recherche d'expressions régulières dans le texte,
- une combinaison de ce qui précède.
La recherche d'expressions régulières dans le texte est très souple, il est facile d'écrire des règles de correspondance, mais elle peut souvent donner lieu à un grand nombre de faux positifs et les règles de correspondance ne tiennent pas compte du contexte du code environnant.
La correspondance AST traite le code source comme un code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance plus spécifique et contextuelle et peut réduire le nombre de faux positifs signalés par rapport au code.
L'analyse statique dans l'intégration continue
L'analyse statique est souvent 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é 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 d'analyse statique de manière à ce qu'il ne mesure que des parties spécifiques du code et ne rende compte que d'un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées puisqu'elles ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et leur configuration est une décision subjective et que différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile que l'analyse statique soit effectuée dans le cadre de l'IC, mais cela risque de retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de retour d'information lorsqu'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 IC est qu'il est plus facile d'ignorer les résultats.
Pour aider les équipes à prêter davantage attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil métrique dans le processus de construction, afin de faire échouer la construction si le seuil est dépassé, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'IDE
Pour recevoir un retour d'information plus rapidement, il existe de nombreux plugins IDE qui exécutent les règles d'analyse statique dans l'IDE à la demande, ou périodiquement lorsque le code est modifié.
Les violations de règles sont alors visibles dans l'IDE lorsque 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 trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien qu'il puisse être "bruyant" avec des faux positifs ou des règles qui ne vous intéressent pas, cela peut être résolu en prenant une mesure supplémentaire pour configurer l'outil d'analyse statique afin d'ignorer les règles. Mais vous pouvez résoudre ce problème en prenant la peine de configurer l'outil d'analyse statique pour qu'il ignore certaines règles.
Correction du code sur la base des règles de l'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur, qui doit donc comprendre la cause de la violation de la règle et la manière de la corriger.
Très peu d'outils d'analyse statique offrent également la possibilité de corriger les violations, car la correction est souvent liée au contexte de l'équipe, à la technologie utilisée et aux styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont livrés avec des règles par défaut, il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur pourrait rencontrer, et toutes les circonstances dans lesquelles une règle devrait s'appliquer. Parfois, les circonstances dans lesquelles une règle devrait s'appliquer peuvent être subtiles et ne pas être faciles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en recherchant 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 proposer de règles correspondant à votre domaine ou à votre bibliothèque et, en outre, les outils peuvent souvent être difficiles à configurer et à développer.
Gênes
Aucun de ces "inconvénients" n'est insurmontable :
- faux positifs
- l'absence de correctifs
- configuration pour ignorer les règles
- ajouter des règles spécifiques au contexte
Mais elles sont souvent utilisées comme excuses pour éviter d'utiliser les outils d'analyse statique, ce qui est dommage car l'analyse statique peut être extrêmement utile, en tant que moyen d'améliorer la qualité de l'information :
- mettre en évidence de meilleures approches pour les développeurs débutants
- obtenir un retour d'information rapide sur les violations claires du code
- identifier des problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- renforcer le fait que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur les IDE
En tant que contributeur individuel à un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent à partir de l'IDE afin de recevoir rapidement un retour d'information sur mon code.
Cela complète le processus d'examen des demandes d'extraction et l'intégration de l'IC qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront une longueur d'avance et qui amélioreront mon flux de travail individuel.
Lorsque des outils fonctionnent dans l'IDE, il peut être tentant de les considérer comme interchangeables, car ils ont tendance à partager la même interface graphique de base et la même approche de configuration.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, 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 énumérés ci-dessous :
- les inspections intégrées d'IntelliJ - les modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei à partir de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble et se complètent mutuellement.
IntelliJ Inspections
Si vous utilisez IntelliJ, vous utilisez déjà leurs inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'IDE. Certaines d'entre elles ont également des options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles peuvent être configurées pour être activées ou désactivées, et pour choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'IDE.
Il y a beaucoup de bonnes inspections IntelliJ. Je le sais parce que je les ai lues pendant que j'écrivais ces lignes. J'utilise les Inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des Inspections, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage, et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à construire la mémoire musculaire de l'utilisateur :
- remarquer les avertissements et les erreurs dans le code source au fur et à mesure que vous écrivez le code
- le passage de la souris sur le code signalé pour connaître les violations des règles
- utiliser alt+enter pour appliquer une solution rapide au problème
SpotBugs
Le plugin SpotBugs IntelliJ utilise l'analyse statique pour essayer de vous alerter sur les bogues dans votre code.
SpotBugs peut être configuré à partir des Préférences d'IntelliJ pour analyser votre code, les règles utilisées peuvent être trouvées dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis je lance l'option "Analyser les fichiers du projet, y compris les sources de test".
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider de ce qu'il faut faire.
SpotBugs détecte les problèmes mais ne propose pas d'actions QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je le considère comme un second avis objectif utile à consulter dans mon IDE.
SonarLint
Le plugin SonarLint.
SonarLint peut être configuré à partir des préférences d'IntelliJ pour sélectionner les règles sur lesquelles le code est validé.
Par défaut, SonarLint fonctionne en temps réel et affiche les problèmes liés au code que vous êtes en train d'éditer.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile dans le passé pour m'alerter sur les nouvelles fonctionnalités de Java que je connaissais 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 "Sun Checks" et "Google Checks".
Vous pouvez facilement en trouver la définition en ligne.
CheckStyle apporte la plus grande valeur ajoutée lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin de l'IDE peut alors être configuré pour utiliser ce jeu de règles et les programmeurs peuvent effectuer une analyse, avant de livrer le code à l'IC.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus de CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
Sensei
Sensei utilise l'analyse statique basée sur un arbre syntaxique abstrait (AST) pour faire correspondre le code et pour créer des corrections rapides, 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 a été créé pour faciliter l'élaboration de règles de correspondance personnalisées qui n'existent pas 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 dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code la recette correspond. Et lors de la définition des QuickFixes, l'état avant et après du code peut être comparé immédiatement. Il est ainsi plus facile de créer des recettes très contextuelles, c'est-à-dire propres à une équipe, à une technologie ou même à un programmeur.
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 résolvent pas. Un cas d'utilisation courant de Sensei est de reproduire la recherche correspondante de l'autre outil dans Sensei, et de l'étendre avec une correction rapide. L'avantage est que la correction personnalisée appliquée répond déjà aux normes de codage de votre projet.
Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans le jeu IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je veux utiliser.
Je renforce les outils existants, plutôt que de tenter 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 alors créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei n'est pas livré avec un grand nombre de recettes génériques comme les outils d'analyse statique mentionnés, sa force est de rendre facile la création de nouvelles recettes, avec des QuickFixes configurés pour correspondre à votre style de codage spécifique et à vos cas d'utilisation.
NOTE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques. vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à étendre pour répondre à mon contexte spécifique. J'utilise des outils d'analyse statique dans l'IDE depuis des années pour m'aider à identifier les problèmes et en apprendre davantage 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 de code les plus courants dès la sortie de la boîte, souvent avec des solutions rapides associées.
- SpotBugs trouve des bogues simples que j'aurais pu manquer et me signale des problèmes de performance.
- SonarLint identifie des fonctionnalités Java dont je n'étais pas conscient et m'incite à trouver d'autres façons de modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant l'IC.
- Sensei m'aide à créer des QuickFixes pour améliorer les scénarios courants trouvés par les outils d'analyse statique et à créer des recettes spécifiques à un projet ou à une technologie qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis recherchez simplement "sensei secure code".
Vous pouvez trouver un dépôt de code d'exemple et de recettes pour des cas d'utilisation courants sur le compte GitHub Secure Code Warrior , dans le projet `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez 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 est l'analyse automatisée du 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 souvent utilisée pour détecter :
- Vulnérabilités en matière de sécurité.
- Problèmes de performance.
- Non-respect des normes.
- Utilisation de concepts de programmation obsolètes.
Comment fonctionne un outil d'analyse statique ?
Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source des schémas de codage spécifiques auxquels est associée une sorte d'avertissement ou d'information.
Cela peut être aussi simple que "Les classes de test de JUnit 5 n'ont pas besoin d'être 'publiques'". Ou quelque chose de plus complexe à identifier comme "Une entrée de chaîne non fiable est utilisée dans une instruction d'exécution SQL".
Les outils d'analyse statique varient dans la manière dont ils mettent en œuvre cette fonctionnalité.
- pour créer un arbre syntaxique abstrait (AST),
- la recherche d'expressions régulières dans le texte,
- une combinaison de ce qui précède.
La recherche d'expressions régulières dans le texte est très souple, il est facile d'écrire des règles de correspondance, mais elle peut souvent donner lieu à un grand nombre de faux positifs et les règles de correspondance ne tiennent pas compte du contexte du code environnant.
La correspondance AST traite le code source comme un code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance plus spécifique et contextuelle et peut réduire le nombre de faux positifs signalés par rapport au code.
L'analyse statique dans l'intégration continue
L'analyse statique est souvent 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é 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 d'analyse statique de manière à ce qu'il ne mesure que des parties spécifiques du code et ne rende compte que d'un sous-ensemble de règles.
L'objectivité est assurée par les règles utilisées puisqu'elles ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et leur configuration est une décision subjective et que différentes équipes choisissent d'utiliser différentes règles à différents moments.
Il est utile que l'analyse statique soit effectuée dans le cadre de l'IC, mais cela risque de retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de retour d'information lorsqu'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 IC est qu'il est plus facile d'ignorer les résultats.
Pour aider les équipes à prêter davantage attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil métrique dans le processus de construction, afin de faire échouer la construction si le seuil est dépassé, par exemple si un certain nombre de règles sont déclenchées.
Analyse statique dans l'IDE
Pour recevoir un retour d'information plus rapidement, il existe de nombreux plugins IDE qui exécutent les règles d'analyse statique dans l'IDE à la demande, ou périodiquement lorsque le code est modifié.
Les violations de règles sont alors visibles dans l'IDE lorsque 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 trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien qu'il puisse être "bruyant" avec des faux positifs ou des règles qui ne vous intéressent pas, cela peut être résolu en prenant une mesure supplémentaire pour configurer l'outil d'analyse statique afin d'ignorer les règles. Mais vous pouvez résoudre ce problème en prenant la peine de configurer l'outil d'analyse statique pour qu'il ignore certaines règles.
Correction du code sur la base des règles de l'analyse statique
Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur, qui doit donc comprendre la cause de la violation de la règle et la manière de la corriger.
Très peu d'outils d'analyse statique offrent également la possibilité de corriger les violations, car la correction est souvent liée au contexte de l'équipe, à la technologie utilisée et aux styles de codage convenus.
Règles par défaut
Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont livrés avec des règles par défaut, il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur pourrait rencontrer, et toutes les circonstances dans lesquelles une règle devrait s'appliquer. Parfois, les circonstances dans lesquelles une règle devrait s'appliquer peuvent être subtiles et ne pas être faciles à détecter.
L'espoir est qu'en utilisant un outil d'analyse statique et en recherchant 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 proposer de règles correspondant à votre domaine ou à votre bibliothèque et, en outre, les outils peuvent souvent être difficiles à configurer et à développer.
Gênes
Aucun de ces "inconvénients" n'est insurmontable :
- faux positifs
- l'absence de correctifs
- configuration pour ignorer les règles
- ajouter des règles spécifiques au contexte
Mais elles sont souvent utilisées comme excuses pour éviter d'utiliser les outils d'analyse statique, ce qui est dommage car l'analyse statique peut être extrêmement utile, en tant que moyen d'améliorer la qualité de l'information :
- mettre en évidence de meilleures approches pour les développeurs débutants
- obtenir un retour d'information rapide sur les violations claires du code
- identifier des problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
- renforcer le fait que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)
Outils d'analyse statique basés sur les IDE
En tant que contributeur individuel à un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent à partir de l'IDE afin de recevoir rapidement un retour d'information sur mon code.
Cela complète le processus d'examen des demandes d'extraction et l'intégration de l'IC qu'un projet peut avoir.
J'essaie d'identifier les outils qui me donneront une longueur d'avance et qui amélioreront mon flux de travail individuel.
Lorsque des outils fonctionnent dans l'IDE, il peut être tentant de les considérer comme interchangeables, car ils ont tendance à partager la même interface graphique de base et la même approche de configuration.
Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, 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 énumérés ci-dessous :
- les inspections intégrées d'IntelliJ - les modèles de codage courants
- SpotBugs - erreurs courantes
- SonarLint - modèles d'utilisation courants
- CheckStyle - modèles de style courants
- Sensei à partir de Secure Code Warrior - création de règles personnalisées
Je les utilise tous parce qu'ils fonctionnent bien ensemble et se complètent mutuellement.
IntelliJ Inspections
Si vous utilisez IntelliJ, vous utilisez déjà leurs inspections.
Il s'agit de règles d'analyse statique qui sont signalées dans l'IDE. Certaines d'entre elles ont également des options QuickFix pour réécrire le code afin de résoudre le problème.
Les règles peuvent être configurées pour être activées ou désactivées, et pour choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'IDE.
Il y a beaucoup de bonnes inspections IntelliJ. Je le sais parce que je les ai lues pendant que j'écrivais ces lignes. J'utilise les Inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des Inspections, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage, et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.
L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à construire la mémoire musculaire de l'utilisateur :
- remarquer les avertissements et les erreurs dans le code source au fur et à mesure que vous écrivez le code
- le passage de la souris sur le code signalé pour connaître les violations des règles
- utiliser alt+enter pour appliquer une solution rapide au problème
SpotBugs
Le plugin SpotBugs IntelliJ utilise l'analyse statique pour essayer de vous alerter sur les bogues dans votre code.
SpotBugs peut être configuré à partir des Préférences d'IntelliJ pour analyser votre code, les règles utilisées peuvent être trouvées dans l'onglet Détecteur.
J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis je lance l'option "Analyser les fichiers du projet, y compris les sources de test".
Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider de ce qu'il faut faire.
SpotBugs détecte les problèmes mais ne propose pas d'actions QuickFix pour tenter de les résoudre.
SpotBugs est facile à configurer et je le considère comme un second avis objectif utile à consulter dans mon IDE.
SonarLint
Le plugin SonarLint.
SonarLint peut être configuré à partir des préférences d'IntelliJ pour sélectionner les règles sur lesquelles le code est validé.
Par défaut, SonarLint fonctionne en temps réel et affiche les problèmes liés au code que vous êtes en train d'éditer.
SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.
J'ai trouvé SonarLint utile dans le passé pour m'alerter sur les nouvelles fonctionnalités de Java que je connaissais 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 "Sun Checks" et "Google Checks".
Vous pouvez facilement en trouver la définition en ligne.
CheckStyle apporte la plus grande valeur ajoutée lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin de l'IDE peut alors être configuré pour utiliser ce jeu de règles et les programmeurs peuvent effectuer une analyse, avant de livrer le code à l'IC.
CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus de CI lorsque le nombre de violations de CheckStyle dépasse un seuil.
Sensei
Sensei utilise l'analyse statique basée sur un arbre syntaxique abstrait (AST) pour faire correspondre le code et pour créer des corrections rapides, 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 a été créé pour faciliter l'élaboration de règles de correspondance personnalisées qui n'existent pas 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 dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code la recette correspond. Et lors de la définition des QuickFixes, l'état avant et après du code peut être comparé immédiatement. Il est ainsi plus facile de créer des recettes très contextuelles, c'est-à-dire propres à une équipe, à une technologie ou même à un programmeur.
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 résolvent pas. Un cas d'utilisation courant de Sensei est de reproduire la recherche correspondante de l'autre outil dans Sensei, et de l'étendre avec une correction rapide. L'avantage est que la correction personnalisée appliquée répond déjà aux normes de codage de votre projet.
Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans le jeu IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je veux utiliser.
Je renforce les outils existants, plutôt que de tenter 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 alors créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.
Sensei n'est pas livré avec un grand nombre de recettes génériques comme les outils d'analyse statique mentionnés, sa force est de rendre facile la création de nouvelles recettes, avec des QuickFixes configurés pour correspondre à votre style de codage spécifique et à vos cas d'utilisation.
NOTE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques. vous pouvez le trouver ici.
Résumé
J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à étendre pour répondre à mon contexte spécifique. J'utilise des outils d'analyse statique dans l'IDE depuis des années pour m'aider à identifier les problèmes et en apprendre davantage 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 de code les plus courants dès la sortie de la boîte, souvent avec des solutions rapides associées.
- SpotBugs trouve des bogues simples que j'aurais pu manquer et me signale des problèmes de performance.
- SonarLint identifie des fonctionnalités Java dont je n'étais pas conscient et m'incite à trouver d'autres façons de modéliser mon code.
- CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant l'IC.
- Sensei m'aide à créer des QuickFixes pour améliorer les scénarios courants trouvés par les outils d'analyse statique et à créer des recettes spécifiques à un projet ou à une technologie qui peuvent être difficiles à configurer dans un autre outil.
---
Installez Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis recherchez simplement "sensei secure code".
Vous pouvez trouver un dépôt de code d'exemple et de recettes pour des cas d'utilisation courants sur le compte GitHub Secure Code Warrior , dans le projet `sensei-blog-examples`.
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 vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
.png)
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.
