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 dépôt (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 ne relèvent plus du cas d'école. En mars 2025, la compromission de l'action tj-actions/changed-files a permis d'exfiltrer les secrets de milliers de dépôts en quelques heures. Le détail qui compte : l'attaquant a réécrit les tags de v1 à v45, si bien que les versions réputées les plus stables livraient elles aussi le code malveillant.

Le problème des tags mutables

Quand vous écrivez actions/checkout@v4 derrière uses:, vous faites confiance à un tag Git, c'est-à-dire à une étiquette déplaçable. Le mainteneur du dépôt peut la faire pointer ailleurs quand il le veut, et rien dans votre code ne changera pour autant.

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 déplace le tag v4 vers du code malveillant
5. Votre prochain pipeline exécute le code de l'attaquant, sans que vous ayez rien changé

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 : elle se calcule à partir du contenu. Contrairement à un tag, elle est donc immuable, puisque modifier une seule ligne du code produit une autre empreinte, et votre workflow ne la trouverait plus.

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

# ✅ SÉCURISÉ : SHA épinglé
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Le commentaire # v7.0.1 garde la trace de la version lisible derrière l'empreinte, sans quoi personne ne saurait dire ce qui est épinglé. Des outils comme Renovate et Dependabot savent mettre à jour ces SHA automatiquement en réécrivant le commentaire avec eux : il reste donc juste après chaque montée de version.

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@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

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. Faire passer les secrets par env:

# ❌ Le secret devient un argument de commande, visible dans la liste des processus
- run: curl -H "Authorization: Bearer ${{ secrets.API_TOKEN }}" https://api.interne.lan/deploy

# ✅ Le secret entre par env: et ne quitte jamais l'environnement du step
- run: curl -H "Authorization: Bearer $API_TOKEN" https://api.interne.lan/deploy
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}

GitHub masque la valeur exacte d'un secret dans les journaux, quelle que soit la façon dont vous l'employez : les deux formes ci-dessus affichent ***. La différence est ailleurs, et elle est réelle : une valeur interpolée dans run: est écrite dans la ligne de commande du processus, donc lisible par tout ce qui tourne sur le runner. Le bloc env: l'y évite.

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-24.04
    steps:
      # Actions épinglées par SHA
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - name: Installer Python
        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
        with:
          python-version: '3.12'

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

      - name: Lancer les tests
        run: pytest

Trois choses méritent d'être relevées dans cet exemple, et ce sont exactement les trois réflexes vus plus haut :

• il déclare permissions: contents: read, donc le jeton du workflow ne peut rien écrire ;
• il épingle ses deux actions par SHA, avec la version en commentaire ;
• il fait une seule chose, tester le code, ce qui le rend facile à relire.

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-24.04, windows-2025
Action	Un composant réutilisable (comme une bibliothèque)	actions/checkout, actions/setup-python
SHA	Identifiant unique et immuable d'un commit	3d3c42e5aac5ba805825da76410c181273ba90b1

Glissez pour voir

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 disposez maintenant du vocabulaire et des réflexes qui rendent la suite lisible :

• ce qu'est un pipeline CI/CD, et ce qu'il automatise réellement ;
• comment GitHub Actions s'insère dans votre façon de travailler ;
• pourquoi la sécurité se pose dès le premier workflow, et pas après ;
• les trois réflexes : épingler par SHA, restreindre les permissions, faire passer les secrets par env:.

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

×

📖 Voir la documentation →