Comparatif de vitesse des outils SAST : Snyk Code, SonarQube et LGTM

On nous a demandé de comparer les temps d’analyse de Snyk Code et de deux outils SAST courants : LGTM et SonarQube. Pour cette étude, nous avons formulé plusieurs hypothèses, dont nous partageons les détails en toute transparence.

En bref

Les tests de sécurité des applications statiques (SAST) ne peuvent être adaptés aux développeurs que s’ils fournissent un retour quasi immédiat et ne ralentissent pas vos processus de développement. Snyk Code est jusqu’à 106 fois plus rapide que LGTM. En moyenne, Snyk Code est 5 fois plus rapide que SonarQube et 14 fois plus rapide que LGTM. En résumé, Snyk Code s’impose comme l’un des moteurs d’analyse sémantique les plus rapides du marché.

Environnement de test

Nous avons sélectionné 48 dépôts open source JavaScript (répertoriés ci-dessous). L’objectif était de reproduire des bases de code typiques des développeurs d’aujourd’hui ; JavaScript nous a semblé être un dénominateur commun pertinent. Nous avons choisi un échantillon aléatoire parmi les dépôts les mieux notés sur GitHub afin de représenter des cas d’usage réels.

Pour les outils d’analyse, nous avons choisi l’édition Community de SonarQube, un outil d’analyse statique open source largement utilisé. Comme il s’exécute localement, nous devions disposer d’un PC assez performant. Les tests précédents avec l’édition gratuite de SonarCloud ont montré qu’un SonarQube exécuté sur un bon PC est plus rapide que SonarCloud gratuit ; il n’est donc pas injuste d’utiliser le moteur local plutôt que la version cloud. Nous avons dû utiliser l’une des machines existantes de nos développeurs (détails ci-dessous). Le second outil est LGTM, créé par Semmle, une entreprise rachetée par GitHub. LGTM utilise une recherche de code sémantique approfondie basée sur CodeQL. Nous avons utilisé l’offre SaaS de LGTM.

Enfin, Snyk Code est la solution SAST de Snyk. Elle s’appuie sur l’ancien moteur d’analyse DeepCode, qui a bénéficié de plusieurs mois de développement supplémentaires chez Snyk. Outre sa convivialité pour les développeurs et sa grande précision, Snyk Code a été conçu pour être extrêmement rapide. Il s’appuie pour cela sur un moteur de contraintes propriétaire. Nous avons retenu ces outils parce que (1) leurs licences nous autorisent à les exécuter et à les comparer, (2) ce sont des moteurs sémantiques et non des linters (comme ESLint), (3) ils sont courants et largement utilisés et (4) nous avons inclus un moteur local et une solution SaaS.

La vitesse est essentielle pour qu’une solution SAST soit adaptée aux développeurs. Il est bien connu que les développeurs sont plus efficaces lorsque les problèmes de sécurité sont détectés pendant le développement, afin de pouvoir les corriger avant l’enregistrement du code. Ils ont encore le code bien en tête. Snyk Code propose des plug-ins pour les IDE qui s’intègrent naturellement au flux de travail des développeurs. En outre, Snyk Code fournit des diagrammes de flux de données faciles à comprendre et des explications détaillées, avec des exemples de correctifs employés dans des bibliothèques open source dans le même contexte. Pour ce test, toutefois, nous nous sommes concentrés sur la vitesse.

Pour réaliser le test, nous avons lancé une analyse sur chacun des dépôts : SonarQube en local, LGTM et Snyk Code en SaaS. Comme indiqué plus haut, nous avons sélectionné les dépôts de cette façon afin que les temps d’analyse ne dépendent pas de la bande passante du réseau.

Nous avons également choisi de vrais dépôts open source plutôt que des benchmarks, car l’objectif était de reproduire le travail réel des développeurs. Comparer les outils SAST à l’aide de benchmarks pose ses propres problèmes et, dans ce cas, cela ne nous aurait pas aidés.

Résultats des tests

Voici les principales valeurs statistiques (arrondies) du temps d’analyse, en secondes. (n=48, arrondi à l’entier) :

Voici les résultats sous forme de nuage de points (plus bas = meilleur, échelle logarithmique, graphique réalisé avec R et ggplot2) :

L’axe logarithmique accentue excessivement la dispersion dans la partie basse du graphique. En réalité, l’écart-type de Snyk Code est bien inférieur à celui de SonarQube, par exemple.

Voici un diagramme en boîte des valeurs (plus bas = meilleur ; nous avons utilisé une échelle logarithmique pour faire tenir toutes les valeurs sur le graphique, réalisé avec R et ggplot2 ; la médiane et la moyenne sont indiquées) :

Le graphique montre clairement que, dans la majorité des cas, Snyk est nettement plus rapide que les deux autres outils. La médiane de Snyk est de 6,7 fois (SonarQube) à 16,4 fois (LGTM) plus rapide, ce qui montre que les résultats ne reposent pas sur quelques valeurs exceptionnellement bonnes, mais sont généralisables.

Dans le graphique ci-dessus, l’étendue des valeurs de la colonne LGTM est notable. Elle va approximativement de 2 minutes (acceptable, en quelque sorte) à plus de 17 minutes (inacceptable). Les développeurs ne vont pas attendre plusieurs minutes les résultats pendant leur journée de travail. Heureusement, la médiane de LGTM est d’environ 3 minutes.

Par rapport au premier test de vitesse que nous avions réalisé (à l’époque sous le nom de DeepCode, aujourd’hui Snyk Code), nous avons constaté d’importantes améliorations des performances, car nous avons nettement optimisé le chargement vers le service cloud au cours des derniers mois. Cette fois-ci, SonarQube était également plus rapide, probablement parce que nous avons utilisé un PC plus puissant, avec un niveau de parallélisme supérieur à celui du premier test.

Autre constat intéressant : du point de vue de la vitesse, les moteurs SaaS et ceux installés localement ne sont pas si différents.

Hypothèses et limites

• Nous avons choisi SonarQube (Community Edition 8.9.1) et LGTM, car leurs licences nous autorisent à effectuer ces comparaisons et qu’ils sont largement utilisés.

• Nous avons choisi 48 dépôts JavaScript de taille moyenne, qui nous semblaient représentatifs du travail des développeurs. Nous avons constitué un échantillon aléatoire parmi les quelque 200 000 dépôts GitHub les plus populaires selon le nombre d’étoiles. La taille du code n’était pas un critère.

• Nous avons imposé une analyse complète et n’avons pas utilisé de mécanisme d’analyse différentielle. Par exemple, avec les plug-ins IDE de Snyk Code, après une première analyse, le plug-in IDE effectue des analyses différentielles et économise de la bande passante.

• Nous avons utilisé un Intel Xeon à 2 GHz, avec 16 cœurs et 64 Go de RAM.

Données brutes

Nous souhaitons également fournir les données brutes afin que vous puissiez appliquer vos propres méthodes statistiques. (Temps en secondes)