Bien démarrer avec GitHub Actions : pipelines CI/CD et sécurité

Avant de créer votre premier workflow, prenons le temps de comprendre ce qu’est un pipeline CI/CD, comment GitHub Actions fonctionne, et surtout pourquoi la sécurité doit être votre priorité dès le premier jour.

C’est quoi un pipeline CI/CD ?

Imaginez que vous travaillez sur une application. À chaque modification du code, vous devez :

1. Vérifier que le code compile et que les tests passent
2. Construire l’application (créer un exécutable, une image Docker…)
3. Déployer vers un environnement (staging, production…)

Faire tout ça à la main, c’est long, répétitif, et source d’erreurs. Un pipeline CI/CD automatise ces étapes.

CI/CD, ça veut dire quoi ?

• CI (Continuous Integration) : À chaque modification, le code est automatiquement testé et intégré. On détecte les bugs très tôt.
• CD (Continuous Delivery/Deployment) : Le code validé est automatiquement préparé (ou déployé) vers les environnements cibles.

L’idée : des petits changements fréquents, validés automatiquement, plutôt que des grosses releases risquées tous les mois.

Pour approfondir ces concepts indépendamment de l’outil, consultez le guide sur les pipelines CI/CD qui détaille l’histoire, les concepts et les enjeux de sécurité.

GitHub Actions : le moteur de vos pipelines

GitHub Actions est le service CI/CD intégré à GitHub. Quand quelque chose se passe sur votre repository (un push, une pull request, une release…), GitHub Actions peut automatiquement exécuter des tâches.

Concrètement :

1. Un événement déclenche le pipeline (vous poussez du code)
2. Un workflow définit quoi faire (tester, builder, déployer)
3. Un runner exécute les tâches (une machine virtuelle fournie par GitHub)
4. Un résultat est produit (succès/échec, artefacts, déploiement)

Pourquoi la sécurité AVANT tout le reste ?

Ce n'est pas optionnel

Un pipeline CI/CD a accès à vos secrets (tokens d’API, mots de passe), votre code source, et souvent vos environnements de production. Une erreur de configuration peut exposer tout votre système.

Les attaques sur les pipelines CI/CD ont explosé. En mars 2025, une action GitHub compromise (tj-actions/changed-files) a permis d’exfiltrer les secrets de milliers de dépôts en quelques heures. L’attaque a touché toutes les versions de v1 à v45 — y compris celles considérées comme “stables”.

Le problème des tags mutables

Quand vous écrivez uses: actions/checkout@v4, vous faites confiance à un tag Git. Mais un tag peut être déplacé à tout moment par le mainteneur.

Voici ce qui peut se passer :

1. Vous utilisez actions/checkout@v4 dans votre workflow
2. L’action fonctionne parfaitement pendant des mois
3. Un attaquant compromet le compte du mainteneur
4. Il modifie le tag v4 pour pointer vers du code malveillant
5. Votre prochain pipeline exécute le code de l’attaquant — sans que vous changiez quoi que ce soit

C’est exactement ce qui s’est passé avec tj-actions/changed-files.

La solution : épingler par SHA

Un SHA (Secure Hash Algorithm) est l’empreinte cryptographique d’un commit. Contrairement à un tag, il est immuable — impossible de le modifier sans changer le hash.

# ❌ DANGEREUX : tag mutable
- uses: actions/checkout@v4

# ✅ SÉCURISÉ : SHA épinglé
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Le commentaire # v4.1.1 vous permet de garder une trace de la version correspondante. Des outils comme Renovate peuvent mettre à jour ces SHA automatiquement tout en gardant le commentaire.

Les trois réflexes de sécurité

Dès votre premier workflow, adoptez ces pratiques :

1. Épingler les actions par SHA

# Toujours utiliser le SHA complet, pas le tag
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

2. Déclarer des permissions minimales

# Par défaut, un workflow a TROP de permissions
# Limitez explicitement au strict nécessaire
permissions:
  contents: read  # Lecture seule sur le code

3. Ne jamais afficher de secrets dans les logs

# ❌ CATASTROPHE : le secret apparaît dans les logs
- run: echo "Token: ${{ secrets.API_TOKEN }}"

# ✅ Les secrets sont masqués automatiquement si utilisés correctement
- run: curl -H "Authorization: Bearer ${{ secrets.API_TOKEN }}" https://api.example.com

Vous apprendrez tout ça en détail

Ces concepts sont introduits ici pour que vous compreniez pourquoi c’est important. Le guide Sécurité : les bases vous montrera comment les appliquer concrètement.

Votre premier workflow

Maintenant que vous comprenez les enjeux, voici un exemple de workflow sécurisé pour une API Python :

.github/workflows/ci.yml

name: CI Pipeline

# Permissions minimales déclarées au niveau du workflow
permissions:
  contents: read

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # Actions épinglées par SHA
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

      - name: Installer Python
        uses: actions/setup-python@0b93645e9fea7318ecaed2b359559ac225c90a2b # v5.3.0
        with:
          python-version: '3.12'

      - name: Installer les dépendances
        run: pip install -r requirements.txt

      - name: Lancer les tests
        run: pytest

Ce workflow :

• Déclare permissions: contents: read pour limiter les accès
• Utilise des SHA au lieu de tags pour les actions
• Fait exactement ce qu’il doit faire : tester le code

Les concepts clés

Avant d’aller plus loin, voici le vocabulaire essentiel :

Terme	Définition	Exemple
Workflow	Un fichier YAML qui décrit votre pipeline	.github/workflows/ci.yml
Job	Un groupe de tâches qui s’exécutent sur la même machine	test, build, deploy
Step	Une tâche individuelle dans un job	« Installer Python », « Lancer pytest »
Runner	La machine (VM) qui exécute le job	ubuntu-latest, windows-latest
Action	Un composant réutilisable (comme une bibliothèque)	actions/checkout, actions/setup-python
SHA	Identifiant unique et immuable d’un commit	b4ffde65f46336ab88eb53be808477a3936bae11

Jobs vs Steps

Un job s’exécute sur une machine virtuelle dédiée. Plusieurs jobs peuvent tourner en parallèle sur des machines différentes.

Les steps d’un même job s’exécutent séquentiellement sur la même machine. Ils partagent le même système de fichiers.

Ce que vous allez apprendre

Cette section Fondations vous donne les bases pour créer et comprendre vos premiers workflows en toute sécurité :

Qu'est-ce qu'un workflow ? Structure des fichiers, emplacement, anatomie d'un workflow

Sécurité : les bases Permissions, épinglage SHA, protection contre les injections

Gestion des Secrets Où stocker vos mots de passe, tokens et variables

La marketplace GitHub Actions Comprendre le Marketplace, évaluer les actions tierces, et adopter les bons réflexes

Prochaine étape

Vous comprenez maintenant :

• Ce qu’est un pipeline CI/CD et pourquoi c’est utile
• Comment GitHub Actions s’intègre à votre workflow de développement
• Pourquoi la sécurité doit être intégrée dès le premier jour
• Les trois réflexes essentiels (SHA, permissions, secrets)

Passez au guide Qu’est-ce qu’un workflow ? pour découvrir la structure des fichiers et créer votre premier pipeline.