3 paramètres pour évaluer les tests SAST

Dans notre précédent article de blog sur les raisons pour lesquelles vous ne pouvez pas comparer les outils SAST en vous appuyant uniquement sur des listes, des suites de tests et des benchmarks, nous avons étudié les différents outils et indicateurs couramment utilisés aujourd’hui pour évaluer et comparer les outils de test SAST. Nous avons également examiné quelques raisons pour lesquelles ces outils peuvent produire des résultats incohérents et ne pas être fiables pour évaluer un outil de test SAST.

Pour évaluer un outil de test SAST, vous devez plutôt prendre en compte 3 paramètres :

• la précision

• l’exhaustivité

• les autres avantages spécifiques

Dans cet article, nous allons examiner ces paramètres et voir comment les mesurer. Pour évaluer un outil de test SAST, deux types de mesures sont pertinents : les mesures quantitatives (le nombre de résultats par rapport au « bruit ») et qualitatives (notamment la profondeur de prise en charge des langages et cette prise en charge elle-même).

Aspects quantitatifs

Les définitions suivantes de la précision et de l’exhaustivité peuvent sembler un peu complexes au premier abord, car elles sont en réalité les deux faces d’une même pièce. Il est mathématiquement impossible (selon le théorème de Rice) de réaliser une analyse statique parfaite d’un programme. On pourrait penser qu’augmenter le nombre de suggestions permettrait de détecter tous les problèmes possibles. Malheureusement, cela augmente également le nombre de faux positifs (FP) jusqu’à ce que le bruit rende les résultats inexploitables. Les fournisseurs de solutions de test SAST peuvent employer quelques astuces pour améliorer les résultats, mais la perfection est mathématiquement impossible.

Précision

Dans le contexte des tests SAST, la précision se définit généralement comme le fait d’obtenir le plus grand nombre de VP (vrais positifs, c’est-à-dire des problèmes réels détectés) tout en limitant au maximum les FP (résultats qui ne correspondent pas à des vulnérabilités et sont donc erronés).

La précision est particulièrement importante. Un taux de précision élevé signifie que nous obtenons davantage de résultats exploitables et moins de « bruit » (des rapports non pertinents et sans suite possible). Le « bruit » est également le principal facteur qui dissuade les développeurs d’utiliser des produits de test SAST. Plus la précision est élevée, meilleure est donc l’expérience globale des développeurs.

Pour calculer la précision, vous devez d’abord trier les résultats. La formule est alors TP*100/(TP+FP). Vous obtiendrez un nombre compris entre 1 et 100. Plus ce nombre est élevé, plus la précision est grande. Par exemple, un outil qui détecte 140 VP et 40 FP aurait un taux de précision de 77,7 %.

Exhaustivité

Le NIST définit l’exhaustivité, parfois appelée taux de rappel, comme « une mesure des problèmes réels détectés (VP) par rapport à l’ensemble des problèmes possibles (VP et faux négatifs). Plus l’exhaustivité est élevée (jusqu’à son maximum théorique de 1), mieux l’outil couvre les problèmes présents dans le code ». Concrètement, il s’agit du nombre de problèmes réels qui n’ont pas été détectés, les faux négatifs (FN).

Plus l’outil est exhaustif, meilleure est votre visibilité et votre protection. Cela peut également se traduire par un plus grand nombre de résultats, bien sûr, mais si le taux de précision est élevé, la plupart d’entre eux devraient être pertinents. Cela dit, la gravité de ces résultats joue toujours un rôle essentiel dans l’exhaustivité : un millier de FN de faible gravité n’est pas forcément problématique si vous cherchez à réduire le bruit. En règle générale, moins il y a de FN, mieux c’est. Et il est important de savoir comment les éliminer pour ne pas passer à côté des véritables vulnérabilités.

Cet indicateur ne peut être calculé que si vous connaissez des vulnérabilités présentes dans votre code ou si vous comparez plusieurs outils et avez constaté des écarts dans les résultats. Une autre approche consiste à examiner la gravité des FN et à traiter en priorité les plus importants. Les FN sont difficiles à mesurer, car ce sont des inconnues inconnues. Il est inévitable de devoir faire des compromis. L’expérience montre que les FN sont toujours à prévoir dans les projets non triviaux. En cybersécurité, baisser la garde parce qu’on se sent trop en sécurité n’est jamais une option.

L’aspect qualitatif

L’évaluation qualitative porte sur la prise en charge des langages et des vulnérabilités. Comme nous l’avons vu dans l’article précédent, s’en tenir aux listes de vulnérabilités connues, aux suites de tests et aux dépôts intentionnellement vulnérables donne une image incomplète. Un bon outil SAST va donc au-delà des listes.

Cette évaluation peut être divisée en deux axes : la prise en charge des langages et des vulnérabilités, et la profondeur et la précision de l’approche.

Comment évaluer la prise en charge des langages ?

Il est important de comprendre comment les priorités et les choix de prise en charge des langages sont définis pour l’outil SAST que vous évaluez.

Nous savons déjà que les listes de vulnérabilités ne suffisent pas. Une approche plus complète consisterait à regrouper des données provenant de plusieurs sources afin de proposer une prise en charge solide des langages, à jour face aux cyberrisques actuels et pertinente dans son contexte.

Les listes peuvent donc servir de référence, mais il existe d’autres sources à explorer :

• Sources d’actualité : les vulnérabilités « tendance » et les nouveaux vecteurs publiés sont plus susceptibles d’être exploités

• Bases de données sur les vulnérabilités connues et données sur les exploits, comme la base NVD et la Snyk Vulnerability Database.

• Bonnes pratiques et contexte propres aux langages et aux frameworks

• Recherche sur les vulnérabilités zero-day, notamment les nouveaux schémas et ceux déjà connus

Pour déterminer les langages et les frameworks pris en charge par Snyk Code, nous utilisons toutes les sources ci-dessus, et bien d’autres, afin de dresser la liste des problèmes les plus pertinents auxquels nos clients doivent prêter attention.

Comment évaluer la profondeur et la précision de la prise en charge des langages ?

Disposer d’une liste solide de langages et de vulnérabilités pris en charge est une première étape importante, mais vous devez également examiner dans quelle mesure cette prise en charge se traduit par des résultats.

Par exemple, un outil SAST qui s’appuie sur la communauté open source pour créer et publier de nouvelles règles, sans processus d’examen rigoureux ou presque, risque de générer de nombreux FP et produit souvent des résultats incohérents selon les langages et les vulnérabilités.

Chez Snyk Code, une équipe de chercheurs en sécurité dédiés travaille sans relâche pour prendre en charge toujours plus de langages et de vulnérabilités, ainsi que pour améliorer la prise en charge existante en renforçant sa profondeur et sa précision.

Quelle est la vitesse de développement et de maintenance de l’outil SAST ?

Comme indiqué plus haut, la maintenance et le développement continu d’une solution SAST sont importants. Cela concerne deux aspects : la feuille de route du produit et la capacité de l’entreprise ou de la communauté à la concrétiser. Les avancées récentes en matière d’apprentissage automatique rendent intéressant d’observer leur influence sur cette feuille de route. La prise en charge des langages modernes, l’utilisation d’un moteur moderne et la rapidité d’ajout de nouveaux langages sont également essentielles.

Ensuite, il est important de comprendre dans quelle mesure une entreprise ou une communauté est en capacité de maintenir la base de connaissances SAST. Comme indiqué plus haut, la sécurité exige une vigilance constante et une capacité à réagir à diverses sources.

Pour tout rassembler

Après l’évaluation quantitative, vous devez comprendre comment l’outil se comporte réellement sur le terrain. La meilleure prise en charge des langages et des vulnérabilités ne suffit pas si l’outil produit trop de résultats (même s’il s’agit de VP) ou, à l’inverse, trop de bruit (des FP). Un professionnel de la sécurité cherche un haut niveau d’exhaustivité, tandis qu’un développeur s’intéresse davantage à des conseils pratiques permettant de corriger concrètement les problèmes. Il est donc important de trouver un équilibre entre le nombre de suggestions, leur priorité et la capacité de l’équipe de développement à y donner suite. Notre expérience et nos recherches montrent que submerger les développeurs de suggestions, surtout si leur précision est faible, les démotive et ralentit le processus.

Du point de vue qualitatif, nous vous conseillons de dresser la liste des aspects pertinents dans votre environnement, de créer une matrice et d’y indiquer les valeurs pour chaque concurrent.

Pour mesurer les caractéristiques quantitatives, nous vous conseillons de choisir des projets réels que vous connaissez bien. Pour plus de simplicité, choisissez un projet de petite ou moyenne taille. Comme indiqué dans l’article précédent, évitez les applications intentionnellement vulnérables, car elles ne reflètent probablement pas la valeur réelle de l’outil.

Après avoir exécuté l’outil SAST et obtenu les résultats, vous devez les trier. Le tri consiste à déterminer si un résultat donné est un VP (un problème réel) ou un FP (un problème qui n’existe pas). Les résultats SAST dépendent souvent du contexte ; il est donc important de bien connaître le projet que vous analysez. Au final, votre expertise et votre travail ne peuvent pas être remplacés par des résultats de benchmark préétablis.

Enfin, vous devrez calculer la précision et l’exhaustivité à l’aide des formules présentées plus tôt dans cet article.

Pourquoi ne pas simplement rassembler tous les outils et les exécuter ?

Comme indiqué plus haut, chaque outil génère des VP et des FP. Il peut donc sembler logique d’utiliser tous les outils possibles, mais en réalité, le travail nécessaire pour éliminer le bruit l’emporte sur la valeur ajoutée par un outil supplémentaire. Les développeurs devront traiter des suggestions en doublon provenant de différents outils et présentées dans des formats différents, ce qui engendre beaucoup de travail supplémentaire, sans compter les contraintes de durée d’exécution. Cette méthode permet certes d’obtenir des chiffres de FN et de FP, mais elle n’est pas viable en continu. Selon notre expérience, une plateforme facile à utiliser pour les développeurs est essentielle. Si vous évoluez dans un environnement très critique du point de vue de la sécurité ou soumis à une réglementation, vous pourriez ajouter des outils spécialisés plus tard dans le processus CI/CD.

Un outil SAST est sans aucun doute un outil puissant que chaque développeur devrait avoir dans sa « boîte à outils » et qui peut vraiment faire la différence pour la sécurité de vos applications. Il est donc essentiel de choisir l’outil le mieux adapté à vos besoins et à ceux de votre organisation. Nous espérons que les informations et les étapes présentées ci-dessus et dans l’article précédent vous aideront à prendre de meilleures décisions.