Qualité du code : les nouvelles ambitions de Sonar

Les quatre grandes fonctions portées par Sonar

Pour faire son office, Sonar a développé au fil des ans un ensemble de techniques basées sur l’analyse lexicale, l’analyse syntaxique, les exécutions symboliques et la « taint analysis ». Cette dernière technique consiste à détecter les vulnérabilités ou les bugs générés par les utilisateurs, volontairement ou non.

Olivier Gaudin, PDG et fondateur de Sonar

« Nous faisons principalement quatre choses », résume Olivier Gaudin. « La première, c’est d’assurer la consistance du code ».

Il s’agit d’analyser le style d’écriture du code pour que les développeurs n’aient pas à assembler des blocs différents de code en fonction des auteurs. « Il s’agit de maximiser l’appartenance collective du code. C’est quelque chose d’assez basique, mais qui si elle n’est pas respectée peut coûter très cher sur le long terme », prévient-il.

La deuxième chose que doivent permettre les outils de Sonar, c’est le respect des bonnes pratiques de développement. Cela consiste par exemple à repérer les copier-coller ou les blocs de code trop verbeux ou complexes, selon le dirigeant.

Ensuite, l’éditeur entend détecter les « problèmes applicatifs qui vont se révéler au moment de l’utilisation : les Null pointer exception, le fait que la mémoire ne soit pas désallouée en C++, des connexions aux bases de données qui ne sont pas fermées, etc. », indique Olivier Gaudin.

Ces problèmes peuvent être d’ordre opérationnel, mais aussi de sécurité. C’est le quatrième point. D’après le PDG, il s’agit de répondre à certaines questions critiques pour la santé d’une application.

« Y a-t-il des adresses IP codées en dur ? Des mots de passe dans le code ? Les algorithmes de chiffrement sont-ils suffisamment puissants ? Est-il possible d’injecter autre chose que la donnée attendue quand un utilisateur interagit avec le système ? (injections SQL, Cross-Site Scripting, commandes shell, etc.) », évoque Olivier Gaudin.

SAST ou « Deep SAST » ?

Généralement, les outils de test de sécurité sont répartis en plusieurs catégories suivant si ces opérations sont statiques (SAST), dynamiques (DAST) ou interactives (IAST).

D’un point de vue purement technique en matière de sécurité, Sonar développe une solution SAST.

Mais pour Olivier Gaudin, de ces distinctions techniques découle « une vue du marché ». « Nous nous intéressons à tous les attributs du code source : la sûreté, la sécurité, la conformité, la durabilité, la maintenabilité, la portabilité, la lisibilité, etc. », affirme-t-il.

« Les gros éditeurs du monde de la cybersécurité en ont un peu décidé autrement pour nous. Ils ont créé avec Gartner des catégories auxquelles nous devons nous adapter », renchérit-il.

Ces acteurs entendent, selon lui, fournir des solutions verticales quand d’autres proposent des outils spécifiques. Sonar se veut plus horizontal. « Nous ne couvrons que le code et sa qualité au sens large du terme », insiste Olivier Gaudin. « Quand nous arrivons aux questions autour de la sécurité du code, nous nous retrouvons en compétition avec les éditeurs comme Checkmarx ».

De manière générale, Sonar estime que ce travail d’analyse et d’amélioration de la qualité du code « doit être effectué par les développeurs au sein des processus de développement ». Et non par des équipes externes.

« Et l’on ne peut pas fournir à des développeurs un outil qui lève des problèmes à tout va. C’est plutôt le travail d’une équipe de risques », considère le PDG.

Pour être clair, Sonar a intégré son moteur SAST en 2019. Il est donc arrivé plus tardivement sur ce marché que ses compétiteurs. Et pourtant le dirigeant s’est dit surpris par les premiers retours des clients quand la fonctionnalité a été commercialisée après un an de développement.

« Certains nous ont dit que notre outil ne trouvait pas les problèmes que les autres solutions en place détectaient habituellement », raconte-t-il. « D’autres nous ont dit qu’ils allaient immédiatement adopter notre produit parce que tout ce que nous trouvions était extrêmement précis, et il y avait peu de faux positifs », poursuit-il.

« Cela m’a mis la puce à l’oreille, je me suis dit que c’était un marché de surface et que la recherche logicielle s’est un peu arrêtée en cours de route », observe-t-il. 

« Les acteurs cherchent et intègrent des éléments pour détecter les nouvelles vulnérabilités, mais ils ne semblent pas avoir investi dans les manières d’aller plus loin dans l’analyse », précise-t-il.

« Le problème de ces techniques [SAST], c’est qu’elles vivent assez mal qu’il y ait des inconnues dans le système. Il faut donc arbitrer sur la manière de les présenter ».

Dans un même temps, le dirigeant balaie devant sa porte. In fine, Sonar rencontre les mêmes défis techniques que ses concurrents de l’analyse et de la sécurité du code.

« Le problème de ces techniques, c’est qu’elles vivent assez mal qu’il y ait des inconnues dans le système. Il faut donc arbitrer sur la manière de les présenter », explique Olivier Gaudin. « Certains acteurs se disent “je ne sais pas, donc c’est une vulnérabilité ou un bug à signaler”. D’autres les considèrent comme normaux. Plus il y a d’hypothèses, moins les résultats sont précis », déplore-t-il.

Sonar a fait le choix de ne pas remonter aux développeurs ces inconnus quand elles sont trop difficiles à démêler. « Ce sont des résolutions de construction de code complexes à comprendre, le suivi des données une fois stockées dans un SGBD quand elles sont reprises par un autre programme ou encore les interactions avec des dépendances externes », liste Olivier Gaudin.

Concernant ce point, Sonar se soigne. « Nous pensons que notre moteur est bon, maintenant nous voulons résoudre ces inconnues quand c’est pertinent de le faire pour nos utilisateurs », indique le PDG.

L’éditeur entend ainsi développer ce qu’il appelle un « Deep SAST », qui outre le support des 10 grandes vulnérabilités recensées par l’OWASP devra proposer des fonctionnalités plus avancées, sans plus de précision pour le moment. À l’avenir, l’entreprise compte ajouter des tutoriels et des formations à même depuis SonarCloud concernant les questions de sécurité.

Les effets « pernicieux » de la mauvaise qualité du code

L’exécution de ces analyses à l’écriture du code, avant la mise en production et à la revue d’architecture, pourrait être considérée comme optionnelle pour certaines équipes. Une fois inscrite dans des pratiques quotidiennes de développement, la valeur de tels produits pourrait être difficilement perceptible.

D’autant que l’édition Enterprise de SonarQube est disponible à partir de 20 000 dollars par an pour l’analyse d’un million de lignes de code et jusqu’à 240 000 dollars par an pour un maximum de 100 millions de lignes analysées.

Conscient de ce phénomène, Olivier Gaudin considère que les problèmes de qualité coûtent beaucoup plus cher que les problèmes de sécurité.

« En matière de sécurité, il suffit d’une attaque bien placée pour que tout s’arrête [...]. En revanche, les problèmes de qualité sont beaucoup plus pernicieux ».

« En matière de sécurité, il suffit d’une attaque bien placée pour que tout s’arrête : l’impact potentiel est infini », déclare-t-il. Cela implique donc une vigilance constante.

« En revanche, les problèmes de qualité sont beaucoup plus pernicieux », souligne-t-il.

« Par exemple, si l’inconsistance du code rallonge la durée des revues, que vos développeurs passent 80 % de leur temps à lire du code et 20 % à le modifier, et que vous avez plusieurs milliers de développeurs, ce sont des millions d’euros qui sont en jeu chaque année », illustre-t-il.

Les clients de Sonar semblent convaincus par cette approche qui met la propreté du code au centre des approches de développement. L’éditeur va bientôt générer 200 millions d’euros de revenus annuels récurrents et a levé 375 millions d’euros à la fin du mois d’avril 2022.

Sonar revendique plus de 6 millions d’utilisateurs, dont 300 000 organisations qui déploient les versions open source de ses produits. Il compte plus de 15 000 clients payants.

Outre la volonté de supporter la qualité des fichiers de configuration IaC (Infrastructure-as-Code) en prenant en charge les règles Terraform spécifiques à Azure, GCP et AWS depuis SonarQube, l’éditeur entend surtout renforcer sa présence commerciale en recrutant des commerciaux et des évangélistes.

« Nous sommes une petite société entre guillemets », affirme Olivier Gaudin. « Une entreprise avec 300 collaborateurs ce n’est pas négligeable, mais pour 200 millions d’ARR, c’est minuscule ».

« Pour atteindre la masse critique, nous devons avoir davantage de commerciaux, prêcher la bonne parole dans les comités de documents, il faut que nous résolvions les défauts de nos produits », anticipe-t-il.

Dans cette optique, Sonar compte ouvrir des bureaux en Asie-Pacifique depuis Shanghai, et en Amérique du Sud, depuis le Brésil.