Le test dynamique de sécurité applicative (DAST) est un contrôle de sécurité à l’exécution essentiel dans les environnements de livraison logicielle réglementés. Pour les auditeurs, les responsables conformité et les régulateurs, la question n’est pas de savoir quel outil DAST une organisation utilise, mais si les contrôles DAST sont adéquats, appliqués et documentés par des preuves.
Ce guide propose 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 production de preuves, le traitement des exceptions et l’alignement réglementaire. Il explique également comment les auditeurs abordent une revue DAST en pratique, afin que les équipes puissent anticiper les questions qui seront posées et les preuves qui seront demandées.
Pourquoi les contrôles DAST comptent en environnement réglementé
Le DAST évalue les applications à l’exécution, révélant des vulnérabilités liées à l’authentification, à l’autorisation, à la gestion des sessions et à la configuration que l’analyse statique ne peut détecter. Dans les environnements réglementés, le DAST joue le rôle d’une étape de validation contrôlée — vérifiant que les contrôles à l’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 facultatif. Il prouve que l’organisation teste le logiciel déployé à la recherche de faiblesses exploitables, dans le cadre d’un processus reproductible et auditable. Les référentiels réglementaires attendent de plus en plus des organisations qu’elles démontrent des tests à l’exécution dans le cadre de leur cycle de développement sécurisé.
Cadre d’évaluation DAST pour les auditeurs
Lorsqu’ils évaluent les contrôles DAST d’une organisation, les auditeurs devraient examiner cinq domaines clés :
1. Couverture
Déterminez si l’analyse DAST couvre suffisamment le portefeuille applicatif de l’organisation. Les questions clés comprennent :
- Quel pourcentage des applications exposées en production fait l’objet d’une analyse DAST ?
- Les applications web et les API sont-elles toutes deux incluses dans le périmètre ?
- L’analyse authentifiée couvre-t-elle tous les rôles utilisateur pertinents ?
- Les applications nouvellement déployées sont-elles automatiquement intégrées à 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 candidate à la release, ou seulement selon un calendrier périodique ?
- Existe-t-il un intervalle maximal défini entre les analyses pour chaque application ?
- Les calendriers d’analyse sont-ils documentés et respectés de manière cohérente ?
3. Application et portes de politique
Vérifiez que les constats DAST influencent les décisions de déploiement :
- Les constats de sévérité critique ou élevée bloquent-ils le déploiement ?
- Les portes de politique sont-elles définies dans le 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 tâches 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 selon une politique de rétention définie ?
- L’exécution des analyses peut-elle être rattachée à des releases ou déploiements précis ?
- Les constats sont-ils suivis jusqu’à leur correction ou une acceptation documentée ?
- Des données d’analyse historiques sont-elles disponibles pour l’analyse de tendances ?
5. Gestion des exceptions et des suppressions
Évaluez la manière dont les faux positifs et les risques acceptés sont traités :
- Existe-t-il un processus formel de suppression ou d’acceptation des constats DAST ?
- Les suppressions exigent-elles une justification documentée et une approbation ?
- Les suppressions sont-elles limitées dans le temps et revues périodiquement ?
- Dispose-t-on d’une visibilité sur le nombre total et le taux de constats supprimés ?
Tableau d’évaluation des contrôles DAST
Le tableau suivant offre une référence structurée aux auditeurs qui évaluent les contrôles DAST :
| Domaine d’évaluation | Ce qu’il faut demander | À quoi ressemble une bonne pratique | Signaux d’alerte |
|---|---|---|---|
| Couverture de l’analyse | Inventaire des applications analysées par rapport au portefeuille applicatif total | Toutes les applications exposées en production et les API sont analysées ; la couverture dépasse 90 % | De larges portions du portefeuille sont exclues sans acceptation du risque documentée |
| Fréquence des analyses | Journaux d’exécution des analyses avec horodatage ; configurations des pipelines CI/CD | Analyses exécutées à chaque candidate à la release ou au moins chaque semaine ; calendriers documentés | Analyses ponctuelles uniquement ; aucun calendrier défini ; longs écarts entre les analyses |
| Analyse authentifiée | Preuves de configurations d’analyse authentifiée ; documentation de la couverture des rôles | Les analyses couvrent plusieurs rôles utilisateur ; l’authentification est stable et maintenue | Analyses non authentifiées uniquement ; échecs d’authentification non investigués |
| Application des politiques | Définitions de pipeline montrant les conditions de porte ; enregistrements de déploiement | Les constats critiques et élevés bloquent le déploiement ; les portes sont versionnées | Aucune porte en place ; constats purement consultatifs ; portes contournables sans trace |
| Rétention des preuves | Rapports d’analyse historiques ; documentation de la politique de rétention des données | Résultats d’analyse conservés pendant la durée requise ; traçables jusqu’à des releases précises | Aucune politique de rétention ; résultats supprimés après chaque analyse ; aucun lien avec les releases |
| Correction des constats | Enregistrements de suivi des tickets ; délais de correction et rapports de respect des SLA | Constats critiques corrigés dans les SLA définis ; suivi systématique | Constats non suivis ; aucun SLA de correction ; important arriéré de constats critiques non traités |
| Gestion des exceptions | Enregistrements de suppression ; circuits d’approbation ; journaux de revue des exceptions | Les suppressions exigent une justification documentée et une approbation ; limitées dans le temps | Suppressions en masse sans revue ; aucune expiration ; aucune séparation des tâches |
| Responsabilité et gouvernance | Matrice RACI ; documents de politique ; définitions de rôles | Responsabilité claire de la politique DAST, de l’analyse et de l’approbation des exceptions | Aucune responsabilité définie ; responsabilité ponctuelle ; aucune documentation de gouvernance |
Correspondance réglementaire — contrôles DAST
Les contrôles DAST correspondent à des exigences de plusieurs référentiels réglementaires et de conformité. Le tableau suivant résume les principales correspondances :
| Référentiel | Exigence pertinente | Application des contrôles DAST |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Article 8 — gestion du risque lié aux TIC ; Article 9 — protection et prévention | Le DAST apporte la preuve de tests de sécurité continus à l’exécution, dans le cadre de la gestion du risque lié aux TIC. Il démontre que les applications sont testées à la recherche de vulnérabilités avant le déploiement. |
| NIS2 (directive sur la sécurité des réseaux et de l’information) | Article 21 — mesures de gestion des risques de cybersécurité | Le DAST répond à l’exigence de traitement des vulnérabilités et de développement sécurisé. Il apporte la preuve d’une 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é du cycle de développement sécurisé. Il 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 prouve que les modifications applicatives sont testées à la recherche de vulnérabilités de sécurité. Il soutient la détection des modifications non autorisées ou non sécurisées. |
| PCI DSS 4.0 | Exigence 6.4 — les applications web exposées au public sont protégées ; 6.5 — les changements sont gérés | Le DAST satisfait l’exigence d’analyse des vulnérabilités des applications exposées au public. Il démontre des tests continus dans le cadre de la gestion des changements. |
Comment les auditeurs examinent réellement les contrôles DAST
Le cadre et les correspondances ci-dessus décrivent à quoi ressemble une bonne gouvernance DAST sur le papier. Il est tout aussi important de comprendre comment les auditeurs abordent une revue en pratique — ce qu’ils scrutent, ce qu’ils négligent largement et ce qui produit de manière fiable des constats. Le DAST est l’un des contrôles les plus mal compris lors des audits : beaucoup d’équipes supposent qu’il sera jugé sur la couverture des analyses ou le nombre brut de vulnérabilités, alors qu’en réalité les auditeurs l’évaluent comme un contrôle de gouvernance et de risque intégré au cycle de livraison logicielle.
Le point de vue de l’auditeur sur le DAST
Les auditeurs n’évaluent pas le DAST comme un exercice de test d’intrusion ni comme un outil de découverte de vulnérabilités. Ils l’évaluent plutôt comme un mécanisme de contrôle de la gouvernance et du risque intégré au cycle de livraison logicielle. Du point de vue de l’audit, le DAST répond à trois questions fondamentales :
- Le test de sécurité applicative est-il appliqué de manière cohérente ?
- Les décisions de risque sont-elles traçables et justifiées ?
- L’organisation peut-elle prouver l’exécution du contrôle dans le temps ?
La profondeur technique du scanner compte bien moins que la façon dont le contrôle est conçu, appliqué et documenté par des preuves.
Ce que les auditeurs examinent réellement
Exécution cohérente dans les pipelines CI/CD. Les auditeurs vérifient que les analyses DAST ne sont ni facultatives ni ponctuelles. Ils attendent des analyses intégrées à des étapes de pipeline définies (généralement en préproduction ou avant release), déclenchées automatiquement plutôt que manuellement, avec des conditions claires dans lesquelles elles doivent s’exécuter. Les preuves examinées comprennent généralement les définitions de pipeline, les journaux d’exécution des jobs et l’historique des analyses sur plusieurs releases. Une exécution incohérente est souvent interprétée comme un contrôle inefficace.
Blocage et logique de décision. Les auditeurs se concentrent fortement sur ce qui se passe lorsque le DAST détecte des problèmes. Ils attendent des seuils de sévérité définis, des règles de blocage de pipeline explicites et des processus d’exception ou de contournement documentés. Autoriser un build malgré des constats n’est acceptable que s’il existe une justification, une approbation et une traçabilité documentées. Une question fréquente de l’auditeur est :
« Montrez-moi pourquoi cette release a été autorisée malgré les constats DAST. »
Gouvernance des faux positifs. Les auditeurs n’attendent pas zéro faux positif. Ce qu’ils évaluent, c’est la manière dont les faux positifs sont traités : circuits de suppression formels, approbation des suppressions fondée sur les rôles, et revue périodique ou expiration des constats supprimés. Les suppressions permanentes et non documentées constituent un signal d’alerte fréquent.
Rétention des preuves et traçabilité. Le DAST n’est auditable que si des preuves existent. Les auditeurs attendent des résultats d’analyse conservés, un lien entre les résultats et des builds ou releases précis, et une corrélation entre les constats, les approbations et les décisions de déploiement. Ces preuves doivent être résistantes à l’altération, conservées conformément à la politique et récupérables sans reconstruction manuelle.
Alignement sur la gestion des risques. Les auditeurs rattachent souvent le DAST à des référentiels de contrôle plus larges tels qu’ISO 27001, SOC 2, DORA et NIS2. Ils vérifient si le DAST est mentionné dans les politiques de sécurité, si les responsabilités sont clairement attribuées et si les exceptions font l’objet d’une acceptation formelle du risque plutôt que d’être ignorées. Un DAST sans responsabilité documentée est perçu comme un contrôle faible.
Ce que les auditeurs ignorent le plus souvent
Comprendre ce que les auditeurs négligent est aussi utile que de savoir ce qu’ils examinent. En pratique, trois éléments pèsent bien moins que les équipes ne l’imaginent.
- La marque de l’outil et les arguments marketing. Les auditeurs se soucient généralement peu de l’éditeur DAST utilisé, et ils n’évaluent ni la popularité du scanner, ni les allégations d’IA, ni le nombre de vulnérabilités détectées. Un outil basique doté d’une gouvernance solide est souvent mieux perçu qu’un outil avancé utilisé de manière incohérente.
- Le nombre brut de vulnérabilités. Un nombre élevé de constats n’impressionne pas les auditeurs, et un nombre faible ne les rassure pas. Ce qui compte, c’est la cohérence de l’exécution, la clarté de la prise de décision et les preuves de correction ou d’acceptation. Les auditeurs analysent rarement les vulnérabilités individuelles, sauf lorsqu’ils enquêtent sur un incident précis.
- Les allégations de couverture d’analyse maximale. Des affirmations telles que « nous analysons tout » ne sont pas convaincantes sans preuve. Les auditeurs préfèrent un périmètre défini, des exclusions documentées et une justification de ce qui n’est pas analysé. Une analyse trop large et mal contrôlée est souvent perçue comme immature plutôt qu’avancée.
Ce qui déclenche fréquemment des constats d’audit
Certains schémas conduisent presque toujours à des constats, même lorsqu’un outil d’analyse est techniquement en place :
- Le DAST s’exécute mais n’impose rien. Si les analyses s’exécutent sans jamais bloquer les releases et sans processus d’exception formel, les auditeurs concluent souvent que le contrôle « existe mais n’est pas efficace ».
- Des suppressions sans gouvernance. Les suppressions appliquées directement par les développeurs, sans date d’expiration ni enregistrement de revue, sont interprétées comme une acceptation du risque non contrôlée.
- L’absence de preuves historiques. Pouvoir montrer uniquement la dernière analyse ne suffit pas. Les auditeurs attendent des preuves historiques sur plusieurs releases et la capacité de reconstituer les décisions passées ; l’absence de preuves entraîne souvent des constats, même lorsque les analyses ont été techniquement exécutées.
- Une exécution manuelle ou incohérente. Les analyses déclenchées manuellement ou « quand le temps le permet » sont rarement acceptées en environnement réglementé, où l’automatisation et la cohérence sont des critères d’audit essentiels.
Comment les organisations matures réussissent les audits DAST
Les organisations qui réussissent systématiquement les audits traitent le DAST comme un contrôle CI/CD imposé par la politique, comme un point de décision plutôt que comme un simple scanner, et comme une source de preuves plutôt que seulement une source de constats. Elles conçoivent le DAST en gardant à l’esprit les résultats d’audit dès le départ, au lieu d’essayer de greffer la gouvernance plus tard. La distinction se lit dans les questions que posent les auditeurs. Ils demandent rarement « quelle est la qualité de votre outil DAST ? ». Ils demandent « pouvez-vous prouver que le test de sécurité applicative est appliqué, gouverné et auditable ? ». Les équipes qui intègrent cette différence évitent la plupart des constats liés au DAST.
Déficiences de contrôle DAST fréquemment relevées lors des audits
D’après les schémas observés dans les environnements réglementés, les déficiences de contrôle DAST suivantes 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 tôt — tandis que les applications plus récentes ou internes sont exclues. L’absence d’un processus d’intégration automatisé signifie que la couverture se dégrade avec le temps à mesure que le portefeuille grandit.
2. Analyse non authentifiée uniquement
L’analyse DAST est configurée mais s’exécute uniquement sur les surfaces non authentifiées. Cela offre une assurance limitée, car la plupart des vulnérabilités critiques — dont le contrôle d’accès défaillant et l’élévation de privilèges — se situent derrière des points de terminaison authentifiés.
3. Aucune application — les constats sont purement consultatifs
Les analyses DAST s’exécutent, mais les résultats n’influencent pas les décisions de déploiement. Les constats sont journalisés mais ne bloquent jamais une release, réduisant de fait le DAST à un exercice de reporting plutôt qu’à un contrôle de sécurité. C’est une déficience de conception de contrôle importante.
4. Gestion des exceptions non gouvernée
Les constats sont supprimés ou marqués comme acceptés sans justification documentée, approbation ni expiration. Avec le temps, le nombre de constats supprimés augmente et l’organisation perd la visibilité sur son exposition réelle au risque.
5. Aucune 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 mine 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 responsabilité définie et sans cohérence dans la configuration ou la fréquence des analyses. Il en résulte une couverture imprévisible et des preuves peu fiables.
7. Aucune intégration au suivi des tickets
Les constats DAST ne sont pas systématiquement acheminés vers les systèmes de suivi des tickets, rendant impossible de démontrer que les constats ont été triés, attribués et corrigés dans des délais définis.
Liste de vérification de la gouvernance
Les auditeurs qui examinent les contrôles DAST devraient vérifier les points suivants :
- Une politique DAST existe, est approuvée et définit le périmètre, la fréquence et la responsabilité
- La couverture des analyses inclut toutes les applications du périmètre, y compris les API
- Les analyses sont automatisées et intégrées aux pipelines CI/CD, ou planifiées à une fréquence définie
- Des portes de politique existent et conditionnent les décisions de déploiement selon la sévérité des constats
- Les preuves sont conservées avec une traçabilité jusqu’aux releases et déploiements précis
- Les constats sont suivis jusqu’à leur correction ou une acceptation du risque documentée
- 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
Évaluer les contrôles DAST dans les environnements réglementés exige plus que de confirmer qu’un outil d’analyse est installé. Les auditeurs doivent évaluer si le DAST est appliqué de manière cohérente, si les constats sont imposés et corrigés, si les preuves sont conservées et si les exceptions sont gouvernées.
Les organisations qui traitent le DAST comme un contrôle contraignant et documenté par des preuves — plutôt que comme une analyse facultative — sont bien mieux placées pour satisfaire les exigences réglementaires au titre de DORA, NIS2, ISO 27001, SOC 2 et PCI DSS.
Articles liés
- Meilleurs outils DAST pour les pipelines CI/CD d’entreprise (édition 2026)
- Gouvernance des outils DAST — liste de sélection, déploiement et pourquoi les mises en œuvre échouent
- Gérer les faux positifs dans les pipelines DAST d’entreprise
Foire aux questions — auditer les contrôles DAST
Que les auditeurs devraient-ils vérifier en premier lors de l’examen 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 constats influencent les décisions de déploiement au moyen de portes de politique définies.
Quelle est la déficience de contrôle DAST la plus fréquente en environnement réglementé ?
La déficience la plus fréquente est l’exécution du DAST en mode consultatif uniquement : les analyses s’exécutent mais les constats ne bloquent pas le déploiement, rendant le contrôle inefficace comme porte de sécurité.
Quels référentiels réglementaires exigent le DAST ou les tests de sécurité à l’exécution ?
DORA, NIS2, ISO 27001, SOC 2 et PCI DSS comportent tous des exigences qui s’alignent sur les tests de sécurité à l’exécution. Le DAST fournit une preuve de détection continue des vulnérabilités dans les applications déployées.
Les auditeurs se soucient-ils de l’éditeur DAST qu’une organisation utilise ?
En général, non. Les auditeurs évaluent la façon dont le contrôle est gouverné, appliqué et documenté par des preuves, plutôt que la marque du scanner. Un outil basique doté d’une gouvernance solide est mieux perçu qu’un outil avancé utilisé de manière incohérente.
