Le Dynamic Application Security Testing (DAST) est largement adopté dans les pipelines CI/CD d’entreprise, mais c’est aussi l’un des contrôles les plus mal compris lors des audits. De nombreuses équipes supposent que les auditeurs évalueront le DAST sur la base de la couverture des analyses ou du nombre de vulnérabilités. En réalité, les auditeurs évaluent le DAST très différemment.
Cet article explique ce que les auditeurs recherchent réellement, ce qu’ils ignorent largement et ce qui déclenche généralement des constats d’audit lors de l’examen des contrôles DAST dans les environnements réglementés.
La perspective de l’auditeur sur le DAST
Les auditeurs n’évaluent pas le DAST comme un exercice de test d’intrusion ou comme un outil de découverte de vulnérabilités. Au contraire, ils évaluent le DAST comme un mécanisme de gouvernance et de contrôle des risques intégré dans le cycle de livraison logicielle.
Du point de vue de l’audit, le DAST répond à trois questions fondamentales :
- Les tests de sécurité applicative sont-ils appliqués 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 importe bien moins que la manière dont le contrôle est conçu, appliqué et documenté.
Ce que les auditeurs examinent réellement
1. Exécution cohérente dans les pipelines CI/CD
Les auditeurs vérifient que les analyses DAST ne sont ni optionnelles ni ponctuelles. Ils s’attendent à voir :
- le DAST intégré à des étapes de pipeline définies (généralement staging ou pré-production),
- les analyses déclenchées automatiquement, pas manuellement,
- des conditions claires sous lesquelles les analyses doivent s’exécuter (branche, environnement, type de version).
Les preuves généralement examinées incluent :
- les définitions de pipeline,
- les journaux d’exécution des jobs,
- les historiques d’analyses sur plusieurs versions.
Une exécution incohérente est souvent interprétée comme un contrôle inefficace.
2. Logique de porte et de décision
Les auditeurs se concentrent fortement sur ce qui se passe lorsque le DAST détecte des problèmes.
Ils s’attendent à voir :
- des seuils de sévérité définis,
- des règles de porte de pipeline explicites,
- des processus documentés d’exceptions ou de dérogation.
Laisser passer des builds malgré des résultats est acceptable uniquement si une justification documentée, une approbation et une traçabilité existent.
Une question courante des auditeurs est :
« Montrez-moi pourquoi cette version a été autorisée malgré les résultats DAST. »
3. Gouvernance des faux positifs
Les auditeurs ne s’attendent pas à zéro faux positif. Ce qu’ils évaluent, c’est comment les faux positifs sont gérés.
Ils recherchent :
- des workflows formels de suppression,
- l’approbation des suppressions basée sur les rôles,
- la revue périodique ou l’expiration des résultats supprimés.
Les suppressions permanentes et non documentées sont un signal d’alerte fréquent lors des audits.
4. Rétention des preuves et traçabilité
Le DAST n’est auditable que si des preuves existent.
Les auditeurs s’attendent à :
- des résultats d’analyse conservés,
- un lien entre les résultats d’analyse et des builds ou versions spécifiques,
- une corrélation entre les résultats, les approbations et les décisions de déploiement.
Les preuves doivent être :
- résistantes à la falsification,
- conservées selon la politique,
- récupérables sans reconstruction manuelle.
5. Alignement avec la gestion des risques
Les auditeurs font souvent correspondre le DAST à des cadres de contrôle plus larges (ISO 27001, SOC 2, DORA, NIS2).
Ils vérifient si :
- le DAST est référencé dans les politiques de sécurité,
- les responsabilités sont clairement assignées,
- les exceptions font l’objet d’une acceptation du risque plutôt que d’être ignorées.
Le DAST sans propriété documentée est considéré comme un contrôle faible.
Ce que les auditeurs ignorent généralement
1. Marque de l’outil et arguments marketing
Les auditeurs ne se soucient généralement pas du fournisseur DAST que vous utilisez.
Ils n’évaluent pas :
- la popularité du scanner,
- les revendications d’IA,
- le nombre de vulnérabilités détectées.
Un outil basique avec une gouvernance solide est souvent perçu plus favorablement qu’un outil avancé utilisé de manière incohérente.
2. Nombre brut de vulnérabilités
Des nombres élevés de résultats n’impressionnent pas les auditeurs. Des nombres faibles ne les rassurent pas non plus.
Ce qui compte, c’est :
- la cohérence de l’exécution,
- la clarté de la prise de décision,
- les preuves de remédiation ou d’acceptation.
Les auditeurs analysent rarement les vulnérabilités individuelles, sauf dans le cadre de l’investigation d’un incident spécifique.
3. Revendications de couverture maximale des analyses
Des déclarations comme « nous analysons tout » ne sont pas convaincantes sans preuve.
Les auditeurs préfèrent :
- un périmètre défini,
- des exclusions documentées,
- 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 couramment des constats d’audit
1. Le DAST s’exécute mais n’applique rien
Si les analyses s’exécutent mais ne bloquent jamais les versions et n’ont pas de processus formel d’exception, les auditeurs concluent souvent que le DAST est uniquement informatif.
Cela conduit fréquemment à des constats tels que :
- « Le contrôle existe mais n’est pas efficace. »
2. Suppressions sans gouvernance
Les signaux d’alerte typiques incluent :
- des suppressions appliquées directement par les développeurs,
- pas de dates d’expiration,
- pas d’enregistrements de revue.
Les auditeurs peuvent interpréter cela comme une acceptation non contrôlée du risque.
3. Preuves historiques manquantes
Pouvoir montrer uniquement la dernière analyse est insuffisant.
Les auditeurs s’attendent à :
- des preuves historiques sur plusieurs versions,
- la capacité de reconstituer les décisions passées.
Les preuves manquantes entraînent souvent des constats même si les analyses ont été techniquement exécutées.
4. Exécution manuelle ou incohérente
Les analyses DAST déclenchées manuellement ou « quand le temps le permet » sont rarement acceptées dans les environnements réglementés.
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 appliqué par politique,
- un point de décision, pas seulement un scanner,
- une source de preuves, pas seulement de résultats.
Elles conçoivent le DAST avec les résultats d’audit à l’esprit dès le départ, plutôt que d’essayer de rétrofiter la gouvernance par la suite.
Point clé à retenir
Les auditeurs ne demandent pas :
« Quelle est la qualité de votre outil DAST ? »
Ils demandent :
« Pouvez-vous prouver que les tests de sécurité applicative sont appliqués, gouvernés et auditables ? »
Les équipes qui comprennent cette distinction évitent la plupart des constats d’audit liés au DAST.
Articles DAST connexes
- Meilleurs outils DAST pour les pipelines CI/CD d’entreprise
- Sélection d’un outil DAST adapté aux pipelines CI/CD d’entreprise
- Sélection d’outils DAST — Matrice d’évaluation RFP (entreprise et environnements réglementés)
- Comparaison des outils DAST d’entreprise : évaluation basée sur RFP
- Gestion des faux positifs dans les pipelines DAST d’entreprise
- Sélection d’outils DAST pour les entreprises — Liste de vérification d’audit
