Les listes, suites de tests et benchmarks ne suffisent pas à comparer les outils SAST

Il existe de nombreux défis lorsqu’on cherche à identifier le meilleur outil SAST pour son équipe. Mais comment mesurer un outil conçu pour détecter les inconnues ? Comment savoir s’il répond à vos besoins ? Comment comparer différents outils ? Rien d’étonnant à ce qu’on nous demande souvent : « Snyk Code couvre-t-il l’OWASP Top 10 ? », puis : « Comment nous conseillez-vous d’évaluer et de comparer différents outils SAST ? »

Nous voulons tous des réponses simples. Dans le contexte des comparaisons d’outils SAST, les « étalons de mesure » les plus utilisés sont des études et des listes des vulnérabilités les plus courantes contre lesquelles il faut se protéger (OWASP Top 10, SANS-25, etc.). Comparer les résultats de deux outils SAST à l’aide de ces listes peut sembler simple, mais la réponse est plus nuancée. Dans cet article, nous allons examiner les limites de ces étalons de mesure.

Avant d’examiner chaque norme, commençons par définir quelques termes.

• L’OWASP Top 10 est une liste des dix principaux risques que les développeurs doivent connaître lorsqu’ils créent une application web. Elle est publiée par la fondation OWASP® et sa dernière révision date de 2017.

• Le SANS-25 est une liste des 25 types d’erreurs logicielles les plus dangereuses. Elle est publiée par le SANS Institute et sa dernière révision date de 2011.

• Le CWE Top 25 est une autre liste, très similaire au SANS-25, mais mise à jour plus fréquemment. Elle est publiée par l’équipe CWE et sa dernière révision date de 2020.

• Benchmark est une suite de tests open source spécialement conçue pour évaluer les outils SAST. Elle ne teste que Java et fait l’objet d’une maintenance active, même si sa dernière version majeure date de 2016.

• Les applications volontairement vulnérables sont des dépôts ou des projets conçus pour sensibiliser et fournir des exemples de vulnérabilités. Ils peuvent également suivre différentes normes. Ces projets n’ont pas été créés pour les outils SAST. Parmi les exemples, citons OWASP/NodeGoat, appsecco/dvna, WebGoat et juice-shop.

C’est parti !

Les limites des listes de vulnérabilités pour évaluer les outils SAST

Plusieurs raisons expliquent pourquoi les différentes listes de vulnérabilités ne conviennent pas à l’évaluation des outils SAST ni à la priorisation des problèmes détectés par SAST :

• Portée limitée : certaines listes se limitent souvent à un domaine précis. Par exemple, l’OWASP Top 10 ne concerne que la sécurité des applications web.

• Trop génériques : à l’inverse, le SANS-25 et le CWE Top 25 ne font pas de distinction entre les environnements et les langages. Les listes peuvent donc inclure de nombreuses vulnérabilités (ou CWE) qui ne sont pas forcément pertinentes pour tous les langages. Par exemple, CWE-416: Use After Free ne concerne que les langages de bas niveau comme C, C++, Rust, etc.

• Potentiellement obsolètes : ces listes ne sont souvent pas mises à jour régulièrement. La dernière mise à jour de l’OWASP Top 10 date de 2017, et celle du SANS-25 de 2011. Elles ne reflètent donc pas nécessairement l’état actuel de la sécurité des applications. La récente recrudescence des attaques contre la chaîne d’approvisionnement et des attaques par typosquattage en est un exemple frappant : aucune des deux listes ne mentionne ces problèmes.

• Non pertinents pour SAST — Certains problèmes ne sont pas nécessairement pertinents dans le contexte de SAST (sans que cela signifie qu’ils ne sont pas importants en général). Par exemple, l’OWASP Top 10 mentionne l’insuffisance de la journalisation et de la surveillance, qui n’est pas en soi une vulnérabilité.

Les limites des suites de tests et des applications volontairement vulnérables pour évaluer les outils SAST

Les suites de tests comme l’OWASP Benchmark et les dépôts vulnérables ont également leurs propres limites :

• Couverture limitée des langages : aucune suite de tests ni application volontairement vulnérable ne permet de tester plusieurs langages. L’OWASP Benchmark, par exemple, ne contient que des problèmes liés à Java.

• Surapprentissage : lorsqu’un ensemble de suites de tests ou d’applications volontairement vulnérables devient une « référence du marché », les entreprises peuvent adapter les capacités SAST de leurs produits à ces problèmes spécifiques. Leurs produits obtiennent alors d’excellents résultats sur ces benchmarks. Malheureusement, cela ne garantit pas une précision ni une profondeur équivalentes dans des conditions réelles.

• Manque de réalisme sémantique : les exemples inclus dans les benchmarks et les applications vulnérables ne représentent souvent pas les applications du monde réel, où les flux de données sont généralement plus complexes.

Alors... comment comparer les outils SAST ?

Nous avons passé en revue les différents outils disponibles et expliqué pourquoi ils ne sont pas idéaux pour évaluer les outils SAST. Cela ne signifie pas que ces listes, suites de tests et benchmarks sont inutiles. La plupart ont été créés pour former les développeurs et les sensibiliser aux problèmes de sécurité courants. Même s’ils ne sont pas adaptés à l’évaluation d’un outil SAST, nous pensons qu’ils peuvent contribuer grandement à renforcer l’expertise de votre organisation en matière de sécurité.

Vous vous demandez peut-être maintenant : si les normes ci-dessus ne sont pas à la hauteur, quelle est la bonne méthode pour évaluer les outils SAST ? Consultez notre prochain article pour découvrir 3 paramètres permettant d’évaluer les tests SAST.