Comparer les contrôles de tests de sécurité CI/CD : ce que les auditeurs, les responsables conformité et les 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 fréquemment comparés sur la base de leurs capacités techniques de détection. Pour les auditeurs et les 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 avec les référentiels de conformité.
Cet article compare le SAST (Static Application Security Testing), le DAST (Dynamic Application Security Testing) et le SCA (Software Composition Analysis) sous l’angle de la gouvernance et de l’audit, afin d’aider les auditeurs à comprendre ce que fait chaque contrôle, quelles preuves il doit 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 classification de gravité et décisions de conformité (réussite/échec) aux politiques |
| Capacité d’application dans le 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 reliés à des builds, des commits et des versions spécifiques |
| Alignement avec les référentiels de conformité | DORA (contrôle préventif du codage), NIS2 (SDLC sécurisé), ISO 27001 (A.8.25-28), SOC 2 (CC8.1), PCI DSS (6.3) |
| Exigences de gouvernance | Seuils de gravité définis, politiques de suppression documentées, conservation des résultats de scan |
Ce que les auditeurs doivent vérifier pour le SAST :
- Le SAST s’exécute automatiquement à chaque build ou pull request — pas uniquement à la demande
- Les seuils de gravité sont définis et appliqués (les builds échouent lorsque les seuils sont franchis)
- Les constats supprimés disposent de justifications documentées avec dates de revue et d’expiration
- Les résultats de scan sont conservés et reliés à des versions spécifiques
- Toutes les bases de code de production sont couvertes par l’analyse SAST
Signaux d’alerte pour le SAST :
- Le SAST est configuré mais non appliqué — les builds se poursuivent quels que soient les constats
- Un grand nombre de constats supprimés sans justification documentée ni date d’expiration
- Les résultats de scan ne peuvent pas être reliés à des versions ou des builds spécifiques
- Il existe des bases de code de production non couvertes par l’analyse SAST
- Le SAST ne s’exécute qu’à la demande plutôt qu’automatiquement à 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é à l’exécution des applications déployées ou en préproduction |
| Qualité des preuves | Moyenne à élevée — produit des constats à l’exécution mais peut nécessiter du contexte pour être interprétée |
| Capacité d’application dans le CI/CD | Moyenne — généralement utilisé comme porte de livraison, non comme porte au moment du build |
| Traçabilité d’audit | Moyenne — les résultats sont reliés aux environnements et aux versions, mais la traçabilité vers des changements de code spécifiques est indirecte |
| Alignement avec les référentiels de conformité | DORA (validation à l’exécution), 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 blocage documentée, flux d’exception et d’approbation |
Ce que les auditeurs doivent vérifier pour le DAST :
- Le DAST s’exécute avant les livraisons en production, pas uniquement à la demande ni selon un calendrier déconnecté des déploiements
- Des seuils définis existent pour bloquer ou retarder les livraisons
- Les exceptions au blocage DAST sont documentées avec approbations et justifications
- La gestion des faux positifs suit un processus gouverné (suppression basée sur les rôles, justification documentée, expiration)
- Le périmètre du DAST couvre toutes les applications exposées vers l’extérieur et critiques
Signaux d’alerte pour le DAST :
- Le DAST ne s’exécute qu’occasionnellement ou selon un calendrier déconnecté du processus de livraison
- Aucune logique de blocage n’existe — toutes les livraisons se poursuivent quels que soient les constats DAST
- Les résultats DAST ne peuvent pas être reliés à des déploiements ou des versions spécifiques
- Les applications exposées vers l’extérieur ou critiques sont exclues du périmètre du 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 la 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, des SBOM, des rapports de vulnérabilités et des enregistrements de conformité des licences |
| Capacité d’application dans le 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 les inventaires de dépendances fournissent des enregistrements clairs et auditables par version |
| Alignement avec les référentiels de conformité | NIS2 (risque de chaîne d’approvisionnement), DORA (risque lié aux tiers TIC), 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 conservation des SBOM, procédures de réponse aux vulnérabilités |
Ce que les auditeurs doivent vérifier pour le SCA :
- Le SCA s’exécute automatiquement pendant les builds et produit des inventaires de dépendances à jour
- Des SBOM sont générés et conservés pour chaque version
- 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 le SCA :
- Aucun inventaire de dépendances ni SBOM n’existe pour les applications de production
- Les vulnérabilités critiques connues dans les dépendances ne sont pas traitées ni documentées
- Le 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 à l’exécution | Gestion du risque de chaîne d’approvisionnement |
| Qualité des preuves | Élevée | Moyenne à élevée | Très élevée |
| Capacité d’application dans le CI/CD | Forte (blocage du build) | Moyenne (blocage de la livraison) | Forte (blocage des dépendances) |
| Traçabilité d’audit | Élevée (reliée au commit) | Moyenne (reliée à l’environnement) | Très élevée (reliée au SBOM) |
| Alignement avec les référentiels de conformité | Large | Large | Critique pour les réglementations sur la chaîne d’approvisionnement |
| Complexité de gouvernance | Moyenne (gestion des suppressions) | Moyenne à élevée (gouvernance des faux positifs) | Moyenne (gestion de la politique 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 du risque TIC et la résilience opérationnelle des entités financières. Du point de vue de l’audit :
- Le SCA est critique — DORA exige une visibilité sur le risque lié aux tiers TIC, y compris les dépendances logicielles
- Le SAST est important — il soutient les contrôles préventifs au sein du cycle de développement sécurisé
- Le DAST apporte une validation complémentaire — il démontre les tests à l’exécution 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 :
- Le SCA est essentiel — il traite directement les exigences de risque liées à la chaîne d’approvisionnement et aux dépendances
- Le SAST soutient le développement sécurisé — il s’aligne avec les exigences des pratiques de sécurité dès la conception
- Le DAST valide l’exposition des services — il aide à démontrer que les services exposés vers l’extérieur sont testés
ISO 27001
ISO 27001 exige des organisations qu’elles démontrent l’efficacité de leurs contrôles à travers le système de management de la sécurité de l’information :
- Les trois contrôles sont pertinents — ils démontrent collectivement des pratiques de développement sécurisé (contrôles de l’Annexe A, A.8.25–28)
- Le SCA fournit souvent les preuves les plus claires — les SBOM et les 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 distinctes
SOC 2
SOC 2 évalue les contrôles liés à la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la protection des données personnelles :
- Le SAST et le SCA soutiennent les critères de service de confiance Sécurité et Intégrité du traitement
- Le DAST soutient la preuve des tests de sécurité à l’exécution
- Les auditeurs doivent se concentrer sur le fait que les contrôles sont appliqués de manière cohérente et produisent des preuves conservées
PCI DSS
PCI DSS comporte des exigences explicites en matière de tests de sécurité des applications :
- Le SAST est directement référencé (exigence 6.3) — des revues de code ou une analyse automatisée du code sont requises
- Le DAST est directement référencé (exigences 6.4, 11.3) — les tests de sécurité des applications web sont obligatoires
- Le 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 par couches
- Le SAST et le SCA sont fondamentaux — ils doivent être présents dans tout pipeline CI/CD mature
- Le DAST ajoute une validation à l’exécution mais ne doit pas être le seul contrôle de test
- L’application dans le CI/CD compte plus que la profondeur du scan — un contrôle qui s’exécute mais ne bloque pas est faible
- La qualité des preuves compte plus que le nombre de vulnérabilités — recherchez la traçabilité, la conservation et la gouvernance
Les pipelines les plus auditables utilisent :
Le SAST + le SCA appliqués par défaut, le DAST à des points de contrôle définis, avec tous les résultats conservés et traçables.
Correspondance outils → contrôles
La comparaison ci-dessus se concentre sur ce que le SAST, le DAST et le SCA accomplissent en tant que contrôles individuels. Dans un pipeline réel, ces contrôles de test coexistent avec un ensemble plus large de catégories d’outillage, et les auditeurs n’en évaluent aucun de manière isolée : ils évaluent quels contrôles sont appliqués, où et avec quelle cohérence. Un outil de sécurité n’a de valeur d’audit que lorsqu’il applique un contrôle concret et génère des preuves fiables. La correspondance ci-dessous montre comment chaque catégorie d’outillage de sécurité CI/CD soutient les contrôles fondamentaux attendus dans les environnements d’entreprise et réglementés, et quelles preuves chacune doit produire.
Pourquoi la correspondance outil-contrôle est importante
Sans correspondance claire :
- l’outillage devient une « sécurité pour cocher des cases »
- les contrôles restent théoriques
- les preuves d’audit sont fragmentées
- la responsabilité est floue
Les auditeurs demandent généralement :
Quel contrôle cet outil applique-t-il, et où sont les preuves ?
Cette section répond à cette question.
Les principales catégories d’outillage de sécurité CI/CD correspondent aux contrôles fondamentaux comme suit. Pour chaque catégorie, les questions pertinentes pour un auditeur sont les mêmes : quel contrôle cet outil applique-t-il, et où sont les preuves ?
1. Outils de sécurité du code source et des dépôts
Outils typiques
- Fonctionnalités de sécurité des plateformes Git
- Protection des branches
- Détection des secrets
Contrôles appliqués
- Gestion des identités et des accès
- Gestion des changements et approbations
- Séparation des tâches
- Traçabilité des changements
Preuves d’audit
- historique des commits
- approbations de pull requests
- règles de protection des branches
- journaux d’accès
2. Fonctionnalités de sécurité natives de la plateforme CI/CD
Outils typiques
- RBAC de la plateforme CI/CD
- Portes d’approbation
- Protection des environnements
Contrôles appliqués
- Usage obligatoire du CI/CD
- Gestion des changements et approbations
- Séparation des tâches
Preuves d’audit
- journaux d’exécution du pipeline
- enregistrements d’approbation
- historique des déploiements
3. Outils de gestion et de détection des secrets
Outils typiques
- Scanners de secrets
- Coffres-forts / gestionnaires de secrets cloud
Contrôles appliqués
- Protection des secrets
- Gestion des identités et des accès
Preuves d’audit
- journaux d’accès aux secrets
- historique de rotation
- absence de secrets dans le code
4. Tests statiques de sécurité des applications (SAST)
Outils typiques
- Moteurs d’analyse de code
- Scanners basés sur des politiques
Contrôles appliqués
- Tests de sécurité automatisés
- Application d’un SDLC sécurisé
Preuves d’audit
- rapports de scan
- décisions de politique
- builds bloqués
5. Analyse de composition logicielle (SCA)
Outils typiques
- Scanners de dépendances
- Outils de conformité des licences
Contrôles appliqués
- Risque tiers et de chaîne d’approvisionnement
- Tests de sécurité automatisés
Preuves d’audit
- inventaires de dépendances
- rapports de vulnérabilités
- SBOM
6. Outils d’intégrité des builds et de sécurité des artefacts
Outils typiques
- Signature des artefacts
- Outils de provenance et d’attestation
- Registres immuables
Contrôles appliqués
- Intégrité et provenance des artefacts
- Atténuation du risque de chaîne d’approvisionnement
Preuves d’audit
- artefacts signés
- SBOM
- attestations de provenance
7. Tests dynamiques de sécurité des applications (DAST)
Outils typiques
- Scanners de vulnérabilités web/API
Contrôles appliqués
- Tests de sécurité automatisés
- Validation à l’exécution
Preuves d’audit
- journaux d’exécution des scans
- rapports de vulnérabilités
- décisions de porte de livraison
8. Outils de journalisation, de surveillance et de preuve
Outils typiques
- Plateformes d’agrégation de journaux
- SIEM
- Systèmes de surveillance et d’alerte
Contrôles appliqués
- Journalisation et conservation des preuves
- Détection et réponse aux incidents
Preuves d’audit
- journaux centralisés
- alertes
- enregistrements d’incidents
9. Outils de gouvernance des tiers et de la chaîne d’approvisionnement
Outils typiques
- Plateformes de gestion du risque fournisseur
- Systèmes de suivi des dépendances
Contrôles appliqués
- Risque tiers et de chaîne d’approvisionnement
- Gouvernance et supervision
Preuves d’audit
- inventaires de fournisseurs
- évaluations des risques
- contrôles contractuels
Outils → contrôles en un coup d’œil
| Catégorie d’outils | Principaux contrôles appliqués |
|---|---|
| Sécurité des dépôts | IAM, gestion des changements, séparation des tâches |
| Plateforme CI/CD | Pipeline obligatoire, approbations |
| Outils de secrets | Protection des secrets, IAM |
| SAST | SDLC sécurisé, tests automatisés |
| SCA | Risque de chaîne d’approvisionnement, tests |
| Sécurité des artefacts | Intégrité, provenance |
| DAST | Tests de sécurité à l’exécution |
| Journalisation et SIEM | Preuves, réponse aux incidents |
| Gouvernance des fournisseurs | Risque tiers |
Comment les auditeurs utilisent cette correspondance
Les auditeurs, généralement :
- partent d’un contrôle
- demandent quel système l’applique
- réclament des preuves issues de ce système
Une correspondance claire :
- réduit le temps d’audit
- évite les preuves en double
- renforce la responsabilité des contrôles
Conclusion
Le SAST, le DAST et le SCA répondent à 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é de ses preuves, sa traçabilité et son alignement avec 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 reliées à des versions spécifiques ? Et une gouvernance est-elle en place pour les exceptions et les suppressions ?
Pour aller plus loin (auditeurs)
- Glossaire des termes de sécurité et de conformité CI/CD
- L’architecture de double conformité expliquée
- Comment les auditeurs examinent réellement les pipelines CI/CD
