TL;DR
- Le SAST analyse le code sans exécuter l’application.
- Le DAST teste une application en fonctionnement depuis l’extérieur.
- Le SAST permet de détecter certains problèmes tôt dans le développement.
- Le DAST permet d’observer le comportement réel de l’application.
- Les deux méthodes ont leurs limites et peuvent produire des faux positifs.
- Une stratégie complète combine souvent SAST, DAST, révision manuelle du code et tests de pénétration.
- Dans une démarche DevSecOps, ces contrôles peuvent être intégrés à différentes étapes du développement.
Lorsque des développeurs souhaitent améliorer la sécurité d’une application Web, deux méthodes reviennent souvent : SAST et DAST.
Le SAST, pour Static Application Security Testing, correspond à une analyse statique de la sécurité des applications. Il examine le code sans exécuter l’application.
Le DAST, pour Dynamic Application Security Testing, correspond à un test dynamique de sécurité des applications. Il analyse une application pendant son fonctionnement, depuis l’extérieur.
La question n’est donc pas nécessairement de choisir entre SAST et DAST, mais plutôt de comprendre quand utiliser chaque méthode et ce qu’elle permet de détecter.
SAST vs DAST : comparaison rapide
Comparaison SAST vs DAST : le SAST analyse le code source sans exécuter l’application, tandis que le DAST teste une application Web en fonctionnement.
La principale différence entre SAST vs DAST tient donc au moment et au point de vue de l’analyse.
Qu’est-ce que le SAST?
SAST signifie Static Application Security Testing, ou analyse statique de la sécurité des applications.
Le principe est relativement simple : analyser le code sans avoir besoin d’exécuter l’application.
Un outil SAST peut examiner :
- le code source;
- certains fichiers compilés;
- les flux de données;
- les appels de fonctions;
- certaines configurations;
- des modèles de programmation susceptibles de créer des vulnérabilités.
L’objectif est d’identifier des faiblesses directement dans la logique ou la structure du logiciel.
Le NIST recommande plus largement d’intégrer des pratiques de développement sécurisé aux différentes étapes du cycle de développement logiciel plutôt que de traiter la sécurité uniquement après la création du produit.
À quel moment utiliser le SAST?
L’un des avantages du static application security testing est qu’il peut être utilisé relativement tôt.
Un développeur peut analyser son code :
- pendant le développement;
- avant une fusion de code;
- pendant une demande de fusion;
- dans un pipeline d’intégration continue;
- avant une nouvelle version.
Cette approche permet de repérer certains problèmes avant que l’application soit déployée.
Dans un environnement DevSecOps, cela peut notamment permettre d’intégrer des contrôles de sécurité directement aux pratiques de développement.
Quels problèmes le SAST peut-il détecter?
Les capacités précises varient selon l’outil et le langage utilisé, mais une analyse statique peut notamment aider à repérer :
- certaines validations insuffisantes des entrées;
- des fonctions dangereuses;
- des problèmes de gestion des données;
- certains défauts liés à l’authentification;
- des secrets ou renseignements sensibles présents dans le code;
- des pratiques de programmation pouvant créer des vulnérabilités.
L’un de ses principaux avantages est sa capacité à indiquer parfois l’endroit précis du code concerné.
Pour un développeur, il est beaucoup plus utile de recevoir :
« vérifiez cette fonction dans ce fichier »
que simplement :
« votre application présente un problème quelque part ».
Quelles sont les limites du SAST?
Le SAST ne voit pas tout.
Comme l’application n’est pas exécutée, l’outil ne peut pas nécessairement observer la façon dont elle se comporte dans son environnement réel.
Certaines vulnérabilités dépendent par exemple :
- de la configuration du serveur;
- des interactions entre plusieurs services;
- de l’état de l’application;
- de l’authentification;
- de la logique métier;
- de comportements qui apparaissent uniquement à l’exécution.
Une analyse statique peut également produire des faux positifs.
Un outil peut considérer qu’un morceau de code présente un risque alors que, dans son contexte réel, des mécanismes supplémentaires rendent l’exploitation impossible.
Les résultats doivent donc être examinés et priorisés.
Qu’est-ce que le DAST?
DAST signifie Dynamic Application Security Testing, ou test dynamique de sécurité des applications.
Contrairement au SAST, le dynamic application security testing analyse une application pendant qu’elle fonctionne.
L’outil interagit avec l’application depuis l’extérieur, un peu comme pourrait le faire un utilisateur ou un attaquant.
Il peut notamment :
- envoyer des requêtes;
- modifier certains paramètres;
- analyser les réponses du serveur;
- tester des formulaires;
- explorer différentes pages;
- vérifier certains comportements inattendus.
L’outil ne cherche pas nécessairement à comprendre comment le code a été écrit.
Il observe plutôt :
Que se passe-t-il lorsque l’application reçoit telle ou telle requête?
À quel moment utiliser le DAST?
Comme l’application doit fonctionner, le DAST intervient généralement plus tard que le SAST.
Il peut être utilisé :
- dans un environnement de test;
- dans un environnement de préproduction;
- sur une version déployée spécifiquement pour les tests;
- dans certains cas, sur une application en production lorsque les tests sont strictement contrôlés.
L’objectif est d’observer la sécurité de l’application telle qu’elle se comporte réellement.
Quels problèmes le DAST peut-il repérer?
Selon les capacités de l’outil, un test dynamique peut contribuer à repérer certaines vulnérabilités liées notamment :
- aux entrées utilisateur;
- aux mécanismes d’authentification;
- aux sessions;
- aux réponses du serveur;
- aux configurations de sécurité;
- à certaines vulnérabilités Web exploitables.
L’intérêt du DAST est qu’il vérifie le comportement réel d’une application en fonctionnement.
Par exemple, un développeur peut avoir écrit un code qui semble correct lorsqu’il est analysé isolément, mais une mauvaise interaction entre le serveur Web, l’application et sa configuration peut introduire un problème observable uniquement après le déploiement.
Quelles sont les limites du DAST?
Le DAST possède lui aussi des angles morts.
Comme l’outil observe principalement l’application depuis l’extérieur, il ne sait pas toujours où se situe précisément le problème dans le code.
Il peut détecter une vulnérabilité sans pouvoir indiquer exactement quelle fonction ou quelle ligne doit être modifiée.
Sa couverture dépend également de sa capacité à explorer l’application.
Si une partie de l’application n’est jamais atteinte pendant le test, elle risque de ne pas être analysée.
Cela peut poser problème avec :
- les applications complexes;
- les fonctions accessibles uniquement après authentification;
- les parcours utilisateurs particuliers;
- certaines interfaces de programmation;
- des fonctions rarement utilisées.
Comme le SAST, le DAST peut aussi générer des faux positifs ou manquer certaines vulnérabilités.
SAST vs DAST : pourquoi les deux approches sont complémentaires
Il peut être tentant de chercher à déterminer lequel est « meilleur ».
Ce n’est généralement pas la question la plus utile.
Le SAST et le DAST examinent deux aspects différents d’une même application.
On peut simplifier ainsi :
SAST demande :
« Y a-t-il quelque chose de dangereux dans le code? »
DAST demande :
« Est-ce que je peux provoquer un comportement dangereux lorsque l’application fonctionne? »
Une faiblesse peut être repérée par les deux méthodes.
Une autre peut n’être visible que par l’une d’elles.
C’est pourquoi une stratégie de sécurité applicative repose généralement sur plusieurs couches de contrôle plutôt que sur un seul outil.
Le Secure Software Development Framework du NIST suit cette même logique générale : la sécurité doit être intégrée à l’ensemble du cycle de développement et reposer sur plusieurs pratiques complémentaires.
Exemple pratique : une équipe Web québécoise développe une nouvelle application
Imaginons une équipe de développement à Montréal qui prépare une plateforme permettant à des clients de créer un compte et de consulter des documents.
Étape 1 : développement
Pendant que les développeurs écrivent le code, une analyse SAST est exécutée automatiquement.
L’outil signale qu’une fonction traite certaines entrées utilisateur de manière potentiellement dangereuse.
Le développeur vérifie le résultat et modifie le code avant de poursuivre.
Étape 2 : révision du code
Un autre membre de l’équipe effectue une révision manuelle.
Il remarque un problème de logique que l’analyse automatisée n’avait pas détecté.
Le code est corrigé.
Étape 3 : environnement de test
L’application est ensuite déployée dans un environnement de test.
Une analyse DAST est lancée.
Elle détecte qu’une fonction de l’application répond d’une façon inattendue à certaines requêtes.
L’équipe analyse le comportement et corrige la configuration concernée.
Étape 4 : test de pénétration
Avant une mise en production importante, l’organisation peut également demander un test de pénétration.
Un spécialiste tente alors d’exploiter les fonctions de l’application en utilisant plusieurs méthodes, notamment des techniques qui demandent du raisonnement humain et une compréhension de la logique métier.
Cette combinaison donne donc :
SAST + révision manuelle + DAST + test de pénétration
Chaque méthode observe l’application sous un angle différent.
Le SAST et le DAST remplacent-ils un test de pénétration?
Non.
Les tests automatisés sont particulièrement utiles pour analyser régulièrement une application, mais ils ne reproduisent pas entièrement le travail d’un professionnel en sécurité.
Un test de pénétration peut inclure :
- une exploration manuelle;
- l’enchaînement de plusieurs vulnérabilités;
- l’analyse de la logique métier;
- des scénarios adaptés au fonctionnement précis de l’application;
- l’évaluation de l’impact potentiel d’une vulnérabilité.
Un outil automatique peut repérer qu’un paramètre semble vulnérable.
Un professionnel peut parfois aller plus loin et déterminer ce qu’un attaquant pourrait réellement faire avec cette faiblesse.
Ces contrôles sont donc complémentaires.
Qu’en est-il des faux positifs?
Les faux positifs constituent une réalité importante de l’application security testing.
Un faux positif se produit lorsqu’un outil signale une vulnérabilité potentielle qui n’est finalement pas exploitable dans le contexte réel.
Plus une équipe automatise ses analyses, plus elle doit également mettre en place un processus permettant de :
- valider les résultats;
- éliminer les alertes non pertinentes;
- évaluer la gravité des vulnérabilités;
- déterminer lesquelles doivent être corrigées en priorité.
Sans cette étape, les équipes risquent de recevoir tellement d’alertes qu’elles finissent par ne plus savoir lesquelles sont importantes.
Le nombre de résultats détectés n’est donc pas nécessairement un bon indicateur de maturité en sécurité.
La capacité à comprendre et à corriger les vulnérabilités importantes l’est davantage.
Comment intégrer SAST et DAST dans une approche DevSecOps?
Le DevSecOps vise notamment à mieux intégrer la sécurité aux processus de développement plutôt qu’à l’ajouter uniquement à la fin.
Le SAST se prête particulièrement bien aux contrôles effectués tôt et fréquemment.
Une équipe peut par exemple déclencher automatiquement une analyse lorsqu’un développeur soumet du nouveau code.
Le DAST intervient lorsqu’une version fonctionnelle de l’application est disponible.
Un pipeline simplifié pourrait ainsi ressembler à ceci :
Développement → SAST → révision → construction → déploiement en test → DAST → validation → mise en production
Les organisations n’ont toutefois pas besoin d’automatiser tout leur processus immédiatement.
Une petite équipe Web québécoise peut commencer par intégrer quelques contrôles importants et les améliorer progressivement.
Pour approfondir cette approche, consultez notre article sur le DevSecOps au Québec.
Une équipe DevSecOps compare les résultats de tests SAST vs DAST afin d’identifier différentes vulnérabilités et de renforcer la sécurité d’une application Web.
Quel test faut-il utiliser en premier?
Si l’équipe possède accès au code source et souhaite détecter des problèmes le plus tôt possible, le SAST constitue généralement un bon point de départ.
Le DAST devient particulièrement pertinent lorsqu’une version fonctionnelle de l’application peut être testée.
Une séquence logique peut donc être :
- analyser le code;
- corriger les problèmes pertinents;
- déployer l’application dans un environnement contrôlé;
- tester son comportement;
- vérifier manuellement les résultats importants.
Cette approche permet de détecter certains problèmes avant qu’ils deviennent plus difficiles ou coûteux à corriger.
SAST et DAST ne couvrent pas tous les risques
Même combinées, ces deux méthodes ne représentent qu’une partie de la sécurité des applications.
Une organisation doit également tenir compte de plusieurs autres éléments, notamment :
- la conception sécurisée;
- la gestion des dépendances;
- les bibliothèques tierces;
- les secrets et identifiants;
- les configurations;
- les autorisations;
- la sécurité des interfaces de programmation;
- les pratiques de développement;
- les tests manuels.
Le NIST souligne d’ailleurs que les pratiques de développement sécurisé doivent être intégrées aux processus existants tout au long du cycle de développement logiciel.
Pour aller plus loin, consultez également notre guide sur la façon de renforcer la sécurité des applications Web.
Développez vos compétences en sécurité applicative
Comprendre la différence entre SAST et DAST permet de choisir les bons contrôles aux différentes étapes du développement.
La sécurité applicative demande toutefois aussi des compétences en développement sécurisé, analyse des vulnérabilités, tests, gestion des configurations et DevSecOps.
Développez des compétences pratiques en développement sécurisé, tests d’applications et DevSecOps grâce à l’AEC Sécurité des applications Web du Collège Cumberland.
FAQ
Quelle est la différence entre SAST et DAST?
Le SAST analyse le code d’une application sans l’exécuter, tandis que le DAST analyse le comportement d’une application en fonctionnement depuis l’extérieur. Le SAST est généralement utilisé plus tôt dans le développement, alors que le DAST nécessite une application pouvant être exécutée.
Qu’est-ce que le SAST?
Le Static Application Security Testing est une méthode d’analyse statique utilisée pour identifier certaines faiblesses dans le code d’une application. Elle peut notamment être intégrée aux outils de développement et aux processus d’intégration continue.
Qu’est-ce que le DAST?
Le Dynamic Application Security Testing consiste à analyser une application pendant son exécution. L’outil envoie des requêtes et étudie les réponses afin de détecter certains comportements ou vulnérabilités observables depuis l’extérieur.
SAST ou DAST : lequel est le plus efficace?
Ils répondent à des besoins différents. Le SAST permet notamment de détecter certains problèmes directement dans le code, tandis que le DAST observe le comportement réel de l’application. Les utiliser ensemble offre généralement une couverture plus complète que l’utilisation d’une seule méthode.
Peut-on automatiser les tests SAST et DAST?
Oui. Les outils SAST peuvent notamment être exécutés lors de modifications du code ou dans un pipeline d’intégration continue. Les outils DAST peuvent être lancés automatiquement lorsqu’une version de l’application est déployée dans un environnement de test.
SAST et DAST font-ils partie du DevSecOps?
Ils peuvent faire partie d’une démarche DevSecOps lorsqu’ils sont intégrés aux processus de développement et de déploiement. Le DevSecOps ne se limite toutefois pas à ces deux types de tests : il comprend plus largement l’intégration de pratiques de sécurité tout au long du cycle de développement.
