Hardening de l'environnement de build : sécuriser runners et pipelines

Un pipeline CI/CD dispose souvent d’un accès privilégié à des ressources sensibles : code source, registres, identités de déploiement, secrets applicatifs ou accès cloud temporaires. C’est la cible parfaite pour une attaque supply chain. Et pourtant, c’est souvent le dernier endroit qu’on pense à sécuriser.

Le hardening (durcissement) de l’environnement de build consiste à réduire la surface d’attaque de vos pipelines CI/CD : runners, secrets, réseau, cache, et processus de build. C’est un prérequis pratique pour progresser vers SLSA, en particulier à partir du moment où l’on vise une plateforme de build maîtrisée et, plus encore, des hardened builds de niveau 3.

Ce que vos allez apprendre

• Les vecteurs d’attaque sur les environnements de build
• L’architecture défensive : runners éphémères, isolation, egress control
• La gestion des secrets : OIDC, tokens courts, rotation automatique
• Le durcissement pas à pas de GitHub Actions et GitLab CI

Prérequis

• Connaissance de base des pipelines CI/CD (GitHub Actions ou GitLab CI)
• Lecture recommandée : Attaques sur les pipelines

Pourquoi sécuriser l’environnement de build ?

Le pipeline : une cible de choix

L’environnement de build est un actif critique car il :

Caractéristique	Risque associé
A accès aux secrets de production	Exfiltration de credentials
Peut modifier le code (merge, tag)	Injection de backdoors
Signe les artefacts	Signature d’artefacts compromis
Publie vers les registres	Distribution de malware
Exécute du code tiers (actions, packages)	Exécution de code malveillant

Glissez pour voir

La surface d’attaque d’un pipeline

┌─────────────────────────────────────────────────────────────────────────────┐
│                    SURFACE D'ATTAQUE D'UN PIPELINE CI/CD                    │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌───────────────────┐    ┌───────────────────┐    ┌──────────────────┐   │
│   │   CODE SOURCE     │    │    RUNNER         │    │   ARTEFACTS      │   │
│   │                   │    │                   │    │                  │   │
│   │ - Repo compromis  │───▶│ - VM persistante  │───▶│ - Image signée   │   │
│   │ - PR malveillante │    │ - Secrets exposés │    │ - Registre public│   │
│   │ - Workflow modifié│    │ - Réseau ouvert   │    │ - Cache empoisonné│  │
│   └───────────────────┘    └───────────────────┘    └──────────────────┘   │
│                                   │                                         │
│                                   ▼                                         │
│   ┌───────────────────┐    ┌───────────────────┐    ┌──────────────────┐   │
│   │   DÉPENDANCES     │    │    ACTIONS/JOBS   │    │   RÉSEAU         │   │
│   │                   │    │                   │    │                  │   │
│   │ - npm/pip/maven   │───▶│ - Actions tierces │───▶│ - Egress libre   │   │
│   │ - Images base     │    │ - Plugins non vér.│    │ - C2 possible    │   │
│   │ - Cache compromis │    │ - Permissions trop│    │ - Exfiltration   │   │
│   └───────────────────┘    └───────────────────┘    └──────────────────┘   │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Exemples d’attaques réelles

Attaque	Vecteur	Impact
Codecov (2021)	Script bash modifié dans l’image de build	Exfiltration de secrets CI vers l’attaquant
Event-stream (2018)	Mainteneur compromis → code malveillant	Vol de Bitcoin via dépendance npm
SolarWinds (2020)	Compromission du build system	Backdoor dans 18 000 organisations
tj-actions (2025)	Action GitHub compromise	Exfiltration de secrets
xz-utils (2024)	Build scripts modifiés	Backdoor SSH dans binaires

Glissez pour voir

Différentes couches d'attaque

Toutes ces attaques ne ciblent pas exactement la même couche, mais elles ont en commun d’exploiter la confiance accordée au processus de build, à ses dépendances ou à ses intégrations :

• Pipeline compromis : Codecov, SolarWinds
• Dépendance/action compromise : event-stream, tj-actions
• Mainteneur / upstream compromis : xz-utils, event-stream

Architecture défensive

Les 7 piliers du hardening

┌─────────────────────────────────────────────────────────────────────────────┐
│                   ARCHITECTURE DÉFENSIVE CI/CD                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   1. ÉPHÉMÉRITÉ        2. ISOLATION         3. LEAST PRIVILEGE             │
│   ┌──────────────┐    ┌──────────────┐     ┌──────────────┐                │
│   │ Runner détruit│   │ Pas de réseau│     │ Permissions  │                │
│   │ après chaque  │   │ entre jobs   │     │ minimales    │                │
│   │ job           │   │              │     │              │                │
│   └──────────────┘    └──────────────┘     └──────────────┘                │
│                                                                             │
│   4. EGRESS CONTROL    5. SECRETS COURTS   6. VÉRIFICATION                 │
│   ┌──────────────┐    ┌──────────────┐     ┌──────────────┐                │
│   │ Whitelist des │   │ OIDC, tokens │     │ Code review  │                │
│   │ destinations  │   │ éphémères    │     │ des workflows│                │
│   │ réseau        │   │              │     │              │                │
│   └──────────────┘    └──────────────┘     └──────────────┘                │
│                                                                             │
│   7. IMMUTABILITÉ DES INPUTS                                               │
│   ┌──────────────────────────────────────────────────────┐                 │
│   │ Actions pinées SHA, images digest, lockfiles figés   │                 │
│   └──────────────────────────────────────────────────────┘                 │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Pilier 1 : Runners éphémères

Principe : Chaque job s’exécute sur une machine vierge, détruite après exécution.

Mode	Sécurité	Performance	Coût
Runner persistant	⚠️ Faible	⭐⭐⭐ Rapide	💰 Bas
Runner éphémère VM	✅ Très bon isolement de base	⭐⭐ Moyen	💰💰 Moyen
Runner éphémère conteneur	⚠️ Bon niveau possible, dépend de la config	⭐⭐⭐ Rapide	💰 Bas
GitHub-hosted	✅ Élevée	⭐⭐ Moyen	💰💰💰 Élevé

Glissez pour voir

Conteneur ≠ VM en termes d'isolation

Un runner conteneurisé peut être bien isolé, mais ce n’est pas automatiquement équivalent à une VM éphémère. Le niveau de sécurité dépend du modèle d’exécution, des privilèges accordés, du partage du daemon Docker, des volumes montés, des capacités Linux, et de la possibilité de sortir du conteneur vers l’hôte.

Pourquoi c’est crucial :

• Pas de persistance d’un attaquant entre les jobs
• Pas de credentials résiduels sur la machine
• Pas de malware persistant installé par un job précédent

GitHub Actions (ARC)

Avec Actions Runner Controller (ARC), configurez des runners éphémères sur Kubernetes. Cet exemple est conceptuel — consultez la documentation ARC officielle pour le CRD exact selon votre version :

# Exemple conceptuel - vérifiez la doc ARC pour les runner scale sets
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: ephemeral-runners
spec:
  replicas: 3
  template:
    spec:
      ephemeral: true  # Détruit après chaque job
      repository: votre-org/votre-repo
      labels:
        - ephemeral
        - linux

Runner Scale Sets

Les versions récentes d’ARC privilégient les runner scale sets pour l’autoscaling. Consultez la documentation GitHub pour la configuration recommandée.

GitLab CI

Configurez des runners Docker avec hygiène renforcée (réduction du cache et de la persistance, sans être de vrais runners éphémères au sens infrastructurel) :

# config.toml - Runner Docker à faible persistance
[[runners]]
  name = "docker-hygiene-renforcee"
  executor = "docker"

  [runners.docker]
    image = "debian:bookworm-slim"
    privileged = false
    disable_cache = true  # Pas de cache partagé
    pull_policy = "always"

    # Nettoyage automatique
    cleanup_grace_period_seconds = 30

Ce n'est pas de l'éphémérité complète

Ces options améliorent l’hygiène mais ne garantissent pas : destruction de l’hôte, absence totale de persistance latérale, ou isolement fort entre jobs. Pour une vraie éphémérité, il faut des runners VM détruits après chaque job.

Pilier 2 : Isolation entre jobs

Principe : Un job ne doit pas pouvoir accéder aux ressources d’un autre job.

Il faut distinguer deux types d’isolation :

Type	Description	Mécanismes
Isolation d’exécution	Séparation technique (processus, réseau, filesystem)	Runners éphémères, network policies, conteneurs/VMs dédiés
Séparation logique	Contrôle d’accès aux ressources (secrets, déploiements)	Environments, permissions, approbations

Glissez pour voir

Environment ≠ isolation runtime

Dans GitHub Actions et GitLab CI, environment sert surtout à appliquer des protections (approbations, secrets dédiés, règles de déploiement). Ce n’est pas un mécanisme d’isolation runtime entre jobs au sens système.

GitHub Actions

.github/workflows/secure-build.yml

jobs:
  build:
    runs-on: ubuntu-latest
    # Isolation via environment
    environment: production

    # Permissions minimales par job
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      # Pas d'accès aux secrets d'autres environments
      - name: Build
        env:
          API_KEY: ${{ secrets.PROD_API_KEY }}
        run: make build

GitLab CI

.gitlab-ci.yml

build:
  stage: build
  # Isolation via environment
  environment:
    name: production

  # Variables scoped à cet environment
  variables:
    API_KEY: $PROD_API_KEY

  # Runner dédié avec tag
  tags:
    - production
    - isolated

  script:
    - make build

Pilier 3 : Least Privilege (permissions minimales)

Principe : Chaque job n’a accès qu’aux ressources strictement nécessaires.

GitHub Actions : Permissions explicites

# Désactiver les permissions par défaut
permissions: {}

jobs:
  lint:
    runs-on: ubuntu-latest
    permissions:
      contents: read  # Lecture du code uniquement
    steps:
      - uses: actions/checkout@v4
      - run: npm run lint

  deploy:
    runs-on: ubuntu-latest
    needs: lint
    permissions:
      contents: read
      id-token: write     # Pour OIDC
      packages: write     # Pour publier
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: make deploy

Permissions explicites obligatoires

Les permissions effectives du GITHUB_TOKEN dépendent des paramètres GitHub (repo/org) et du workflow. Par sécurité, définissez toujours les permissions minimales requises au niveau du workflow ou du job. Ne comptez pas sur les défauts.

Matrice des permissions GitHub Actions

Permission	Quand l’utiliser	Risque si trop large
contents: read	Checkout du code	Permet de lire le code (risque si donné à du code non fiable)
contents: write	Push, merge, tags	Modification du dépôt, tags, releases — injection de code
packages: write	Publication d’images/packages	Distribution de malware via registre
id-token: write	OIDC vers cloud providers	Accès cloud si le trust côté provider est mal configuré
actions: write	Gestion des workflows	Modification/annulation de workflows sensibles
security-events: write	Upload de résultats de scan	Potentiel masquage de vulnérabilités

Glissez pour voir

Pilier 4 : Contrôle de l’egress (sortie réseau)

Principe : Limiter les destinations réseau autorisées pour empêcher l’exfiltration.

Pourquoi c’est critique :

• Un runner compromis peut envoyer des secrets vers un serveur C2
• Les attaques comme Codecov exfiltrent les données via HTTP

Implémentation avec Harden-Runner (GitHub Actions)

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@v2
        with:
          # Mode audit (recommandé pour commencer)
          egress-policy: audit

      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

Après quelques runs, passez en mode blocage :

      - name: Harden Runner
        uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: >
            github.com:443
            registry.npmjs.org:443
            nodejs.org:443

Limites de Harden-Runner

Harden-Runner améliore la visibilité et le contrôle réseau dans GitHub Actions, mais il ne remplace ni une architecture d’exécution saine, ni la revue des workflows, ni la réduction des privilèges. Des analyses ont documenté des contournements possibles — c’est une couche supplémentaire, pas un bouclier absolu.

Network policies Kubernetes (self-hosted)

Cet exemple montre une restriction de port (443 uniquement), pas une vraie whitelist de destinations :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: runner-egress-port-restriction
spec:
  podSelector:
    matchLabels:
      app: github-runner
  policyTypes:
    - Egress
  egress:
    # Restriction de PORT, pas de destination
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - port: 443
          protocol: TCP
    # Ceci autorise tout Internet en 443, pas une whitelist

Ce n'est pas une vraie whitelist

Cette NetworkPolicy autorise tout Internet en 443. Pour une vraie liste blanche de destinations, il faut combiner avec : DNS interne + proxy sortant, egress gateway (Istio, Cilium), ou firewall/NAT/proxy contrôlé en dehors de Kubernetes.

Pilier 5 : Secrets courte durée (OIDC)

Principe : Remplacer les secrets statiques par des tokens éphémères via OIDC.

Le problème des secrets statiques

Secret statique	Risque
AWS Access Key	Valide indéfiniment, exfiltrable
Docker Hub token	Permet de publier des images
NPM token	Permet de publier des packages
Kubeconfig	Accès complet au cluster

Glissez pour voir

La solution : OIDC (OpenID Connect)

┌────────────────┐         ┌────────────────┐         ┌────────────────┐
│  GitHub Actions │────────▶│   AWS / GCP    │────────▶│   Ressource    │
│                │  Token   │   IAM / WIF    │  Accès  │   Cloud        │
│                │  OIDC    │                │  temp.  │                │
└────────────────┘         └────────────────┘         └────────────────┘

1. GitHub génère un token OIDC (JWT) avec l'identité du workflow
2. Le cloud provider vérifie le token et émet des credentials temporaires
3. Les credentials expirent après quelques minutes/heures

Le trust côté cloud est critique

OIDC supprime les secrets statiques du pipeline, mais le niveau réel de sécurité dépend de la politique de confiance côté fournisseur cloud : audience, repository autorisé, branche ou tag permis, environnement, durée des credentials, et permissions du rôle IAM obtenu. Un trust trop permissif annule les bénéfices.

AWS

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-actions
          aws-region: eu-west-1
          # Pas de secrets ! Le token OIDC suffit

      - name: Deploy to S3
        run: aws s3 sync ./dist s3://my-bucket

GCP

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Authenticate to Google Cloud (OIDC)
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/123/locations/global/workloadIdentityPools/my-pool/providers/github
          service_account: deploy@my-project.iam.gserviceaccount.com

      - name: Deploy
        run: gcloud run deploy my-service --image=...

Azure

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Azure Login (OIDC)
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          # Pas de client secret, OIDC est utilisé

      - name: Deploy
        run: az webapp deploy ...

Pilier 6 : Vérification des inputs

Principe : Valider et restreindre ce qui peut déclencher et modifier le pipeline.

Protections sur les pull requests

.github/workflows/ci.yml

on:
  pull_request:
    # Ne pas exécuter sur les PRs des forks (par défaut)
    # Utiliser pull_request_target avec précaution

jobs:
  build:
    runs-on: ubuntu-latest
    # Vérifier que le workflow n'a pas été modifié dans la PR
    if: github.event.pull_request.head.repo.full_name == github.repository

    steps:
      - uses: actions/checkout@v4
        with:
          # Checkout la base, pas la PR (pour les workflows sensibles)
          ref: ${{ github.base_ref }}

pull_request_target : danger

pull_request_target s’exécute avec les permissions du repo principal MÊME pour les PRs de forks. C’est une source majeure de compromission.

Règle simple :

• pull_request pour tester du code non approuvé avec permissions réduites
• pull_request_target seulement pour des workflows “de contrôle” qui ne touchent pas le code de la PR

Bloquer les modifications de fichiers sensibles

.github/workflows/ci.yml

jobs:
  check-files:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Check for sensitive file changes
        run: |
          SENSITIVE_FILES=".github/workflows/ Dockerfile Makefile"
          CHANGED=$(git diff --name-only origin/main...HEAD)

          for file in $SENSITIVE_FILES; do
            if echo "$CHANGED" | grep -q "$file"; then
              echo "::error::Modification of $file requires special approval"
              exit 1
            fi
          done

Compléter avec d'autres protections

Cette vérification par git diff est utile mais pas suffisante seule. Complétez avec : CODEOWNERS sur les workflows, protections de branches, revue obligatoire, et éventuellement un workflow dédié de validation des changements CI.

Pilier 7 : Immutabilité des inputs

Principe : Figer les entrées de build pour éviter les modifications silencieuses.

Input	Risque si non figé	Bonne pratique
Actions GitHub	Tag mutable peut être modifié	Pinner par SHA
Images Docker	Tag latest ou version peut changer	Pinner par digest
Dépendances	Résolution dynamique peut changer	Lockfiles obligatoires
Scripts téléchargés	Contenu peut être modifié	Interdire `curl

Glissez pour voir

# Actions pinées par SHA
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

# Images pinées par digest
FROM python:3.12-slim@sha256:abc123...

Méfiance sur les scripts et actions composite

Les actions qui exécutent des scripts shell ou font des curl | bash contournent les garanties du pinning. Auditez ces actions avant usage.

Hardening pas à pas

Checklist de hardening GitHub Actions

1. Permissions minimales globales

   # Au niveau du workflow
   permissions:
     contents: read

2. Pinning des actions par SHA

   # ❌ Mauvais
   - uses: actions/checkout@v4
   
   # ✅ Bon
   - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

   Utilisez pin-github-action pour automatiser.

3. OIDC pour tous les déploiements cloud

   Remplacez les secrets statiques AWS/GCP/Azure par OIDC.

4. Harden-Runner pour le contrôle egress

   - uses: step-security/harden-runner@v2
     with:
       egress-policy: audit  # puis block

5. Environments pour les secrets sensibles

   Configurez des environments avec approbation pour la production.

6. Code review obligatoire pour les workflows

   Ajoutez les fichiers .github/workflows/** dans les CODEOWNERS.

7. Audit régulier des permissions

   Utilisez StepSecurity Secure Repo pour auditer.

Checklist de hardening GitLab CI

1. Variables protégées et masquées (côté GitLab UI)

   Les variables protégées et masquées se configurent dans GitLab (Settings → CI/CD → Variables), pas dans le YAML :

   • Protected : uniquement disponibles sur branches/tags protégés
   • Masked : masquées dans les logs de pipeline

   Dans le .gitlab-ci.yml, vous accédez simplement à la variable :

   deploy_prod:
     script:
       - echo "Deploying with key..."
       - deploy --api-key=$PROD_API_KEY  # Configuré côté GitLab
     rules:
       - if: $CI_COMMIT_REF_PROTECTED == "true"

2. Runners dédiés par environment

   deploy_prod:
     tags:
       - production
       - secure
     environment:
       name: production

3. Review apps isolées

   review:
     environment:
       name: review/$CI_COMMIT_REF_SLUG
       auto_stop_in: 1 week

4. Protected branches + merge rules

   • Exiger 2 approbations pour main
   • Pipeline réussi obligatoire
   • Pas de push direct

5. Secrets via OIDC + Vault (recommandé)

   Utilisez les ID tokens OIDC pour authentification sans secrets statiques :

   deploy_prod:
     id_tokens:
       VAULT_ID_TOKEN:
         aud: https://vault.example.com
     secrets:
       DATABASE_PASSWORD:
         vault:
           engine:
             name: kv-v2
             path: production
           path: db
           field: password
         token: $VAULT_ID_TOKEN
     script:
       - deploy --db-password=$DATABASE_PASSWORD

   Le job reçoit un token OIDC que Vault vérifie avant d’émettre le secret.

6. Audit des jobs avec needs

   deploy:
     needs:
       - test
       - security_scan
     when: on_success  # Uniquement si les jobs précédents réussissent

Architecture cible alignée SLSA

Vue d’ensemble

Cette architecture représente une cible d’inspiration SLSA niveau 3, pas une conformité automatique. Les exigences SLSA sont précises et dépendent des détails d’implémentation.

┌─────────────────────────────────────────────────────────────────────────────┐
│          ARCHITECTURE CIBLE POUR BUILDS DURCIS (type SLSA L3)            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   SOURCE                BUILDER                ARTEFACTS                    │
│   ┌──────────┐         ┌──────────────┐       ┌──────────────┐             │
│   │          │         │              │       │              │             │
│   │  Git +   │────────▶│  Runner      │──────▶│  Image +     │             │
│   │  Signed  │         │  Éphémère    │       │  SBOM +      │             │
│   │  Commits │         │              │       │  Provenance  │             │
│   │          │         │  Hermetic    │       │  Signée      │             │
│   └──────────┘         │  Build       │       └──────────────┘             │
│        │               │              │              │                      │
│        │               └──────────────┘              │                      │
│        │                      │                      │                      │
│        ▼                      ▼                      ▼                      │
│   ┌──────────┐         ┌──────────────┐       ┌──────────────┐             │
│   │ Signature│         │ Pas d'accès  │       │ Vérification │             │
│   │ GPG/SSH  │         │ réseau sauf  │       │ avant        │             │
│   │          │         │ whitelist    │       │ déploiement  │             │
│   └──────────┘         └──────────────┘       └──────────────┘             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Mapping SLSA ↔ piliers de hardening

Ce tableau est une lecture opérationnelle simplifiée pour relier le hardening du build à la progression SLSA ; il ne remplace pas la lecture des exigences officielles SLSA.

Niveau SLSA	Exigences	Piliers couverts
Level 1	Provenance basique	Éphémérité (partiel), Immutabilité
Level 2	Provenance signée, build service	Éphémérité, Isolation, Vérification, Immutabilité
Level 3	Isolation complète, provenance non-falsifiable	Tous les piliers

Glissez pour voir

Monitoring et détection

Signaux d’alerte à surveiller

Signal	Ce qu’il indique	Action
Job anormalement long	Exfiltration, crypto mining	Alerter + investiguer
Connexions réseau inattendues	C2, exfiltration	Bloquer + alerter
Modification de workflow sans PR	Compromission	Bloquer + révoquer
Échecs de signature répétés	Tentative de contournement	Alerter
Nouveau mainteneur sur action utilisée	Supply chain risk	Revoir l’action

Glissez pour voir

Outils de monitoring

Outil	Fonction
Harden-Runner	Log des connexions réseau depuis les runners
Dependency Review	Alertes sur nouvelles dépendances vulnérables
GitHub Audit Log	Toutes les actions sur le repo/org
Falco	Runtime security pour runners Kubernetes
Datadog CI Visibility	Métriques et traces des pipelines

Glissez pour voir

Ce que ce guide ne couvre pas

Le hardening du build est une pièce essentielle, mais pas suffisante seule :

Sujet	Où le traiter
Sécurité du code source	Revue de code, SAST, policies de contribution
Sécurité des dépendances	SBOM, SCA, veille CVE, lockfiles
Signature et provenance des artefacts	Sigstore, SLSA
Admission policy côté cluster	Kyverno, OPA Gatekeeper, vérification provenance
Gestion des mainteneurs tiers	Due diligence, audit des actions/packages utilisés

Glissez pour voir

Priorisation réaliste

Si vous partez de zéro, voici l’ordre recommandé :

1. Permissions minimales — impact immédiat, facile à implémenter

2. Pinning des actions et images — protège contre les modifications silencieuses

3. OIDC pour les déploiements cloud — élimine les secrets statiques

4. Runners éphémères — élimine la persistance

5. Audit egress (mode observation) — comprendre le trafic réseau

6. Blocage egress — après avoir validé les destinations légitimes

7. Architecture hermétique complète — objectif long terme

Compromis coût / sécurité / opérabilité

Le hardening a un coût. Assumez ces compromis plutôt que de les subir :

Mesure	Bénéfice sécurité	Coût / friction
Runners VM éphémères	Isolation maximale	Plus cher, plus lent que conteneurs
Egress strict	Bloque exfiltration	Nécessite maintenance de la whitelist
OIDC	Plus de secrets statiques	Paramétrage IAM initial
Revue obligatoire des workflows	Bloque les modifications malveillantes	Ralentit légèrement le développement
Pinning par SHA	Prévient les modifications furtives	Maintenance des mises à jour

Glissez pour voir

Le bon compromis

Le niveau de hardening doit correspondre à la criticité de ce que vous protégez. Un projet open-source personnel n’a pas les mêmes besoins qu’un pipeline qui déploie en production clients.

À retenir

Les 6 points essentiels de ce guide :

• Le pipeline CI/CD est une cible critique — il dispose d’accès privilégiés aux ressources sensibles
• 7 piliers de défense : éphémérité, isolation, least privilege, egress control, secrets courts (OIDC), vérification des inputs, immutabilité des inputs
• Les runners éphémères sont la base — mais un conteneur n’est pas automatiquement aussi isolé qu’une VM
• OIDC remplace les secrets statiques — mais le niveau de sécurité dépend du trust configuré côté cloud
• Le hardening est un prérequis pratique pour progresser vers SLSA — pas une garantie automatique de conformité
• Priorisez : permissions, pinning, OIDC d’abord ; egress strict et architecture hermétique ensuite

Prochaines étapes

SLSA

Comprenez les niveaux SLSA et comment les atteindre Lire le guide SLSA

Attaques GitHub Actions

Techniques offensives et défensives sur les pipelines Lire le guide

Sigstore

Signez vos artefacts avec Cosign et Fulcio Lire le guide Sigstore

SBOM

Générez un inventaire de vos composants à chaque build Lire le guide SBOM

×

📖 Voir la documentation →