Comparaison des contrôles de tests de sécurité CI/CD : ce que les auditeurs, responsables conformité et régulateurs doivent savoir
Les contrôles de tests de sécurité dans les pipelines CI/CD — communément désignés par SAST, DAST et SCA — sont souvent comparés sur la base de leurs capacités de détection technique. Pour les auditeurs et responsables conformité, les dimensions de comparaison pertinentes sont différentes : objectifs de contrôle, qualité des preuves, capacité d’application, traçabilité d’audit et alignement sur les cadres de conformité.
Cet article compare SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) et SCA (Software Composition Analysis) du point de vue de la gouvernance et de l’audit, aidant les auditeurs à comprendre ce que fait chaque contrôle, quelles preuves il devrait produire et comment vérifier qu’il est correctement mis en œuvre.
SAST — Propriétés de contrôle pour les auditeurs
| Propriété de contrôle | SAST (Static Application Security Testing) |
|---|---|
| Objectif de contrôle | Détecter les vulnérabilités de sécurité dans le code source avant le déploiement |
| Qualité des preuves | Élevée — produit des rapports de scan détaillés avec classifications de sévérité et décisions de politique réussite/échec |
| Capacité d’application CI/CD | Forte — peut bloquer les builds et empêcher le déploiement lorsque les seuils sont dépassés |
| Traçabilité d’audit | Élevée — les résultats peuvent être liés à des builds, commits et releases spécifiques |
| Alignement sur les cadres de conformité | DORA (contrôle préventif du code), NIS2 (SDLC sécurisé), ISO 27001 (A.8.25-28), SOC 2 (CC8.1), PCI DSS (6.3) |
| Exigences de gouvernance | Seuils de sévérité définis, politiques de suppression documentées, rétention des résultats de scan |
Ce que les auditeurs doivent vérifier pour SAST :
- SAST s’exécute automatiquement à chaque build ou pull request — pas uniquement à la demande
- Les seuils de sévérité sont définis et appliqués (les builds échouent quand les seuils sont dépassés)
- Les résultats supprimés ont des justifications documentées avec dates de révision et d’expiration
- Les résultats de scan sont conservés et liés à des releases spécifiques
- Tous les codes en production sont couverts par le scan SAST
Signaux d’alerte pour SAST :
- SAST est configuré mais non appliqué — les builds continuent indépendamment des résultats
- Grand nombre de résultats supprimés sans justification documentée ni date d’expiration
- Les résultats de scan ne peuvent pas être tracés à des releases ou builds spécifiques
- Des codes en production existent qui ne sont pas couverts par le scan SAST
- SAST ne s’exécute qu’à la demande plutôt qu’automatiquement dans chaque build
DAST — Propriétés de contrôle pour les auditeurs
| Propriété de contrôle | DAST (Dynamic Application Security Testing) |
|---|---|
| Objectif de contrôle | Valider la sécurité en runtime des applications déployées ou en staging |
| Qualité des preuves | Moyenne à élevée — produit des résultats en runtime mais peut nécessiter du contexte pour interprétation |
| Capacité d’application CI/CD | Moyenne — généralement utilisé comme porte de mise en production, pas comme porte de build |
| Traçabilité d’audit | Moyenne — les résultats sont liés aux environnements et releases, mais la traçabilité vers des changements de code spécifiques est indirecte |
| Alignement sur les cadres de conformité | DORA (validation en runtime), ISO 27001 (A.8.25-28), SOC 2 (CC7.1), PCI DSS (6.4, 11.3) |
| Exigences de gouvernance | Points d’exécution définis, logique de porte documentée, flux d’exception et d’approbation |
Ce que les auditeurs doivent vérifier pour DAST :
- DAST s’exécute avant les mises en production, pas uniquement à la demande ou sur un planning déconnecté des déploiements
- Des seuils définis existent pour bloquer ou retarder les releases
- Les exceptions aux portes DAST sont documentées avec approbations et justifications
- La gestion des faux positifs suit un processus gouverné (suppression par rôle, justification documentée, expiration)
- Le périmètre DAST couvre toutes les applications exposées et critiques
Signaux d’alerte pour DAST :
- DAST ne s’exécute qu’occasionnellement ou sur un planning déconnecté du processus de release
- Aucune logique de porte n’existe — toutes les releases continuent indépendamment des résultats DAST
- Les résultats DAST ne peuvent pas être liés à des déploiements ou releases spécifiques
- Les applications exposées ou critiques sont exclues du périmètre DAST
- Les faux positifs sont supprimés sans approbations documentées ni dates d’expiration
SCA — Propriétés de contrôle pour les auditeurs
| Propriété de contrôle | SCA (Software Composition Analysis) |
|---|---|
| Objectif de contrôle | Gérer le risque tiers et de chaîne d’approvisionnement en identifiant les dépendances vulnérables et non conformes |
| Qualité des preuves | Très élevée — produit des inventaires de dépendances, SBOM, rapports de vulnérabilités et enregistrements de conformité des licences |
| Capacité d’application CI/CD | Forte — peut bloquer les builds lorsque des dépendances vulnérables ou non conformes sont détectées |
| Traçabilité d’audit | Très élevée — les SBOM et inventaires de dépendances fournissent des enregistrements clairs et auditables par release |
| Alignement sur les cadres de conformité | NIS2 (risque chaîne d’approvisionnement), DORA (risque tiers ICT), ISO 27001 (A.8.25-28), SOC 2 (CC3.2), PCI DSS (6.3) |
| Exigences de gouvernance | Politiques d’approbation des dépendances, génération et rétention des SBOM, procédures de réponse aux vulnérabilités |
Ce que les auditeurs doivent vérifier pour SCA :
- SCA s’exécute automatiquement pendant les builds et produit des inventaires de dépendances à jour
- Les SBOM sont générés et conservés pour chaque release
- Les dépendances vulnérables connues déclenchent des réponses définies (blocage, alerte ou acceptation documentée du risque)
- La conformité des licences est activement surveillée et les violations sont traitées
- Les politiques de dépendances définissent les composants acceptables et les processus d’approbation des exceptions
Signaux d’alerte pour SCA :
- Aucun inventaire de dépendances ou SBOM n’existe pour les applications en production
- Les vulnérabilités critiques connues dans les dépendances ne sont pas traitées ni documentées
- SCA n’est pas intégré au CI/CD — il s’exécute manuellement ou pas du tout
- Aucune gouvernance sur les composants tiers pouvant être utilisés
- La conformité des licences n’est pas surveillée, créant un risque juridique et réglementaire
Comparaison côte à côte : SAST vs DAST vs SCA du point de vue de l’audit
| Dimension d’audit | SAST | DAST | SCA |
|---|---|---|---|
| Objectif de contrôle | Sécurité préventive au niveau du code | Validation en runtime | Gestion du risque de chaîne d’approvisionnement |
| Qualité des preuves | Élevée | Moyenne-Élevée | Très élevée |
| Capacité d’application CI/CD | Forte (porte de build) | Moyenne (porte de release) | Forte (blocage de dépendances) |
| Traçabilité d’audit | Élevée (liée aux commits) | Moyenne (liée aux environnements) | Très élevée (SBOM-linked) |
| Alignement sur les cadres de conformité | Large | Large | Critique pour les réglementations de chaîne d’approvisionnement |
| Complexité de gouvernance | Moyenne (gestion des suppressions) | Moyenne-Élevée (false positive governance) | Moyenne (gestion des politiques de dépendances) |
Quels contrôles comptent le plus sous chaque réglementation
DORA (Digital Operational Resilience Act)
DORA met l’accent sur la gestion des risques ICT et la résilience opérationnelle des entités financières. Du point de vue de l’audit :
- SCA est critique — DORA exige une visibilité sur le risque tiers ICT, y compris les dépendances logicielles
- SAST est important — soutient les contrôles préventifs dans le cycle de développement sécurisé
- DAST fournit une validation complémentaire — démontre les tests en runtime des services déployés
NIS2 (Network and Information Security Directive)
NIS2 se concentre sur la sécurité de la chaîne d’approvisionnement, la gestion des incidents et la gestion des risques pour les entités essentielles et importantes :
- SCA est essentiel — répond directement aux exigences de risque de chaîne d’approvisionnement et de dépendances
- SAST soutient le développement sécurisé — s’aligne sur les exigences de pratiques sécurisées dès la conception
- DAST valide l’exposition des services — aide à démontrer que les services exposés sont testés
ISO 27001
ISO 27001 exige des organisations qu’elles démontrent l’efficacité des contrôles dans le système de management de la sécurité de l’information :
- Les trois contrôles sont pertinents — ils démontrent collectivement les pratiques de développement sécurisé (contrôles Annexe A A.8.25–28)
- SCA fournit souvent les preuves les plus claires — les SBOM et inventaires de dépendances sont des artefacts tangibles et auditables
- Les auditeurs doivent vérifier que les contrôles sont intégrés au CI/CD, et non réalisés comme des activités manuelles séparées
SOC 2
SOC 2 évalue les contrôles liés à la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la vie privée :
- SAST et SCA soutiennent les critères de confiance Sécurité et Intégrité du traitement
- DAST soutient les preuves de tests de sécurité en runtime
- Les auditeurs doivent se concentrer sur le fait que les contrôles sont appliqués de manière constante et produisent des preuves conservées
PCI DSS
PCI DSS a des exigences explicites pour les tests de sécurité des applications :
- SAST est directement référencé (Exigence 6.3) — les revues de code ou l’analyse automatisée de code sont requises
- DAST est directement référencé (Exigences 6.4, 11.3) — les tests de sécurité des applications web sont obligatoires
- SCA soutient les exigences de gestion des vulnérabilités en suivant les vulnérabilités connues dans les dépendances
Conseils pratiques pour les auditeurs
- Aucun contrôle unique n’est suffisant — les organisations doivent démontrer une approche en couches
- SAST et SCA sont fondamentaux — ils devraient être présents dans tout pipeline CI/CD mature
- DAST ajoute la validation en runtime mais ne devrait pas être le seul contrôle de test
- L’application CI/CD compte plus que la profondeur de scan — un contrôle qui s’exécute mais ne bloque pas est faible
- Qualité des preuves matters more than vulnerability count — look for traceability, retention, and governance
Les pipelines les plus auditables utilisent :
SAST + SCA appliqués par défaut, DAST à des points de contrôle définis, avec tous les résultats conservés et traçables.
Conclusion
SAST, DAST et SCA servent des objectifs de contrôle différents mais complémentaires au sein des pipelines CI/CD. Pour les auditeurs, la valeur de chaque contrôle ne réside pas dans ses capacités de détection, mais dans son application, la qualité des preuves, la traçabilité et l’alignement sur les réglementations applicables.
Lors de l’évaluation des contrôles de tests de sécurité CI/CD, concentrez-vous sur : Le contrôle est-il appliqué ? Produit-il des preuves fiables ? Ces preuves peuvent-elles être tracées à des releases spécifiques ? Et une gouvernance est-elle en place pour les exceptions et les suppressions ?
Ressources connexes pour les auditeurs
- Glossaire des termes de sécurité et conformité CI/CD
- Outils de sécurité CI/CD — Correspondance des contrôles
- Architecture de double conformité expliquée
- Comment les auditeurs examinent réellement les pipelines CI/CD
