Quelques outils d’analyse statique de code
Pour faciliter l’analyse du code source, des outils payants sont accessibles, avec des tarifs et des stratégies d’éditeurs variables. Certains sont adaptés pour de grandes entreprises et d’autres plus abordables pour des organisations de moindre ampleur.
Voici quelques outils d’analyse qui vous alertent lorsqu’ils rencontrent une anomalie ou une erreur potentielle :
- Sonarqube,
- Code Climate,
- Codacy,
- Coverity,
- Checkmarx,
- etc.
Ces outils gèrent beaucoup de langages connus (PHP, Java, .Net, etc.), ils évaluent la qualité du projet et indiquent la présence de bugs (problèmes) dans le code source. Certains outils permettent même d’attribuer un score de dette technique et une évaluation de la charge de travail pour y remédier.
Ces outils facilitent grandement la gestion de la qualité du code. Ils permettent de mettre en évidence les problèmes liés directement au code source de votre application web ou mobile et de soutenir les développeurs dans leur travail d’analyse.
Déterminer les métriques sur le code
Lors de l’analyse du code source, il faut déterminer des indicateurs métriques. Ces valeurs serviront de référence à l’analyse de la qualité du code source de votre application. Voici quelques métriques pouvant être utilisées :
- Le nombre de fichiers, de lignes de code, de commentaires, le taux de commentaires par rapport au nombre de lignes de code.
- La complexité cyclomatique définit le nombre de chemins uniques qu’il est possible d’emprunter. La complexité cyclomatique n’est autre que la somme de tous les chemins uniques possibles. De fait, plus il y a de chemins uniques (comme des conditions) dans le code source de votre application, plus la complexité cyclomatique est élevée. Elle permet de se rendre compte visuellement de la complexité de la structure d’un programme. L’objectif est d’éviter les pertes de temps liées à la compréhension du code.
Par exemple, observons deux fonctions visibles dans 2 colonnes différentes. 2 codes sources sont présentés avec la même complexité cyclomatique de 4. Mais avec une complexité cognitive différente. Le code de droite est beaucoup plus lisible grâce à l’utilisation de structures de contrôles différentes. Et il révèle moins de complexité cognitive.
- La complexité cognitive est le fait de quantifier l’effort nécessaire et la facilité avec laquelle une personne(développeur ou développeuse) est capable de le comprendre. Elle mesure la charge mentale induite par le code source. Elle encourage les pratiques de codage “propres” en incrémentant les constructions de code qui demandent un effort supplémentaire à le comprendre.
La lecture du code source peut être complexe. Déterminer des métriques permet de mieux observer le code. Ces indicateurs permettent de définir la rapidité avec laquelle le code source va être compris, que ce soit par une machine ou un humain. Par exemple, selon la complexité cognitive, ce sera plus ou moins simple d’étudier le code source et de le reprendre.
Il faut donc déterminer si le code source est qualitatif, lisible, propre et compréhensible par tous. Attention, en cas de reprise de code source, plus il est complexe, plus il sera long à étudier.
Analyser ces relevés permet d’évaluer la complexité du code, de mesurer les portions du code pour les comparer et pointer les endroits les plus pertinents en termes d’amélioration. Ces métriques se concentrent sur les zones à risque, plus susceptibles de contenir des vulnérabilités.
Déterminer la qualité du code
Trois aspects caractérisent la qualité du code source.
- La stabilité se définit par le nombre de bugs, d’anomalies potentielles détectées dans le code,
- La sécurité correspond au nombre de vulnérabilités potentielles qui pourraient être exploitées par des hackers. Il est important que les bonnes pratiques en matière de sécurité soient respectées dans le code source. En effet, il est plus fréquent que ce que l’on croit de trouver des mots de passe en clair dans du code source, rendant votre application vulnérable.
- La maintenabilité est matérialisée par ce que l’on appelle les “code smells”. Un code smell, n’est rien d’autre que du “mauvais code” soit un code de mauvaise qualité. Il est le résultat de mauvaises pratiques de conception.
Il est intéressant de mesurer la qualité du code pour définir si le code est maintenable sur le long terme.
La sécurité et les vulnérabilités
Du point de vue de la sécurité et des vulnérabilités, il existe Open Web Application Security Project (OWASP).
C’est une communauté (et une fondation) qui travaille à l’élaboration des bonnes pratiques en matière de sécurité des applications web. OWASP est aussi responsable du projet Top Ten. Ce projet est aujourd’hui une référence internationale dans le domaine de la sécurité. Beaucoup d’outils d’analyse utilisent cette codification pour classer les vulnérabilités détectées.
Le projet Top Ten classe et détaille les 10 risques les plus critiques (codifiés de A1 à A10) avec des indicateurs vous donnant des informations sur la gravité de certaines des failles.
Voici le classement qui identifie les vulnérabilités de sécurité les plus critiques.
| A1 : Défauts d’injection | A6 : Mauvaise configuration de sécurité |
| A2 : Authentification brisée | A7 : Script intersite (XSS) |
| A3 : Exposition de données sensibles | A8 : Désérialisation non sécurisée |
| A4 : Entités externes XML (XEE) | A9 : Utilisation de composants avec des vulnérabilités connues |
| A5 : Contrôle d’accès cassé | A10 : Insuffisance de journalisation et de surveillance |
Source : OWASP Top Ten Web Application Security Risks | OWASP
Comment mesurer le risque potentiel d’une vulnérabilité ?
Chaque vulnérabilité est automatiquement supposée comme potentiellement critique et doit être analysée précisément. Certaines de ces failles vont être exploitables plus ou moins facilement. Des failles de sécurité peuvent subsister, car elles sont la plupart du temps dues à des fautes de programmation de l’application.
Le manque de compétence en sécurité de certains développeurs peut expliquer les vulnérabilités récurrentes qu’elles présentent. Par exemple, une application peut comporter des erreurs perturbant son bon fonctionnement, en causant une lecture du code difficile (complexité cognitive).
On distingue 4 comportements possibles en cas de détection d’une vulnérabilité :
- Un vrai négatif est une activité normale correctement considérée
- Un faux positif appelé aussi fausse alerte, est une activité normale considérée à tort comme une attaque
- Un faux négatif est une attaque non détectée, considérée donc à tort comme une activité normale
- Un vrai positif est une attaque correctement détectée et considérée comme telle.
Les vrais négatifs et vrais positifs correspondent aux comportements souhaités.
L’efficacité d’une protection se mesure par le taux de faux positifs et de faux négatifs.
Considérer les coûts liés
Lors d’une analyse de code, nous cherchons aussi à obtenir les coûts liés pour remettre la qualité du code à un niveau satisfaisant.
Il y a 2 types de coûts à prendre en considération :
- Le coût de remédiation, qui est une estimation du temps utile pour corriger les bugs et les vulnérabilités.
- Le coût de la dette technique, qui estime le temps nécessaire pour corriger les problèmes liés à la maintenabilité et aux mauvaises pratiques de conception.
Exemple d’analyse de code
Nous prenons comme exemple l’analyse d’une partie d’un code source avec l’outil Sonarqube. L’outil a détecté un bug (problème) potentiel jugé critique. Il indique qu’il faut 10 minutes d’effort pour corriger ce problème précis dans le code.
Voici un autre exemple présentant un tableau de bord avec une vue complète d’analyses et des mesures.
L’outil a détecté 103 bugs dans le code source, cela se traduit par une mauvaise note (E) et une mauvaise note en termes de fiabilité du code, mais il n’a pas soulevé de vulnérabilité particulière.
L’outil évoque une amélioration possible en 1 jour et 2 heures de dette technique (ce qui est assez faible en matière de temps) et indique qu’il y a 82 codes smells à vérifier, ce qui est un bon indice de maintenabilité. Soyez également attentif au concept de Hotspot. Les hotspots des endroits sensibles dans le code ; il faut donc aller vérifier qu’il n’y contiennent pas de failles.
Dans la vue ci-dessous, l’outil Sonarqube montre qu’il existe des efforts de remédiation à réaliser. Il détermine un nombre de minutes d’efforts pour corriger et améliorer le code source pour chacun des dossiers utilisé dans l’application.
Comme un audit du code source est chronophage, des solutions intégrées à ces outils vous feront gagner du temps et vous permettront de mettre en place un plan d’action pour prioriser vos actions. Un planning prévisionnel vous aidera à gérer aussi bien les actions correctrices que les actions préventives, pour empêcher l’augmentation de la dette technique.
Nous vous conseillons d’auditer uniquement ce que vous maîtrisez à l’instant de l’audit applicatif. Pour ce qui est de la gestion du temps de travail que cela nécessite, vérifiez les problèmes un à un, les bugs et les codes smells. Un audit peut durer de quelques jours à plusieurs semaines. Cela varie en fonction de l’ampleur du code à auditer. En effet, plus l’application est complexe, plus le volume de code source est important, plus le temps à y accorder est important.
Une mauvaise gestion des erreurs peut exposer des données sensibles, ou se traduire par un code non maintenable (et donc coûteux à l’entretien). Les développeurs testent alors la sécurité de l’application lors du processus de développement, et vérifient que la nouvelle version ou la version mise à jour ne présente aucune vulnérabilité. Un audit de sécurité peut garantir la conformité de l’application avec un ensemble spécifique de critères de sécurité. Une fois que l’application a passé cet audit, les développeurs doivent s’assurer que seuls les utilisateurs autorisés peuvent y accéder.
Les étapes de l’analyse de code source en vidéo
Comment analyser le code source de votre application web ou mobile ?
Rediffusion du webinaire sur l’audit de code source d’une application web ou mobile, présenté par Antony Zanetti, Directeur Technique et co-fondateur d’AxioCode. La présentation est suivie par une séance de questions/réponses. Vous avez d’autres questions ? Posez-les nous.
En conclusion
Pour réduire les coûts liés à la dette technique, un travail régulier sur la qualité du code est indispensable. Il arrive que des vulnérabilités s’insèrent dans le code. Pour éviter cette situation, il est nécessaire de former les développeurs à l’identification des risques et d’utiliser des outils adéquats pour repérer plus facilement les vulnérabilités.
Si les applications ne sont pas maintenues à jour, elles deviendront vulnérables et s’exposeront à des attaques malveillantes pouvant porter atteinte à la confidentialité, à l’intégrité ou à la disponibilité des informations. Pour faire face à ces menaces, il est recommandé de procéder à des audits de code, de former et d’outiller les développeurs à l’identification des vulnérabilités et surtout à la qualité du code.
Avoir de la dette technique ne fait pas de votre application un échec. Le plus important est de réussir à la traiter régulièrement afin d’en améliorer la qualité et réduire les risques. L’ajout de nouvelles fonctionnalités peut amener de la dette technique, il faut donc procéder régulièrement à des vérifications. Il est nécessaire d’être conscient des failles à corriger afin de les réduire, même si cela engage du temps.
Une application professionnelle vous pose problème ? Vous n’avez pas les compétences en interne ? Vous n’avez pas le temps d’analyser votre application ? AxioCode peut vous aider.
Demandez conseil à un expert ou faites un diagnostic autonome rapide de votre application.
Evaluez l’obsolescence de votre application
Vous pouvez bénéficier de notre service d’audit dédié aux applications web et mobiles. Vous obtiendrez ainsi une étude détaillée de votre application et une feuille de route.
