5 conseils pour choisir le bon outil DAST

Il est essentiel de protéger vos applications web et vos API contre les menaces, et un outil de test dynamique de la sécurité des applications (DAST) joue un rôle central dans cette démarche. Cet article présente les caractéristiques clés d’un outil DAST moderne, en particulier à mesure que les équipes de développement utilisent davantage les assistants de programmation basés sur l’IA. Nous aborderons les difficultés que vous pourriez rencontrer lors de sa mise en œuvre et les moyens de faire évoluer vos tests de sécurité au rythme de l’innovation.

En nous appuyant sur les fonctionnalités avancées et simplifiées de Snyk API & Web, nous allons examiner les éléments fondamentaux d’une mise en œuvre DAST réussie : découverte des actifs, réalisation de tests de sécurité efficaces, gestion efficiente des résultats et intégration des fonctionnalités à votre pipeline de développement. 

1. Découverte des actifs

Les organisations sont exposées aux cyberattaques malveillantes par l’intermédiaire des actifs accessibles depuis leur surface d’attaque. Il est donc fondamental de comprendre cette surface et de prendre des mesures efficaces pour la protéger. C’est d’autant plus important que les outils d’IA peuvent accélérer la création de microservices et d’API, parfois plus vite que les équipes de sécurité ne peuvent les suivre.

Connaître la surface d’attaque

Un outil DAST doté de fonctions de découverte des actifs est essentiel pour établir l’inventaire des actifs de votre organisation et comprendre sa surface d’attaque. Comme les menaces évoluent constamment, l’outil DAST doit aussi pouvoir tenir cet inventaire à jour en découvrant régulièrement de nouveaux actifs.

Analyser la surface d’attaque

L’outil DAST doit proposer toutes les fonctionnalités nécessaires pour faciliter l’analyse des actifs découverts et identifier les plus critiques afin de les hiérarchiser. Il peut, par exemple, fournir un score de risque préliminaire pour évaluer la criticité d’un actif, des captures d’écran pour faciliter son identification ou des adresses IP pour savoir où les actifs sont accessibles.

Intégration fluide aux analyses de sécurité

Après avoir déterminé quels actifs sont les plus critiques sur votre surface d’attaque, vous voudrez les tester afin d’identifier en détail les vulnérabilités et de les protéger efficacement. Il est donc important de rechercher un outil DAST qui intègre parfaitement la découverte des actifs aux analyses de sécurité. 

2. Cibles des analyses de sécurité

Une cible est un élément que vous souhaitez analyser pour identifier des vulnérabilités. Que vous utilisiez comme cibles des actifs issus de la découverte ou que vous en créiez vous-même, l’outil DAST doit prendre en charge différents types de cibles et proposer tous les moyens nécessaires pour les configurer afin d’obtenir les meilleurs résultats d’analyse de sécurité. Voici les aspects à prendre en compte pour choisir votre outil DAST.

Types de cibles

Un outil DAST doit, au minimum, prendre en charge les types de cibles suivants :

Cibles web

Un outil DAST doit prendre en charge les types d’applications web les plus courants exécutés dans un navigateur :

• Modernes Applications monopages (SPA) : ces applications offrent une excellente expérience utilisateur, car elles s’appuient souvent largement sur le rendu côté client et sur une API dorsale. L’outil DAST doit pouvoir analyser l’application côté client ainsi que l’API dorsale, même si celle-ci se trouve sur un autre hôte.

• Applications web traditionnelles : ces applications exécutent la majeure partie de leur logique côté serveur. Chaque page est donc générée à la suite d’une réponse du serveur à une requête HTTP, ce qui ralentit légèrement la réaction aux interactions utilisateur. Il s’agit du type de cible de base que tout outil DAST doit pouvoir analyser.

Cibles API 

Choisissez un outil DAST prenant en charge les API décrites dans les formats de spécification les plus courants :

• OpenAPI : cette spécification d’API standard permet aux outils de générer du code, de la documentation, des cas de test et bien plus encore. L’outil DAST doit pouvoir utiliser ce format standard pour déterminer les points de terminaison de l’API à analyser. Pour vérifier la validité de vos spécifications OpenAPI, essayez Swagger Editor.

• Collection Postman : il s’agit d’un moyen d’accéder à une API à l’aide d’une collection prédéfinie de requêtes destinées à ses points de terminaison, avec Postman, et de tirer parti des scripts de prérequête et des tests pour définir des variables d’environnement et manipuler des données. L’outil DAST doit pouvoir exploiter ces collections et exécuter leurs requêtes pour analyser les points de terminaison de l’API. Il est essentiel que la collection Postman contienne une séquence de requêtes fonctionnelle vers les points de terminaison de l’API, qui puisse être appelée plusieurs fois. 

Cibles avec authentification

Une cible avec authentification comporte des zones accessibles uniquement aux utilisateurs authentifiés. L’outil DAST doit permettre de configurer l’authentification pour se connecter et accéder à ces zones réservées. Vérifiez la prise en charge des fonctionnalités d’authentification suivantes :

• Formulaire de connexion : lorsque la cible comporte un formulaire de connexion, l’outil DAST doit permettre d’identifier la page de connexion et de configurer les identifiants nécessaires pour se connecter.

• Connexions complexes : lorsque la cible comporte des parcours de connexion complexes (par exemple, en plusieurs étapes), l’outil DAST doit permettre de configurer la séquence d’étapes et les valeurs à saisir pour se connecter.

• En-têtes et cookies d’authentification personnalisés : cette fonctionnalité est également intéressante dans un outil DAST, car elle permet de prendre en charge des scénarios d’authentification encore plus variés, par exemple lorsque le processus repose sur un e-mail contenant un lien de connexion envoyé à l’utilisateur. 

• Connexion avec authentification à deux facteurs : lorsque la cible exige une authentification à deux facteurs (2FA), l’outil DAST doit permettre de la configurer, en plus des deux fonctionnalités d’authentification mentionnées précédemment.

• Détection de déconnexion : certaines cibles peuvent vous déconnecter automatiquement (par exemple, à l’expiration d’une session). L’outil DAST doit permettre de configurer et de détecter ces situations, puis de se reconnecter afin que les analyses continuent d’accéder aux zones réservées aux utilisateurs authentifiés.

Ajuster la couverture des cibles

Les cibles peuvent être complexes et nécessiter des configurations spécifiques pour affiner la couverture et analyser efficacement les éléments souhaités. L’outil DAST doit donc proposer des fonctionnalités permettant d’ajuster les analyses afin d’atteindre les zones attendues dans le périmètre de la cible :

• Ajouter l’accès aux zones « masquées » : il arrive que l’exploration de la cible ne suffise pas à accéder à certaines zones de son périmètre. Par exemple, une cible comme https://example.com peut comporter une zone accessible uniquement par un lien direct, tel que https://example.com/back-office. Dans ce cas, l’outil DAST doit permettre d’ajouter ces zones « masquées » au périmètre de la cible.

• Restreindre l’accès aux zones critiques : si la cible comporte des zones sensibles à exclure des tests de sécurité (par exemple, des pages avec des formulaires qui envoient des e-mails aux utilisateurs), l’outil DAST doit permettre de les configurer et de les exclure du périmètre de la cible.

• Ajouter l’accès à d’autres hôtes : certaines cibles s’appuient sur des fonctionnalités de services hébergés sur d’autres hôtes. Par exemple, la cible https://example.com peut envoyer des requêtes à une API située sur un autre hôte, comme https://api.example.com. L’outil DAST doit permettre d’étendre le périmètre de la cible à d’autres hôtes.

Parcours personnalisés pour les cibles complexes

Lorsque la cible comporte des parcours complexes ou exige des valeurs spécifiques (comme des formulaires avec des combinaisons de valeurs interdépendantes), l’outil DAST doit permettre de créer et d’exécuter des séquences de navigation personnalisées. Vous pourrez ainsi suivre les parcours prévus et accéder à davantage de zones de la cible.

En-têtes et cookies personnalisés pour des comportements spécifiques

Un outil DAST permettant de définir des informations spécifiques dans les en-têtes ou les cookies peut être essentiel pour identifier les requêtes DAST. Cette fonctionnalité peut avoir plusieurs usages, par exemple :

• Un pare-feu bloque les requêtes DAST vers la cible en raison de l’agent utilisateur. Vous pouvez débloquer les requêtes en définissant un « User-Agent » personnalisé dans l’en-tête et en configurant le pare-feu en conséquence.

• La cible dispose d’un contrôle « humain » (comme un CAPTCHA) qui bloque les requêtes DAST. En envoyant des informations personnalisées dans un cookie, vous pouvez configurer la logique de la cible pour désactiver ce contrôle et permettre à l’analyse de sécurité de se poursuivre.

Accéder aux cibles bloquées par des WAF

Si vous utilisez un pare-feu applicatif (WAF) devant votre cible, celui-ci peut interpréter les requêtes de l’outil DAST comme des attaques malveillantes. Les requêtes risquent alors d’être bloquées et l’analyse de la cible peut échouer avant d’être terminée. Pour éviter cela, l’outil DAST doit vous fournir ses adresses IP afin que vous puissiez les ajouter à la liste d’autorisation du WAF et débloquer les analyses.

Cibles situées sur des réseaux privés inaccessibles

Certaines cibles ne sont pas publiques et se trouvent sur des réseaux privés, ce qui les rend inaccessibles depuis l’extérieur. L’outil DAST doit proposer des fonctionnalités permettant de configurer l’accès à ces cibles privées.

3. Analyse des cibles

Une fois la cible définie, l’outil DAST doit l’explorer afin de parcourir toutes les zones accessibles et de couvrir la plus grande partie possible de son périmètre. Il doit ensuite effectuer des tests de sécurité approfondis dans ces zones pour détecter le plus grand nombre de vulnérabilités.

Couverture de l’analyse

Un rapport détaillé sur la couverture de l’analyse est indispensable pour vous assurer que l’ensemble de la cible est pris en compte. Un excellent rapport doit vous permettre de repérer facilement si l’analyse atteint les zones attendues. Cela suppose bien sûr que vous connaissiez en détail votre cible et toutes les zones à couvrir, afin d’obtenir des informations utiles et de tirer le meilleur parti du rapport de couverture.

Vulnérabilités testées

Il est essentiel que l’outil DAST dispose d’une excellente liste de vulnérabilités à tester et qu’il la mette régulièrement à jour pour détecter les vulnérabilités les plus récentes. Votre outil DAST doit vous donner accès à cette liste et vous indiquer la fréquence de ses mises à jour, afin que vous puissiez vérifier qu’elle répond à vos exigences de sécurité. Cela concerne aussi bien les vulnérabilités traditionnelles que les nouveaux types de failles logiques susceptibles d’être introduites par du code généré par l’IA.

Analyse de technologies spécifiques

Un outil DAST qui détecte les technologies utilisées par les cibles (par exemple, PHP, React ou Linux) fournit des informations précieuses pour les analyses de sécurité. Il permet d’affiner les tests en fonction de ces technologies et d’obtenir de meilleurs résultats. Certains outils DAST permettent même de configurer à l’avance les technologies utilisées par les cibles pour s’assurer qu’elles sont prises en compte. 

Analyses planifiées

Exécuter des analyses à intervalles réguliers est important pour maintenir à jour la liste des vulnérabilités détectées sur vos cibles. La planification des analyses est donc une fonctionnalité très utile d’un outil DAST : elle automatise ces opérations sans intervention manuelle de votre part.

Mettre les analyses en pause et les reprendre

La possibilité de mettre les analyses en pause et de les reprendre est une fonctionnalité DAST à prendre en compte, car elle permet de gérer les situations critiques. Par exemple, si vous constatez qu’une analyse perturbe le fonctionnement normal d’une application, vous pouvez simplement la mettre en pause et la reprendre à un moment plus opportun.

C’est encore mieux si l’outil DAST prend en charge les périodes d’interruption. Il peut alors mettre automatiquement les analyses en pause pendant des périodes définies (par exemple, les heures de travail), puis les reprendre automatiquement lors de périodes « sûres » (par exemple, la nuit).

Analyses partielles

Les analyses couvrent généralement l’ensemble du périmètre de la cible. Elles peuvent donc prendre du temps, tout comme l’obtention des résultats. Dans certains cas, après une première analyse complète, il n’est pas nécessaire de réanalyser toute la cible. Il peut alors être utile de limiter les analyses aux zones qui vous intéressent. On parle d’analyses partielles. Si votre outil DAST les permet, vous devriez pouvoir les configurer comme suit :

• Périmètre réduit : les analyses couvrent uniquement les zones de la cible que vous avez définies comme importantes à réanalyser.

• Incrémentielles : les analyses couvrent uniquement les éléments nouveaux et/ou mis à jour dans une cible.

Profils d’analyse personnalisés

Les profils d’analyse personnalisés sont importants pour ajuster précisément le comportement des analyses dans un outil DAST. Voici quelques exemples d’utilisation courante de ces profils lorsque vous souhaitez :

• Vous concentrer sur les vulnérabilités critiques : vous définissez un profil d’analyse personnalisé qui vise uniquement à détecter les vulnérabilités les plus critiques, c’est-à-dire les plus urgentes à corriger.

• Privilégier la rapidité : si vos cibles peuvent gérer un grand nombre de requêtes, vous pouvez créer un profil personnalisé qui lance des analyses en envoyant davantage de requêtes en parallèle. Vous obtenez ainsi des résultats plus rapidement. 

Effectuer des analyses non intrusives : pour les cibles sur lesquelles vous souhaitez éviter toute opération destructive, vous pouvez créer un profil personnalisé qui exclut les requêtes destructives, telles que les requêtes DELETE.

4. Résultats des analyses

À mesure que vous analysez vos cibles, les vulnérabilités détectées doivent être rassemblées dans des résultats qui contiennent toutes les informations nécessaires pour savoir où vos cibles doivent être protégées et comment les sécuriser. Votre outil DAST doit fournir ces informations précieuses ainsi que toutes les fonctionnalités nécessaires pour faciliter le traitement et la gestion des résultats.

Précision des résultats

C’est l’un des facteurs les plus importants concernant les résultats. Si les vulnérabilités détectées ne sont pas fiables, les utilisateurs risquent de perdre confiance dans l’outil DAST et de le discréditer. Vous devez vous assurer que l’outil fournit des résultats précis, notamment :

• Un faible taux de faux positifs : si l’outil DAST identifie à tort une activité normale ou bénigne comme une vulnérabilité, il génère un faux positif. Un taux élevé de faux positifs peut vous faire perdre, à vous et à votre organisation, beaucoup de temps à enquêter sur des « problèmes » qui ne constituent pas de véritables menaces et à les traiter, tout en discréditant l’outil.

• Un faible nombre de faux négatifs : cela se produit lorsque l’outil DAST ne détecte pas des vulnérabilités réelles dont vous savez qu’elles existent. Essayez de comparer les résultats obtenus sur une cible réelle dont vous connaissez les vulnérabilités. Évitez les cibles de test courantes ou présentant de fausses vulnérabilités (par exemple, à des fins pédagogiques), car les résultats risquent de ne pas être fiables. 

• Une détection cohérente : l’outil DAST doit fournir des résultats cohérents et les mettre à jour lors des analyses suivantes tant que les vulnérabilités n’ont pas été corrigées. À l’inverse, il doit cesser de signaler une vulnérabilité une fois celle-ci corrigée.

Des informations utiles et pertinentes dans les résultats

Lors de l’analyse des résultats, l’outil DAST doit vous fournir autant d’informations pertinentes et utiles que possible. C’est la seule façon de prendre des décisions éclairées sur chaque résultat et de mettre en œuvre des mesures efficaces pour protéger vos cibles. 

Voici quelques informations utiles à inclure dans vos résultats :

• La description de la vulnérabilité.

• L’endroit où elle a été détectée sur la cible.

• Le point d’injection vulnérable.

• Le risque et le score CVSS associés au résultat.

• Les éléments qui prouvent la présence de la vulnérabilité. 

• Les détails des requêtes exécutées et des réponses reçues.

• Des informations sur la manière de corriger la vulnérabilité.

Partager les résultats

Il est important que l’outil DAST fournisse des rapports sur les résultats et les conditions d’analyse que vous pouvez partager avec d’autres équipes, au sein ou en dehors de votre organisation. Ces rapports doivent contenir les informations nécessaires pour permettre à leurs destinataires de les analyser et de prendre des décisions de manière autonome, avec peu ou pas d’aide de votre part. Par exemple, un rapport destiné à une équipe de direction peut se limiter à un résumé général, tandis qu’un rapport destiné à une équipe de sécurité peut être beaucoup plus détaillé. 

Selon les exigences de votre organisation, les rapports peuvent également inclure des informations sur la conformité à certaines normes importantes, comme PCI DSS, OWASP Top 10, ISO 27001 et HIPAA.

Gérer les résultats

Lors de l’analyse des résultats et de la prise de décision sur les mesures à prendre, l’outil DAST doit offrir les fonctionnalités nécessaires pour agir en conséquence. Voici quelques actions utiles : 

• Relancer un test : au lieu d’effectuer une analyse complète, vous pouvez relancer un test sur un résultat spécifique et vérifier facilement si la vulnérabilité détectée a bien été corrigée. 

• Accepter le risque : dans certains contextes, la vulnérabilité ne présente aucun risque pour l’organisation ou est déjà connue et jugée acceptable. Vous devriez alors pouvoir marquer le risque associé au résultat comme acceptable.

• Marquer comme non valide : si vous concluez que la vulnérabilité signalée n’est pas exploitable, vous devriez pouvoir marquer le résultat comme non valide et le signaler comme faux positif. 

Ajouter des notes : les notes associées aux résultats facilitent le partage et permettent de conserver une trace des informations importantes au sein de votre organisation.

5. Intégration et automatisation

Pour améliorer l’efficacité de votre organisation, votre outil DAST doit vous aider à intégrer les tests de sécurité plus tôt dans le cycle de développement. Cela consiste à introduire les tests de sécurité plus tôt dans le cycle de vie du développement logiciel (SDLC), grâce à l’intégration et à l’automatisation.

Intégration avec les solutions de gestion ou les outils de suivi des problèmes

Si votre organisation utilise un outil de suivi des problèmes pour gérer les tâches (ou un outil de gestion des vulnérabilités pour les centraliser), l’outil DAST que vous choisissez doit permettre une synchronisation bidirectionnelle. Ainsi :

• L’outil DAST peut créer automatiquement des problèmes dans l’outil de suivi lorsqu’il détecte de nouvelles vulnérabilités. 

• Une fois la nouvelle vulnérabilité corrigée par votre équipe, l’outil DAST relance un test.

• Si la vulnérabilité persiste après ce nouveau test, l’outil DAST rouvre le problème.

Commencez par vous concentrer sur les applications web ou les API à haut risque, et collaborez d’abord avec les équipes qui en sont responsables. Une fois le processus bien rodé, étendez-le aux autres équipes. Vous pourrez ainsi améliorer la résolution des problèmes de sécurité en l’intégrant au cycle de développement de vos équipes.

Automatisation des pipelines CI/CD

Vous pouvez également automatiser l’outil DAST au sein de vos pipelines CI/CD. Si votre outil DAST prend en charge ce type d’automatisation, vous pouvez déclencher automatiquement des tests de sécurité dans différents environnements, du développement à la production.

Cette approche vous permet d’intégrer les tests de sécurité au cycle de vie logiciel sans intervention manuelle. Elle ajoute toutefois des étapes aux processus CI/CD et peut modifier les méthodes de travail de vos équipes. Il est donc essentiel d’évaluer l’impact de l’automatisation avec chaque équipe et d’associer les équipes DevOps aux échanges afin de comprendre les changements nécessaires et de les planifier. 

Simplifier la mise en œuvre du DAST avec Snyk API & Web 

La mise en œuvre efficace d’une solution DAST basée sur l’IA est essentielle pour protéger vos applications web et vos API contre les menaces potentielles. Tout commence par une découverte exhaustive des actifs, qui vous aide à comprendre et à gérer votre surface d’attaque. En sachant exactement quels actifs protéger, vous pouvez configurer vos cibles avec davantage de précision, vous assurer que vos analyses sont complètes et, une fois les résultats obtenus, vérifier leur exactitude et les gérer efficacement. Tout cela en intégrant l’outil DAST à vos workflows existants.

En vous assurant que votre outil DAST réunit tous les éléments clés décrits dans cet article, vous pouvez renforcer la posture de sécurité de votre organisation et mieux protéger vos actifs contre l’évolution des cybermenaces, y compris celles liées au code généré par l’IA.

Snyk API & Web, un élément clé de la Snyk AI Trust Platform, simplifie l’ensemble du processus et facilite la détection des vulnérabilités ainsi que la protection de vos actifs. En intégrant nos fonctionnalités DAST conçues pour les développeurs à vos workflows existants, vous pouvez sécuriser vos applications et permettre à vos équipes d’innover en toute sécurité grâce à l’IA.

Pourquoi ne pas l’essayer ? Inscrivez-vous dès aujourd’hui et découvrez ce que Snyk API & Web peut faire pour vous.