Test dynamique de sécurité des applications (DAST) :

Un outil DAST n’a besoin d’aucune information sur votre application, comme le langage de programmation dans lequel elle a été codée. Il permet ainsi d’améliorer la sécurité de votre application même si vous utilisez des langages de programmation peu répandus.

En quoi les tests DAST se différencient-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 statiques de sécurité des applications (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 dynamiques de sécurité des applications (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é.

Les tests interactifs de sécurité des applications (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. Elle 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 DAST, et la méthode à suivre pour les combiner.

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

Les tests DAST sont particulièrement complémentaires des méthodes de test de sécurité des applications basées sur des contrôles statiques du code source, comme les tests SAST et SCA, car ils fournissent des informations supplémentaires liées à l’exécution.

Bien souvent, les outils SAST se contentent d’analyser des extraits de code sans prendre leur contexte en compte. Le code d’un fichier peut ainsi être jugé problématique alors que du code contenu dans un autre fichier vient le compléter. Les mécanismes de sécurité que vous avez déployés sur votre système peuvent aussi s’exécuter sur un ordinateur différent. Par exemple, un outil SAST signalerait une saisie non nettoyée, car il ne saurait pas faire le lien avec le nettoyage qui intervient sur le serveur juste avant l’utilisation des données.

Les outils DAST procèdent à des tests de bout en bout. Ils ne savent pas si le code client suit les meilleures pratiques de nettoyage des saisies. Ils se contentent de regarder l’entrée et la sortie de l’application. Si la sortie est nettoyée, ils n’ont pas besoin de savoir où le nettoyage a eu lieu dans votre architecture.

En revanche, les parties de votre application qui ne génèrent des erreurs que dans de rares cas peuvent ne pas être relevées par un outil DAST, car il ne couvre que des cas d’utilisation précis, et non pas des saisies théoriques. C’est précisément sur ce point que les outils SAST et SCA ont un rôle à jouer. Ces outils analysent le code source à la recherche de comportements problématiques qu’un outil DAST ne saurait détecter.

Par exemple, une conversion de type peut échouer ou générer une sortie inappropriée. Un test DAST couvrant uniquement 10 saisies pourrait indiquer que tout va bien, mais un outil SAST saurait qu’une méthode de conversion peut échouer avec certaines valeurs que vous n’avez même pas pensé à implémenter dans votre application.

Avantages et inconvénients des tests DAST

La nature même des outils DAST, dont la principale fonction est de tester une application lors de son exécution, offre un certain nombre d’avantages, mais présente aussi quelques inconvénients. Étudions-les plus en détail pour déterminer si ces outils conviendraient à votre projet de logiciel.

Avantages  :

• Moins de faux positifs : un outil DAST n’analyse pas toute l’application et va donc normalement générer moins de faux positifs qu’un outil SAST. Vous pouvez ainsi déterminer bien plus rapidement si une vulnérabilité signalée est réelle et si elle peut être évitée.

• Aucun lien avec le langage de programmation : les tests DAST sont les seuls tests de sécurité non spécifiques au langage de programmation utilisé. Ils n’analysent pas le code source, le bytecode ou le code assembleur, mais se contentent de vérifier les entrées et sorties de votre système. Si votre application utilise un langage de programmation peu répandu, les tests DAST peuvent constituer votre seule option.

• Nouvelle vérification rapide des vulnérabilités corrigées : les tests DAST aident à éviter les régressions. Lorsqu’une vulnérabilité de sécurité est détectée et reproduite, il devient possible d’automatiser ce processus et de l’ajouter à la suite des tests DAST. Ainsi, chaque nouveau test inclura les interactions ayant abouti aux problèmes détectés précédemment. Si ces problèmes refont surface pour une raison ou pour une autre, ils seront repérés et n’arriveront donc pas en production.

Inconvénients :

• Aucune information sur le code : les tests DAST n’analysent que les entrées et sorties de votre système. Il est ainsi impossible de faire le lien entre les vulnérabilités détectées et des lignes de code en particulier.

• Lenteur : étant donné que vous devez exécuter et utiliser le logiciel, les tests sont plus longs, même avec des méthodes automatisées. Enchaîner les clics au cours d’un processus d’inscription avec plusieurs combinaisons d’entrées prend du temps.

• Résultats tardifs dans le pipeline de CI/CD : les tests DAST interviennent en toute fin du pipeline de CI/CD, car ils nécessitent l’exécution de votre application. Ce processus peut donc devenir très chronophage, en particulier si votre application prend de l’importance.

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

Réussir le déploiement des tests DAST

Les tests DAST reposant sur l’exécution de votre application, leur ajout à votre pipeline de test n’est pas aussi simple que pour les tests SAST. Certes, il est possible de les automatiser, mais la partie automatisée devra d’abord être scriptée ou enregistrée. Autrement dit, il y a un processus à suivre après l’ajout d’un outil DAST à votre pipeline.

1\. Concertez-vous avec vos utilisateurs

Avant de lancer l’implémentation de vos tests DAST, allez à la rencontre de vos utilisateurs et notez comment ils utilisent l’application. Demandez-leur non seulement de lister leurs actions, mais aussi de les expliquer.

Ils ont tendance à oublier sur quels éléments de l’application ils cliquent vraiment : les interactions fréquentes finissent souvent par devenir inconscientes. Si ce phénomène aide les utilisateurs à se concentrer sur leurs tâches, un point non mentionné ne veut pas dire qu’il ne pose pas problème.

2\. Automatisez les interactions des utilisateurs

L’étape suivante consiste à employer un outil d’automatisation pour créer un script reprenant les actions de l’utilisateur. Le processus est généralement plus simple dans le cas d’une CLI ou d’une API que pour une interface graphique, mais il est possible dans tous ces cas.

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

Une fois que vous avez fini d’automatiser les interactions correspondant aux cas d’utilisation les plus importants, vous pouvez exécuter ces scripts avec votre application pendant que l’outil DAST analyse celle-ci. Après la première exécution, vous pouvez commencer à corriger vos vulnérabilités de sécurité.

4\. Complétez votre arsenal avec des tests de régression

Si vous repérez des vulnérabilités de sécurité dans l’utilisation qui est faite de votre application au quotidien, vous pouvez ajouter des scripts dédiés à ces utilisations spécifiques à votre suite de tests. Ainsi, vous aurez la certitude que ces problèmes ne réapparaîtront pas.

En résumé

Si les outils DAST offrent un moyen fiable de détecter les vulnérabilités, ils ne suffisent pas. Pour autant, ils peuvent constituer votre seule option, si vous utilisez par exemple un langage de programmation peu répandu pour votre application ou vos packages en source fermée, ou encore des extensions d’un langage de programmation courant.

L’exécution d’un outil DAST peut prendre beaucoup de temps, en particulier pour les interactions complexes. Si vous ne parvenez pas à automatiser ces interactions, vous devrez les exécuter manuellement avant chaque nouvelle version, ce qui risque de demander des jours, voire des semaines.

La comparaison des tests SAST et DAST semble profiter aux tests SAST, car ils peuvent être utilisés plus tôt dans le processus de développement quand la correction des problèmes de sécurité est plus facile et moins coûteuse. Pour autant, les outils DAST ont aussi des avantages non négligeables.