GitHub Actions et GitLab CI/CD : sécuriser ses pipelines contre le vol de secrets

Un pipeline CI/CD détient les clés du royaume : jetons de publication des paquets, accès aux registres d’images, identifiants cloud, clés de déploiement en production. C’est pourquoi il est devenu une cible prioritaire. En 2025 et 2026, les attaques se sont enchaînées : action GitHub tj-actions piégée en mars 2025, étiquettes de trivy-action réécrites en mars 2026, ver Mini Shai-Hulud qui, en mai 2026, a détourné des workflows pour publier 172 paquets malveillants avec des attestations de provenance pourtant valides. Voici les mesures qui protègent vos secrets, sur GitHub Actions comme sur GitLab CI/CD.

L’essentiel en 30 secondes

• Épinglez les actions et composants tiers par empreinte SHA complète : une étiquette de version peut être déplacée.
• Permissions minimales : jeton du workflow en lecture seule par défaut, droits accordés job par job.
• Remplacez les secrets statiques par OIDC pour l’accès au cloud et la publication des paquets.
• Isolez le code non fiable : jamais de secrets dans les pipelines qui exécutent le code d’une contribution externe ; méfiance extrême envers pull_request_target.
• Protégez les déploiements par des environnements avec approbation et des branches protégées.

Ce que les attaques récentes ont exploité

GitHub Actions : la configuration de base

name: ci
on:
  push:
    branches: [main]
  pull_request:

permissions: {}

jobs:
  tests:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<sha-complet-de-40-caracteres> # v5
        with:
          persist-credentials: false
      - run: make test

  deploiement:
    if: github.ref == 'refs/heads/main'
    needs: tests
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@<sha-complet-de-40-caracteres> # v5
        with:
          persist-credentials: false
      - run: ./deployer.sh

• permissions: {} au niveau du workflow, puis droits explicites par job.
• persist-credentials: false : le jeton n’est pas laissé dans la configuration Git du runner.
• environment: production : secrets de production accessibles uniquement à ce job, avec relecteurs obligatoires.
• id-token: write uniquement pour le job qui s’authentifie au cloud ou au registre de paquets via OIDC.

Les réglages d’organisation à activer

• Jeton GITHUB_TOKEN en lecture seule par défaut (les organisations anciennes ont souvent des droits plus larges).
• Obligation d’épinglage par SHA des actions, disponible depuis août 2025, et liste des actions autorisées. Une action compromise peut être bloquée rapidement avec la syntaxe !organisation/action.
• Versions immuables (disponibles depuis octobre 2025) pour vos propres actions publiées.
• Approbation obligatoire des workflows déclenchés par des contributeurs externes.

Le piège de l’injection de script

Insérer directement un titre de pull request ou de ticket dans une commande permet à un attaquant d’y glisser du code :

# Dangereux : le titre est interprété par le shell
- run: echo "Titre : ${{ github.event.pull_request.title }}"

# Sûr : passer par une variable d'environnement
- env:
    TITRE: ${{ github.event.pull_request.title }}
  run: echo "Titre : $TITRE"

GitLab CI/CD : les équivalents

• Variables protégées et masquées : disponibles uniquement sur les branches et étiquettes protégées.
• Portée du jeton de job (CI_JOB_TOKEN) limitée aux projets explicitement autorisés.
• OIDC via id_tokens pour l’accès au cloud, avec des conditions sur le projet, la branche et l’environnement.
• Includes et composants épinglés sur une empreinte de commit plutôt qu’une branche.
• Runners : pas de runner partagé en mode privilégié ; runners éphémères pour les projets sensibles ; runners distincts pour la production.
• Environnements protégés avec approbation pour les déploiements.

Outils utiles

• zizmor : analyse statique des workflows GitHub (injections, permissions excessives, déclencheurs dangereux).
• pinact, Renovate ou Dependabot : épinglage par SHA et mises à jour contrôlées, idéalement avec un délai de quelques jours avant d’adopter une nouvelle version.
• Restriction des flux sortants des runners, pour empêcher l’exfiltration vers des serveurs inconnus.

Ces mesures complètent la surveillance des dépendances vulnérables, la génération d’un SBOM et la signature des artefacts.

Questions fréquentes

Épingler par SHA empêche-t-il les mises à jour de sécurité ?

Non, cela les rend explicites : un outil propose la mise à jour, vous la relisez, puis vous fusionnez. C’est exactement le contrôle qui manquait lors des incidents de 2025 et 2026.

Peut-on utiliser pull_request_target en sécurité ?

Très difficilement. GitHub l’exécute désormais toujours depuis la branche par défaut, mais exécuter le code de la contribution dans ce contexte reste dangereux. Préférez pull_request sans secrets, et un second workflow séparé pour les actions privilégiées.

Que faire si une action que nous utilisons est compromise ?

Bloquer l’action, identifier les exécutions pendant la période concernée, faire tourner tous les secrets accessibles à ces workflows, puis rechercher des traces d’exfiltration et de publications non prévues.

Les runners auto-hébergés sont-ils plus sûrs ?

Pas par défaut : un runner persistant peut conserver des traces d’un job à l’autre. Utilisez des runners éphémères et ne les attachez jamais à des dépôts publics.

Sources

• Wiz, guide de durcissement de GitHub Actions, mis à jour en avril 2026.
• Aqua Security, attaque de la chaîne d’approvisionnement de Trivy, mars 2026.
• Cloud Security Alliance, note sur Mini Shai-Hulud, mai 2026.
• GitHub Docs, durcissement de la sécurité de GitHub Actions.
• GitLab Docs, recommandations de durcissement CI/CD.

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous auditons vos chaînes de déploiement lors d’un audit. Demandez un devis gratuit ou appelez le 05 32 42 99 98.