Le Dynamic Application Security Testing (DAST) est un contrôle de sécurité utilisé dans les pipelines CI/CD pour tester les applications en cours d’exécution à la recherche de vulnérabilités. Pour les auditeurs et les responsables conformité, le DAST est fréquemment rencontré lors des revues de sécurité applicative et de gouvernance de la livraison logicielle — pourtant, il reste l’un des contrôles les plus mal compris dans les environnements réglementés.
Cette FAQ aborde les questions les plus courantes que les auditeurs et les responsables conformité se posent sur le DAST, en se concentrant sur ce qu’il faut vérifier, quelles preuves attendre et comment le DAST s’inscrit dans les cadres de conformité et de gouvernance plus larges.
Qu’est-ce que le DAST et pourquoi est-il important pour les auditeurs ?
Le DAST (Dynamic Application Security Testing) est un contrôle de sécurité qui teste les applications en cours d’exécution en interagissant avec elles de l’extérieur, simulant des scénarios d’attaque réels. Contrairement à l’analyse au niveau du code (SAST), le DAST valide le comportement à l’exécution des applications — y compris les flux d’authentification, la gestion des sessions et les points d’accès exposés.
Pour les auditeurs, le DAST est important car il fournit la preuve que les applications ont été testées dans des conditions réalistes avant le déploiement en production. C’est un contrôle détectif et préventif qui, lorsqu’il est correctement appliqué, démontre qu’une organisation valide la sécurité applicative dans le cadre de son processus de mise en production.
En quoi le DAST diffère-t-il du SAST et du SCA ?
Les auditeurs rencontrent fréquemment ces trois contrôles ensemble. Voici comment ils diffèrent :
- SAST (Static Application Security Testing) analyse le code source pour trouver des vulnérabilités avant que l’application ne s’exécute. C’est un contrôle préventif au niveau du code.
- SCA (Software Composition Analysis) identifie les risques dans les bibliothèques tierces et les dépendances. C’est un contrôle de risque de la chaîne d’approvisionnement.
- DAST teste l’application en cours d’exécution de l’extérieur, sans accès au code source. C’est un contrôle de validation à l’exécution.
Dans les environnements réglementés, ces trois contrôles sont complémentaires. Les auditeurs devraient s’attendre à voir les trois (ou des alternatives justifiées) dans le cadre d’un programme de sécurité applicative mature. L’absence de l’un d’entre eux devrait susciter des questions sur la manière dont ce domaine de risque est traité.
Quand le DAST doit-il s’exécuter dans un pipeline CI/CD ?
Du point de vue de l’audit, le DAST doit s’exécuter à des points de contrôle définis dans le processus de livraison logicielle — généralement avant les mises en production, après des changements significatifs ou selon un calendrier pour les applications critiques.
Les auditeurs doivent vérifier que l’exécution du DAST est liée au processus de mise en production, et non réalisée comme une activité isolée déconnectée des déploiements. La question clé est : l’organisation peut-elle démontrer que le DAST a été exécuté et ses résultats examinés avant qu’une version spécifique n’atteigne la production ?
Le DAST peut-il bloquer les mises en production dans les environnements réglementés ?
Oui. Lorsqu’il est correctement gouverné, le DAST agit comme un contrôle de porte dans les pipelines CI/CD. Les mises en production peuvent être bloquées lorsque les résultats dépassent des seuils de sévérité prédéfinis ou lorsque l’acceptation du risque requise n’a pas été approuvée.
Les auditeurs doivent vérifier :
- Les seuils de porte sont définis dans la politique et appliqués dans le pipeline
- Les exceptions (mises en production qui procèdent malgré les résultats) sont documentées avec des approbations
- Le mécanisme de porte ne peut pas être facilement contourné par les équipes de développement
Les organisations qui autorisent les mises en production avec des exceptions documentées ne sont pas nécessairement non conformes — mais ces exceptions doivent être correctement gouvernées, approuvées et traçables.
Comment les faux positifs doivent-ils être gouvernés dans le DAST ?
Les faux positifs (résultats qui ne représentent pas de véritables vulnérabilités) sont inhérents au DAST. La préoccupation de gouvernance n’est pas de savoir si les faux positifs existent, mais comment ils sont gérés.
Les auditeurs devraient s’attendre à voir :
- Un processus défini pour examiner et classifier les résultats comme faux positifs
- Des approbations de suppression basées sur les rôles (pas en libre-service par les développeurs)
- Des justifications documentées pour chaque résultat supprimé
- Des dates d’expiration sur les suppressions, avec revue périodique
- Une piste d’audit montrant qui a approuvé chaque suppression et quand
Signal d’alerte : Un grand nombre de résultats supprimés sans justification documentée, ou des suppressions qui n’expirent jamais.
Qu’attendent généralement les auditeurs des contrôles DAST ?
Les auditeurs évaluent le DAST comme un contrôle de gouvernance, et non comme un outil de test d’intrusion. L’évaluation se concentre sur :
- Exécution cohérente — le DAST est-il exécuté de manière fiable dans le cadre du processus de mise en production ?
- Logique de porte documentée — les seuils de sévérité sont-ils définis et appliqués ?
- Décisions de suppression traçables — les exceptions sont-elles gouvernées et auditables ?
- Preuves conservées — les résultats d’analyse peuvent-ils être récupérés pour une version donnée ?
- Adéquation du périmètre — le DAST couvre-t-il les applications les plus importantes ?
Les auditeurs n’évaluent généralement pas la marque du scanner, le nombre de vulnérabilités ou la profondeur d’analyse de manière isolée. L’accent est mis sur la gouvernance, l’application et la qualité des preuves du contrôle.
Le DAST est-il obligatoire selon DORA, NIS2, ISO 27001 ou PCI DSS ?
La plupart des réglementations et standards n’imposent pas le DAST nommément. Au contraire, ils exigent des organisations qu’elles démontrent des tests de sécurité applicative efficaces, une gestion des risques et une rétention des preuves.
Le DAST est couramment utilisé comme un composant d’une stratégie plus large de sécurité applicative et de gouvernance CI/CD. Sa pertinence varie selon le cadre :
- DORA : Exige la gestion des risques ICT et les tests — le DAST soutient les preuves de validation à l’exécution
- NIS2 : Exige la gestion des risques et le développement sécurisé — le DAST valide l’exposition des services
- ISO 27001 : Exige la démonstration de l’efficacité des contrôles (Annexe A, A.8.25-28) — le DAST contribue aux preuves
- PCI DSS : Exige explicitement les tests de sécurité des applications web (Exigences 6.4, 11.3) — le DAST est couramment utilisé pour satisfaire cette exigence
Que doivent rechercher les auditeurs dans les rapports DAST ?
Lors de l’examen des rapports DAST, les auditeurs doivent regarder au-delà du nombre brut de vulnérabilités. Les éléments clés à évaluer sont :
- Périmètre des tests : Quelles applications et points d’accès ont été testés ? Les applications critiques et exposées à l’extérieur étaient-elles incluses ?
- Classification de sévérité : Les résultats sont-ils classifiés par sévérité, et les classifications suivent-elles un standard défini ?
- Résultat de la porte : L’analyse a-t-elle abouti à une décision de réussite ou d’échec ? Si des résultats étaient présents, la version a-t-elle été approuvée via une exception documentée ?
- Données de tendance : Les résultats récurrents sont-ils traités, ou les mêmes problèmes apparaissent-ils sur plusieurs versions ?
- Détails des suppressions : Les résultats supprimés sont-ils documentés avec des justifications et des approbations ?
- Traçabilité : Le rapport peut-il être lié à une version, un environnement et une date spécifiques ?
Comment les auditeurs vérifient-ils que le DAST est correctement appliqué ?
Vérifier l’application du DAST nécessite de regarder au-delà des documents de politique. Les auditeurs doivent :
- Demander les configurations de pipeline — vérifier que le DAST est défini comme une étape obligatoire qui ne peut pas être ignorée
- Échantillonner les mises en production récentes — pour une sélection de déploiements récents en production, demander les résultats DAST correspondants
- Vérifier les preuves de contournement — rechercher les mises en production qui ont procédé sans exécution DAST ou avec des résultats outrepassés
- Examiner les enregistrements d’exception — si des exceptions existent, vérifier qu’elles suivent le processus d’approbation documenté
- Évaluer la couverture du périmètre — vérifier que le DAST couvre toutes les applications dans le périmètre défini, en particulier les systèmes exposés à l’extérieur et critiques
Signal d’alerte : L’organisation dispose d’une politique DAST mais ne peut pas produire de résultats d’analyse pour les mises en production récentes, ou les configurations de pipeline montrent le DAST comme une étape optionnelle.
Quels sont les constats d’audit DAST courants ?
Sur la base des observations d’audit courantes, les constats les plus fréquents liés au DAST incluent :
- Le DAST n’est pas appliqué dans le pipeline — il est disponible mais optionnel, et les équipes peuvent le sauter sans approbation
- Pas de seuils de porte définis — le DAST s’exécute mais toutes les versions procèdent indépendamment des résultats
- Les résultats d’analyse ne sont pas conservés — l’organisation ne peut pas produire de preuves DAST historiques pour les versions passées
- Périmètre incomplet — le DAST ne couvre que certaines applications, laissant les systèmes critiques ou exposés à l’extérieur non testés
- Suppression non gouvernée des faux positifs — les résultats sont supprimés sans justification documentée ni approbation
- Pas de connexion au processus de mise en production — le DAST s’exécute selon un calendrier mais n’est pas lié aux déploiements réels, rendant les résultats non liables à des versions spécifiques
- Résultats récurrents non résolus — les mêmes vulnérabilités apparaissent sur plusieurs versions sans remédiation ni acceptation documentée du risque
Comment les organisations doivent-elles préparer leurs contrôles DAST pour l’audit ?
Les organisations se préparant à un audit doivent s’assurer qu’elles peuvent démontrer :
- Le DAST est intégré dans le pipeline CI/CD à des points de contrôle définis
- Les seuils de porte et les workflows d’approbation sont documentés et appliqués
- Les résultats d’analyse sont conservés et peuvent être récupérés pour toute version spécifique
- Les suppressions de faux positifs sont gouvernées avec des approbations documentées
- Le périmètre DAST couvre toutes les applications dans le périmètre de conformité
- La gestion des exceptions suit des procédures documentées avec une autorisation appropriée
Quelles preuves le DAST doit-il produire pour les auditeurs ?
Le DAST doit produire des preuves structurées, conservées et traçables. Les auditeurs devraient s’attendre aux artefacts de preuves suivants d’un contrôle DAST correctement gouverné :
- Rapports d’analyse par version : Chaque mise en production devrait avoir un rapport DAST correspondant montrant ce qui a été testé, ce qui a été trouvé et quel a été le résultat de la porte
- Résultats classifiés par sévérité : Les résultats devraient être catégorisés par sévérité selon un standard défini (ex. CVSS, matrice de sévérité interne)
- Décisions de porte : Un enregistrement clair de réussite/échec pour chaque analyse, avec documentation de tout dérogation ou exception
- Enregistrements de suppression : Documentation des résultats supprimés incluant la justification, l’approbateur et la date d’expiration
- Documentation du périmètre : Preuves des applications et points d’accès inclus dans les tests
- Données de tendance : Résultats d’analyse historiques montrant si les résultats sont traités au fil du temps
- Métadonnées de traçabilité : Liens entre les résultats d’analyse et la version spécifique, l’environnement, l’exécution du pipeline et la date
Si une organisation ne peut pas produire ces artefacts pour une version donnée, le contrôle DAST peut exister dans la politique mais ne fonctionne pas comme preuve de gouvernance efficace.
Quels sont les signaux d’alerte DAST courants lors des audits ?
Lors des revues d’audit, les signaux d’alerte suivants indiquent que la gouvernance DAST est faible, incomplète ou inefficace :
- Le DAST existe dans la politique mais pas dans la pratique : L’organisation dispose d’une politique DAST mais ne peut pas produire de résultats d’analyse pour les mises en production récentes
- Étape optionnelle du pipeline : Le DAST est configuré dans le pipeline CI/CD mais peut être ignoré ou contourné sans approbation
- Pas de seuils de porte : Le DAST s’exécute mais toutes les versions procèdent indépendamment des résultats — le contrôle n’a aucun pouvoir d’application
- Déconnecté des mises en production : Le DAST s’exécute selon un calendrier (ex. hebdomadaire) mais n’est pas lié aux déploiements réels, rendant les résultats non traçables vers des versions spécifiques
- Suppressions massives sans gouvernance : De grands nombres de résultats sont supprimés sans justification documentée, identité de l’approbateur ou dates d’expiration
- Périmètre incomplet : Les applications critiques ou exposées à l’extérieur sont exclues des tests DAST sans acceptation documentée du risque
- Pas de rétention des preuves : Les résultats d’analyse sont éphémères et ne peuvent pas être récupérés pour les versions passées
- Résultats récurrents non résolus : Les mêmes vulnérabilités apparaissent sur plusieurs versions sans remédiation ni escalade
- Suppression en libre-service : Les développeurs peuvent supprimer les résultats sans revue ou approbation indépendante
Tout signal d’alerte justifie une investigation plus approfondie et devrait être documenté comme un constat ou une observation d’audit.
Comment le DAST correspond-il aux exigences DORA, NIS2 et ISO 27001 ?
Le DAST n’est généralement pas imposé nommément dans les cadres réglementaires, mais il soutient directement les exigences clés des principales réglementations et standards :
DORA (Digital Operational Resilience Act)
DORA exige des entités financières qu’elles maintiennent des cadres de gestion des risques ICT incluant les tests des systèmes ICT. Le DAST soutient la conformité DORA en :
- Fournissant des preuves de validation à l’exécution pour les applications déployées
- Démontrant que les applications sont testées dans des conditions réalistes avant le déploiement en production
- Soutenant l’exigence d’identification et de gestion continues des risques ICT
NIS2 (Network and Information Security Directive)
NIS2 exige des entités essentielles et importantes qu’elles mettent en œuvre des mesures de gestion des risques incluant des pratiques de développement sécurisé et la gestion des vulnérabilités. Le DAST soutient NIS2 en :
- Validant que les services exposés à l’extérieur sont testés pour les classes de vulnérabilités connues
- Produisant des preuves d’identification proactive des vulnérabilités dans les systèmes déployés
- Soutenant la prévention des incidents en identifiant les faiblesses exploitables avant les attaquants
ISO 27001 (Annexe A, A.8.25-28)
ISO 27001 exige des organisations qu’elles démontrent des pratiques de développement sécurisé et l’efficacité des contrôles. Le DAST soutient ISO 27001 en :
- Contribuant aux preuves de développement et de test d’applications sécurisés (A.8.25-28)
- Fournissant des résultats de contrôle mesurables démontrant l’efficacité des processus de test de sécurité
- Soutenant l’amélioration continue par l’analyse des tendances des résultats à l’exécution
Les auditeurs doivent noter que le DAST seul ne satisfait aucun de ces cadres — c’est un composant d’un ensemble plus large de contrôles de sécurité applicative qui devrait également inclure SAST, SCA et d’autres contrôles complémentaires.
Ressources connexes pour les auditeurs
- Glossaire des termes de sécurité et conformité CI/CD
- Comment les auditeurs évaluent réellement les contrôles DAST dans les environnements réglementés
- Avant l’arrivée de l’auditeur — Liste de vérification de préparation à l’audit CI/CD
- Conformité continue via CI/CD
