Les pipelines CI\/CD sont devenus la colonne vert\u00e9brale de la livraison logicielle moderne. Ils compilent le code, ex\u00e9cutent les tests, g\u00e8rent les secrets, provisionnent l’infrastructure et d\u00e9ploient les applications en production. Pourtant, ce r\u00f4le central en fait l’un des composants les plus privil\u00e9gi\u00e9s \u2014 et les plus vis\u00e9s \u2014 de toute votre pile technologique. Un pipeline compromis n’affecte pas un seul syst\u00e8me ; il peut se propager en cascade \u00e0 travers chaque environnement, chaque artifact et chaque client que votre logiciel atteint.<\/p>\n\n
Des attaques tr\u00e8s m\u00e9diatis\u00e9es de la cha\u00eene d’approvisionnement \u2014 SolarWinds, Codecov et les diverses compromissions de packages npm\/PyPI \u2014 ont d\u00e9montr\u00e9 que les attaquants ciblent de plus en plus le processus de build et de d\u00e9ploiement lui-m\u00eame plut\u00f4t que l’application en cours d’ex\u00e9cution. Lorsqu’un pipeline est compromis, l’attaquant obtient la capacit\u00e9 d’injecter du code malveillant dans des artifacts de confiance, d’exfiltrer des secrets \u00e0 grande \u00e9chelle et de se d\u00e9placer lat\u00e9ralement entre les environnements avec les m\u00eames privil\u00e8ges \u00e9lev\u00e9s que ceux dont dispose le pipeline.<\/p>\n\n
Le durcissement des pipelines est la pratique syst\u00e9matique consistant \u00e0 r\u00e9duire la surface d’attaque, \u00e0 appliquer le moindre privil\u00e8ge et \u00e0 mettre en place des contr\u00f4les de d\u00e9fense en profondeur \u00e0 chaque \u00e9tape de votre workflow CI\/CD. Ce guide couvre les domaines essentiels du durcissement des pipelines \u2014 de l’isolation des runners et de la protection des secrets \u00e0 l’application des politiques et aux contr\u00f4les de d\u00e9ploiement \u2014 avec des conseils de mise en \u0153uvre pratiques et des liens vers des labs pratiques o\u00f9 appliquer chaque concept.<\/p>\n\n
Avant de plonger dans les techniques de durcissement, il est important de comprendre pourquoi les pipelines CI\/CD repr\u00e9sentent des cibles aussi attrayantes pour les adversaires. Les pipelines fonctionnent g\u00e9n\u00e9ralement avec des privil\u00e8ges \u00e9lev\u00e9s qui d\u00e9passent de loin ce que d\u00e9tient un d\u00e9veloppeur individuel. Ils disposent d’un acc\u00e8s en \u00e9criture aux registres d’artifacts, d’identifiants de d\u00e9ploiement pour les environnements de production, d’un acc\u00e8s aux coffres de secrets et de l’autorit\u00e9 pour modifier l’infrastructure. Cette concentration de privil\u00e8ges cr\u00e9e un point unique de compromission dont le rayon d’impact s’\u00e9tend \u00e0 l’ensemble du cycle de vie de la livraison logicielle.<\/p>\n\n
Consid\u00e9rez ce \u00e0 quoi un pipeline typique peut acc\u00e9der : d\u00e9p\u00f4ts de code source, registres de d\u00e9pendances, container registries, identifiants de fournisseurs cloud, cha\u00eenes de connexion aux bases de donn\u00e9es, cl\u00e9s API de services tiers, identifiants de clusters Kubernetes et cibles de d\u00e9ploiement dans les environnements de d\u00e9veloppement, de staging et de production. Un attaquant qui prend le contr\u00f4le du pipeline obtient de fait un acc\u00e8s simultan\u00e9 \u00e0 toutes ces ressources.<\/p>\n\n
De plus, les pipelines traitent des entr\u00e9es non fiables \u2014 pull requests de contributeurs externes, mises \u00e0 jour de d\u00e9pendances, charges utiles de webhooks \u2014 \u00e0 l’aide de code qui fait souvent l’objet d’un examen de s\u00e9curit\u00e9 moins pouss\u00e9 que l’application elle-m\u00eame. Les fichiers de configuration de pipeline, les scripts shell et les actions personnalis\u00e9es sont rarement soumis \u00e0 la m\u00eame rigueur de revue de code que le code applicatif de production, ce qui cr\u00e9e des angles morts que les attaquants peuvent exploiter.<\/p>\n\n
Le runner de build \u2014 l’environnement de calcul o\u00f9 s’ex\u00e9cutent les jobs du pipeline \u2014 est la fronti\u00e8re de s\u00e9curit\u00e9 la plus fondamentale de votre syst\u00e8me CI\/CD. Si les runners ne sont pas correctement isol\u00e9s, toute autre mesure de durcissement peut \u00eatre contourn\u00e9e. La strat\u00e9gie d’isolation des runners repose sur une d\u00e9cision de conception critique : runners \u00e9ph\u00e9m\u00e8res ou persistants.<\/p>\n\n
Les runners persistants (\u00e0 longue dur\u00e9e de vie) conservent un \u00e9tat entre les ex\u00e9cutions de jobs. Cela signifie que les artifacts, les identifiants, les variables d’environnement et les modifications du syst\u00e8me de fichiers d’un job peuvent potentiellement \u00eatre accessibles aux jobs suivants. Les runners persistants cr\u00e9ent plusieurs risques de s\u00e9curit\u00e9 :<\/p>\n\n
Les runners \u00e9ph\u00e9m\u00e8res sont cr\u00e9\u00e9s \u00e0 neuf pour chaque job et d\u00e9truits imm\u00e9diatement apr\u00e8s son ach\u00e8vement. Cette approche offre de solides garanties d’isolation : chaque job d\u00e9marre dans un environnement propre et sain, et toute modification \u2014 intentionnelle ou malveillante \u2014 est automatiquement \u00e9cart\u00e9e. Les avantages incluent :<\/p>\n\n
Pour les organisations qui utilisent Kubernetes, Actions Runner Controller (ARC)<\/strong> fournit une solution robuste pour des runners GitHub Actions \u00e9ph\u00e9m\u00e8res et \u00e0 mise \u00e0 l’\u00e9chelle automatique. ARC provisionne dynamiquement des pods runner en r\u00e9ponse aux demandes des workflows et les d\u00e9truit une fois chaque job termin\u00e9. Cette approche combine les avantages d’isolation des runners \u00e9ph\u00e9m\u00e8res avec les atouts op\u00e9rationnels de l’orchestration Kubernetes.<\/p>\n\n Les consid\u00e9rations de durcissement cl\u00e9s lors du d\u00e9ploiement d’ARC incluent : utiliser des pools de n\u0153uds d\u00e9di\u00e9s pour les workloads de runners, appliquer des politiques r\u00e9seau Kubernetes pour restreindre les communications runner-\u00e0-runner et runner-\u00e0-cluster, configurer des pod security standards pour emp\u00eacher l’\u00e9l\u00e9vation de privil\u00e8ges, et utiliser des syst\u00e8mes de fichiers racine en lecture seule lorsque c’est possible. Pour un parcours complet du d\u00e9ploiement et de la configuration s\u00e9curis\u00e9s d’ARC, consultez notre lab pratique : Runners auto-h\u00e9berg\u00e9s \u00e9ph\u00e9m\u00e8res avec Actions Runner Controller<\/a>.<\/p>\n\n Au-del\u00e0 des runners \u00e9ph\u00e9m\u00e8res, des couches d’isolation suppl\u00e9mentaires renforcent votre posture de s\u00e9curit\u00e9 :<\/p>\n\n Le principe du moindre privil\u00e8ge est peut-\u00eatre la strat\u00e9gie de durcissement la plus d\u00e9terminante que vous puissiez appliquer aux pipelines CI\/CD. Chaque pipeline, chaque job et chaque \u00e9tape devrait fonctionner avec l’ensemble minimal absolu de permissions requis pour accomplir sa t\u00e2che \u2014 et rien de plus.<\/p>\n\n La plupart des plateformes CI\/CD fournissent des tokens automatiques (par exemple, D\u00e9clarez les permissions au niveau du workflow avec des valeurs par d\u00e9faut minimales, puis n’accordez de permissions suppl\u00e9mentaires qu’aux jobs sp\u00e9cifiques qui en ont besoin. Ainsi, une \u00e9tape de build compromise ne peut pas abuser des identifiants de d\u00e9ploiement si ceux-ci ne sont disponibles que pour le job de d\u00e9ploiement.<\/p>\n\n Le durcissement des pipelines va au-del\u00e0 des permissions de tokens : il concerne aussi la fa\u00e7on dont les responsabilit\u00e9s sont r\u00e9parties dans le pipeline. Les principes essentiels incluent :<\/p>\n\n Pour une exploration plus approfondie de la mise en \u0153uvre de la s\u00e9paration des responsabilit\u00e9s et du moindre privil\u00e8ge dans vos pipelines, lisez notre guide d\u00e9taill\u00e9 : S\u00e9paration des responsabilit\u00e9s et moindre privil\u00e8ge dans les pipelines CI\/CD<\/a>.<\/p>\n\n Les secrets \u2014 cl\u00e9s API, identifiants de bases de donn\u00e9es, cl\u00e9s de signature, tokens de fournisseurs cloud \u2014 sont le nerf de la guerre des op\u00e9rations de pipeline et la cible principale des attaquants. Une strat\u00e9gie compl\u00e8te de protection des secrets traite de la fa\u00e7on dont les secrets sont stock\u00e9s, inject\u00e9s, cadr\u00e9s, renouvel\u00e9s et surveill\u00e9s.<\/p>\n\n Pour des sch\u00e9mas complets d’int\u00e9gration des gestionnaires de secrets \u00e0 vos pipelines CI\/CD, consultez notre guide : Gestion des secrets dans les pipelines CI\/CD : sch\u00e9mas avec Vault<\/a>.<\/p>\n\n L’une des avanc\u00e9es les plus importantes en mati\u00e8re de s\u00e9curit\u00e9 des pipelines est l’adoption de la f\u00e9d\u00e9ration OpenID Connect (OIDC) pour l’authentification cloud. Au lieu de stocker des identifiants cloud \u00e0 longue dur\u00e9e de vie sous forme de secrets de pipeline, OIDC permet au pipeline d’\u00e9changer un token de courte dur\u00e9e, sign\u00e9 cryptographiquement, contre des identifiants cloud temporaires.<\/p>\n\n Les avantages sont consid\u00e9rables :<\/p>\n\n M\u00eame avec une bonne gestion des secrets, des fuites peuvent survenir via les logs du pipeline, les messages d’erreur, les uploads d’artifacts ou des \u00e9tapes mal configur\u00e9es. Mettez en place plusieurs couches de pr\u00e9vention des fuites :<\/p>\n\n Notre lab pratique d\u00e9taille la mise en \u0153uvre de ces contr\u00f4les de bout en bout : D\u00e9tecter et pr\u00e9venir les fuites de secrets dans les pipelines CI\/CD<\/a>.<\/p>\n\n Une dimension souvent n\u00e9glig\u00e9e du durcissement des pipelines est le contr\u00f4le des ressources r\u00e9seau auxquelles les jobs de build peuvent acc\u00e9der. Par d\u00e9faut, la plupart des runners disposent d’un acc\u00e8s Internet sans restriction, ce qui cr\u00e9e des occasions d’attaques par confusion de d\u00e9pendances, d’exfiltration de donn\u00e9es et de communication de commande et contr\u00f4le depuis des \u00e9tapes de build compromises.<\/p>\n\n La mise en place de contr\u00f4les r\u00e9seau pendant le processus de build r\u00e9duit consid\u00e9rablement la surface d’attaque :<\/p>\n\n L’expression ultime du contr\u00f4le r\u00e9seau pendant le build est le build herm\u00e9tique \u2014 un build qui n’a aucun acc\u00e8s r\u00e9seau et repose enti\u00e8rement sur des d\u00e9pendances pr\u00e9-t\u00e9l\u00e9charg\u00e9es et v\u00e9rifi\u00e9es. Les builds herm\u00e9tiques offrent la plus forte garantie contre les attaques de la cha\u00eene d’approvisionnement pendant la phase de build, car le processus de build ne peut pas t\u00e9l\u00e9charger de d\u00e9pendances inattendues ou alt\u00e9r\u00e9es.<\/p>\n\n La mise en place de builds herm\u00e9tiques comporte plusieurs \u00e9tapes :<\/p>\n\n Des syst\u00e8mes de build comme Bazel et Buck2 prennent en charge nativement les builds herm\u00e9tiques. Pour les autres outils de build, vous pouvez approcher des builds herm\u00e9tiques en utilisant des politiques r\u00e9seau au niveau des conteneurs (par exemple, les Les revues de s\u00e9curit\u00e9 manuelles ne passent pas \u00e0 l’\u00e9chelle face \u00e0 la v\u00e9locit\u00e9 des pipelines CI\/CD modernes. L’application des politiques automatise les d\u00e9cisions de s\u00e9curit\u00e9 en codifiant les exigences de s\u00e9curit\u00e9 de votre organisation sous forme de politiques lisibles par machine, \u00e9valu\u00e9es automatiquement \u00e0 chaque \u00e9tape du pipeline.<\/p>\n\n L’ Open Policy Agent (OPA)<\/strong> et son langage de politiques Rego<\/strong> se sont impos\u00e9s comme le standard de facto du policy-as-code dans les environnements cloud-native. Dans le contexte des pipelines CI\/CD, OPA peut appliquer des politiques dans plusieurs domaines :<\/p>\n\n Conftest<\/strong> est un outil de test b\u00e2ti sur OPA qui simplifie l’int\u00e9gration des contr\u00f4les de politique dans les pipelines CI\/CD. Conftest peut valider des formats de donn\u00e9es structur\u00e9s \u2014 YAML, JSON, HCL, Dockerfile, et plus \u2014 par rapport \u00e0 des politiques Rego, ce qui le rend id\u00e9al pour v\u00e9rifier les manifestes Kubernetes, les configurations Terraform, les Dockerfiles et les d\u00e9finitions de pipeline elles-m\u00eames.<\/p>\n\n Pour un guide approfondi de la mise en \u0153uvre du policy-as-code dans vos pipelines CI\/CD avec OPA, Rego et Conftest, consultez : Policy as Code en CI\/CD : OPA, Rego et portes de s\u00e9curit\u00e9<\/a>.<\/p>\n\n Une application efficace des politiques op\u00e8re \u00e0 plusieurs niveaux :<\/p>\n\n La phase de d\u00e9ploiement repr\u00e9sente le point o\u00f9 les actions du pipeline impactent directement les syst\u00e8mes de production et les utilisateurs finaux. Durcir les contr\u00f4les de d\u00e9ploiement est essentiel pour emp\u00eacher les changements non autoris\u00e9s, limiter le rayon d’impact et permettre une reprise rapide en cas de probl\u00e8me.<\/p>\n\n Les r\u00e8gles de protection d’environnement cr\u00e9ent des points de contr\u00f4le obligatoires avant que les d\u00e9ploiements ne puissent se poursuivre :<\/p>\n\n GitOps \u00e9l\u00e8ve Git au rang de source unique de v\u00e9rit\u00e9 pour l’\u00e9tat de l’infrastructure et des applications. Un mod\u00e8le de d\u00e9ploiement GitOps offre de solides b\u00e9n\u00e9fices en mati\u00e8re de durcissement :<\/p>\n\n Les strat\u00e9gies de livraison progressive limitent le rayon d’impact des d\u00e9ploiements en exposant progressivement les changements au trafic de production :<\/p>\n\n Des outils comme Argo Rollouts, Flagger et Istio fournissent des capacit\u00e9s de livraison progressive automatis\u00e9e qui s’int\u00e8grent \u00e0 votre pipeline CI\/CD pour imposer des pratiques de d\u00e9ploiement s\u00fbres.<\/p>\n\n Le durcissement ne concerne pas uniquement la pr\u00e9vention \u2014 il exige aussi la capacit\u00e9 de d\u00e9tecter les anomalies, d’enqu\u00eater sur les incidents et de r\u00e9pondre aux menaces visant l’infrastructure de votre pipeline. Une surveillance compl\u00e8te ferme la boucle de r\u00e9troaction, en garantissant que vos mesures de durcissement fonctionnent et en vous alertant lorsqu’elles \u00e9chouent.<\/p>\n\n Capturez et centralisez les logs d’audit de chaque composant de votre infrastructure CI\/CD :<\/p>\n\n Au-del\u00e0 de la journalisation, mettez en place une d\u00e9tection active des comportements suspects du pipeline :<\/p>\n\n Suivez les m\u00e9triques cl\u00e9s qui indiquent la sant\u00e9 et la posture de s\u00e9curit\u00e9 de votre infrastructure de pipeline :<\/p>\n\n Le durcissement des pipelines est un parcours, pas un projet ponctuel. Les organisations devraient adopter une approche incr\u00e9mentale, en priorisant les contr\u00f4les en fonction du risque et de la complexit\u00e9 de mise en \u0153uvre. La feuille de route suivante propose une s\u00e9quence pratique pour faire m\u00fbrir la posture de s\u00e9curit\u00e9 de vos pipelines.<\/p>\n\n La th\u00e9orie est essentielle, mais c’est l’exp\u00e9rience pratique qui fait la diff\u00e9rence. Les labs pratiques suivants vous permettent de mettre en \u0153uvre les techniques de durcissement abord\u00e9es dans ce guide dans des environnements r\u00e9alistes :<\/p>\n\n Les outils et frameworks suivants soutiennent le durcissement des pipelines dans les domaines couverts par ce guide :<\/p>\n\nTechniques d’isolation suppl\u00e9mentaires des runners<\/h3>\n\n
\n
Moindre privil\u00e8ge : r\u00e9duire les permissions des pipelines<\/h2>\n\n
P\u00e9rim\u00e8tre des tokens<\/h3>\n\n
GITHUB_TOKEN<\/code> dans GitHub Actions) qui accordent un acc\u00e8s au d\u00e9p\u00f4t et aux ressources associ\u00e9es. Par d\u00e9faut, ces tokens comportent souvent des permissions trop larges. Le durcissement exige un p\u00e9rim\u00e8tre explicite :<\/p>\n\n# GitHub Actions: Restrict default token permissions\npermissions:\n contents: read\n packages: read\n\njobs:\n deploy:\n permissions:\n contents: read\n deployments: write\n id-token: write # Only for OIDC-based authentication<\/code><\/pre>\n\nS\u00e9paration des responsabilit\u00e9s<\/h3>\n\n
\n
Protection des secrets : pr\u00e9venir les fuites et r\u00e9duire l’exposition<\/h2>\n\n
Bonnes pratiques de gestion des secrets<\/h3>\n\n
\n
F\u00e9d\u00e9ration OIDC : \u00e9liminer les identifiants \u00e0 longue dur\u00e9e de vie<\/h3>\n\n
\n
# GitHub Actions OIDC with AWS\njobs:\n deploy:\n permissions:\n id-token: write\n contents: read\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/deploy-role\n aws-region: us-east-1\n # No static AWS keys needed!<\/code><\/pre>\n\nPr\u00e9vention des fuites de secrets<\/h3>\n\n
\n
gitleaks<\/code>, trufflehog<\/code>, ou detect-secrets<\/code> pour intercepter les secrets avant qu’ils n’entrent dans le d\u00e9p\u00f4t.<\/li>\nRestrictions r\u00e9seau : contr\u00f4ler les communications pendant le build<\/h2>\n\n
Contr\u00f4les r\u00e9seau pendant le build<\/h3>\n\n
\n
Builds herm\u00e9tiques<\/h3>\n\n
\n
NetworkPolicy<\/code> de Kubernetes) ou des r\u00e8gles de pare-feu qui bloquent toute sortie pendant l’\u00e9tape de build.<\/p>\n\nApplication des politiques : des portes de s\u00e9curit\u00e9 automatis\u00e9es<\/h2>\n\n
Policy as Code avec OPA et Rego<\/h3>\n\n
\n
Conftest pour des contr\u00f4les de politiques int\u00e9gr\u00e9s au pipeline<\/h3>\n\n
# Example Rego policy: Deny containers running as root\npackage main\n\ndeny[msg] {\n input.kind == \"Deployment\"\n container := input.spec.template.spec.containers[_]\n not container.securityContext.runAsNonRoot\n msg := sprintf(\"Container '%s' must set runAsNonRoot: true\", [container.name])\n}<\/code><\/pre>\n\nApplication des politiques en couches<\/h3>\n\n
\n
Contr\u00f4les de d\u00e9ploiement : prot\u00e9ger les environnements de production<\/h2>\n\n
Portes et approbations d’environnement<\/h3>\n\n
\n
main<\/code> peut d\u00e9ployer en production.<\/li>\nGitOps : des d\u00e9ploiements d\u00e9claratifs et auditables<\/h3>\n\n
\n
Livraison progressive : d\u00e9ploiements canary et blue-green<\/h3>\n\n
\n
Surveillance et d\u00e9tection<\/h2>\n\n
Journalisation d’audit des pipelines<\/h3>\n\n
\n
D\u00e9tection d’anomalies<\/h3>\n\n
\n
M\u00e9triques de s\u00e9curit\u00e9 et tableaux de bord<\/h3>\n\n
\n
Feuille de route de mise en \u0153uvre<\/h2>\n\n
Phase 1 : fondations (semaines 1-4)<\/h3>\n\n
\n
permissions:<\/code> restrictifs dans GitHub Actions).<\/li>\nPhase 2 : isolation et secrets (semaines 5-8)<\/h3>\n\n
\n
Phase 3 : politiques et contr\u00f4les r\u00e9seau (semaines 9-12)<\/h3>\n\n
\n
Phase 4 : durcissement du d\u00e9ploiement (semaines 13-16)<\/h3>\n\n
\n
Phase 5 : surveillance et am\u00e9lioration continue (en continu)<\/h3>\n\n
\n
Labs pratiques<\/h2>\n\n
\n
Outils et ressources<\/h2>\n\n
Isolation des runners<\/h3>\n\n
\n
Secrets et identit\u00e9<\/h3>\n\n
\n
D\u00e9tection de secrets<\/h3>\n\n
\n
Application des politiques<\/h3>\n\n
\n
D\u00e9ploiement et GitOps<\/h3>\n\n
\n