Le Dynamic Application Security Testing (DAST) est un contr\u00f4le de s\u00e9curit\u00e9 utilis\u00e9 dans les pipelines CI\/CD pour tester les applications en cours d’ex\u00e9cution \u00e0 la recherche de vuln\u00e9rabilit\u00e9s. Pour les auditeurs et les responsables conformit\u00e9, le DAST est fr\u00e9quemment rencontr\u00e9 lors des revues de s\u00e9curit\u00e9 applicative et de gouvernance de la livraison logicielle \u2014 pourtant, il reste l’un des contr\u00f4les les plus mal compris dans les environnements r\u00e9glement\u00e9s.<\/p>\n\n\n\n
Cette FAQ aborde les questions les plus courantes que les auditeurs et les responsables conformit\u00e9 se posent sur le DAST<\/strong>, en se concentrant sur ce qu’il faut v\u00e9rifier, quelles preuves attendre et comment le DAST s’inscrit dans les cadres de conformit\u00e9 et de gouvernance plus larges.<\/p>\n\n\n\n Le DAST (Dynamic Application Security Testing) est un contr\u00f4le de s\u00e9curit\u00e9 qui teste les applications en cours d’ex\u00e9cution en interagissant avec elles de l’ext\u00e9rieur, simulant des sc\u00e9narios d’attaque r\u00e9els. Contrairement \u00e0 l’analyse au niveau du code (SAST), le DAST valide le comportement \u00e0 l’ex\u00e9cution<\/strong> des applications \u2014 y compris les flux d’authentification, la gestion des sessions et les points d’acc\u00e8s expos\u00e9s.<\/p>\n\n\n\n Pour les auditeurs, le DAST est important car il fournit la preuve que les applications ont \u00e9t\u00e9 test\u00e9es dans des conditions r\u00e9alistes avant le d\u00e9ploiement en production. C’est un contr\u00f4le d\u00e9tectif et pr\u00e9ventif<\/strong> qui, lorsqu’il est correctement appliqu\u00e9, d\u00e9montre qu’une organisation valide la s\u00e9curit\u00e9 applicative dans le cadre de son processus de mise en production.<\/p>\n\n\n\n Les auditeurs rencontrent fr\u00e9quemment ces trois contr\u00f4les ensemble. Voici comment ils diff\u00e8rent :<\/p>\n\n\n\n Dans les environnements r\u00e9glement\u00e9s, ces trois contr\u00f4les sont compl\u00e9mentaires. Les auditeurs devraient s’attendre \u00e0 voir les trois (ou des alternatives justifi\u00e9es) dans le cadre d’un programme de s\u00e9curit\u00e9 applicative mature. L’absence de l’un d’entre eux devrait susciter des questions sur la mani\u00e8re dont ce domaine de risque est trait\u00e9.<\/p>\n\n\n\n Du point de vue de l’audit, le DAST doit s’ex\u00e9cuter \u00e0 des points de contr\u00f4le d\u00e9finis<\/strong> dans le processus de livraison logicielle \u2014 g\u00e9n\u00e9ralement avant les mises en production, apr\u00e8s des changements significatifs ou selon un calendrier pour les applications critiques.<\/p>\n\n\n\n Les auditeurs doivent v\u00e9rifier que l’ex\u00e9cution du DAST est li\u00e9e au processus de mise en production<\/strong>, et non r\u00e9alis\u00e9e comme une activit\u00e9 isol\u00e9e d\u00e9connect\u00e9e des d\u00e9ploiements. La question cl\u00e9 est : l’organisation peut-elle d\u00e9montrer que le DAST a \u00e9t\u00e9 ex\u00e9cut\u00e9 et ses r\u00e9sultats examin\u00e9s avant qu’une version sp\u00e9cifique n’atteigne la production ?<\/p>\n\n\n\n Oui. Lorsqu’il est correctement gouvern\u00e9, le DAST agit comme un contr\u00f4le de porte<\/strong> dans les pipelines CI\/CD. Les mises en production peuvent \u00eatre bloqu\u00e9es lorsque les r\u00e9sultats d\u00e9passent des seuils de s\u00e9v\u00e9rit\u00e9 pr\u00e9d\u00e9finis ou lorsque l’acceptation du risque requise n’a pas \u00e9t\u00e9 approuv\u00e9e.<\/p>\n\n\n\n Les auditeurs doivent v\u00e9rifier :<\/p>\n\n\n\n Les organisations qui autorisent les mises en production avec des exceptions document\u00e9es ne sont pas n\u00e9cessairement non conformes \u2014 mais ces exceptions doivent \u00eatre correctement gouvern\u00e9es, approuv\u00e9es et tra\u00e7ables.<\/p>\n\n\n\n Les faux positifs (r\u00e9sultats qui ne repr\u00e9sentent pas de v\u00e9ritables vuln\u00e9rabilit\u00e9s) sont inh\u00e9rents au DAST. La pr\u00e9occupation de gouvernance n’est pas de savoir si les faux positifs existent, mais comment ils sont g\u00e9r\u00e9s<\/strong>.<\/p>\n\n\n\n Les auditeurs devraient s’attendre \u00e0 voir :<\/p>\n\n\n\n Signal d’alerte :<\/strong> Un grand nombre de r\u00e9sultats supprim\u00e9s sans justification document\u00e9e, ou des suppressions qui n’expirent jamais.<\/p>\n\n\n\n Les auditeurs \u00e9valuent le DAST comme un contr\u00f4le de gouvernance<\/strong>, et non comme un outil de test d’intrusion. L’\u00e9valuation se concentre sur :<\/p>\n\n\n\n Les auditeurs n’\u00e9valuent g\u00e9n\u00e9ralement pas la marque du scanner, le nombre de vuln\u00e9rabilit\u00e9s ou la profondeur d’analyse de mani\u00e8re isol\u00e9e. L’accent est mis sur la gouvernance, l’application et la qualit\u00e9 des preuves du contr\u00f4le.<\/p>\n\n\n\n La plupart des r\u00e9glementations et standards n’imposent pas le DAST nomm\u00e9ment. Au contraire, ils exigent des organisations qu’elles d\u00e9montrent des tests de s\u00e9curit\u00e9 applicative efficaces, une gestion des risques et une r\u00e9tention des preuves<\/strong>.<\/p>\n\n\n\n Le DAST est couramment utilis\u00e9 comme un composant d’une strat\u00e9gie plus large de s\u00e9curit\u00e9 applicative et de gouvernance CI\/CD. Sa pertinence varie selon le cadre :<\/p>\n\n\n\n Lors de l’examen des rapports DAST, les auditeurs doivent regarder au-del\u00e0 du nombre brut de vuln\u00e9rabilit\u00e9s. Les \u00e9l\u00e9ments cl\u00e9s \u00e0 \u00e9valuer sont :<\/p>\n\n\n\n V\u00e9rifier l’application du DAST n\u00e9cessite de regarder au-del\u00e0 des documents de politique. Les auditeurs doivent :<\/p>\n\n\n\n Signal d’alerte :<\/strong> L’organisation dispose d’une politique DAST mais ne peut pas produire de r\u00e9sultats d’analyse pour les mises en production r\u00e9centes, ou les configurations de pipeline montrent le DAST comme une \u00e9tape optionnelle.<\/p>\n\n\n\n Sur la base des observations d’audit courantes, les constats les plus fr\u00e9quents li\u00e9s au DAST incluent :<\/p>\n\n\n\n Les organisations se pr\u00e9parant \u00e0 un audit doivent s’assurer qu’elles peuvent d\u00e9montrer :<\/p>\n\n\n\n Le DAST doit produire des preuves structur\u00e9es, conserv\u00e9es et tra\u00e7ables. Les auditeurs devraient s’attendre aux artefacts de preuves suivants d’un contr\u00f4le DAST correctement gouvern\u00e9 :<\/p>\n\n\n\n Si une organisation ne peut pas produire ces artefacts pour une version donn\u00e9e, le contr\u00f4le DAST peut exister dans la politique mais ne fonctionne pas comme preuve de gouvernance efficace.<\/p>\n\n\n\n Lors des revues d’audit, les signaux d’alerte suivants indiquent que la gouvernance DAST est faible, incompl\u00e8te ou inefficace :<\/p>\n\n\n\n Tout signal d’alerte justifie une investigation plus approfondie et devrait \u00eatre document\u00e9 comme un constat ou une observation d’audit.<\/p>\n\n\n\n Le DAST n’est g\u00e9n\u00e9ralement pas impos\u00e9 nomm\u00e9ment dans les cadres r\u00e9glementaires, mais il soutient directement les exigences cl\u00e9s des principales r\u00e9glementations et standards :<\/p>\n\n\n\n DORA exige des entit\u00e9s financi\u00e8res qu’elles maintiennent des cadres de gestion des risques ICT incluant les tests des syst\u00e8mes ICT. Le DAST soutient la conformit\u00e9 DORA en :<\/p>\n\n\n\n NIS2 exige des entit\u00e9s essentielles et importantes qu’elles mettent en \u0153uvre des mesures de gestion des risques incluant des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 et la gestion des vuln\u00e9rabilit\u00e9s. Le DAST soutient NIS2 en :<\/p>\n\n\n\n ISO 27001 exige des organisations qu’elles d\u00e9montrent des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 et l’efficacit\u00e9 des contr\u00f4les. Le DAST soutient ISO 27001 en :<\/p>\n\n\n\n Les auditeurs doivent noter que le DAST seul ne satisfait aucun de ces cadres \u2014 c’est un composant d’un ensemble plus large de contr\u00f4les de s\u00e9curit\u00e9 applicative qui devrait \u00e9galement inclure SAST, SCA et d’autres contr\u00f4les compl\u00e9mentaires.<\/p>\n\n\n\n
\n\n\n\nQu’est-ce que le DAST et pourquoi est-il important pour les auditeurs ?<\/strong><\/h2>\n\n\n\n
\n\n\n\nEn quoi le DAST diff\u00e8re-t-il du SAST et du SCA ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQuand le DAST doit-il s’ex\u00e9cuter dans un pipeline CI\/CD ?<\/strong><\/h2>\n\n\n\n
\n\n\n\nLe DAST peut-il bloquer les mises en production dans les environnements r\u00e9glement\u00e9s ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nComment les faux positifs doivent-ils \u00eatre gouvern\u00e9s dans le DAST ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQu’attendent g\u00e9n\u00e9ralement les auditeurs des contr\u00f4les DAST ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nLe DAST est-il obligatoire selon DORA, NIS2, ISO 27001 ou PCI DSS ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQue doivent rechercher les auditeurs dans les rapports DAST ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nComment les auditeurs v\u00e9rifient-ils que le DAST est correctement appliqu\u00e9 ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQuels sont les constats d’audit DAST courants ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nComment les organisations doivent-elles pr\u00e9parer leurs contr\u00f4les DAST pour l’audit ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQuelles preuves le DAST doit-il produire pour les auditeurs ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nQuels sont les signaux d’alerte DAST courants lors des audits ?<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nComment le DAST correspond-il aux exigences DORA, NIS2 et ISO 27001 ?<\/strong><\/h2>\n\n\n\n
DORA (Digital Operational Resilience Act)<\/strong><\/h3>\n\n\n\n
\n
NIS2 (Network and Information Security Directive)<\/strong><\/h3>\n\n\n\n
\n
ISO 27001 (Annexe A, A.8.25-28)<\/strong><\/h3>\n\n\n\n
\n
\n\n\n\nRessources connexes pour les auditeurs<\/strong><\/h2>\n\n\n\n
\n
\n\n\n