ELEPHANT technologies, c'est l’ESN locale et à taille humaine spécialisée sur 2 métiers : le développement et le pilotage autour de 4 expertises : Embedded & IoT, Digital et Agile.

 

Aujourd’hui, retrouvez Robert notre elephantech fullstack qui nous parle de la qualité du code. A travers son article, il nous explique comment mesurer cette qualité grâce à 6 métriques et nous présente les différents tests de sécurité réalisables.

 

Introduction 

 

Ecrire un code c’est bien mais écrire un code de qualité c’est mieux.  Un code de qualité est un code facile, facile à tester, facile à maintenir,  facile à lire et facile à comprendre. La qualité de code est la manière avec laquelle une fonctionnalité est implémentée. Une métrique logicielle est une mesure d’une propriété, d’une partie d’un logiciel ou de ses spécifications. Il n’existe pas de métrique « ultime » : la pertinence de chaque métrique dépend de la qualité de l’interprétation qui est faite et du projet.

 

Dans la suite de cet article, je vous présenterai six métriques que j’ai personnellement trouvées pertinentes. 

 

  • D’abord, il y a ce que l’on appelle la  complexité cyclomatique 

c’est-à-dire le nombre de chemin linéairement indépendant à travers le code source d’un programme. Moins il y en a, mieux c’est.  Par exemple un if créera deux branches, complexité cyclomatique est de deux.  La complexité cyclomatique est aussi égale aux nombre de if du programme +1.  Dans du code, plus il y aura de boucles for imbriquées plus la complexité cyclomatique sera importante.  Une complexité cyclomatique trop élevée indique qu’il faut refactoriser la méthode.

 

  • On regarde aussi la  couverture de code 

c’est le nombre de test qui couvre le code et le nombre de branche qu’empruntent ces tests. Plus un code est couvert moins le nombre de bugs est important.

 

  • Le nombre de « code smells »

c’est-à-dire des mauvaises pratiques de développement dont on sait par expérience qu’elles risquent de crée des bugs.

 

  • La dette technique

c’est-à-dire le temps nécessaire à corriger un code qu’il soit lisible,  maintenable et correctement testé.  Plus la dette technique est importante plus le coût de remise à niveau sera important.

 

  • Les métriques liées aux fonctions.

Ici on regarde beaucoup de métriques différentes : le nombre de fonction d’abord, mais aussi leurs longueurs et leurs profondeurs d’appels. Plus une fonction est longue plus il y a de chance qu’elle contienne un bug. Plus il y a d’appels entre les fonctions plus on a de chance de tomber sur un bug. Plus on a des arguments en entrée plus on va devoir faire les tests.

 

  • Les tests de sécurité 

ne concernent pas la vitesse ou les performances mais plutôt la recherche de vulnérabilités. Durant la phase de qualité de code il est important de tester son code pour avoir une vision de sécurité de ce dernier.  Il existe 5 types différents de test de sécurité dans le code.

 

1. Le SAST (Static Application Security Testing) ou test de sécurité statique de l’application. Ce test consiste à tester le code source de l’application contre des vulnérabilités connues. Il n’est pas nécessaire d’avoir compilé l’application.  Le but est de tester le code source de l’application à la recherche des vulnérabilités connues du langage.

 

2. Le DAST (Dynamic Application Security Testing) ou Test de sécurité dynamique de l’application. Ce test consiste à tester dynamiquement une application déployée. Il intervient généralement durant la phase de déploiement continue de l’application. Ce type de test fonctionne en mode boite noire, c’est-à-dire que le test s’exécute sans avoir accès au code source, ni au binaire.

 

3.SCA (Software Composition Analysis) Comme les applications embarquent généralement des frameworks, les dépendances,  des librairies Open Source ou propriétaires entre autres, il est nécessaire d’avoir un outil pour vérifier que l’artefact résultant n’embarque pas des composants connus comme vulnérables ou obsolètes.  Exemples d’outils : SonaType, NPM Audit, Jfrog XRAY, OWASP dependency-check.

 

4.Le IAST (Interactive Application Security Testing) ou test de sécurité interactif de l’application. Ce test consiste à tester l’application depuis l’intérieur de celle-ci. Contrairement au DAST, le IAST a accès au binaire de l’application et au code source. Il permet d’avoir une portée plus importante pour l’analyse des failles de sécurité de l’application.  

 

5.Le RAST (Runtime Application Security Testing). Une fois intégré permet d’analyser le trafic entrant et sortant, le modèle  de comportement de l’utilisateur final pour empêcher les attaques de sécurités. Le RAST est déployé sur un serveur web ou d’application, ce qui le place à côté de l’application principale pendant son exécution pour surveiller le les flux entrant et sortant.

 

                      Sur la partie test de sécurité, les outils peuvent être complémentaires :

  • SAST+SCA

pour la partie développement et analyse des composants/licences logiciels

  • SAST+DAST

pour la couverture plus complète de tests de sécurité, l’un couvrant les défauts de l’autres (vue statique et vue runtime).

  • SAST+SCA+DAST

en standard avec un test d’intrusion additionnel pour les applications critique.

  • IAST

pour une analyse de sécurité liée au fonctionnel de l’application et à sa technologie car installé sur le serveur.

                     

Le choix des solutions dépendra fortement du contexte  d’entreprise.

 

C’est clair que ca fait pas mal de test à faire sur un programme, la bonne nouvelle c’est qu’il y a des outils comme SonarQube qui font cela automatiquement. Ils permettent de récolter les métriques précises sur la qualité du code. Ce qui est bien avec SonarQube, c'est qu'il indique les endroits précis à corriger afin d’avoir le code le plus propre possible.

 

Conclusion 

 

 🐘 Nous remercions Robert pour cet article, dans le prochain il nous montrera comment combiner SAST+SCA+DAST , et en attendant si vous souhaitez découvrir d'autres articles tech : c'est juste ici

 

Sources : 

https://owasp.org/www-community/Component_Analysis

https://www.microfocus.com/en-us/cyberres/application-security

https://fr.parasoft.com/solutions/code-quality/

https://linsolas.developpez.com/articles/java/qualite/sonar/?page=page_1