Tests dynamiques de sécurité des applications (DAST)

Un outil DAST n’a besoin d’aucune information sur votre application, par exemple sur le langage de programmation utilisé pour la développer. Vous pouvez ainsi renforcer la sécurité de votre application même si vous utilisez des langages de programmation de niche.

En quoi le DAST diffère-t-il des autres méthodes de tests de sécurité ?

Pour déterminer si une méthode de test de sécurité convient à votre environnement de test applicatif, il est important de prendre en compte ses avantages et ses limites. Examinons les différences entre ces méthodes de test.

SAST vs DAST vs SCA

Les tests statiques de sécurité des applications (SAST) se concentrent sur le code. Ils interviennent tôt dans le pipeline CI, en analysant le code source, le bytecode ou le code binaire afin de repérer les pratiques de codage problématiques qui ne respectent pas les bonnes pratiques. Le SAST dépend du langage de programmation.

Les tests dynamiques de sécurité des applications (DAST) sont une méthode de test en boîte noire qui analyse les applications au moment de leur exécution. Ils interviennent plus tard dans le pipeline CI. Le DAST est efficace pour prévenir les régressions et ne dépend pas d’un langage de programmation spécifique.

Les tests interactifs de sécurité des applications (IAST) ressemblent au DAST, car ils s’intéressent au comportement de l’application lors de son exécution. Toutefois, l’analyse IAST repose plutôt sur une combinaison de tests en boîte noire, d’analyses et d’examens des flux internes de l’application. L’IAST permet d’associer les résultats similaires à ceux du DAST au code source, comme avec le SAST. En contrepartie, l’IAST dépend du langage de programmation et ne peut intervenir que plus tard dans le pipeline CI.

L’analyse de la composition logicielle (SCA) s’intéresse aux dépendances de code tierces utilisées dans l’application. Elle est très efficace pour les applications qui utilisent de nombreuses bibliothèques open source. Cette méthode dépend également du langage de programmation.

Pour en savoir plus, consultez SAST et DAST : quelles différences et comment les combiner ?.

Comment le DAST s’intègre-t-il aux autres méthodes de tests de sécurité des applications ?

Le DAST complète idéalement les méthodes de tests de sécurité des applications qui reposent sur des vérifications statiques, comme le SAST et la SCA, car il apporte des informations supplémentaires sur l’exécution à l’analyse statique du code source.

Souvent, les outils SAST n’examinent que des extraits de code isolés, sans tenir compte de leur contexte. Le code d’un fichier peut être considéré comme problématique, même si le code d’un autre fichier qui l’utilise corrige tous les problèmes. Les mesures de sécurité que vous avez mises en place dans votre système peuvent même s’exécuter sur un ordinateur complètement différent. Par exemple, un outil SAST signalera une entrée non assainie comme problématique, car il ne peut pas la mettre en relation avec l’assainissement effectué sur le serveur juste avant l’utilisation des données.

Les outils DAST adoptent une approche de test de bout en bout. Ils ne savent pas si le code client respecte les bonnes pratiques d’assainissement des entrées. Ils examinent les entrées et les sorties de votre application ; si la sortie est assainie, ils ne se préoccupent pas de l’endroit où l’assainissement a eu lieu dans votre architecture.

Cependant, les parties de votre application qui échouent uniquement dans des cas limites peuvent échapper à un outil DAST, car celui-ci ne couvre que des cas d’usage spécifiques, et non des entrées théoriques. C’est là que les outils SAST et SCA entrent en jeu. Ils examinent le code source et recherchent les comportements problématiques qui passeraient inaperçus avec un outil DAST seul.

Par exemple, une conversion de type peut parfois échouer ou produire des résultats indésirables. Un test DAST qui ne couvre que 10 entrées pourrait conclure que tout va bien, tandis qu’un outil SAST saurait qu’une méthode de conversion risque d’échouer pour certaines valeurs auxquelles vous n’auriez même pas pensé en développant votre application.

Avantages et inconvénients du DAST

Les outils DAST ont pour fonction principale de tester une application lors de son exécution. Cette approche présente plusieurs avantages, mais aussi des inconvénients. Examinons-les plus en détail pour vous aider à déterminer si le DAST convient à votre projet logiciel.

Avantages :

• Moins de faux positifs : Comme il n’analyse pas l’ensemble de l’application, le DAST génère généralement moins de faux positifs que le SAST. Vous pouvez ainsi vérifier plus rapidement si une vulnérabilité est réelle et déterminer s’il est possible de l’éviter par la suite.

• Indépendant du langage : Le DAST est la seule méthode de test de sécurité qui ne soit pas liée à un langage de programmation spécifique. Il n’examine ni le code source, ni le bytecode, ni le code assembleur ; il vérifie simplement les entrées et les sorties de votre système. Si votre application est développée dans un langage de programmation de niche, le DAST peut être votre seule option.

• Retest rapide des vulnérabilités corrigées : Le DAST aide à prévenir les régressions. Si une vulnérabilité est détectée et reproduite, la reproduction peut être automatisée et ajoutée à la suite de tests DAST. Chaque version ultérieure inclura ainsi les interactions qui ont entraîné des problèmes par le passé. Si ces problèmes réapparaissent, le DAST les détectera avant la mise en production.

Inconvénients :

• Aucune information sur le code : Le DAST examine uniquement les entrées et les sorties de votre système. Il est donc impossible d’associer les vulnérabilités détectées à des lignes de code.

• Processus de test plus lent : La nécessité d’exécuter et d’utiliser le logiciel peut ralentir le processus de test, même avec des méthodes de test automatisées. Parcourir un processus d’inscription en testant différentes combinaisons d’entrées prend tout simplement du temps.

• Résultats tardifs dans le pipeline CI/CD : Le DAST intervient à l’extrémité du pipeline CI/CD, car les outils DAST doivent exécuter votre application pour fonctionner. Cela peut prendre beaucoup de temps, surtout si votre application s’est développée au fil du temps.

• Des tests manuels peuvent être nécessaires : Si, pour une raison quelconque, vous ne pouvez pas automatiser l’exécution et l’utilisation de votre application, vous devrez retirer les vérifications DAST de votre pipeline CI/CD et tester l’application manuellement à chaque version.

Comment mettre en œuvre le DAST avec succès

Comme le DAST repose sur l’exécution de votre application, l’ajouter à votre pipeline de test n’est pas aussi simple que d’y intégrer le SAST. Le DAST peut être automatisé, mais il faut d’abord écrire un script ou enregistrer les étapes à automatiser. L’ajout d’un outil DAST à votre pipeline nécessite donc de suivre un processus.

1. Échangez avec vos utilisateurs

Pour commencer à mettre en œuvre le DAST, échangez avec vos utilisateurs et consignez la façon dont ils utilisent votre application. En plus de noter leurs actions, demandez-leur de vous expliquer ce qu’ils font.

Les utilisateurs oublient souvent sur quoi ils cliquent réellement dans une application : les interactions fréquentes deviennent inconscientes. Cela les aide à se concentrer sur leurs tâches, mais le fait qu’ils ne pensent pas à un élément sur lequel ils ont cliqué ne signifie pas que cela ne peut pas poser problème.

2. Automatisez les interactions des utilisateurs

L’étape suivante consiste à utiliser un outil d’automatisation pour créer un script qui reproduit les actions des utilisateurs. Cette opération peut être plus simple pour les applications CLI et API que pour les interfaces graphiques, mais elle est généralement possible dans tous les cas.

3. Ajoutez les scripts de test à votre pipeline CI/CD

Lorsque vous aurez couvert les principaux cas d’usage avec des interactions automatisées, vous pourrez exécuter ces scripts sur votre application pendant qu’un outil DAST l’analyse. Après le premier passage du DAST, vous pourrez commencer à corriger les vulnérabilités de sécurité.

4. Ajoutez des tests de régression à la suite de tests

Si vous découvrez des vulnérabilités de sécurité lors de l’utilisation quotidienne de votre application, vous pouvez ajouter des scripts correspondant aux usages concernés à votre suite de tests. Vous éviterez ainsi que ces problèmes ne réapparaissent.

Résumé

Le DAST est une méthode fiable de détection des vulnérabilités, mais il ne suffit pas à couvrir tous les risques. Il peut toutefois être la seule solution disponible, par exemple si vous utilisez un langage de programmation de niche pour développer votre application, ou des packages ou extensions à code source fermé pour un langage de programmation courant.

L’exécution d’un outil DAST peut prendre beaucoup de temps, en particulier lorsque les interactions sont complexes. Et si vous ne pouvez pas automatiser ces interactions, vous devrez les effectuer manuellement avant chaque version, ce qui peut prendre des jours, voire des semaines.

En comparant le SAST et le DAST, le SAST peut sembler être le meilleur choix dans l’ensemble, car il peut être utilisé plus tôt dans le processus de développement, lorsque la correction des problèmes de sécurité détectés est plus simple et moins coûteuse. Mais les outils DAST offrent aussi des avantages considérables.