Pourquoi les outils SAST conçus pour les développeurs sont l’avenir de la sécurité du code

La sécurité des applications couvre un vaste champ pour les équipes qui créent et déploient des applications cloud natives. Cet écosystème regroupe de nombreux processus, outils et membres d’équipe, allant de l’automatisation des pipelines sécurisés (bonjour DevSecOps) à la sécurité de l’open source, en passant par les tests de sécurité de l’infrastructure cloud. Certaines méthodologies de test de sécurité des applications se concentrent sur la sécurité du code et sont officiellement désignées sous le nom d’outils de test statique de sécurité des applications (SAST), parfois appelés outils d’analyse statique du code.

Si le terme technique SAST ne vous est pas familier, commençons par une introduction aux notions de base. Nous verrons ensuite comment les outils SAST conçus pour les développeurs vont façonner l’ensemble du secteur de la sécurité.

Que sont les outils SAST ?

Les outils SAST sont des outils de test statique de sécurité des applications qui analysent le code source pour suivre le parcours des données, depuis les vecteurs d’entrée potentiels des utilisateurs jusqu’aux opérations sensibles des interfaces de programmation d’applications. Par exemple, un outil SAST peut déterminer si une saisie dans un champ de recherche risque de déclencher une fonction liée à la base de données qui exécute une requête de façon non assainie, non sécurisée et imprévue (autrement dit, une vulnérabilité de sécurité par injection SQL).

Les outils SAST traditionnels et les raisons de leur échec

Le test statique de sécurité des applications n’est pas un concept nouveau. De nombreuses entreprises et de nombreux outils se sont lancés dans ce domaine il y a plusieurs décennies. Pour comprendre à quoi ressemble l’avenir de la sécurité du code, nous devons d’abord examiner le fonctionnement des outils SAST traditionnels et les raisons pour lesquelles ils n’ont pas été adoptés aussi largement que nous l’aurions souhaité.

Les outils SAST traditionnels sont lents à s’exécuter

Dans les équipes de sécurité et DevOps traditionnelles, il n’est pas rare d’entendre des remarques comme : « L’analyse SAST prend trop de temps » ou « Intégration continue ? Plutôt attente continue que l’analyse SAST se termine ! » Il était devenu courant que les outils SAST passent des heures, voire des jours, à analyser les dépôts de code source pendant la phase de build ou d’intégration continue (CI).

Des ajustements ont été apportés pour répondre au besoin d’obtenir des résultats plus rapidement, par exemple en travaillant sur les différences de code source ou en programmant la tâche CI SAST la nuit ou le week-end. Toutefois, il s’agit de solutions de contournement qui montrent que l’outil est inadapté et incapable de s’adapter aux processus et aux attentes du développement moderne.

La sécurité est généralement mal intégrée au cycle de développement logiciel

Pour pallier les retards de retour d’information évoqués plus haut, les outils SAST étaient mis en place comme un processus CI distinct, afin de ne pas bloquer les développeurs avec des évaluations de longue durée. Mais intégrer les outils SAST à la CI va à l’encontre de leur objectif initial, puisqu’ils devraient pouvoir se concentrer sur le code source. Cela signifie que les outils SAST doivent être utilisés pendant le développement du logiciel, au lieu d’intervenir après coup, lors de l’examen en CI.

Intégrer des outils de sécurité aux processus de build et d’intégration continue est un excellent moyen d’introduire la sécurité. Mais pour ne pas nuire à la productivité des développeurs, ces outils doivent être rapides et fournir des retours exploitables.

Les faux positifs entraînent l’abandon des outils SAST

La précision, ou plus précisément son absence, est un autre problème majeur pour les utilisateurs d’outils SAST. Les outils SAST traditionnels ont tendance à générer trop de fausses alertes et donc trop de notifications inutiles. Les alertes de sécurité exigent toute l’attention des développeurs. Lorsqu’une grande partie de ces notifications sont de faux signalements, le développement s’en trouve ralenti.

Les faux positifs sont une source de frustration et créent des tensions avec l’équipe de sécurité des applications. Au final, les développeurs finissent par ignorer toutes les alertes de sécurité et par abandonner complètement l’outil.

Les outils SAST traditionnels détectent les problèmes, mais ne les corrigent pas

Enfin, même lorsque les résultats d’un outil SAST sont exacts, ils ne vous indiquent pas comment résoudre le problème. Cette lacune tient à la conception même des outils SAST. À l’origine, ils ont été conçus pour les équipes de sécurité, notamment AppSec. Les résultats pouvaient donc manquer de contexte sur le flux d’exécution, ou simplement signaler le problème au moyen d’un code CWE (Common Weakness Enumeration, une description d’une vulnérabilité potentielle). Mais si vous n’étiez pas déjà expert en sécurité, un outil SAST ne vous aiderait pas à corriger le problème ou la vulnérabilité.

Les personnes capables de résoudre les problèmes de sécurité étaient des spécialistes expérimentés en sécurité des applications et les membres de leur communauté, ce qui créait un nouveau goulot d’étranglement. Les développeurs à qui l’on remettait les résultats d’une analyse SAST étaient également frustrés de ne pas pouvoir agir pour résoudre les problèmes.

Les outils SAST modernes conçus pour les développeurs doivent améliorer leur productivité

À la base, un outil SAST se concentre sur la sécurité du code. Il détecte des problèmes tels que l’exposition de données sensibles, l’injection SQL, l’injection de code et d’autres types de vulnérabilités. Qui a introduit ces problèmes de sécurité ? Des développeurs comme vous et moi. Alors, qui devrait les corriger ? C’est bien ça : les développeurs.

Conçu pour les développeurs, voilà le secret des meilleurs outils SAST. C’est ainsi que Snyk révolutionne le domaine de la sécurité des applications. Snyk s’est bâti sur une approche axée sur les développeurs.

Voyons ce qu’un outil SAST doit offrir pour proposer une expérience de sécurité productive aux développeurs.

La sécurité du code intégrée aux flux de travail des développeurs

Si les développeurs jouent un rôle essentiel dans la correction des vulnérabilités, une caractéristique clé d’un outil SAST est de s’intégrer de la manière la plus conviviale possible à leur environnement.

Où les développeurs passent-ils le plus clair de leur temps, en dehors de Google et StackOverflow ?

1. Dans leur IDE, comme IntelliJ ou Visual Studio Code

2. Dans l’interface de ligne de commande (CLI), où ils peuvent interagir avec leurs dépôts Git, exécuter des commandes, déboguer et gérer le code source et les routines de leurs projets

3. Lors des revues de code

Pour être adoptés, les outils SAST doivent aider les développeurs à détecter et à résoudre les problèmes de sécurité directement dans les outils qu’ils utilisent déjà. Les résultats doivent aussi fournir suffisamment de contexte pour qu’ils puissent à la fois détecter et corriger les vulnérabilités dans leur code.

Pour les développeurs qui passent leurs journées dans un IDE, voici un exemple de l’outil SAST Snyk Code en action, qui montre à quoi ressemble une intégration fluide des outils de sécurité :

À gauche, une liste des vulnérabilités potentielles dues à de mauvaises pratiques de codage sécurisé. À droite, dans le panneau inférieur, le contexte détaillé, ligne par ligne, montre comment un flux de données vulnérable se manifeste et peut être exploité.

Si vous préférez passer le plus clair de votre temps dans un terminal, l’interface de ligne de commande vous conviendra davantage. Dans ce cas, vous pouvez utiliser la CLI Snyk Code à cette fin.

En fait, si vous appréciez les hooks Git, par exemple pour exécuter un linter, une suite de tests ou d’autres automatisations avant que les développeurs ne valident ou n’envoient leur code, vous pouvez aussi utiliser la CLI Snyk à cette fin.

Voici le résultat d’un test de sécurité du code exécuté avec la CLI Snyk sur le même projet :

❯ snyk code test

Testing /Users/lirantal/projects/repos/goof ...

 ✗ [Medium] Cleartext Transmission of Sensitive Information
     Path: Users/lirantal/projects/repos/goof/app.js, line 12
     Info: http (used in require) is an insecure protocol and should not be used in new code.

 ✗ [Medium] Information Exposure
     Path: Users/lirantal/projects/repos/goof/app.js, line 27
     Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 77
     Info: This endpoint handler performs a system command execution and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 166
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 223
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [High] SQL Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 39
     Info: Unsanitized input from the HTTP request body flows into find, where it is used in an SQL query. This may result in an SQL Injection vulnerability.

 ✗ [High] Command Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 86
     Info: Unsanitized input from the HTTP request body flows into child_process.exec, where it is used to build a shell command. This may result in a Command Injection vulnerability.

 ✗ [High] Cross-site Scripting (XSS)
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 109
     Info: Unsanitized input from the HTTP request body flows into send, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS).

✔ Test completed

Test type:         Static code analysis
Project path:      /Users/lirantal/projects/repos/goof

8 Code issues found
3 [High]  5 [Medium]

Résultats d’analyse de sécurité en temps réel

Pour prendre en charge les flux de travail des développeurs mentionnés ci-dessus, un outil SAST doit être suffisamment rapide pour fournir des résultats d’analyse de sécurité en temps réel. Cette rapidité favorise l’adoption de pratiques de codage sécurisé dès le départ. Les développeurs peuvent ainsi détecter et corriger les problèmes de sécurité pendant qu’ils codent, au lieu de laisser l’équipe de sécurité ou une intégration DevSecOps les repérer après l’envoi du code. Cette dernière approche risque d’accroître la frustration : le code doit alors être remanié, ce qui génère des changements inutiles et ralentit globalement la mise en production.

Notre approche du codage sécurisé sans friction rend Snyk Code unique et en fait un outil d’analyse statique du code particulièrement performant. À quelle vitesse fonctionne Snyk Code ? Essayez-le et constatez-le par vous-même.

Une grande précision et peu de faux positifs

L’intégration aux flux de travail et des retours rapides sont importants, mais un aspect souvent négligé de l’expérience développeur concerne les données elles-mêmes.

Les développeurs doivent pouvoir faire confiance à leurs outils pour les adopter pleinement et les intégrer à leurs flux de travail. La qualité des données de sécurité communiquées par un outil SAST détermine si les développeurs l’intègrent volontiers à leurs pratiques ou l’abandonnent en raison d’un trop grand nombre de faux positifs.

Pour atteindre une précision de premier plan, Snyk Code s’appuie sur un modèle de machine learning entraîné à partir de véritables problèmes de sécurité du code trouvés dans les projets open source de GitHub. Il peut ensuite appliquer ces connaissances pour repérer des schémas dans votre propre code. Pour améliorer encore l’entraînement de ces modèles de machine learning, le moteur d’IA de Snyk Code s’appuie sur la base de données de vulnérabilités élaborée et sélectionnée par Snyk, ainsi que sur des commits de référence. Tout cela contribue à réduire considérablement les faux positifs.

Donner aux développeurs les moyens de corriger les problèmes de sécurité du code

Un fil de discussion StackOverflow, c’est le meilleur allié des développeurs, n’est-ce pas ? Je plaisante à moitié : les développeurs apprécient les exemples utiles qui montrent comment résoudre des problèmes de code. Alors, pourquoi les problèmes de sécurité devraient-ils faire exception ?

Prenons l’exemple d’un outil SAST qui signale une vulnérabilité potentielle d’injection de commande, souvent répertoriée sous le nom de CWE-78 : neutralisation incorrecte d’éléments spéciaux utilisés dans une commande du système d’exploitation (« injection de commande système »). Tout un programme, n’est-ce pas ? Les développeurs n’ont généralement pas les connaissances en sécurité nécessaires pour comprendre les CVE, les CWE, leur impact, ni même comment corriger ces problèmes tout en respectant les pratiques de codage sécurisé. C’est à cette problématique que Snyk s’est consacré.

En tant que développeur, il est tout à fait possible que vous n’ayez pas l’expertise en sécurité nécessaire pour corriger ce problème d’injection de commande à la ligne 86, qui utilise une API Node.js non sécurisée : exec(). Que faire si un rapport de sécurité vous signale ce problème ?

Voici un autre domaine dans lequel Snyk Code se distingue des outils SAST traditionnels : il vous aide à résoudre les problèmes de sécurité du code qu’il détecte. En bas à droite de la capture d’écran suivante de l’IDE IntelliJ, vous pouvez voir que, pour ce projet Node.js, Snyk Code affiche les différences de commits de plusieurs projets open source qui corrigent le problème d’injection de code signalé ici.

Grâce à ces informations, les développeurs peuvent voir comment d’autres personnes ont résolu des problèmes de sécurité similaires. Ce contexte plus complet sur le correctif suggéré leur permet de prendre une décision plus éclairée.

En résumé

En conclusion, les développeurs ont besoin d’un outil SAST capable de détecter les problèmes de sécurité dans leur code, mais aussi dans les dépendances open source qu’ils utilisent. Il doit également recommander des correctifs exploitables pour les vulnérabilités détectées. Enfin, pour être adopté, il doit être rapide, précis et intégré aux outils et aux flux de travail des développeurs. La tâche peut sembler ambitieuse, mais tout outil SAST conçu pour les développeurs doit réunir toutes ces capacités pour être efficace — et c’est exactement ce que propose Snyk Code. Consultez notre guide d’achat SAST pour vous aider à choisir l’outil SAST adapté à votre organisation.

Vous êtes arrivé jusqu’ici et vous souhaitez savoir comment les tests SAST et DAST sont liés ?

Que sont les tests SAST et DAST ?

Le SAST (test statique de sécurité des applications) est une méthode qui permet à un outil d’analyser le code source d’une application pour repérer les flux de données de la source à la destination et détecter d’éventuelles failles de sécurité ou vulnérabilités liées à ces flux. Le DAST (test dynamique de sécurité des applications), quant à lui, nécessite que l’application soit en ligne et exécutée dans un environnement adapté. Un outil peut alors observer le trafic, explorer les pages web et, de manière générale, automatiser les interactions avec l’application afin de déterminer si elle présente des failles de sécurité. Pour en savoir plus, découvrez les différences entre le SAST et le DAST et comment combiner ces deux approches.