Le Dynamic Application Security Testing (DAST) est un contrôle de sécurité critique à l’exécution dans les environnements de livraison logicielle réglementés. Pour les auditeurs, les responsables conformité et les régulateurs, la question n’est pas quel outil DAST une organisation utilise, mais si les contrôles DAST sont adéquats, appliqués et documentés.
Ce guide fournit un cadre structuré pour évaluer les contrôles DAST d’une organisation au sein des pipelines CI/CD — en se concentrant sur la couverture, l’application, la génération de preuves, la gestion des exceptions et l’alignement réglementaire.
Pourquoi les contrôles DAST sont importants dans les environnements réglementés
Le DAST évalue les applications à l’exécution, découvrant les vulnérabilités liées à l’authentification, l’autorisation, la gestion des sessions et la configuration que l’analyse statique ne peut pas détecter. Dans les environnements réglementés, le DAST sert d’étape de validation contrôlée — vérifiant que les contrôles d’exécution fonctionnent comme prévu avant la mise en production du logiciel.
Du point de vue de la gouvernance, le DAST n’est pas un outillage optionnel. C’est la preuve que l’organisation teste les logiciels déployés pour détecter les faiblesses exploitables dans le cadre d’un processus répétable et auditable. Les cadres réglementaires attendent de plus en plus des organisations qu’elles démontrent des tests d’exécution dans le cadre de leur cycle de développement sécurisé.
Cadre d’évaluation DAST pour les auditeurs
Lors de l’évaluation des contrôles DAST d’une organisation, les auditeurs doivent évaluer cinq domaines clés :
1. Couverture
Déterminez si l’analyse DAST couvre adéquatement le portefeuille applicatif de l’organisation. Les questions clés incluent :
- Quel pourcentage des applications en production est soumis à l’analyse DAST ?
- Les applications web et les API sont-elles toutes incluses dans le périmètre ?
- L’analyse authentifiée couvre-t-elle tous les rôles utilisateurs pertinents ?
- Les applications nouvellement déployées sont-elles automatiquement inscrites à l’analyse DAST ?
2. Fréquence et points de déclenchement
Évaluez quand et à quelle fréquence les analyses DAST sont exécutées :
- Le DAST est-il intégré aux pipelines CI/CD, ou exécuté uniquement de manière ponctuelle ?
- Les analyses sont-elles déclenchées à chaque release candidate, ou uniquement selon un calendrier périodique ?
- Existe-t-il un intervalle maximum défini entre les analyses pour chaque application ?
- Les calendriers d’analyse sont-ils documentés et systématiquement respectés ?
3. Application et portes de politique
Vérifiez que les résultats DAST influencent les décisions de déploiement :
- Les résultats critiques ou de haute sévérité bloquent-ils le déploiement ?
- Les portes de politique sont-elles définies en code et versionnées ?
- Les développeurs peuvent-ils contourner les portes DAST ? Si oui, le contournement est-il journalisé et approuvé ?
- Existe-t-il une séparation des fonctions entre ceux qui exécutent les analyses et ceux qui approuvent les exceptions ?
4. Preuves et piste d’audit
Évaluez la qualité et l’exhaustivité des preuves DAST :
- Les résultats d’analyse sont-ils conservés avec une politique de rétention définie ?
- L’exécution des analyses peut-elle être tracée jusqu’à des versions ou déploiements spécifiques ?
- Les résultats sont-ils suivis jusqu’à la remédiation ou l’acceptation documentée ?
- Les données historiques d’analyse sont-elles disponibles pour l’analyse des tendances ?
5. Gestion des exceptions et des suppressions
Évaluez comment les faux positifs et les risques acceptés sont gérés :
- Existe-t-il un processus formel pour supprimer ou accepter les résultats DAST ?
- Les suppressions nécessitent-elles une justification documentée et une approbation ?
- Les suppressions sont-elles limitées dans le temps et périodiquement réexaminées ?
- Y a-t-il une visibilité sur le nombre total et le ratio de résultats supprimés ?
Tableau d’évaluation des contrôles DAST
Le tableau suivant fournit une référence structurée pour les auditeurs évaluant les contrôles DAST :
| Domaine d’évaluation | Ce qu’il faut demander | Ce qui constitue une bonne pratique | Signaux d’alerte |
|---|---|---|---|
| Couverture des analyses | Inventaire des applications analysées vs. portefeuille applicatif total | Toutes les applications et API en production sont analysées ; la couverture dépasse 90% | De larges portions du portefeuille sont exclues sans acceptation documentée du risque |
| Fréquence des analyses | Journaux d’exécution des analyses avec horodatages ; configurations des pipelines CI/CD | Les analyses s’exécutent à chaque release candidate ou au moins hebdomadairement ; les calendriers sont documentés | Analyses ponctuelles uniquement ; pas de calendrier défini ; longs intervalles entre les analyses |
| Analyse authentifiée | Preuves de configurations d’analyse authentifiée ; documentation de couverture des rôles | Les analyses couvrent plusieurs rôles utilisateurs ; l’authentification est stable et maintenue | Analyses non authentifiées uniquement ; les échecs d’authentification ne sont pas investigués |
| Application des politiques | Définitions de pipeline montrant les conditions de porte ; registres de déploiement | Les résultats critiques et élevés bloquent le déploiement ; les portes sont versionnées | Pas de porte en place ; les résultats sont uniquement consultatifs ; les portes peuvent être contournées silencieusement |
| Rétention des preuves | Rapports d’analyse historiques ; documentation de la politique de rétention des données | Les résultats d’analyse sont conservés pour la période requise ; traçables jusqu’aux versions spécifiques | Pas de politique de rétention ; résultats supprimés après chaque analyse ; pas de lien avec les versions |
| Remédiation des résultats | Enregistrements de suivi des problèmes ; chronologies de remédiation et rapports de conformité SLA | Les résultats critiques sont remédiés dans les SLA définis ; le suivi est systématique | Résultats non suivis ; pas de SLA de remédiation ; important arriéré de critiques non traités |
| Gestion des exceptions | Registres de suppression ; workflows d’approbation ; journaux de revue des exceptions | Les suppressions nécessitent une justification documentée et une approbation ; limitées dans le temps | Suppressions en masse sans revue ; pas d’expiration ; pas de séparation des fonctions |
| Propriété et gouvernance | Matrice RACI ; documents de politique ; définitions des rôles | Propriété claire de la politique DAST, de l’analyse et de l’approbation des exceptions | Pas de propriété définie ; responsabilité ponctuelle ; pas de documentation de gouvernance |
Correspondance réglementaire — Contrôles DAST
Les contrôles DAST correspondent aux exigences de plusieurs cadres réglementaires et de conformité. Le tableau suivant résume les principales correspondances :
| Cadre | Exigence pertinente | Comment les contrôles DAST s’appliquent |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Article 8 — Gestion des risques ICT ; Article 9 — Protection et prévention | Le DAST fournit des preuves de tests de sécurité continus à l’exécution dans le cadre de la gestion des risques ICT. Démontre que les applications sont testées pour les vulnérabilités avant le déploiement. |
| NIS2 (Network and Information Security Directive) | Article 21 — Mesures de gestion des risques de cybersécurité | Le DAST soutient l’exigence de gestion des vulnérabilités et de pratiques de développement sécurisé. Fournit des preuves de détection systématique des vulnérabilités dans les applications déployées. |
| ISO 27001:2022 | Annexe A 8.25 — Cycle de développement sécurisé ; A 8.8 — Gestion des vulnérabilités techniques | Le DAST est un contrôle clé dans le cycle de développement sécurisé. Démontre la gestion des vulnérabilités techniques pour les environnements d’exécution. |
| SOC 2 (Type II) | CC7.1 — Détection des changements ; CC8.1 — Gestion des changements | Le DAST fournit des preuves que les changements applicatifs sont testés pour les vulnérabilités de sécurité. Soutient la détection des changements non autorisés ou non sécurisés. |
| PCI DSS 4.0 | Exigence 6.4 — Les applications web publiques sont protégées ; 6.5 — Les changements sont gérés | Le DAST satisfait l’exigence d’analyse de vulnérabilités des applications publiques. Démontre des tests continus dans le cadre de la gestion des changements. |
Déficiences courantes des contrôles DAST identifiées lors des audits
Sur la base des schémas observés dans les environnements réglementés, les déficiences suivantes des contrôles DAST sont fréquemment identifiées lors des audits :
1. Couverture incomplète
Les organisations analysent un sous-ensemble d’applications — généralement celles intégrées au départ — tandis que les applications plus récentes ou internes sont exclues. L’absence d’un processus d’inscription automatisé signifie que la couverture se dégrade au fil du temps à mesure que le portefeuille croît.
2. Analyse non authentifiée uniquement
L’analyse DAST est configurée mais ne s’exécute que sur les surfaces non authentifiées. Cela fournit une assurance limitée car la plupart des vulnérabilités critiques — y compris le contrôle d’accès défaillant et l’escalade de privilèges — existent derrière des points d’accès authentifiés.
3. Pas d’application — Les résultats sont uniquement consultatifs
Les analyses DAST s’exécutent, mais les résultats n’influencent pas les décisions de déploiement. Les résultats sont journalisés mais ne bloquent jamais une version, faisant effectivement du DAST un exercice de reporting plutôt qu’un contrôle de sécurité. Il s’agit d’une déficience significative dans la conception du contrôle.
4. Gestion des exceptions non gouvernée
Les résultats sont supprimés ou marqués comme acceptés sans justification documentée, approbation ou expiration. Au fil du temps, le nombre de résultats supprimés augmente et l’organisation perd la visibilité sur l’exposition réelle au risque.
5. Pas de rétention des preuves
Les résultats d’analyse sont écrasés à chaque exécution et aucune donnée historique n’est conservée. Lorsque les auditeurs demandent des preuves de l’activité DAST sur la période d’audit, l’organisation ne peut pas les fournir. Cela compromet entièrement l’auditabilité du contrôle.
6. Exécution ponctuelle sans gouvernance définie
Le DAST est exécuté manuellement par des équipes individuelles sans politique centralisée, sans propriété définie et sans cohérence dans la configuration ou la fréquence des analyses. Le résultat est une couverture imprévisible et des preuves peu fiables.
7. Pas d’intégration avec le suivi des problèmes
Les résultats DAST ne sont pas systématiquement acheminés vers les systèmes de suivi des problèmes, rendant impossible de démontrer que les résultats ont été triés, assignés et remédiés dans les délais définis.
Liste de vérification de la gouvernance
Les auditeurs examinant les contrôles DAST doivent vérifier les éléments suivants :
- Une politique DAST existe, est approuvée et définit le périmètre, la fréquence et la propriété
- La couverture des analyses inclut toutes les applications dans le périmètre, y compris les API
- Les analyses sont automatisées et intégrées aux pipelines CI/CD ou planifiées avec une fréquence définie
- Des portes de politique existent et appliquent les décisions de déploiement basées sur la sévérité des résultats
- Les preuves sont conservées avec traçabilité vers des versions et déploiements spécifiques
- Les résultats sont suivis jusqu’à la remédiation ou l’acceptation documentée du risque
- Les suppressions sont gouvernées, justifiées, approuvées et limitées dans le temps
- Les rôles et responsabilités sont clairement définis (analyse, politique, approbation des exceptions)
Conclusion
L’évaluation des contrôles DAST dans les environnements réglementés nécessite plus que la confirmation qu’un outil d’analyse est installé. Les auditeurs doivent évaluer si le DAST est appliqué de manière cohérente, si les résultats sont appliqués et remédiés, si les preuves sont conservées et si les exceptions sont gouvernées.
Les organisations qui traitent le DAST comme un contrôle applicable et documenté — plutôt qu’une analyse optionnelle — sont nettement mieux positionnées pour satisfaire les exigences réglementaires sous DORA, NIS2, ISO 27001, SOC 2 et PCI DSS.
Articles connexes
- Meilleurs outils DAST pour les pipelines CI/CD d’entreprise (édition 2026)
- Liste de vérification pour la sélection d’outils DAST en environnement d’entreprise
- Gestion des faux positifs dans les pipelines DAST d’entreprise
- Comment les auditeurs évaluent réellement les contrôles DAST dans les environnements réglementés
Questions fréquentes — Audit des contrôles DAST
Que doivent vérifier en premier les auditeurs lors de l’évaluation des contrôles DAST ?
Commencez par la couverture et l’application. Vérifiez que l’analyse DAST couvre le portefeuille applicatif de l’organisation et que les résultats influencent les décisions de déploiement via des portes de politique définies.
Quelle est la déficience de contrôle DAST la plus courante dans les environnements réglementés ?
La déficience la plus courante est l’exécution du DAST en mode consultatif uniquement — les analyses s’exécutent mais les résultats ne bloquent pas le déploiement, rendant le contrôle inefficace en tant que porte de sécurité.
Quels cadres réglementaires exigent le DAST ou les tests de sécurité à l’exécution ?
DORA, NIS2, ISO 27001, SOC 2 et PCI DSS incluent tous des exigences qui correspondent aux tests de sécurité à l’exécution. Le DAST fournit des preuves de détection continue des vulnérabilités dans les applications déployées.
