Securiser vos pipelines CI/CD

Le pipeline CI/CD : la cible invisible

Votre pipeline CI/CD (Continuous Integration / Continuous Delivery) a acces a tout : code source, secrets, credentials de production, cles de signature. C’est une cible de premier choix.

Le paradoxe du CI/CD est que sa valeur principale (automatisation et rapidite) est aussi son principal risque de securite. Un pipeline qui deploie automatiquement en production en quelques minutes est extremement efficace pour les equipes de developpement, et tout aussi efficace pour un attaquant qui a compromis une etape de ce pipeline. L’attaque SolarWinds (2020) reste l’exemple emblematique : la compromission du pipeline de build d’Orion a permis d’injecter une backdoor dans les mises a jour distribuees a 18 000 organisations.

Les pipelines CI/CD modernes sont aussi particulierement complexes : GitHub Actions, Jenkins, GitLab CI, CircleCI, TeamCity, chacun avec ses propres mecanismes de securite, ses interet propres de configuration et ses risques specifiques.

Risques principaux

  1. Injection de code dans les workflows : un contributeur malveillant modifie le fichier de workflow pour executer du code arbitraire
  2. Secrets exposes : variables d’environnement, tokens, cles API accessibles dans les logs
  3. Dependances de build compromises : actions GitHub, plugins Jenkins infectes
  4. Runners partages : un runner compromis affecte tous les projets qui l’utilisent

Injection via pull requests : dans GitHub Actions, des workflows mal configures peuvent etre declenches par des pull requests de contributeurs externes et avoir acces aux secrets du repository. L’evenement pull_request_target est particulierement dangereux car il s’execute dans le contexte du repository cible (avec ses secrets), pas dans le contexte du fork.

Actions GitHub tierces : les Actions GitHub sont l’equivalent des plugins Jenkins, mais plus faciles a utiliser et a distribuer. Des centaines d’actions tierces ont des acces larges aux secrets et au code. GlassWorm (2026) a compromis 72 extensions VSCode et plusieurs Actions GitHub populaires.

Log injection : des secrets imprimes accidentellement dans les logs CI sont un risque frequent. Les plateformes modernes masquent les secrets connus, mais des tokens ou cles non declares comme secrets peuvent etre loggues en clair.

Controles essentiels

Protection des secrets :

  • Utilisez un vault (HashiCorp Vault, AWS Secrets Manager) au lieu de variables d’environnement
  • Rotez les secrets regulierement
  • Ne logguez jamais les secrets (masquez-les dans les logs)
  • Utilisez des tokens a portee limitee et a duree de vie courte
  • Auditez regulierement les secrets existants et supprimez ceux non utilises

Isolation des builds :

  • Utilisez des runners ephemeres (detruits apres chaque build)
  • Isolez les builds de production des builds de dev/test
  • Limitez les permissions du runner au strict minimum
  • Evitez les runners auto-heberges partages entre plusieurs projets

Verification de l’integrite :

  • Signez vos artefacts de build (cosign, Sigstore)
  • Verifiez les checksums des dependances
  • Utilisez des lock files (package-lock.json, Pipfile.lock)
  • Epinglez les versions des actions CI/CD sur des commits specifiques (pas des tags mutables)

Audit et monitoring :

  • Auditez les modifications des fichiers de workflow
  • Alertez sur les ajouts de nouvelles actions/plugins
  • Revoyez les permissions des tokens d’acces CI/CD

Gestion des permissions dans GitHub Actions

GitHub Actions utilise un token GITHUB_TOKEN automatiquement disponible dans chaque workflow. Par defaut, ce token a des permissions larges. La bonne pratique est de definir des permissions minimales au niveau du workflow :

permissions:
  contents: read
  packages: write

Le principe du moindre privilege s’applique ici : un workflow qui ne fait que lire le code et lancer des tests n’a pas besoin de permissions d’ecriture sur les releases ou les packages.

Securite du code source

Le code source est la matiere premiere du pipeline. Sa securite conditionne tout le reste :

Protections de branche : les branches de production (main, release) doivent etre protegees contre les push directs. Les merges doivent passer par des pull requests avec revue de code obligatoire.

Signature des commits : GPG ou SSH permet de verifier l’identite du committer. Combine avec des regles de branche exigeant des commits signes, cela empeche l’injection de commits malveillants via des comptes compromis.

Code scanning : integrez des outils SAST (Static Application Security Testing) dans le pipeline. GitHub Advanced Security, Semgrep, ou SonarQube peuvent detecter des vulnerabilites introduites dans le code avant le merge.

Framework SLSA

SLSA (Supply-chain Levels for Software Artifacts) est un framework Google qui definit 4 niveaux de securite pour les pipelines de build :

  • SLSA 1 : documentation du processus de build
  • SLSA 2 : build service utilise (pas de builds locaux non documentes)
  • SLSA 3 : build service securise avec protection contre l’injection
  • SLSA 4 : build hermitique et reproductible, revue a deux personnes

Les niveaux 3 et 4 exigent la generation de provenance attestations : des metadonnees signees qui documentent comment l’artefact a ete construit, a partir de quel code source, sur quel systeme.

Cas pratique : durcissement GitHub Actions

Actions recommandees (priorite haute) :

  1. Revoir et limiter les permissions du GITHUB_TOKEN sur tous les workflows
  2. Epingler toutes les actions tierces sur des SHAs de commits, pas des tags
  3. Activer les branch protections avec revue obligatoire
  4. Configurer Dependabot pour les actions et les dependances
  5. Activer les alertes de securite GitHub et le code scanning

A eviter :

  • Declencher des workflows avec pull_request_target sans comprendre les implications
  • Utiliser des expressions non sanitisees directement dans les commandes shell (injection via titres de PR)
  • Stocker des secrets dans les variables d’environnement de repository (preferer les environnements GitHub avec protection)

La securisation d’un pipeline CI/CD est un processus continu : les nouvelles fonctionnalites, les nouvelles dependances et les nouvelles vulnerabilites creent regulierement de nouveaux risques qu’il faut adresser.

Publicité