Les pipelines CI\/CD constituent l’\u00e9pine dorsale de la livraison logicielle moderne. Ils automatisent le parcours du commit de code jusqu’au d\u00e9ploiement en production, permettant aux \u00e9quipes de livrer plus rapidement, de mani\u00e8re plus fiable et avec une plus grande confiance. Mais cette puissance s’accompagne d’un compromis critique : les pipelines sont de plus en plus la cible principale d’attaquants sophistiqu\u00e9s<\/strong>.<\/p>\n R\u00e9fl\u00e9chissez \u00e0 ce qu’un pipeline CI\/CD manipule. Il r\u00e9cup\u00e8re le code source, r\u00e9sout les d\u00e9pendances, acc\u00e8de aux secrets et aux identifiants, construit des artefacts, les pousse vers des registres et d\u00e9ploie sur l’infrastructure de production. Un seul pipeline compromis peut donner \u00e0 un attaquant acc\u00e8s \u00e0 tout<\/em> \u2014 code source, secrets, comptes cloud, donn\u00e9es clients et syst\u00e8mes de production.<\/p>\n Ce guide fournit une vue d’ensemble compl\u00e8te de la s\u00e9curit\u00e9 des pipelines CI\/CD : ce qui est en jeu, o\u00f9 se trouvent les risques et comment construire des pipelines s\u00e9curis\u00e9s de la source \u00e0 la production. Que vous soyez un ing\u00e9nieur s\u00e9curit\u00e9 renfor\u00e7ant des pipelines existants ou une \u00e9quipe DevOps en construisant de nouveaux, ceci est votre r\u00e9f\u00e9rence compl\u00e8te pour comprendre et mettre en \u0153uvre la s\u00e9curit\u00e9 CI\/CD.<\/p>\n Nous couvrirons l’ensemble du paysage \u2014 de la mod\u00e9lisation des menaces et des surfaces d’attaque \u00e0 la gestion des secrets, l’int\u00e9grit\u00e9 des artefacts, l’application des politiques et le durcissement sp\u00e9cifique aux plateformes. Tout au long du guide, nous renverrons vers des guides d\u00e9taill\u00e9s, des travaux pratiques et des ressources concr\u00e8tes qui vous permettront d’approfondir chaque sujet.<\/p>\n Les pipelines CI\/CD occupent une position unique et dangereuse dans l’infrastructure moderne. Ce sont des syst\u00e8mes d’automatisation avec un acc\u00e8s privil\u00e9gi\u00e9<\/strong> \u00e0 pratiquement toutes les ressources critiques de votre organisation. Comprendre pourquoi ils comptent commence par comprendre ce qu’ils peuvent atteindre.<\/p>\n Un pipeline CI\/CD typique a acc\u00e8s \u00e0 :<\/p>\n Un pipeline compromis ne donne pas simplement aux attaquants un point d’ancrage \u2014 il leur donne les cl\u00e9s du royaume<\/strong>. La compromission d’un pipeline est l’un des moyens les plus efficaces pour r\u00e9aliser un mouvement lat\u00e9ral \u00e0 travers une organisation enti\u00e8re.<\/p>\n Ce n’est pas th\u00e9orique. Certains des incidents de s\u00e9curit\u00e9 les plus significatifs de ces derni\u00e8res ann\u00e9es ont \u00e9t\u00e9 des attaques contre les pipelines et la cha\u00eene d’approvisionnement :<\/p>\n Le fil conducteur de tous ces incidents : les attaquants ciblent le pipeline lui-m\u00eame, pas l’application<\/strong>. Les mesures de s\u00e9curit\u00e9 applicative traditionnelles \u2014 WAFs, protection des endpoints, surveillance en temps r\u00e9el \u2014 n’aident pas lorsque le vecteur d’attaque est le syst\u00e8me de build et de d\u00e9ploiement.<\/p>\n Il existe une asym\u00e9trie fondamentale dans la s\u00e9curit\u00e9 CI\/CD. Les pipelines sont con\u00e7us pour \u00eatre permissifs et rapides<\/strong>. Ils ont besoin d’un acc\u00e8s large pour faire leur travail. La s\u00e9curit\u00e9, en revanche, exige restriction et v\u00e9rification<\/strong>. Combler cet \u00e9cart \u2014 maintenir la v\u00e9locit\u00e9 du pipeline tout en appliquant des fronti\u00e8res de s\u00e9curit\u00e9 \u2014 est le d\u00e9fi central de la s\u00e9curit\u00e9 CI\/CD.<\/p>\n Avant de pouvoir s\u00e9curiser un pipeline, vous devez comprendre o\u00f9 il peut \u00eatre attaqu\u00e9. La surface d’attaque CI\/CD est large, couvrant de multiples syst\u00e8mes, fronti\u00e8res de confiance et domaines organisationnels.<\/p>\n La surface d’attaque CI\/CD comprend :<\/p>\n Le projet OWASP Top 10 CI\/CD Security Risks<\/strong> fournit un cadre structur\u00e9 pour comprendre ces menaces. Il catalogue les risques les plus critiques, notamment les m\u00e9canismes de contr\u00f4le de flux insuffisants, la gestion inad\u00e9quate des identit\u00e9s et des acc\u00e8s, l’abus de la cha\u00eene de d\u00e9pendances, l’ex\u00e9cution de pipeline empoisonn\u00e9 et l’hygi\u00e8ne insuffisante des identifiants. Chaque risque correspond \u00e0 des sch\u00e9mas d’attaque r\u00e9els et fournit des recommandations concr\u00e8tes pour l’att\u00e9nuation.<\/p>\n Pour une analyse approfondie des raisons pour lesquelles les pipelines sont la surface d’attaque principale et comment les attaquants les exploitent, consultez notre analyse d\u00e9taill\u00e9e : Pourquoi les Pipelines CI\/CD Sont la Surface d’Attaque Principale<\/a>.<\/p>\n L’un des aspects les plus fondamentaux \u2014 et les plus fr\u00e9quemment mal compris \u2014 de la s\u00e9curit\u00e9 CI\/CD est celui des fronti\u00e8res de confiance<\/strong>. Chaque pipeline op\u00e8re dans un ensemble d’hypoth\u00e8ses de confiance, et les violations de ces hypoth\u00e8ses sont l\u00e0 o\u00f9 la s\u00e9curit\u00e9 s’effondre.<\/p>\n Pour chaque ex\u00e9cution de pipeline, vous devriez \u00eatre en mesure de r\u00e9pondre :<\/p>\n Diff\u00e9rents d\u00e9clencheurs de pipeline portent des niveaux de confiance fondamentalement diff\u00e9rents :<\/p>\n Le principe essentiel : les permissions du pipeline et l’acc\u00e8s aux secrets doivent \u00eatre calibr\u00e9s au niveau de confiance du d\u00e9clencheur<\/strong>. Une pull request d’un fork ne devrait jamais avoir acc\u00e8s aux identifiants de d\u00e9ploiement en production.<\/p>\n Les diff\u00e9rentes plateformes CI\/CD g\u00e8rent l’isolation d’ex\u00e9cution diff\u00e9remment. Comprendre le mod\u00e8le d’ex\u00e9cution \u2014 que les builds s’ex\u00e9cutent dans des VM partag\u00e9es, des conteneurs \u00e9ph\u00e9m\u00e8res ou des serveurs persistants \u2014 impacte directement votre posture de s\u00e9curit\u00e9. Les environnements d’ex\u00e9cution partag\u00e9s cr\u00e9ent des risques de contamination entre builds, de vol d’identifiants et d’empoisonnement du cache.<\/p>\n Pour une exploration compl\u00e8te des mod\u00e8les d’ex\u00e9cution CI\/CD et de leurs implications en mati\u00e8re de s\u00e9curit\u00e9, consultez : Mod\u00e8les d’Ex\u00e9cution CI\/CD, Hypoth\u00e8ses de Confiance et Guide de S\u00e9curit\u00e9<\/a>.<\/p>\n S’il y a un domaine qui m\u00e9rite le plus d’attention dans la s\u00e9curit\u00e9 CI\/CD, c’est la gestion des secrets<\/strong>. La compromission des identifiants est syst\u00e9matiquement la cause n\u00b01 des incidents de s\u00e9curit\u00e9 CI\/CD. Une mauvaise hygi\u00e8ne des secrets \u2014 identifiants cod\u00e9s en dur, acc\u00e8s trop large, jetons \u00e0 longue dur\u00e9e de vie, secrets expos\u00e9s au code non fiable \u2014 est derri\u00e8re pratiquement chaque br\u00e8che majeure de pipeline.<\/p>\n Les pipelines ont besoin de secrets pour fonctionner. Ils ont besoin d’identifiants pour r\u00e9cup\u00e9rer le code, r\u00e9soudre les d\u00e9pendances priv\u00e9es, acc\u00e9der aux API cloud, pousser les artefacts et d\u00e9ployer en production. Le d\u00e9fi est de fournir ces identifiants de mani\u00e8re s\u00e9curis\u00e9e :<\/p>\n Il existe un spectre de maturit\u00e9 pour la gestion des secrets en CI\/CD :<\/p>\n Chaque plateforme CI\/CD fournit un m\u00e9canisme int\u00e9gr\u00e9 de gestion des secrets \u2014 les secrets GitHub Actions, les variables GitLab CI, le magasin d’identifiants Jenkins. Ceux-ci fournissent un chiffrement de base au repos et un masquage dans les logs. C’est un bon point de d\u00e9part mais avec des limitations : ils sont sp\u00e9cifiques \u00e0 la plateforme, difficiles \u00e0 auditer et offrent g\u00e9n\u00e9ralement un contr\u00f4le d’acc\u00e8s \u00e0 gros grain.<\/p>\n L’int\u00e9gration avec des outils d\u00e9di\u00e9s de gestion des secrets \u2014 HashiCorp Vault<\/strong>, AWS Secrets Manager<\/strong>, Azure Key Vault<\/strong>, Google Secret Manager<\/strong> \u2014 fournit une gestion centralis\u00e9e, des politiques d’acc\u00e8s \u00e0 grain fin, la journalisation d’audit et la rotation automatique. Vault, en particulier, excelle dans la g\u00e9n\u00e9ration d’identifiants dynamiques et de courte dur\u00e9e, limit\u00e9s \u00e0 des ex\u00e9cutions de pipeline sp\u00e9cifiques.<\/p>\n Le standard d’excellence pour les identifiants CI\/CD est d’\u00e9liminer enti\u00e8rement les secrets \u00e0 longue dur\u00e9e de vie<\/strong>. En utilisant OIDC (OpenID Connect) et la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail, les pipelines peuvent s’authentifier aupr\u00e8s des fournisseurs cloud en utilisant leur identit\u00e9 de plateforme \u2014 sans aucun secret stock\u00e9. GitHub Actions, GitLab CI et d’autres plateformes peuvent \u00e9changer leurs jetons OIDC contre des identifiants cloud de courte dur\u00e9e limit\u00e9s \u00e0 des d\u00e9p\u00f4ts, branches et environnements sp\u00e9cifiques.<\/p>\n Cette approche fournit :<\/p>\n Pour des conseils de mise en \u0153uvre d\u00e9taill\u00e9s, consultez nos guides approfondis :<\/p>\n S\u00e9curiser ce qui entre<\/em> dans votre pipeline (code, d\u00e9pendances, secrets) n’est que la moiti\u00e9 du combat. Vous devez aussi s\u00e9curiser ce qui en sort<\/em> \u2014 les artefacts que votre pipeline produit et d\u00e9ploie. L’int\u00e9grit\u00e9 des artefacts garantit que ce que vous d\u00e9ployez est exactement ce que vous avez construit, sans falsification en cours de route.<\/p>\n Le logiciel moderne ne se compose pas uniquement de votre code. Une application typique comprend des centaines, voire des milliers de d\u00e9pendances, d’images de base, d’outils de build et d’int\u00e9grations tierces. Chacun de ces \u00e9l\u00e9ments est un maillon de la cha\u00eene d’approvisionnement, et chacun peut \u00eatre compromis. Les attaques de la cha\u00eene d’approvisionnement ciblent ces maillons \u2014 en injectant du code malveillant dans les d\u00e9pendances, en falsifiant les artefacts de build ou en compromettant les registres.<\/p>\n La signature d’images de conteneurs fournit une preuve cryptographique qu’une image a \u00e9t\u00e9 construite par un pipeline de confiance et n’a pas \u00e9t\u00e9 falsifi\u00e9e. Sigstore<\/strong> et son outil Cosign<\/strong> ont consid\u00e9rablement simplifi\u00e9 la signature d’images en fournissant la signature sans cl\u00e9 \u2014 utilisant les identit\u00e9s OIDC (comme l’identit\u00e9 d’un pipeline CI\/CD) pour signer les artefacts sans g\u00e9rer de cl\u00e9s de signature \u00e0 longue dur\u00e9e de vie.<\/p>\n Dans un pipeline s\u00e9curis\u00e9, chaque image de conteneur devrait \u00eatre :<\/p>\n SLSA<\/strong> (Supply-chain Levels for Software Artifacts) fournit un cadre pour am\u00e9liorer progressivement l’int\u00e9grit\u00e9 de la cha\u00eene d’approvisionnement. Au c\u0153ur de SLSA se trouve la provenance<\/strong> \u2014 un enregistrement v\u00e9rifiable de comment, o\u00f9 et par qui un artefact a \u00e9t\u00e9 construit.<\/p>\n Le framework in-toto<\/strong> compl\u00e8te SLSA en fournissant un moyen de d\u00e9finir et de v\u00e9rifier l’ensemble de la cha\u00eene d’approvisionnement logicielle \u2014 du code source \u00e0 travers le build jusqu’au d\u00e9ploiement. Chaque \u00e9tape de la cha\u00eene produit des attestations qui peuvent \u00eatre v\u00e9rifi\u00e9es par rapport \u00e0 une disposition pr\u00e9d\u00e9finie.<\/p>\n Concepts cl\u00e9s :<\/p>\n Un SBOM fournit un inventaire complet de tous les composants d’un artefact logiciel \u2014 chaque biblioth\u00e8que, d\u00e9pendance et version d’outil. Les SBOMs permettent :<\/p>\n Les builds reproductibles garantissent que le m\u00eame code source et les m\u00eames instructions de build produisent toujours le m\u00eame artefact de sortie, bit pour bit. Cette propri\u00e9t\u00e9 permet de v\u00e9rifier ind\u00e9pendamment qu’un artefact publi\u00e9 correspond \u00e0 son code source d\u00e9clar\u00e9, \u00e9liminant toute une classe d’attaques sur les syst\u00e8mes de build.<\/p>\n Pour des conseils de mise en \u0153uvre d\u00e9taill\u00e9s sur l’int\u00e9grit\u00e9 des artefacts, consultez :<\/p>\n Les contr\u00f4les de s\u00e9curit\u00e9 ne sont efficaces que s’ils sont appliqu\u00e9s de mani\u00e8re coh\u00e9rente et automatique<\/strong>. Les revues de s\u00e9curit\u00e9 manuelles ne passent pas \u00e0 l’\u00e9chelle. Les checklists sont oubli\u00e9es. La solution est le Policy as Code<\/strong> \u2014 encoder vos exigences de s\u00e9curit\u00e9 sous forme de politiques lisibles par machine, \u00e9valu\u00e9es automatiquement \u00e0 chaque ex\u00e9cution de pipeline.<\/p>\n L’Open Policy Agent (OPA)<\/strong> et son langage de politique Rego<\/strong> sont devenus le standard de facto pour l’application des politiques dans les environnements cloud-natifs. Dans un contexte CI\/CD, OPA vous permet d’\u00e9crire des politiques qui \u00e9valuent les entr\u00e9es, configurations et sorties du pipeline par rapport \u00e0 vos exigences de s\u00e9curit\u00e9.<\/p>\n V\u00e9rifications de politiques courantes en CI\/CD :<\/p>\n Conftest<\/strong> est un utilitaire qui facilite l’ex\u00e9cution de politiques OPA\/Rego contre des donn\u00e9es de configuration structur\u00e9es dans les pipelines CI\/CD. Il prend en charge YAML, JSON, HCL, Dockerfile et bien d’autres formats, ce qui le rend suffisamment polyvalent pour valider les manifestes Kubernetes, les plans Terraform, les Dockerfiles et les configurations de pipeline.<\/p>\n Une \u00e9tape typique d’application des politiques dans un pipeline :<\/p>\n Au-del\u00e0 des politiques de configuration, une s\u00e9curit\u00e9 CI\/CD efficace n\u00e9cessite des portes de s\u00e9curit\u00e9 automatis\u00e9es<\/strong> \u2014 des points de contr\u00f4le dans le pipeline o\u00f9 les crit\u00e8res de s\u00e9curit\u00e9 doivent \u00eatre satisfaits avant de poursuivre. Celles-ci comprennent :<\/p>\n Pour un guide complet sur la mise en \u0153uvre de l’application des politiques dans vos pipelines, consultez : Policy as Code en CI\/CD : OPA, Rego et Portes de S\u00e9curit\u00e9<\/a>.<\/p>\n Au-del\u00e0 des domaines sp\u00e9cifiques couverts ci-dessus, il existe des pratiques de durcissement fondamentales qui s’appliquent \u00e0 toutes les plateformes et architectures CI\/CD. Ces pratiques r\u00e9duisent votre surface d’attaque, limitent le rayon d’impact et rendent vos pipelines r\u00e9silients face \u00e0 une compromission.<\/p>\n Chaque composant de votre pipeline devrait op\u00e9rer avec les permissions minimales requises<\/strong> pour remplir sa fonction :<\/p>\n Les environnements de build devraient \u00eatre \u00e9ph\u00e9m\u00e8res<\/strong> \u2014 cr\u00e9\u00e9s \u00e0 neuf pour chaque ex\u00e9cution de pipeline et d\u00e9truits ensuite. Les serveurs de build persistants accumulent de l’\u00e9tat, des identifiants en cache et des compromissions potentielles au fil du temps. Les runners \u00e9ph\u00e9m\u00e8res garantissent :<\/p>\n Les actions tierces, plugins et composants r\u00e9utilisables devraient \u00eatre \u00e9pingl\u00e9s \u00e0 des versions sp\u00e9cifiques et immuables<\/strong> \u2014 de pr\u00e9f\u00e9rence par SHA de commit, pas par tag mutable. L’\u00e9pinglage par tag (par ex., Les r\u00e8gles de protection des branches sont votre premi\u00e8re ligne de d\u00e9fense contre les modifications de code non autoris\u00e9es :<\/p>\n Les d\u00e9ploiements en production devraient avoir des garde-fous suppl\u00e9mentaires :<\/p>\n Aucune personne ou syst\u00e8me unique ne devrait contr\u00f4ler l’ensemble du pipeline du commit de code au d\u00e9ploiement en production. Mettez en \u0153uvre la s\u00e9paration des responsabilit\u00e9s en :<\/p>\n Pour des conseils d\u00e9taill\u00e9s sur le durcissement de vos pipelines, consultez :<\/p>\n Bien que les principes de la s\u00e9curit\u00e9 CI\/CD soient universels, chaque plateforme a son propre mod\u00e8le de s\u00e9curit\u00e9, ses fonctionnalit\u00e9s et ses pi\u00e8ges. Voici un bref aper\u00e7u des principales plateformes avec des liens vers des guides d\u00e9taill\u00e9s.<\/p>\n GitHub Actions est la plateforme CI\/CD la plus largement adopt\u00e9e pour l’open source et de nombreux projets commerciaux. Les consid\u00e9rations de s\u00e9curit\u00e9 cl\u00e9s comprennent :<\/p>\n GitLab CI offre une int\u00e9gration profonde avec la plateforme DevSecOps plus large de GitLab. Les consid\u00e9rations de s\u00e9curit\u00e9 cl\u00e9s comprennent :<\/p>\nPourquoi les Pipelines CI\/CD Sont une Priorit\u00e9 S\u00e9curitaire<\/h2>\n
Les Pipelines Sont des Cibles de Haute Valeur<\/h3>\n
\n
Attaques R\u00e9elles Contre les Pipelines<\/h3>\n
\n
Le Probl\u00e8me d’Asym\u00e9trie<\/h3>\n
La Surface d’Attaque CI\/CD<\/h2>\n
Cartographier la Surface d’Attaque<\/h3>\n
\n
.github\/workflows\/<\/code>, .gitlab-ci.yml<\/code>, Jenkinsfile<\/code>) via des pull requests ou des pushs sur des branches<\/li>\nLe Top 10 OWASP des Risques de S\u00e9curit\u00e9 CI\/CD<\/h3>\n
Fronti\u00e8res de Confiance et Mod\u00e8les d’Ex\u00e9cution<\/h2>\n
Questions Cl\u00e9s pour Chaque Pipeline<\/h3>\n
\n
Mod\u00e8les de Confiance en CI\/CD<\/h3>\n
\n
Mod\u00e8les d’Ex\u00e9cution<\/h3>\n
Gestion des Secrets<\/h2>\n
Le Probl\u00e8me des Secrets en CI\/CD<\/h3>\n
\n
Approches de Gestion des Secrets<\/h3>\n
Niveau 1 : Secrets Natifs de la Plateforme<\/h4>\n
Niveau 2 : Gestionnaires de Secrets Externes<\/h4>\n
Niveau 3 : OIDC et F\u00e9d\u00e9ration d’Identit\u00e9 de Charge de Travail<\/h4>\n
\n
Bonnes Pratiques de Gestion des Secrets<\/h3>\n
\n
\n
Int\u00e9grit\u00e9 des Artefacts et S\u00e9curit\u00e9 de la Cha\u00eene d’Approvisionnement<\/h2>\n
Le Probl\u00e8me de la Cha\u00eene d’Approvisionnement<\/h3>\n
Signature d’Images de Conteneurs avec Sigstore et Cosign<\/h3>\n
\n
Provenance et Attestations avec SLSA et in-toto<\/h3>\n
\n
Nomenclature Logicielle (SBOM)<\/h3>\n
\n
Builds Reproductibles<\/h3>\n
\n
Application des Politiques<\/h2>\n
Policy as Code avec OPA et Rego<\/h3>\n
\n
latest<\/code>, les images doivent provenir de registres approuv\u00e9s, pas d’ex\u00e9cution en root<\/li>\nConftest pour l’\u00c9valuation des Politiques CI\/CD<\/h3>\n
\n
Portes de S\u00e9curit\u00e9<\/h3>\n
\n
Bonnes Pratiques de Durcissement des Pipelines<\/h2>\n
Permissions Minimales (Principe du Moindre Privil\u00e8ge)<\/h3>\n
\n
GITHUB_TOKEN<\/code> de GitHub devrait \u00eatre limit\u00e9 en lecture seule par d\u00e9faut, avec des permissions en \u00e9criture accord\u00e9es uniquement aux \u00e9tapes sp\u00e9cifiques qui en ont besoin<\/li>\nAdministratorAccess<\/code><\/li>\nEnvironnements de Build \u00c9ph\u00e9m\u00e8res<\/h3>\n
\n
\u00c9pinglage des Actions et Plugins<\/h3>\n
v1<\/code>) est vuln\u00e9rable au d\u00e9tournement de tag, o\u00f9 un attaquant pousse du code malveillant et d\u00e9place le tag pour pointer vers celui-ci.<\/p>\n# Mauvais : Tag mutable, vuln\u00e9rable au d\u00e9tournement\n- uses: actions\/checkout@v4\n\n# Bon : \u00c9pingl\u00e9 \u00e0 un SHA de commit immuable\n- uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1<\/code><\/pre>\nProtection des Branches et Contr\u00f4les de Fusion<\/h3>\n
\n
Contr\u00f4les de D\u00e9ploiement<\/h3>\n
\n
S\u00e9paration des Responsabilit\u00e9s<\/h3>\n
\n
\n
Recommandations Sp\u00e9cifiques aux Plateformes<\/h2>\n
GitHub Actions<\/h3>\n
\n
permissions<\/code> au niveau du workflow avec des valeurs par d\u00e9faut en lecture seule, en accordant l’\u00e9criture uniquement l\u00e0 o\u00f9 c’est n\u00e9cessaire<\/li>\npull_request_target<\/code> est extr\u00eamement dangereux s’il est mal utilis\u00e9 ; pr\u00e9f\u00e9rer pull_request<\/code> pour le code non fiable<\/li>\nGitLab CI<\/h3>\n
\n
rules: - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"<\/code> pour contr\u00f4ler ce qui s’ex\u00e9cute sur les contributions externes<\/li>\nid_tokens<\/code> pour l’authentification cloud sans cl\u00e9<\/li>\n