{"id":1287,"date":"2026-01-10T11:35:14","date_gmt":"2026-01-10T10:35:14","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/ci-cd-security-tooling-comparison-tables-2\/"},"modified":"2026-07-07T10:45:29","modified_gmt":"2026-07-07T09:45:29","slug":"ci-cd-security-tooling-comparison-tables","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/tool-governance\/ci-cd-security-tooling-comparison-tables\/","title":{"rendered":"Contr\u00f4les de tests de s\u00e9curit\u00e9 CI\/CD \u2014 SAST, DAST et SCA du point de vue de l’auditeur"},"content":{"rendered":"\n

Comparer les contr\u00f4les de tests de s\u00e9curit\u00e9 CI\/CD : ce que les auditeurs, les responsables conformit\u00e9 et les r\u00e9gulateurs doivent savoir<\/strong><\/p>\n\n\n\n

Les contr\u00f4les de tests de s\u00e9curit\u00e9 dans les pipelines CI\/CD \u2014 commun\u00e9ment d\u00e9sign\u00e9s par SAST, DAST et SCA \u2014 sont fr\u00e9quemment compar\u00e9s sur la base de leurs capacit\u00e9s techniques de d\u00e9tection. Pour les auditeurs et les responsables conformit\u00e9, les dimensions de comparaison pertinentes sont diff\u00e9rentes : objectifs de contr\u00f4le, qualit\u00e9 des preuves, capacit\u00e9 d’application, tra\u00e7abilit\u00e9 d’audit et alignement avec les r\u00e9f\u00e9rentiels de conformit\u00e9<\/strong>.<\/p>\n\n\n\n

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 \u00e0 comprendre ce que fait chaque contr\u00f4le, quelles preuves il doit produire et comment v\u00e9rifier qu’il est correctement mis en \u0153uvre.<\/p>\n\n\n\n

\n\n\n\n

SAST \u2014 propri\u00e9t\u00e9s de contr\u00f4le pour les auditeurs<\/strong><\/h2>\n\n\n\n
Propri\u00e9t\u00e9 de contr\u00f4le<\/strong><\/th>SAST (Static Application Security Testing)<\/strong><\/th><\/tr><\/thead>
Objectif de contr\u00f4le<\/td>D\u00e9tecter les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 dans le code source avant le d\u00e9ploiement<\/td><\/tr>
Qualit\u00e9 des preuves<\/td>\u00c9lev\u00e9e \u2014 produit des rapports de scan d\u00e9taill\u00e9s avec classification de gravit\u00e9 et d\u00e9cisions de conformit\u00e9 (r\u00e9ussite\/\u00e9chec) aux politiques<\/td><\/tr>
Capacit\u00e9 d’application dans le CI\/CD<\/td>Forte \u2014 peut bloquer les builds et emp\u00eacher le d\u00e9ploiement lorsque les seuils sont d\u00e9pass\u00e9s<\/td><\/tr>
Tra\u00e7abilit\u00e9 d’audit<\/td>\u00c9lev\u00e9e \u2014 les r\u00e9sultats peuvent \u00eatre reli\u00e9s \u00e0 des builds, des commits et des versions sp\u00e9cifiques<\/td><\/tr>
Alignement avec les r\u00e9f\u00e9rentiels de conformit\u00e9<\/td>DORA (contr\u00f4le pr\u00e9ventif du codage), NIS2 (SDLC s\u00e9curis\u00e9), ISO 27001 (A.8.25-28), SOC 2 (CC8.1), PCI DSS (6.3)<\/td><\/tr>
Exigences de gouvernance<\/td>Seuils de gravit\u00e9 d\u00e9finis, politiques de suppression document\u00e9es, conservation des r\u00e9sultats de scan<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Ce que les auditeurs doivent v\u00e9rifier pour le SAST :<\/strong><\/p>\n\n\n\n

    \n
  • Le SAST s’ex\u00e9cute automatiquement \u00e0 chaque build ou pull request \u2014 pas uniquement \u00e0 la demande<\/li>\n\n\n\n
  • Les seuils de gravit\u00e9 sont d\u00e9finis et appliqu\u00e9s (les builds \u00e9chouent lorsque les seuils sont franchis)<\/li>\n\n\n\n
  • Les constats supprim\u00e9s disposent de justifications document\u00e9es avec dates de revue et d’expiration<\/li>\n\n\n\n
  • Les r\u00e9sultats de scan sont conserv\u00e9s et reli\u00e9s \u00e0 des versions sp\u00e9cifiques<\/li>\n\n\n\n
  • Toutes les bases de code de production sont couvertes par l’analyse SAST<\/li>\n<\/ul>\n\n\n\n

    Signaux d’alerte pour le SAST :<\/strong><\/p>\n\n\n\n

      \n
    • Le SAST est configur\u00e9 mais non appliqu\u00e9 \u2014 les builds se poursuivent quels que soient les constats<\/li>\n\n\n\n
    • Un grand nombre de constats supprim\u00e9s sans justification document\u00e9e ni date d’expiration<\/li>\n\n\n\n
    • Les r\u00e9sultats de scan ne peuvent pas \u00eatre reli\u00e9s \u00e0 des versions ou des builds sp\u00e9cifiques<\/li>\n\n\n\n
    • Il existe des bases de code de production non couvertes par l’analyse SAST<\/li>\n\n\n\n
    • Le SAST ne s’ex\u00e9cute qu’\u00e0 la demande plut\u00f4t qu’automatiquement \u00e0 chaque build<\/li>\n<\/ul>\n\n\n\n
      \n\n\n\n

      DAST \u2014 propri\u00e9t\u00e9s de contr\u00f4le pour les auditeurs<\/strong><\/h2>\n\n\n\n
      Propri\u00e9t\u00e9 de contr\u00f4le<\/strong><\/th>DAST (Dynamic Application Security Testing)<\/strong><\/th><\/tr><\/thead>
      Objectif de contr\u00f4le<\/td>Valider la s\u00e9curit\u00e9 \u00e0 l’ex\u00e9cution des applications d\u00e9ploy\u00e9es ou en pr\u00e9production<\/td><\/tr>
      Qualit\u00e9 des preuves<\/td>Moyenne \u00e0 \u00e9lev\u00e9e \u2014 produit des constats \u00e0 l’ex\u00e9cution mais peut n\u00e9cessiter du contexte pour \u00eatre interpr\u00e9t\u00e9e<\/td><\/tr>
      Capacit\u00e9 d’application dans le CI\/CD<\/td>Moyenne \u2014 g\u00e9n\u00e9ralement utilis\u00e9 comme porte de livraison, non comme porte au moment du build<\/td><\/tr>
      Tra\u00e7abilit\u00e9 d’audit<\/td>Moyenne \u2014 les r\u00e9sultats sont reli\u00e9s aux environnements et aux versions, mais la tra\u00e7abilit\u00e9 vers des changements de code sp\u00e9cifiques est indirecte<\/td><\/tr>
      Alignement avec les r\u00e9f\u00e9rentiels de conformit\u00e9<\/td>DORA (validation \u00e0 l’ex\u00e9cution), ISO 27001 (A.8.25-28), SOC 2 (CC7.1), PCI DSS (6.4, 11.3)<\/td><\/tr>
      Exigences de gouvernance<\/td>Points d’ex\u00e9cution d\u00e9finis, logique de blocage document\u00e9e, flux d’exception et d’approbation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Ce que les auditeurs doivent v\u00e9rifier pour le DAST :<\/strong><\/p>\n\n\n\n

        \n
      • Le DAST s’ex\u00e9cute avant les livraisons en production, pas uniquement \u00e0 la demande ni selon un calendrier d\u00e9connect\u00e9 des d\u00e9ploiements<\/li>\n\n\n\n
      • Des seuils d\u00e9finis existent pour bloquer ou retarder les livraisons<\/li>\n\n\n\n
      • Les exceptions au blocage DAST sont document\u00e9es avec approbations et justifications<\/li>\n\n\n\n
      • La gestion des faux positifs suit un processus gouvern\u00e9 (suppression bas\u00e9e sur les r\u00f4les, justification document\u00e9e, expiration)<\/li>\n\n\n\n
      • Le p\u00e9rim\u00e8tre du DAST couvre toutes les applications expos\u00e9es vers l’ext\u00e9rieur et critiques<\/li>\n<\/ul>\n\n\n\n

        Signaux d’alerte pour le DAST :<\/strong><\/p>\n\n\n\n

          \n
        • Le DAST ne s’ex\u00e9cute qu’occasionnellement ou selon un calendrier d\u00e9connect\u00e9 du processus de livraison<\/li>\n\n\n\n
        • Aucune logique de blocage n’existe \u2014 toutes les livraisons se poursuivent quels que soient les constats DAST<\/li>\n\n\n\n
        • Les r\u00e9sultats DAST ne peuvent pas \u00eatre reli\u00e9s \u00e0 des d\u00e9ploiements ou des versions sp\u00e9cifiques<\/li>\n\n\n\n
        • Les applications expos\u00e9es vers l’ext\u00e9rieur ou critiques sont exclues du p\u00e9rim\u00e8tre du DAST<\/li>\n\n\n\n
        • Les faux positifs sont supprim\u00e9s sans approbations document\u00e9es ni dates d’expiration<\/li>\n<\/ul>\n\n\n\n
          \n\n\n\n

          SCA \u2014 propri\u00e9t\u00e9s de contr\u00f4le pour les auditeurs<\/strong><\/h2>\n\n\n\n
          Propri\u00e9t\u00e9 de contr\u00f4le<\/strong><\/th>SCA (Software Composition Analysis)<\/strong><\/th><\/tr><\/thead>
          Objectif de contr\u00f4le<\/td>G\u00e9rer le risque tiers et de la cha\u00eene d’approvisionnement en identifiant les d\u00e9pendances vuln\u00e9rables et non conformes<\/td><\/tr>
          Qualit\u00e9 des preuves<\/td>Tr\u00e8s \u00e9lev\u00e9e \u2014 produit des inventaires de d\u00e9pendances, des SBOM, des rapports de vuln\u00e9rabilit\u00e9s et des enregistrements de conformit\u00e9 des licences<\/td><\/tr>
          Capacit\u00e9 d’application dans le CI\/CD<\/td>Forte \u2014 peut bloquer les builds lorsque des d\u00e9pendances vuln\u00e9rables ou non conformes sont d\u00e9tect\u00e9es<\/td><\/tr>
          Tra\u00e7abilit\u00e9 d’audit<\/td>Tr\u00e8s \u00e9lev\u00e9e \u2014 les SBOM et les inventaires de d\u00e9pendances fournissent des enregistrements clairs et auditables par version<\/td><\/tr>
          Alignement avec les r\u00e9f\u00e9rentiels de conformit\u00e9<\/td>NIS2 (risque de cha\u00eene d’approvisionnement), DORA (risque li\u00e9 aux tiers TIC), ISO 27001 (A.8.25-28), SOC 2 (CC3.2), PCI DSS (6.3)<\/td><\/tr>
          Exigences de gouvernance<\/td>Politiques d’approbation des d\u00e9pendances, g\u00e9n\u00e9ration et conservation des SBOM, proc\u00e9dures de r\u00e9ponse aux vuln\u00e9rabilit\u00e9s<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

          Ce que les auditeurs doivent v\u00e9rifier pour le SCA :<\/strong><\/p>\n\n\n\n

            \n
          • Le SCA s’ex\u00e9cute automatiquement pendant les builds et produit des inventaires de d\u00e9pendances \u00e0 jour<\/li>\n\n\n\n
          • Des SBOM sont g\u00e9n\u00e9r\u00e9s et conserv\u00e9s pour chaque version<\/li>\n\n\n\n
          • Les d\u00e9pendances vuln\u00e9rables connues d\u00e9clenchent des r\u00e9ponses d\u00e9finies (blocage, alerte ou acceptation document\u00e9e du risque)<\/li>\n\n\n\n
          • La conformit\u00e9 des licences est activement surveill\u00e9e et les violations sont trait\u00e9es<\/li>\n\n\n\n
          • Les politiques de d\u00e9pendances d\u00e9finissent les composants acceptables et les processus d’approbation des exceptions<\/li>\n<\/ul>\n\n\n\n

            Signaux d’alerte pour le SCA :<\/strong><\/p>\n\n\n\n

              \n
            • Aucun inventaire de d\u00e9pendances ni SBOM n’existe pour les applications de production<\/li>\n\n\n\n
            • Les vuln\u00e9rabilit\u00e9s critiques connues dans les d\u00e9pendances ne sont pas trait\u00e9es ni document\u00e9es<\/li>\n\n\n\n
            • Le SCA n’est pas int\u00e9gr\u00e9 au CI\/CD \u2014 il s’ex\u00e9cute manuellement ou pas du tout<\/li>\n\n\n\n
            • Aucune gouvernance sur les composants tiers pouvant \u00eatre utilis\u00e9s<\/li>\n\n\n\n
            • La conformit\u00e9 des licences n’est pas surveill\u00e9e, cr\u00e9ant un risque juridique et r\u00e9glementaire<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n

              Comparaison c\u00f4te \u00e0 c\u00f4te : SAST vs DAST vs SCA du point de vue de l’audit<\/strong><\/h2>\n\n\n\n
              Dimension d’audit<\/strong><\/th>SAST<\/strong><\/th>DAST<\/strong><\/th>SCA<\/strong><\/th><\/tr><\/thead>
              Objectif de contr\u00f4le<\/td>S\u00e9curit\u00e9 pr\u00e9ventive au niveau du code<\/td>Validation \u00e0 l’ex\u00e9cution<\/td>Gestion du risque de cha\u00eene d’approvisionnement<\/td><\/tr>
              Qualit\u00e9 des preuves<\/td>\u00c9lev\u00e9e<\/td>Moyenne \u00e0 \u00e9lev\u00e9e<\/td>Tr\u00e8s \u00e9lev\u00e9e<\/td><\/tr>
              Capacit\u00e9 d’application dans le CI\/CD<\/td>Forte (blocage du build)<\/td>Moyenne (blocage de la livraison)<\/td>Forte (blocage des d\u00e9pendances)<\/td><\/tr>
              Tra\u00e7abilit\u00e9 d’audit<\/td>\u00c9lev\u00e9e (reli\u00e9e au commit)<\/td>Moyenne (reli\u00e9e \u00e0 l’environnement)<\/td>Tr\u00e8s \u00e9lev\u00e9e (reli\u00e9e au SBOM)<\/td><\/tr>
              Alignement avec les r\u00e9f\u00e9rentiels de conformit\u00e9<\/td>Large<\/td>Large<\/td>Critique pour les r\u00e9glementations sur la cha\u00eene d’approvisionnement<\/td><\/tr>
              Complexit\u00e9 de gouvernance<\/td>Moyenne (gestion des suppressions)<\/td>Moyenne \u00e0 \u00e9lev\u00e9e (gouvernance des faux positifs)<\/td>Moyenne (gestion de la politique de d\u00e9pendances)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              \n\n\n\n

              Quels contr\u00f4les comptent le plus sous chaque r\u00e9glementation<\/strong><\/h2>\n\n\n\n

              DORA (Digital Operational Resilience Act)<\/strong><\/h3>\n\n\n\n

              DORA met l’accent sur la gestion du risque TIC et la r\u00e9silience op\u00e9rationnelle des entit\u00e9s financi\u00e8res. Du point de vue de l’audit :<\/p>\n\n\n\n

                \n
              • Le SCA est critique<\/strong> \u2014 DORA exige une visibilit\u00e9 sur le risque li\u00e9 aux tiers TIC, y compris les d\u00e9pendances logicielles<\/li>\n\n\n\n
              • Le SAST est important<\/strong> \u2014 il soutient les contr\u00f4les pr\u00e9ventifs au sein du cycle de d\u00e9veloppement s\u00e9curis\u00e9<\/li>\n\n\n\n
              • Le DAST apporte une validation compl\u00e9mentaire<\/strong> \u2014 il d\u00e9montre les tests \u00e0 l’ex\u00e9cution des services d\u00e9ploy\u00e9s<\/li>\n<\/ul>\n\n\n\n

                NIS2 (Network and Information Security Directive)<\/strong><\/h3>\n\n\n\n

                NIS2 se concentre sur la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, la gestion des incidents et la gestion des risques pour les entit\u00e9s essentielles et importantes :<\/p>\n\n\n\n

                  \n
                • Le SCA est essentiel<\/strong> \u2014 il traite directement les exigences de risque li\u00e9es \u00e0 la cha\u00eene d’approvisionnement et aux d\u00e9pendances<\/li>\n\n\n\n
                • Le SAST soutient le d\u00e9veloppement s\u00e9curis\u00e9<\/strong> \u2014 il s’aligne avec les exigences des pratiques de s\u00e9curit\u00e9 d\u00e8s la conception<\/li>\n\n\n\n
                • Le DAST valide l’exposition des services<\/strong> \u2014 il aide \u00e0 d\u00e9montrer que les services expos\u00e9s vers l’ext\u00e9rieur sont test\u00e9s<\/li>\n<\/ul>\n\n\n\n

                  ISO 27001<\/strong><\/h3>\n\n\n\n

                  ISO 27001 exige des organisations qu’elles d\u00e9montrent l’efficacit\u00e9 de leurs contr\u00f4les \u00e0 travers le syst\u00e8me de management de la s\u00e9curit\u00e9 de l’information :<\/p>\n\n\n\n

                    \n
                  • Les trois contr\u00f4les sont pertinents<\/strong> \u2014 ils d\u00e9montrent collectivement des pratiques de d\u00e9veloppement s\u00e9curis\u00e9 (contr\u00f4les de l’Annexe A, A.8.25\u201328)<\/li>\n\n\n\n
                  • Le SCA fournit souvent les preuves les plus claires<\/strong> \u2014 les SBOM et les inventaires de d\u00e9pendances sont des artefacts tangibles et auditables<\/li>\n\n\n\n
                  • Les auditeurs doivent v\u00e9rifier que les contr\u00f4les sont int\u00e9gr\u00e9s au CI\/CD<\/strong>, et non r\u00e9alis\u00e9s comme des activit\u00e9s manuelles distinctes<\/li>\n<\/ul>\n\n\n\n

                    SOC 2<\/strong><\/h3>\n\n\n\n

                    SOC 2 \u00e9value les contr\u00f4les li\u00e9s \u00e0 la s\u00e9curit\u00e9, la disponibilit\u00e9, l’int\u00e9grit\u00e9 du traitement, la confidentialit\u00e9 et la protection des donn\u00e9es personnelles :<\/p>\n\n\n\n

                      \n
                    • Le SAST et le SCA<\/strong> soutiennent les crit\u00e8res de service de confiance S\u00e9curit\u00e9 et Int\u00e9grit\u00e9 du traitement<\/li>\n\n\n\n
                    • Le DAST<\/strong> soutient la preuve des tests de s\u00e9curit\u00e9 \u00e0 l’ex\u00e9cution<\/li>\n\n\n\n
                    • Les auditeurs doivent se concentrer sur le fait que les contr\u00f4les sont appliqu\u00e9s de mani\u00e8re coh\u00e9rente et produisent des preuves conserv\u00e9es<\/strong><\/li>\n<\/ul>\n\n\n\n

                      PCI DSS<\/strong><\/h3>\n\n\n\n

                      PCI DSS comporte des exigences explicites en mati\u00e8re de tests de s\u00e9curit\u00e9 des applications :<\/p>\n\n\n\n

                        \n
                      • Le SAST est directement r\u00e9f\u00e9renc\u00e9<\/strong> (exigence 6.3) \u2014 des revues de code ou une analyse automatis\u00e9e du code sont requises<\/li>\n\n\n\n
                      • Le DAST est directement r\u00e9f\u00e9renc\u00e9<\/strong> (exigences 6.4, 11.3) \u2014 les tests de s\u00e9curit\u00e9 des applications web sont obligatoires<\/li>\n\n\n\n
                      • Le SCA soutient<\/strong> les exigences de gestion des vuln\u00e9rabilit\u00e9s en suivant les vuln\u00e9rabilit\u00e9s connues dans les d\u00e9pendances<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n

                        Conseils pratiques pour les auditeurs<\/strong><\/h2>\n\n\n\n
                          \n
                        • Aucun contr\u00f4le unique n’est suffisant<\/strong> \u2014 les organisations doivent d\u00e9montrer une approche par couches<\/li>\n\n\n\n
                        • Le SAST et le SCA sont fondamentaux<\/strong> \u2014 ils doivent \u00eatre pr\u00e9sents dans tout pipeline CI\/CD mature<\/li>\n\n\n\n
                        • Le DAST ajoute une validation \u00e0 l’ex\u00e9cution<\/strong> mais ne doit pas \u00eatre le seul contr\u00f4le de test<\/li>\n\n\n\n
                        • L’application dans le CI\/CD compte plus que la profondeur du scan<\/strong> \u2014 un contr\u00f4le qui s’ex\u00e9cute mais ne bloque pas est faible<\/li>\n\n\n\n
                        • La qualit\u00e9 des preuves compte plus que le nombre de vuln\u00e9rabilit\u00e9s<\/strong> \u2014 recherchez la tra\u00e7abilit\u00e9, la conservation et la gouvernance<\/li>\n<\/ul>\n\n\n\n

                          Les pipelines les plus auditables utilisent :<\/p>\n\n\n\n

                          \n

                          Le SAST + le SCA appliqu\u00e9s par d\u00e9faut, le DAST \u00e0 des points de contr\u00f4le d\u00e9finis, avec tous les r\u00e9sultats conserv\u00e9s et tra\u00e7ables.<\/strong><\/p>\n<\/blockquote>\n\n\n\n

                          \n\n\n\n

                          Correspondance outils \u2192 contr\u00f4les<\/strong><\/h2>\n\n\n\n

                          La comparaison ci-dessus se concentre sur ce que le SAST, le DAST et le SCA accomplissent en tant que contr\u00f4les individuels. Dans un pipeline r\u00e9el, ces contr\u00f4les de test coexistent avec un ensemble plus large de cat\u00e9gories d’outillage, et les auditeurs n’en \u00e9valuent aucun de mani\u00e8re isol\u00e9e : ils \u00e9valuent quels contr\u00f4les sont appliqu\u00e9s, o\u00f9 et avec quelle coh\u00e9rence<\/strong>. Un outil de s\u00e9curit\u00e9 n’a de valeur d’audit que lorsqu’il applique un contr\u00f4le concret et g\u00e9n\u00e8re des preuves fiables. La correspondance ci-dessous montre comment chaque cat\u00e9gorie d’outillage de s\u00e9curit\u00e9 CI\/CD soutient les contr\u00f4les fondamentaux attendus dans les environnements d’entreprise et r\u00e9glement\u00e9s, et quelles preuves chacune doit produire.<\/p>\n\n\n\n\n

                          \n\n\n CI\/CD Security Model: Tools \u2192 Controls \u2192 Evidence<\/title>\n \n Conceptual CI\/CD security model showing how tools enforce controls\n and generate audit evidence in enterprise and regulated environments.\n <\/desc>\n\n