Le Guide Complet de la Sécurité des Pipelines CI/CD

Introduction

Les pipelines CI/CD constituent l’épine dorsale de la livraison logicielle moderne. Ils automatisent le parcours du commit de code jusqu’au déploiement en production, permettant aux équipes de livrer plus rapidement, de manière 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és.

Réfléchissez à ce qu’un pipeline CI/CD manipule. Il récupère le code source, résout les dépendances, accède aux secrets et aux identifiants, construit des artefacts, les pousse vers des registres et déploie sur l’infrastructure de production. Un seul pipeline compromis peut donner à un attaquant accès à tout — code source, secrets, comptes cloud, données clients et systèmes de production.

Ce guide fournit une vue d’ensemble complète de la sécurité des pipelines CI/CD : ce qui est en jeu, où se trouvent les risques et comment construire des pipelines sécurisés de la source à la production. Que vous soyez un ingénieur sécurité renforçant des pipelines existants ou une équipe DevOps en construisant de nouveaux, ceci est votre référence complète pour comprendre et mettre en œuvre la sécurité CI/CD.

Nous couvrirons l’ensemble du paysage — de la modélisation des menaces et des surfaces d’attaque à la gestion des secrets, l’intégrité des artefacts, l’application des politiques et le durcissement spécifique aux plateformes. Tout au long du guide, nous renverrons vers des guides détaillés, des travaux pratiques et des ressources concrètes qui vous permettront d’approfondir chaque sujet.

Pourquoi les Pipelines CI/CD Sont une Priorité Sécuritaire

Les pipelines CI/CD occupent une position unique et dangereuse dans l’infrastructure moderne. Ce sont des systèmes d’automatisation avec un accès privilégié à pratiquement toutes les ressources critiques de votre organisation. Comprendre pourquoi ils comptent commence par comprendre ce qu’ils peuvent atteindre.

Les Pipelines Sont des Cibles de Haute Valeur

Un pipeline CI/CD typique a accès à :

Les dépôts de code source — y compris les dépôts privés, les algorithmes propriétaires et la configuration
Les secrets et identifiants — clés API, identifiants de fournisseurs cloud, mots de passe de bases de données, clés de signature
L’infrastructure cloud — comptes AWS, GCP, Azure avec des permissions de déploiement
Les environnements de production — accès direct au déploiement sur les systèmes en production servant les clients
Les registres d’artefacts — registres de conteneurs, dépôts de paquets, stockage de binaires
Les réseaux internes — les runners se trouvent souvent à l’intérieur de réseaux privés avec une connectivité étendue

Un pipeline compromis ne donne pas simplement aux attaquants un point d’ancrage — il leur donne les clés du royaume. La compromission d’un pipeline est l’un des moyens les plus efficaces pour réaliser un mouvement latéral à travers une organisation entière.

Attaques Réelles Contre les Pipelines

Ce n’est pas théorique. Certains des incidents de sécurité les plus significatifs de ces dernières années ont été des attaques contre les pipelines et la chaîne d’approvisionnement :

SolarWinds (2020) — Les attaquants ont compromis le système de build de SolarWinds Orion, injectant du code malveillant dans des mises à jour logicielles signées qui ont été distribuées à environ 18 000 organisations, dont des agences gouvernementales américaines. L’attaque est restée indétectée pendant des mois car le code malveillant était inséré pendant le processus de build, ce qui signifie que le dépôt de code source semblait propre.
Codecov (2021) — Les attaquants ont modifié le script Bash Uploader de Codecov en exploitant une faille dans la création d’images Docker. Pendant plus de deux mois, le script compromis a exfiltré des variables d’environnement — y compris des secrets CI/CD, des jetons API et des identifiants — depuis des milliers d’environnements CI utilisant Codecov.
CircleCI (2023) — L’ordinateur portable d’un ingénieur a été compromis via un malware, ce qui a donné aux attaquants accès à un jeton de session de production CircleCI. À partir de là, les attaquants ont accédé aux variables d’environnement, jetons et clés des clients stockés dans la plateforme CircleCI. Chaque secret stocké dans CircleCI devait être considéré comme compromis.
GitHub Actions (en cours) — De multiples incidents impliquant des actions tierces compromises, des identifiants GITHUB_TOKEN volés et des attaques de la chaîne d’approvisionnement via les dépendances d’actions continuent de démontrer que la sécurité des pipelines est une menace persistante et évolutive.

Le fil conducteur de tous ces incidents : les attaquants ciblent le pipeline lui-même, pas l’application. Les mesures de sécurité applicative traditionnelles — WAFs, protection des endpoints, surveillance en temps réel — n’aident pas lorsque le vecteur d’attaque est le système de build et de déploiement.

Le Problème d’Asymétrie

Il existe une asymétrie fondamentale dans la sécurité CI/CD. Les pipelines sont conçus pour être permissifs et rapides. Ils ont besoin d’un accès large pour faire leur travail. La sécurité, en revanche, exige restriction et vérification. Combler cet écart — maintenir la vélocité du pipeline tout en appliquant des frontières de sécurité — est le défi central de la sécurité CI/CD.

La Surface d’Attaque CI/CD

Avant de pouvoir sécuriser un pipeline, vous devez comprendre où il peut être attaqué. La surface d’attaque CI/CD est large, couvrant de multiples systèmes, frontières de confiance et domaines organisationnels.

Cartographier la Surface d’Attaque

La surface d’attaque CI/CD comprend :

Les dépôts de code source — contournement de la protection des branches, pull requests malveillantes, comptes développeurs compromis, modifications non autorisées des définitions de pipeline
Les définitions de pipeline — Exécution de pipeline empoisonné (PPE), où les attaquants modifient les fichiers de configuration CI (par ex., .github/workflows/, .gitlab-ci.yml, Jenkinsfile) via des pull requests ou des pushs sur des branches
Les environnements de build — runners partagés, caches de build persistants, outils de build compromis, évasions de conteneurs depuis les conteneurs de build
Les dépendances — confusion de dépendances, typosquatting, paquets upstream compromis, dépendances transitives malveillantes
Les secrets et identifiants — accès aux secrets trop large, identifiants à longue durée de vie, secrets fuités dans les logs, secrets accessibles aux builds de dépôts forkés
Les artefacts — artefacts de build falsifiés, images non signées, registres compromis, empoisonnement d’artefacts
Les cibles de déploiement — déploiement non autorisé, portes d’approbation manquantes, séparation insuffisante des environnements

Le Top 10 OWASP des Risques de Sécurité CI/CD

Le projet OWASP Top 10 CI/CD Security Risks fournit un cadre structuré pour comprendre ces menaces. Il catalogue les risques les plus critiques, notamment les mécanismes de contrôle de flux insuffisants, la gestion inadéquate des identités et des accès, l’abus de la chaîne de dépendances, l’exécution de pipeline empoisonné et l’hygiène insuffisante des identifiants. Chaque risque correspond à des schémas d’attaque réels et fournit des recommandations concrètes pour l’atténuation.

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étaillée : Pourquoi les Pipelines CI/CD Sont la Surface d’Attaque Principale.

Frontières de Confiance et Modèles d’Exécution

L’un des aspects les plus fondamentaux — et les plus fréquemment mal compris — de la sécurité CI/CD est celui des frontières de confiance. Chaque pipeline opère dans un ensemble d’hypothèses de confiance, et les violations de ces hypothèses sont là où la sécurité s’effondre.

Questions Clés pour Chaque Pipeline

Pour chaque exécution de pipeline, vous devriez être en mesure de répondre :

Qui a déclenché ce pipeline ? — Était-ce un développeur interne, un contributeur externe, un job planifié ou une mise à jour automatique de dépendance ?
Quel code est exécuté ? — S’agit-il de code provenant d’une branche de confiance, d’une pull request d’un fork, d’une action tierce ou d’une dépendance résolue dynamiquement ?
Quelle identité le pipeline assume-t-il ? — Quels comptes de service, rôles cloud ou jetons de plateforme sont disponibles pendant l’exécution ?
À quelles ressources le pipeline peut-il accéder ? — Quels secrets, infrastructures, registres et environnements sont atteignables ?

Modèles de Confiance en CI/CD

Différents déclencheurs de pipeline portent des niveaux de confiance fondamentalement différents :

Push sur une branche protégée — Confiance élevée. Le code a passé la revue et les règles de protection de branche.
Pull request d’un collaborateur — Confiance moyenne. L’auteur du code est connu mais les modifications n’ont pas été fusionnées.
Pull request d’un fork — Confiance faible. Le code provient d’un contributeur externe et pourrait contenir n’importe quoi.
Jobs planifiés/cron — Confiance variable. Dépend du code et des dépendances résolus au moment de l’exécution.
Déclenchement manuel — Dépend de qui a déclenché et des paramètres fournis.

Le principe essentiel : les permissions du pipeline et l’accès aux secrets doivent être calibrés au niveau de confiance du déclencheur. Une pull request d’un fork ne devrait jamais avoir accès aux identifiants de déploiement en production.

Modèles d’Exécution

Les différentes plateformes CI/CD gèrent l’isolation d’exécution différemment. Comprendre le modèle d’exécution — que les builds s’exécutent dans des VM partagées, des conteneurs éphémères ou des serveurs persistants — impacte directement votre posture de sécurité. Les environnements d’exécution partagés créent des risques de contamination entre builds, de vol d’identifiants et d’empoisonnement du cache.

Pour une exploration complète des modèles d’exécution CI/CD et de leurs implications en matière de sécurité, consultez : Modèles d’Exécution CI/CD, Hypothèses de Confiance et Guide de Sécurité.

Gestion des Secrets

S’il y a un domaine qui mérite le plus d’attention dans la sécurité CI/CD, c’est la gestion des secrets. La compromission des identifiants est systématiquement la cause n°1 des incidents de sécurité CI/CD. Une mauvaise hygiène des secrets — identifiants codés en dur, accès trop large, jetons à longue durée de vie, secrets exposés au code non fiable — est derrière pratiquement chaque brèche majeure de pipeline.

Le Problème des Secrets en CI/CD

Les pipelines ont besoin de secrets pour fonctionner. Ils ont besoin d’identifiants pour récupérer le code, résoudre les dépendances privées, accéder aux API cloud, pousser les artefacts et déployer en production. Le défi est de fournir ces identifiants de manière sécurisée :

Minimiser l’exposition — Les secrets ne doivent être disponibles que pour les étapes spécifiques qui en ont besoin
Limiter la durée de vie — Les identifiants doivent être de courte durée et automatiquement renouvelés
Restreindre la portée — Chaque identifiant ne doit avoir que les permissions minimales requises
Prévenir les fuites — Les secrets ne doivent pas apparaître dans les logs, les artefacts, les messages d’erreur ou les variables d’environnement accessibles au code non fiable

Approches de Gestion des Secrets

Il existe un spectre de maturité pour la gestion des secrets en CI/CD :

Niveau 1 : Secrets Natifs de la Plateforme

Chaque plateforme CI/CD fournit un mécanisme intégré de gestion des secrets — 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épart mais avec des limitations : ils sont spécifiques à la plateforme, difficiles à auditer et offrent généralement un contrôle d’accès à gros grain.

Niveau 2 : Gestionnaires de Secrets Externes

L’intégration avec des outils dédiés de gestion des secrets — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager — fournit une gestion centralisée, des politiques d’accès à grain fin, la journalisation d’audit et la rotation automatique. Vault, en particulier, excelle dans la génération d’identifiants dynamiques et de courte durée, limités à des exécutions de pipeline spécifiques.

Niveau 3 : OIDC et Fédération d’Identité de Charge de Travail

Le standard d’excellence pour les identifiants CI/CD est d’éliminer entièrement les secrets à longue durée de vie. En utilisant OIDC (OpenID Connect) et la fédération d’identité de charge de travail, les pipelines peuvent s’authentifier auprès des fournisseurs cloud en utilisant leur identité de plateforme — sans aucun secret stocké. GitHub Actions, GitLab CI et d’autres plateformes peuvent échanger leurs jetons OIDC contre des identifiants cloud de courte durée limités à des dépôts, branches et environnements spécifiques.

Cette approche fournit :

Aucun secret à voler — les identifiants sont générés à la demande et expirent en quelques minutes
Limitation fine de la portée — l’accès peut être restreint à des dépôts, branches et environnements de déploiement spécifiques
Auditabilité complète — chaque échange d’identifiants est journalisé avec le contexte du pipeline

Bonnes Pratiques de Gestion des Secrets

Ne jamais coder en dur les secrets dans les définitions de pipeline, le code source ou les Dockerfiles
Utiliser des secrets limités par environnement pour séparer les identifiants de staging et de production
Mettre en place la détection de secrets dans les hooks pre-commit et en CI pour capturer les expositions accidentelles
Préférer OIDC/la fédération d’identité de charge de travail aux identifiants stockés partout où c’est possible
Utiliser des secrets dynamiques (par ex., identifiants de base de données dynamiques Vault) générés par exécution de pipeline
Renouveler tous les identifiants à longue durée de vie selon un calendrier régulier et immédiatement après toute suspicion de compromission
Ne jamais exposer les secrets aux builds de pull requests provenant de forks

Pour des conseils de mise en œuvre détaillés, consultez nos guides approfondis :

Intégrité des Artefacts et Sécurité de la Chaîne d’Approvisionnement

Sécuriser ce qui entre dans votre pipeline (code, dépendances, secrets) n’est que la moitié du combat. Vous devez aussi sécuriser ce qui en sort — les artefacts que votre pipeline produit et déploie. L’intégrité des artefacts garantit que ce que vous déployez est exactement ce que vous avez construit, sans falsification en cours de route.

Le Problème de la Chaîne d’Approvisionnement

Le logiciel moderne ne se compose pas uniquement de votre code. Une application typique comprend des centaines, voire des milliers de dépendances, d’images de base, d’outils de build et d’intégrations tierces. Chacun de ces éléments est un maillon de la chaîne d’approvisionnement, et chacun peut être compromis. Les attaques de la chaîne d’approvisionnement ciblent ces maillons — en injectant du code malveillant dans les dépendances, en falsifiant les artefacts de build ou en compromettant les registres.

Signature d’Images de Conteneurs avec Sigstore et Cosign

La signature d’images de conteneurs fournit une preuve cryptographique qu’une image a été construite par un pipeline de confiance et n’a pas été falsifiée. Sigstore et son outil Cosign ont considérablement simplifié la signature d’images en fournissant la signature sans clé — utilisant les identités OIDC (comme l’identité d’un pipeline CI/CD) pour signer les artefacts sans gérer de clés de signature à longue durée de vie.

Dans un pipeline sécurisé, chaque image de conteneur devrait être :

Signée au moment du build en utilisant l’identité vérifiée du pipeline
Vérifiée au moment du déploiement avant d’être admise en production
Rejetée si la signature ne correspond pas à une identité ou une politique de confiance

Provenance et Attestations avec SLSA et in-toto

SLSA (Supply-chain Levels for Software Artifacts) fournit un cadre pour améliorer progressivement l’intégrité de la chaîne d’approvisionnement. Au cœur de SLSA se trouve la provenance — un enregistrement vérifiable de comment, où et par qui un artefact a été construit.

Le framework in-toto complète SLSA en fournissant un moyen de définir et de vérifier l’ensemble de la chaîne d’approvisionnement logicielle — du code source à travers le build jusqu’au déploiement. Chaque étape de la chaîne produit des attestations qui peuvent être vérifiées par rapport à une disposition prédéfinie.

Concepts clés :

Provenance — métadonnées lisibles par machine décrivant le build : quelles entrées ont été utilisées, quel système de build a été exécuté, quelles sorties ont été produites
Attestations — déclarations signées concernant un artefact (par ex., « cette image a été construite à partir de ce commit par ce pipeline »)
Vérification — contrôles automatisés au moment du déploiement qui rejettent les artefacts sans provenance valide

Nomenclature Logicielle (SBOM)

Un SBOM fournit un inventaire complet de tous les composants d’un artefact logiciel — chaque bibliothèque, dépendance et version d’outil. Les SBOMs permettent :

Le suivi des vulnérabilités — lorsqu’un nouveau CVE est publié, vous pouvez immédiatement identifier quels artefacts sont concernés
La conformité des licences — vérification automatisée que tous les composants respectent les exigences de licence
La réponse aux incidents — évaluation rapide du rayon d’impact lorsqu’une compromission de la chaîne d’approvisionnement est découverte

Builds Reproductibles

Les builds reproductibles garantissent que le même code source et les mêmes instructions de build produisent toujours le même artefact de sortie, bit pour bit. Cette propriété permet de vérifier indépendamment qu’un artefact publié correspond à son code source déclaré, éliminant toute une classe d’attaques sur les systèmes de build.

Pour des conseils de mise en œuvre détaillés sur l’intégrité des artefacts, consultez :

Application des Politiques

Les contrôles de sécurité ne sont efficaces que s’ils sont appliqués de manière cohérente et automatique. Les revues de sécurité manuelles ne passent pas à l’échelle. Les checklists sont oubliées. La solution est le Policy as Code — encoder vos exigences de sécurité sous forme de politiques lisibles par machine, évaluées automatiquement à chaque exécution de pipeline.

Policy as Code avec OPA et Rego

L’Open Policy Agent (OPA) et son langage de politique Rego 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’écrire des politiques qui évaluent les entrées, configurations et sorties du pipeline par rapport à vos exigences de sécurité.

Vérifications de politiques courantes en CI/CD :

Politiques d’images de conteneurs — pas de tags latest, les images doivent provenir de registres approuvés, pas d’exécution en root
Politiques de déploiement Kubernetes — limites de ressources requises, pas de conteneurs privilégiés, les politiques réseau doivent exister
Politiques d’Infrastructure as Code — pas de buckets S3 publics, chiffrement activé, groupes de sécurité correctement délimités
Politiques de pipeline — approbation requise avant le déploiement en production, tous les tests doivent passer, résultats de scan de vulnérabilités dans les seuils acceptables

Conftest pour l’Évaluation des Politiques CI/CD

Conftest est un utilitaire qui facilite l’exécution de politiques OPA/Rego contre des données de configuration structurées 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.

Une étape typique d’application des politiques dans un pipeline :

Récupérer les politiques depuis un dépôt central de politiques (versionné et révisé)
Exécuter Conftest contre les fichiers de configuration pertinents
Faire échouer le pipeline si des politiques obligatoires sont violées
Générer un rapport d’évaluation des politiques comme artefact du pipeline

Portes de Sécurité

Au-delà des politiques de configuration, une sécurité CI/CD efficace nécessite des portes de sécurité automatisées — des points de contrôle dans le pipeline où les critères de sécurité doivent être satisfaits avant de poursuivre. Celles-ci comprennent :

Portes d’analyse statique — le code doit passer l’analyse SAST sans résultats critiques
Portes de dépendances — aucun CVE critique ou élevé connu dans les dépendances
Portes de scan d’images — les images de conteneurs doivent passer le scan de vulnérabilités
Portes de conformité — les configurations d’infrastructure doivent respecter les standards de conformité
Portes d’approbation — les déploiements en production nécessitent une approbation humaine explicite

Pour un guide complet sur la mise en œuvre de l’application des politiques dans vos pipelines, consultez : Policy as Code en CI/CD : OPA, Rego et Portes de Sécurité.

Bonnes Pratiques de Durcissement des Pipelines

Au-delà des domaines spécifiques couverts ci-dessus, il existe des pratiques de durcissement fondamentales qui s’appliquent à toutes les plateformes et architectures CI/CD. Ces pratiques réduisent votre surface d’attaque, limitent le rayon d’impact et rendent vos pipelines résilients face à une compromission.

Permissions Minimales (Principe du Moindre Privilège)

Chaque composant de votre pipeline devrait opérer avec les permissions minimales requises pour remplir sa fonction :

Jetons de plateforme — Le GITHUB_TOKEN de GitHub devrait être limité en lecture seule par défaut, avec des permissions en écriture accordées uniquement aux étapes spécifiques qui en ont besoin
Identifiants cloud — Les rôles IAM devraient être limités à des ressources et actions spécifiques, pas des politiques larges comme AdministratorAccess
Accès aux registres — L’accès en écriture (push) devrait être restreint aux pipelines de déploiement, pas à chaque build CI
Accès aux dépôts — Les comptes de service de pipeline ne devraient avoir accès qu’aux dépôts dont ils ont besoin

Environnements de Build Éphémères

Les environnements de build devraient être éphémères — créés à neuf pour chaque exécution de pipeline et détruits ensuite. Les serveurs de build persistants accumulent de l’état, des identifiants en cache et des compromissions potentielles au fil du temps. Les runners éphémères garantissent :

Aucune contamination entre builds — chaque build démarre proprement
Aucun identifiant persistant — rien ne survit au-delà du build
Surface d’attaque réduite — aucun service à longue durée de vie à cibler
Environnements cohérents — pas de dérive de configuration

Épinglage des Actions et Plugins

Les actions tierces, plugins et composants réutilisables devraient être épinglés à des versions spécifiques et immuables — de préférence par SHA de commit, pas par tag mutable. L’épinglage par tag (par ex., v1) est vulnérable au détournement de tag, où un attaquant pousse du code malveillant et déplace le tag pour pointer vers celui-ci.

# Mauvais : Tag mutable, vulnérable au détournement
- uses: actions/checkout@v4

# Bon : Épinglé à un SHA de commit immuable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Protection des Branches et Contrôles de Fusion

Les règles de protection des branches sont votre première ligne de défense contre les modifications de code non autorisées :

Exiger des revues de pull request avant la fusion vers les branches protégées
Exiger la réussite des vérifications de statut (la CI doit passer) avant la fusion
Exiger des commits signés pour une paternité vérifiée
Restreindre qui peut pousser vers les branches protégées
Empêcher les force pushs qui pourraient réécrire l’historique
Exiger un historique linéaire pour maintenir l’auditabilité

Contrôles de Déploiement

Les déploiements en production devraient avoir des garde-fous supplémentaires :

Règles de protection d’environnement — exiger une approbation manuelle pour les déploiements en production
Gels de déploiement — capacité à stopper les déploiements pendant les incidents ou les périodes de gel des changements
Déploiements canary et progressifs — limiter le rayon d’impact en déployant les changements graduellement
Capacités de rollback — rollback automatisé lorsque les health checks de déploiement échouent

Séparation des Responsabilités

Aucune personne ou système unique ne devrait contrôler l’ensemble du pipeline du commit de code au déploiement en production. Mettez en œuvre la séparation des responsabilités en :

Exigeant une revue de code par quelqu’un d’autre que l’auteur
Séparant les permissions CI (build/test) des permissions CD (déploiement)
Utilisant des identifiants séparés pour les différentes étapes du pipeline
Exigeant une approbation multi-parties pour les changements sensibles

Pour des conseils détaillés sur le durcissement de vos pipelines, consultez :

Recommandations Spécifiques aux Plateformes

Bien que les principes de la sécurité CI/CD soient universels, chaque plateforme a son propre modèle de sécurité, ses fonctionnalités et ses pièges. Voici un bref aperçu des principales plateformes avec des liens vers des guides détaillés.

GitHub Actions

GitHub Actions est la plateforme CI/CD la plus largement adoptée pour l’open source et de nombreux projets commerciaux. Les considérations de sécurité clés comprennent :

Permissions du GITHUB_TOKEN — définir les permissions au niveau du workflow avec des valeurs par défaut en lecture seule, en accordant l’écriture uniquement là où c’est nécessaire
Gestion des forks — pull_request_target est extrêmement dangereux s’il est mal utilisé ; préférer pull_request pour le code non fiable
Épinglage des actions — épingler toutes les actions tierces par SHA de commit
Protection d’environnement — utiliser des environnements avec des réviseurs requis et des politiques de branche de déploiement
OIDC — utiliser le fournisseur OIDC de GitHub pour l’authentification sans clé vers AWS, GCP et Azure
Workflows réutilisables — centraliser les patterns de sécurité dans des workflows réutilisables maintenus par l’équipe sécurité

GitLab CI

GitLab CI offre une intégration profonde avec la plateforme DevSecOps plus large de GitLab. Les considérations de sécurité clés comprennent :

Variables protégées — marquer les variables sensibles comme protégées et masquées ; restreindre aux branches/tags protégés
Runners protégés — utiliser des runners protégés pour les déploiements en production, des runners partagés pour les builds CI
Pipelines de merge request — utiliser rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" pour contrôler ce qui s’exécute sur les contributions externes
OIDC/Jetons d’identité — GitLab prend en charge les jetons OIDC via le mot-clé id_tokens pour l’authentification cloud sans clé
Cadres de conformité — utiliser les fonctionnalités de pipeline de conformité de GitLab pour imposer les jobs requis

Tekton

Tekton est un framework CI/CD natif Kubernetes qui offre des propriétés de sécurité uniques grâce à son architecture :

Isolation native Kubernetes — chaque TaskRun s’exécute dans son propre Pod, fournissant une isolation au niveau conteneur par défaut
Limitation des comptes de service — utiliser des comptes de service Kubernetes dédiés pour chaque pipeline avec des permissions RBAC minimales
Tekton Chains — signature automatique des artefacts et génération de provenance, fournissant la conformité SLSA nativement
Bundles OCI — distribuer les définitions de pipeline sous forme d’artefacts OCI pour le versionnage et la vérification d’intégrité
Contrôle d’admission — intégration avec les contrôleurs d’admission Kubernetes (par ex., Kyverno, Gatekeeper) pour l’application des politiques

Consultez les aide-mémoire et travaux pratiques spécifiques aux plateformes sur notre site pour des conseils détaillés et pratiques pour chaque plateforme.

Feuille de Route de Mise en Œuvre

La mise en œuvre de la sécurité CI/CD ne se fait pas du jour au lendemain. Voici une approche par phases qui vous amène de la visibilité de base à l’application complète.

Phase 1 : Visibilité (Semaines 1-4)

On ne peut pas sécuriser ce qu’on ne voit pas. Commencez par un inventaire et une évaluation complets :

Auditer tous les pipelines — inventorier chaque pipeline CI/CD de votre organisation, y compris les systèmes CI parallèles que les équipes ont pu mettre en place de manière indépendante
Cartographier l’utilisation des secrets — identifier chaque secret, identifiant et jeton utilisé dans les pipelines. Documenter leur portée, durée de vie et calendrier de renouvellement
Scanner les expositions — exécuter des outils de détection de secrets contre les dépôts, les définitions de pipeline et les logs de build pour trouver les identifiants fuités
Évaluer les permissions — examiner tous les comptes de service, rôles IAM et jetons de plateforme pour les permissions excessives
Documenter les frontières de confiance — cartographier quels pipelines peuvent accéder à quels environnements, secrets et ressources

Phase 2 : Fondations (Semaines 5-12)

Mettre en place les contrôles de sécurité fondamentaux qui réduisent le plus de risques avec le moins de complexité :

Mettre en œuvre le moindre privilège — réduire tous les identifiants aux permissions minimales requises. Définir le GITHUB_TOKEN en lecture seule par défaut. Limiter les identifiants cloud à des ressources spécifiques
Épingler toutes les dépendances — épingler les actions tierces par SHA de commit, verrouiller les versions des dépendances, épingler les images de base par digest
Sécuriser la gestion des secrets — migrer vers OIDC/la fédération d’identité de charge de travail lorsque c’est possible. Mettre en place des gestionnaires de secrets externes pour tout le reste. Renouveler tous les identifiants
Activer la protection des branches — exiger la revue de code, les vérifications de statut et les commits signés sur toutes les branches protégées
Déployer des runners éphémères — remplacer les serveurs de build persistants par des runners éphémères en environnement propre

Phase 3 : Intégrité (Semaines 13-20)

Construire la confiance que les artefacts sont authentiques et non falsifiés :

Mettre en place la signature des artefacts — signer toutes les images de conteneurs et les artefacts de build avec Cosign en utilisant la signature sans clé
Générer la provenance — produire la provenance SLSA pour tous les artefacts de build, les liant à leur source, système de build et paramètres
Créer des SBOMs — générer des SBOMs pour tous les artefacts, permettant une réponse rapide aux vulnérabilités
Imposer la vérification de signature — configurer les contrôleurs d’admission (Kyverno, Gatekeeper, Sigstore policy-controller) pour rejeter les images non signées ou non vérifiées
Établir des builds reproductibles — travailler vers des builds reproductibles pour les artefacts critiques

Phase 4 : Application (Semaines 21-30)

Automatiser l’application de la sécurité pour qu’elle soit cohérente, évolutive et ne dépende pas de la conformité individuelle :

Mettre en œuvre le Policy as Code — définir les politiques de sécurité en OPA/Rego et les appliquer avec Conftest dans chaque pipeline
Déployer des contrôleurs d’admission — appliquer des politiques d’exécution dans Kubernetes qui valident les images, configurations et déploiements
Automatiser les vérifications de conformité — intégrer la validation de conformité dans les pipelines avec la collecte automatisée de preuves
Mettre en place des portes de sécurité — ajouter des points de contrôle de sécurité obligatoires qui bloquent la progression dans le pipeline lorsque les critères ne sont pas satisfaits
Surveillance continue — mettre en place des alertes pour les violations de politique, les comportements anormaux de pipeline et les modifications non autorisées

Travaux Pratiques

La théorie est essentielle, mais c’est par la pratique que les compétences en sécurité se construisent. Nous proposons des travaux pratiques qui vous permettent de mettre en œuvre chaque concept couvert dans ce guide dans un vrai environnement CI/CD :

Travaux Pratiques de Sécurité GitHub Actions — Exercices pratiques pour sécuriser les workflows GitHub Actions, incluant les permissions de jetons, l’épinglage d’actions et la configuration OIDC
Travaux Pratiques de Sécurité GitLab CI — Exercices pratiques pour durcir les pipelines GitLab CI, les variables protégées et la sécurité des merge requests
Travaux Pratiques de Sécurité Tekton — Sécurité des pipelines natifs Kubernetes avec Tekton, incluant Chains pour la signature et la provenance
Travaux Pratiques d’Intégration Vault CI/CD — Intégrer HashiCorp Vault avec les pipelines CI/CD pour les secrets dynamiques et la gestion des identifiants
Travaux Pratiques de Signature d’Images de Conteneurs avec Cosign — Signer, vérifier et imposer les signatures d’images de conteneurs avec Sigstore Cosign
Travaux Pratiques d’Application des Politiques OPA — Écrire et appliquer des politiques OPA/Rego dans les pipelines CI/CD avec Conftest
Travaux Pratiques de Provenance SLSA — Générer et vérifier la provenance SLSA pour les artefacts de build
Travaux Pratiques de Modélisation des Menaces de Pipeline — Modéliser les menaces d’un pipeline CI/CD pour identifier les risques et prioriser les atténuations

Outils et Ressources

L’écosystème de sécurité CI/CD comprend un ensemble croissant d’outils spécialisés. Voici les catégories essentielles et les outils clés :

Détection et Gestion des Secrets

GitLeaks / TruffleHog — scanner les dépôts et l’historique des commits pour les secrets exposés
HashiCorp Vault — secrets dynamiques, gestion des identifiants et chiffrement en tant que service
AWS Secrets Manager / GCP Secret Manager / Azure Key Vault — gestion des secrets cloud-native

Intégrité des Artefacts

Sigstore (Cosign, Fulcio, Rekor) — signature sans clé, autorité de certification et journal de transparence
in-toto — framework d’intégrité de la chaîne d’approvisionnement
Framework SLSA — niveaux de sécurité de la chaîne d’approvisionnement et provenance
Syft / Trivy — génération de SBOM et scan de vulnérabilités

Application des Politiques

OPA / Conftest — moteur de politique polyvalent pour la validation de configuration
Kyverno — moteur de politique natif Kubernetes
Gatekeeper — intégration OPA pour le contrôle d’admission Kubernetes

Scan de Sécurité des Pipelines

Checkov — scan d’Infrastructure as Code (Terraform, CloudFormation, Kubernetes)
StepSecurity Harden-Runner — sécurité d’exécution pour GitHub Actions
Snyk — scan de sécurité orienté développeur pour le code, les dépendances et les conteneurs

Pour des comparaisons détaillées d’outils et des recommandations, visitez notre page Ressources.

Conclusion

La sécurité des pipelines CI/CD n’est ni un outil unique, ni une pratique isolée, ni un effort ponctuel. C’est une discipline complète qui couvre l’ensemble du cycle de livraison logicielle — du commit du développeur à travers le build, les tests, l’empaquetage et le déploiement en production.

Les points clés à retenir de ce guide :

Les pipelines sont des cibles de haute valeur — ils ont un accès privilégié à tout. Traitez-les avec la même rigueur sécuritaire que les systèmes de production.
Comprenez vos frontières de confiance — sachez qui déclenche vos pipelines, quel code s’exécute et quelles ressources sont accessibles à chaque étape.
Les secrets sont votre plus grand risque — éliminez les identifiants à longue durée de vie partout où c’est possible. Utilisez OIDC, l’identité de charge de travail et les secrets dynamiques.
Vérifiez l’intégrité des artefacts — signez tout, générez la provenance, créez des SBOMs et imposez la vérification au déploiement.
Automatisez l’application — encodez les exigences de sécurité en Policy as Code. Les processus manuels ne passent pas à l’échelle et ne résistent pas à la pression des délais.
Durcissez progressivement — utilisez la feuille de route par phases pour améliorer systématiquement votre posture de sécurité sans perturber la vélocité de livraison.

La surface d’attaque est large, mais les solutions mûrissent rapidement. L’écosystème Sigstore, le framework SLSA, OPA/Conftest, la fédération OIDC et les contrôleurs d’admission Kubernetes fournissent une boîte à outils robuste pour construire des pipelines véritablement sécurisés.

Commencez là où vous en êtes. Auditez votre état actuel, mettez en place les fondations et ajoutez progressivement les contrôles d’intégrité et d’application. Chaque étape que vous franchissez comble une brèche que les attaquants pourraient exploiter.

Explorez les guides détaillés, les travaux pratiques et les ressources référencés tout au long de cet article pour approfondir chaque sujet. Les pipelines sécurisés ne se construisent pas en un jour — mais avec les bonnes connaissances et les bons outils, ils sont tout à fait à votre portée.