Tests de sécurité des applications statiques (SAST)

Chaque développeur aimerait pouvoir sécuriser son code source sans avoir à y penser à chaque instant. Bien souvent, ils ne disposent pas des connaissances suffisantes pour éviter des patterns de programmation à risque ou maîtriser l’utilisation d’API sécurisées. C’est pour cette raison que les tests de sécurité des applications statiques (SAST) ont un rôle à jouer dans la gestion globale de la sécurité de vos applications. Ces tests analysent votre code source afin d’y déceler des vulnérabilités de sécurité et vous épargner ainsi cette tâche.

Les 7 étapes des tests de sécurité des applications statiques (SAST)

Comment fonctionnent les tests SAST ?

Voici les 5 points importants à connaître sur les tests de sécurité des applications statiques :

1. Ils analysent les applications de fond en comble.

2. Ils peuvent être lancés à n’importe quelle étape du cycle de développement logiciel.

3. Ils imposent souvent de créer un modèle que l’outil comprend.

4. Leur analyse repose sur une série de règles.

5. Il existe de nombreux types d’analyses, chacune se concentrant sur des domaines bien précis (voir image ci-dessous).

5 types d’analyses SAST

En quoi les tests SAST différent-ils des autres méthodes de test ?

Pour déterminer si une méthode est adaptée à votre environnement de test d’applications, vous devez étudier ses avantages et ses limites. Voyons de plus près les différences entre chacune d’entre elles.

SAST, DAST ou SCA

Les tests de sécurité des applications statiques (SAST) se concentrent sur le code. Ils interviennent au début du pipeline de CI et analysent le code source, le bytecode ou le code binaire pour identifier les patterns de codage problématiques contraires aux meilleures pratiques. Ces tests doivent être adaptés au langage de programmation utilisé.

Les tests de sécurité des applications dynamiques (DAST) constituent une méthode de test en boîte noire et analysent les applications lors de leur exécution. Ils interviennent plus tard dans le pipeline de CI. Ils sont utiles pour éviter les régressions et ne nécessitent aucune adaptation au langage de programmation utilisé.

Cliquez ici pour en savoir plus sur les différences entre SAST et DAST, et la méthode à suivre pour les combiner.

Les tests de sécurité des applications interactifs (IAST) sont similaires aux tests DAST, car ils se concentrent eux aussi sur le comportement d’une application lors de son exécution. En revanche, ils reposent sur un mélange de tests en boîte noire et d’analyse des flux internes de l’application. Leur avantage réside dans la possibilité de générer des résultats similaires à ceux des tests DAST et de les associer au code source, à la manière des tests SAST. L’inconvénient, c’est que cette approche impose d’adapter les tests IAST au langage de programmation et qu’elle ne peut être exécutée que tardivement dans le pipeline de CI.

L’analyse de la composition des logiciels (SCA) s’intéresse quant à elle aux dépendances à du code tiers. L’analyse SCA est très efficace dans les applications qui font appel à de nombreuses bibliothèques open source. Elle doit elle aussi être adaptée au langage de programmation utilisé.

Cliquez ici pour en savoir plus sur les différences entre SAST et SCA, et sur la sécurisation de vos logiciels avec ces méthodes.

Comment les tests SAST s’intègrent-ils aux autres méthodes de test de la sécurité des applications ?

Les tests SAST s’appliquent au code source. Ils analysent vos lignes de code pour y détecter des vulnérabilités. Cette approche est bien différente des tests DAST, qui ignorent totalement le code et ne s’appuient que sur les entrées et sorties de l’application en cours d’exécution. Dans la pratique, ces deux méthodes sont complémentaires. Un outil SAST peut détecter des vulnérabilités qu’un outil DAST ne repérerait pas forcément, et inversement.

Toutefois, c’est principalement leur rapidité qui les différencie. Un outil DAST impose d’exécuter et d’utiliser l’application à tester, ce qui peut prendre beaucoup de temps si elle est très complexe. A contrario, un outil SAST est capable d’analyser le code source et de l’évaluer par rapport aux meilleures pratiques pour vous indiquer comment l’améliorer.

L’idée est par conséquent d’exécuter un outil SAST au début du développement, par exemple dans l’IDE, en parallèle du codage, ou a minima au début du pipeline de CI/CD , sur vos serveurs de développement. Dans un deuxième temps, une fois que vous avez compilé un fichier binaire, vous pouvez exécuter un outil DAST. En effet, il est préférable de laisser à l’outil SAST, plus rapide, les vulnérabilités que les deux méthodes sont à même d’identifier. Toutes les failles non repérées par cette première étape pourront être signalées par la suite par votre outil DAST.

Avantages et inconvénients des tests SAST

Comme nous l’avons vu, les outils SAST sont loin d’être parfaits et doivent de préférence être utilisés en conjonction avec des outils DAST. Étudions les avantages et inconvénients de ces outils dans la pratique.

Avantages  :

• Utilisation dès le début du développement : les tests SAST vérifient que votre code source respecte les meilleures pratiques. Cela signifie que vous pouvez réaliser ces tests en parallèle de l’écriture du code. De nombreux outils SAST proposent des plug-ins pour les IDE et permettent ainsi d’intercepter les problèmes avant l’intégration du code au logiciel de gestion des versions.

• Mise en lumière des lignes de code qui posent problème : les tests SAST analysent le code source et peuvent donc vous montrer l’emplacement exact d’une faille de sécurité. La recherche et la correction des vulnérabilités sont ainsi bien plus rapides.

• Absence de cas de test : les outils DAST vous demandent ce que vous souhaitez tester. Les outils SAST appliquent directement l’ensemble de leurs règles à votre base de code. Bien souvent, ces règles sont basées sur de nombreux projets différents et des années d’expérience de programmation. Vous pouvez ainsi intercepter des vulnérabilités dont vous ignoriez même la simple possibilité. Ces règles peuvent être appliquées manuellement par le créateur de l’outil ou générées automatiquement par des algorithmes de machine learning entraînés à partir de référentiels open source connus.

• Aucune exécution de l’application nécessaire : les tests SAST analysent le code source avant même que l’application soit exécutée. Par conséquent, ce type de test est bien plus rapide que l’exécution d’une suite de tests DAST complète.

• Automatisation simplifiée : l’analyse de fichiers texte ne demande aucune interaction via une interface graphique. Les outils SAST peuvent donc être automatisés bien plus facilement que leurs équivalents DAST. Ces derniers demandent une configuration plus poussée, liée à l’exécution et l’utilisation de l’application.

Inconvénients :

• Faux positifs : les tests SAST utilisent le code source et ne prennent donc souvent pas en compte le contexte global. Ils ont ainsi tendance à détecter un nombre considérable de problèmes lors de leur première vérification. Malheureusement, ces problèmes sont généralement des faux positifs. Les tests SAST trouvent aussi des problèmes qui peuvent effectivement en être sur une ligne donnée, mais qui sont résolus un peu plus loin.

• Non prise en compte du contexte : les saisies utilisateur non nettoyées font partie de ces faux positifs. Si ces saisies posent un risque de sécurité considérable, elles sont souvent nettoyées dans le back-end. Bien souvent, le code du front-end et le code du back-end se trouve dans des référentiels différents, et les outils SAST ne peuvent donc pas avoir connaissance du nettoyage et génèrent une erreur.

• Adaptation nécessaire au langage utilisé : les tests SAST dépendent fortement du code. Si pour les langages de programmation courants, comme le Java et le C#, il existe de nombreux outils SAST sur le marché, ils sont bien plus rares pour les langages moins connus, comme ReScript et Nim.

Déployer des tests SAST en trois étapes

La configuration d’un outil SAST est très facile si elle intervient dès le début d’un projet. Elle peut en revanche devenir bien plus complexe lorsqu’un projet cumule déjà plusieurs milliers de lignes de code. Dans ce dernier cas, préparez-vous à devoir passer plusieurs jours avant de pouvoir passer aux choses sérieuses. Notez également que vos développeurs les plus expérimentés risquent de devoir consacrer du temps à vérifier les erreurs, notamment les faux positifs.

1\. Identifiez le bon outil

Tout d’abord, vous devez trouver un outil adapté à votre processus de développement et compatible avec votre langage de programmation et votre budget.

Il est important de bien faire la différence entre les outils SAST conventionnels et les outils SAST au service des développeurs.

Les tests SAST n’ont rien de neuf : il existe par conséquent des outils SAST dits conventionnels, dont l’exécution prend des heures, voire des jours. Facteur aggravant, ces outils génèrent quantité de faux positifs et sont donc évités par les développeurs.

Ces outils se retrouvaient ainsi en dehors du pipeline de CI/CD, dans un processus distinct, ce qui compliquait et ralentissait le cycle de publication de nouvelles versions. Autre problème de ces outils : la façon dont ils communiquaient aux développeurs les problèmes détectés. Bien souvent, ils se contentaient de générer une série de vulnérabilités sans indiquer concrètement comment les éliminer.

Les outils SAST de nouvelle génération au service des développeurs, comme Snyk Code, éliminent ces problèmes en se concentrant sur la vitesse. Ils peuvent même s’intégrer à votre IDE préféré et vous alerter de l’existence de problèmes de sécurité dans votre code au moment où vous l’écrivez.

Si votre workflow s’y prête, vous pouvez également exécuter un outil SAST rapide au moment du commit ou de l’intégration du code dans vos référentiels. Les outils SAST au service des développeurs génèrent également des notifications et informations concrètes concernant vos failles de sécurité pour vous aider à les résoudre.

2\. Éliminez les faux positifs

Vous devez ensuite éliminer les faux positifs. Aucun de vos développeurs ne prendra votre outil au sérieux s’ils se retrouvent face à une liste interminable d’erreurs qui n’en sont pas vraiment. En fonction de la taille de votre base de code, ce processus de nettoyage peut prendre beaucoup de temps, car un développeur expérimenté doit passer en revue chaque problème relevé par votre outil SAST afin de s’assurer qu’il ne pose pas de réel problème.

Le moteur d’IA de Snyk Code est entraîné à partir de la base de données des vulnérabilités établie manuellement par Snyk et de commits de référence Ces caractéristiques lui permettent de limiter considérablement le nombre de faux positifs.

3\. Intégrez les tests SAST dans votre pipeline de CI

L’étape suivante consiste à intégrer votre outil SAST dans le pipeline d’intégration continue. Comme nous l’avons vu, certains outils proposent de s’intégrer à votre IDE. Néanmoins, les développeurs peuvent jeter leur dévolu sur des IDE bien particuliers, et il est donc possible que l’outil choisi ne s’intègre pas au leur.

Ils peuvent aussi tout simplement oublier d’exécuter l’outil avant d’intégrer du nouveau code. C’est pour cette raison que l’intégration au pipeline de CI est très importante. Cette possibilité offre l’assurance qu’aucune ligne de code dont les failles de sécurité n’ont pas été vérifiées arrive en production.

Outils SAST au service des développeurs

La capacité des outils SAST à intercepter les problèmes de sécurité tôt dans le processus de développement signifie que même dans un contexte de délais serrés, les développeurs n’ont pas à penser constamment aux meilleures pratiques.

Gardez toutefois en tête que si l’intégration de l’outil SAST intervient tardivement dans le cycle de développement logiciel, il sera difficile de le configurer. En effet, les outils SAST conventionnels génèrent de nombreux faux positifs que les développeurs doivent vérifier. Par ailleurs, si le système repose sur un langage de programmation peu répandu, il n’existe peut-être même pas d’outil à même de vous aider à résoudre vos problèmes de sécurité. Les outils SAST au service des développeurs n’ont pas ces problèmes et proposent un processus plus fluide et efficace. Ils offrent également d’autres avantages intéressants et sont donc indispensables à toute entreprise souhaitant assurer sa sécurité.

Consultez notre guide d’achat des outils SAST pour vous aider à choisir l’outil adapté à votre entreprise.

Ne passez pas des jours et des jours à trier les faux positifs. Avec Snyk Code, un outil SAST au service des développeurs, basé sur le machine learning et disponible gratuitement pour les référentiels open source, vos développeurs pourront travailler efficacement. Vous pouvez aussi essayer notre outil de vérification du code pour vous faire rapidement une idée de la sécurité de votre code.