{"id":679,"date":"2025-12-28T11:47:08","date_gmt":"2025-12-28T10:47:08","guid":{"rendered":"https:\/\/regulated-devsecops.com\/?page_id=679"},"modified":"2026-03-26T07:04:22","modified_gmt":"2026-03-26T06:04:22","slug":"ci-cd-security","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/fr\/ci-cd-security\/","title":{"rendered":"S\u00e9curit\u00e9 CI\/CD dans les Environnements R\u00e9glement\u00e9s"},"content":{"rendered":"\n

Traiter les Pipelines comme des Syst\u00e8mes de Contr\u00f4le R\u00e9glement\u00e9s<\/strong><\/h2>\n\n\n\n

Dans les industries r\u00e9glement\u00e9es, les pipelines CI\/CD ne sont pas de simples outils d’automatisation \u2014 ce sont des syst\u00e8mes de contr\u00f4le<\/strong> qui d\u00e9terminent ce qui est d\u00e9ploy\u00e9 en production. Si un attaquant peut manipuler un pipeline, il peut contourner chaque contr\u00f4le de s\u00e9curit\u00e9 de la cha\u00eene. Si un auditeur ne peut pas v\u00e9rifier le fonctionnement du pipeline, l’organisation \u00e9choue \u00e0 la conformit\u00e9. C’est pourquoi la s\u00e9curit\u00e9 CI\/CD dans les environnements r\u00e9glement\u00e9s doit \u00eatre trait\u00e9e avec la m\u00eame rigueur que la s\u00e9curit\u00e9 de l’infrastructure ou de l’application elle-m\u00eame.<\/p>\n\n\n\n

Ce guide couvre comment s\u00e9curiser les pipelines CI\/CD de bout en bout \u2014 de l’int\u00e9grit\u00e9 du code source aux contr\u00f4les de d\u00e9ploiement \u2014 d’une mani\u00e8re qui r\u00e9siste \u00e0 la fois aux attaques r\u00e9elles et \u00e0 l’examen r\u00e9glementaire dans des cadres tels que DORA<\/strong>, NIS2<\/strong>, ISO 27001<\/strong>, SOC 2<\/strong> et PCI DSS<\/strong>.<\/p>\n\n\n\n

\n\n\n\n

1. Pourquoi les Pipelines CI\/CD Sont des Cibles \u00e0 Haut Risque<\/strong><\/h2>\n\n\n\n

Les pipelines CI\/CD op\u00e8rent au carrefour du code, de l’infrastructure et du d\u00e9ploiement. Ce positionnement les rend particuli\u00e8rement attractifs pour les attaquants :<\/p>\n\n\n\n

    \n
  • Ils ont souvent un acc\u00e8s \u00e9lev\u00e9<\/strong> aux secrets, registres et environnements de production.<\/li>\n\n\n\n
  • Ils ex\u00e9cutent du code arbitraire<\/strong> fourni par les d\u00e9veloppeurs (scripts de build, tests, d\u00e9ploiements).<\/li>\n\n\n\n
  • Ils cr\u00e9ent des artefacts de confiance<\/strong> (images de conteneurs, binaires) qui sont d\u00e9ploy\u00e9s dans des environnements sensibles.<\/li>\n\n\n\n
  • Ils op\u00e8rent souvent avec une supervision de s\u00e9curit\u00e9 minimale<\/strong> par rapport aux syst\u00e8mes de production.<\/li>\n<\/ul>\n\n\n\n

    Les compromissions r\u00e9centes de la cha\u00eene d’approvisionnement \u2014 SolarWinds, CodeCov, l’attaque du flux de travail GitHub d’ua-parser-js \u2014 d\u00e9montrent que les pipelines CI\/CD sont un vecteur d’attaque principal. Pour les environnements r\u00e9glement\u00e9s, il ne s’agit pas seulement d’un risque de s\u00e9curit\u00e9 \u2014 c’est un risque de conformit\u00e9.<\/p>\n\n\n\n

    \n\n\n\n

    2. Int\u00e9grit\u00e9 du Code Source<\/strong><\/h2>\n\n\n\n

    La s\u00e9curit\u00e9 du pipeline commence avant le pipeline lui-m\u00eame. Si l’int\u00e9grit\u00e9 du code source ne peut \u00eatre garantie, rien en aval ne peut \u00eatre fiable.<\/p>\n\n\n\n

    Commits sign\u00e9s<\/h3>\n\n\n\n

    Exigez des commits sign\u00e9s GPG ou SSH pour \u00e9tablir la non-r\u00e9pudiation \u2014 preuve que chaque changement provient d’un d\u00e9veloppeur v\u00e9rifi\u00e9. Cela est de plus en plus attendu dans les cadres n\u00e9cessitant une tra\u00e7abilit\u00e9 des changements<\/strong> et une responsabilit\u00e9<\/strong> (DORA Article 9, ISO 27001 A.8.32).<\/p>\n\n\n\n

    Protection des branches<\/h3>\n\n\n\n

    Appliquez des r\u00e8gles de protection des branches sur les branches critiques (main, release, production) :<\/p>\n\n\n\n

      \n
    • Exigez des pull requests avec un nombre minimum de revues.<\/li>\n\n\n\n
    • Interdisez les force-push et les suppressions de branches.<\/li>\n\n\n\n
    • Exigez la r\u00e9ussite des v\u00e9rifications de statut avant la fusion.<\/li>\n\n\n\n
    • Appliquez une r\u00e9solution lin\u00e9aire de l’historique (pas de merge commits sans revue).<\/li>\n<\/ul>\n\n\n\n

      Revue de code<\/h3>\n\n\n\n

      La revue de code n’est pas seulement un outil de qualit\u00e9 \u2014 c’est un contr\u00f4le de s\u00e9curit\u00e9<\/strong>. Dans les environnements r\u00e9glement\u00e9s, la revue de code sert de contr\u00f4le dual, garantissant qu’aucun individu ne peut introduire unilat\u00e9ralement des changements en production. Documentez les politiques de revue et assurez-vous qu’elles sont v\u00e9rifiables.<\/p>\n\n\n\n

      \n\n\n\n

      3. S\u00e9curit\u00e9 de l’Environnement de Build<\/strong><\/h2>\n\n\n\n

      L’environnement de build est l’endroit o\u00f9 le code source est transform\u00e9 en artefacts d\u00e9ployables. S’il est compromis, chaque artefact qu’il produit est suspect.<\/p>\n\n\n\n

      Environnements de build \u00e9ph\u00e9m\u00e8res<\/h3>\n\n\n\n

      Utilisez des runners\/agents de build \u00e9ph\u00e9m\u00e8res qui sont cr\u00e9\u00e9s \u00e0 nouveau pour chaque ex\u00e9cution de pipeline. Cela emp\u00eache la persistance d’un attaquant et garantit un \u00e9tat propre. \u00c9vitez les runners partag\u00e9s de longue dur\u00e9e lorsque cela est possible.<\/p>\n\n\n\n

      Isolation<\/h3>\n\n\n\n

      Isolez les builds les uns des autres et de l’infrastructure de production :<\/p>\n\n\n\n

        \n
      • Ex\u00e9cutez les builds dans des conteneurs isol\u00e9s ou des machines virtuelles.<\/li>\n\n\n\n
      • Limitez l’acc\u00e8s r\u00e9seau depuis les environnements de build.<\/li>\n\n\n\n
      • Interdisez aux builds d’acc\u00e9der directement aux bases de donn\u00e9es ou services de production.<\/li>\n<\/ul>\n\n\n\n

        Attestation de build<\/h3>\n\n\n\n

        G\u00e9n\u00e9rez des attestations de provenance qui enregistrent ce qui<\/em> a \u00e9t\u00e9 construit, \u00e0 partir de quel<\/em> code source, par quel<\/em> pipeline, et quand<\/em>. Des cadres comme SLSA<\/strong> (Supply-chain Levels for Software Artifacts) fournissent un mod\u00e8le de maturit\u00e9 pour la provenance des builds. \u00c0 un minimum, suivez le mat\u00e9riel source (d\u00e9p\u00f4t, commit, branche), l’identit\u00e9 du build (ID du pipeline, runner) et le hachage de l’artefact de sortie.<\/p>\n\n\n\n

        \n\n\n\n

        4. Gestion des Secrets<\/strong><\/h2>\n\n\n\n

        Les secrets mal g\u00e9r\u00e9s dans les pipelines CI\/CD sont l’une des vuln\u00e9rabilit\u00e9s les plus courantes et les plus dommageables.<\/p>\n\n\n\n

        Ne jamais coder les secrets en dur<\/h3>\n\n\n\n

        Les secrets ne doivent jamais appara\u00eetre dans le code source, les fichiers de configuration du pipeline ou les variables d’environnement de build en texte clair. Utilisez un gestionnaire de secrets d\u00e9di\u00e9 (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.).<\/p>\n\n\n\n

        Acc\u00e8s au moindre privil\u00e8ge<\/h3>\n\n\n\n

        Chaque \u00e9tape du pipeline ne devrait acc\u00e9der qu’aux secrets dont elle a besoin. Les identifiants de d\u00e9ploiement ne devraient pas \u00eatre disponibles lors des \u00e9tapes de build ou de test. Impl\u00e9mentez un acc\u00e8s aux secrets limit\u00e9 dans le temps lorsque cela est possible.<\/p>\n\n\n\n

        Rotation et audit des secrets<\/h3>\n\n\n\n

        Mettez en \u0153uvre une rotation automatique des secrets et auditez chaque acc\u00e8s. Pour la conformit\u00e9 r\u00e9glementaire, vous devez \u00eatre en mesure de prouver que les secrets sont g\u00e9r\u00e9s conform\u00e9ment \u00e0 la politique \u2014 y compris les calendriers de rotation, les journaux d’acc\u00e8s et les proc\u00e9dures de r\u00e9vocation.<\/p>\n\n\n\n

        \n\n\n\n

        5. S\u00e9curit\u00e9 du Registre de Conteneurs<\/strong><\/h2>\n\n\n\n

        Les registres de conteneurs stockent les artefacts de build qui seront d\u00e9ploy\u00e9s en production. Si un registre est compromis, des images malveillantes peuvent \u00eatre d\u00e9ploy\u00e9es dans des environnements r\u00e9glement\u00e9s.<\/p>\n\n\n\n

        Signature des images<\/h3>\n\n\n\n

        Signez toutes les images de conteneurs \u00e0 l’aide d’outils comme Cosign<\/strong> (du projet Sigstore). V\u00e9rifiez les signatures avant le d\u00e9ploiement pour vous assurer que seules les images construites par des pipelines de confiance atteignent la production.<\/p>\n\n\n\n

        Analyse des vuln\u00e9rabilit\u00e9s<\/h3>\n\n\n\n

        Analysez chaque image pour les vuln\u00e9rabilit\u00e9s connues avant qu’elle ne soit pouss\u00e9e vers le registre ou d\u00e9ploy\u00e9e. Int\u00e9grez des scanners (Trivy, Grype, Snyk Container) directement dans le pipeline. D\u00e9finissez des seuils clairs : les vuln\u00e9rabilit\u00e9s critiques\/\u00e9lev\u00e9es bloquent le d\u00e9ploiement.<\/p>\n\n\n\n

        Contr\u00f4les d’acc\u00e8s au registre<\/h3>\n\n\n\n

        Limitez qui peut pousser des images vers les registres de production. Id\u00e9alement, seuls les pipelines CI\/CD peuvent pousser \u2014 jamais les d\u00e9veloppeurs individuels directement. Utilisez des politiques d’acc\u00e8s bas\u00e9es sur les r\u00f4les et des journaux d’audit.<\/p>\n\n\n\n

        \n\n\n\n

        6. S\u00e9curit\u00e9 de la D\u00e9finition du Pipeline<\/strong><\/h2>\n\n\n\n

        Le pipeline lui-m\u00eame est d\u00e9fini dans du code (YAML, Groovy, HCL, etc.). Ce code doit \u00eatre trait\u00e9 avec le m\u00eame soin que le code applicatif.<\/p>\n\n\n\n

        Gouvernance du pipeline as code<\/h3>\n\n\n\n

        Stockez les d\u00e9finitions de pipeline dans un d\u00e9p\u00f4t contr\u00f4l\u00e9 par version avec les m\u00eames protections de branches, exigences de revue de code et contr\u00f4les d’acc\u00e8s que le code applicatif. Les changements de configuration du pipeline doivent passer par un processus de revue formel.<\/p>\n\n\n\n

        Restreindre les modifications du pipeline<\/h3>\n\n\n\n

        Limitez qui peut modifier les d\u00e9finitions de pipeline, en particulier pour les pipelines de production. Utilisez CODEOWNERS ou des m\u00e9canismes \u00e9quivalents pour exiger l’approbation de l’\u00e9quipe s\u00e9curit\u00e9 pour les changements de pipeline.<\/p>\n\n\n\n

        \u00c9tapes de pipeline immuables<\/h3>\n\n\n\n

        Lorsque cela est possible, utilisez des \u00e9tapes de pipeline versionn\u00e9es et immuables plut\u00f4t que des r\u00e9f\u00e9rences mutables. Par exemple, r\u00e9f\u00e9rencez les actions de pipeline par hash de commit plut\u00f4t que par nom de branche pour emp\u00eacher la substitution.<\/p>\n\n\n\n

        \n\n\n\n

        7. Portes de D\u00e9ploiement et S\u00e9paration des Environnements<\/strong><\/h2>\n\n\n\n

        Les contr\u00f4les de d\u00e9ploiement sont l’endroit o\u00f9 la s\u00e9curit\u00e9 CI\/CD et les exigences de conformit\u00e9 se rencontrent le plus directement. Chaque cadre r\u00e9glementaire exige des contr\u00f4les sur la fa\u00e7on dont les changements sont promus en production.<\/p>\n\n\n\n

        Promotion d’environnement<\/h3>\n\n\n\n

        Mettez en \u0153uvre des \u00e9tapes claires : d\u00e9veloppement \u2192 staging \u2192 production. Chaque promotion devrait n\u00e9cessiter la r\u00e9ussite de v\u00e9rifications automatis\u00e9es et (pour la production) des approbations manuelles. Jamais de d\u00e9ploiement en production directement depuis une branche de d\u00e9veloppement.<\/p>\n\n\n\n

        Portes d’approbation<\/h3>\n\n\n\n

        Exigez des approbations explicites pour les d\u00e9ploiements en production \u2014 id\u00e9alement de la part de personnes diff\u00e9rentes de celles qui ont \u00e9crit ou fusionn\u00e9 le code (s\u00e9paration des responsabilit\u00e9s). Documentez les approbations pour les pistes d’audit.<\/p>\n\n\n\n

        Capacit\u00e9 de rollback<\/h3>\n\n\n\n

        Maintenez la capacit\u00e9 de revenir rapidement \u00e0 une version ant\u00e9rieure connue comme bonne. Des cadres r\u00e9glementaires comme DORA exigent explicitement la r\u00e9silience op\u00e9rationnelle, ce qui inclut la gestion du d\u00e9ploiement et la r\u00e9cup\u00e9ration.<\/p>\n\n\n\n

        \n\n\n\n

        8. Journalisation, Surveillance et Piste d’Audit<\/strong><\/h2>\n\n\n\n

        Les pipelines CI\/CD g\u00e9n\u00e8rent de grandes quantit\u00e9s de donn\u00e9es \u2014 mais sans journalisation structur\u00e9e et conservation appropri\u00e9e, ces donn\u00e9es ne servent pas les objectifs de conformit\u00e9.<\/p>\n\n\n\n

        Que journaliser<\/h3>\n\n\n\n