Marketplace GitHub Actions : évaluer les actions tierces

La Marketplace GitHub Actions rassemble des milliers d'actions réutilisables, publiées par GitHub, par des éditeurs et par la communauté. Plutôt que de réécrire la logique qui clone un dépôt, installe Node.js ou déploie sur AWS, vous appelez une action existante avec uses:.

Le gain de temps est réel, et le risque l'est tout autant : une action s'exécute sur votre runner, avec accès au code et aux secrets du job. Choisir une action, c'est donc décider à qui vous accordez cet accès.

Qu'est-ce qu'une action ?

Une action est un composant réutilisable qui encapsule une tâche complète. Au lieu d'une vingtaine de lignes de shell pour installer Python et gérer son cache, vous écrivez quatre lignes de YAML :

- uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
  with:
    python-version: '3.12'
    cache: 'pip'

L'action setup-python gère tout : téléchargement, installation, configuration du PATH, mise en cache des dépendances. Vous vous concentrez sur votre logique métier.

Les trois types d'actions

Type	Description	Linux	macOS	Windows
JavaScript	Code JS exécuté directement sur le runner	✅	✅	✅
Docker	Conteneur avec un environnement complet	✅	❌	❌
Composite	Assemblage d'autres actions et commandes	✅	✅	✅

Glissez pour voir

Les actions JavaScript sont les plus rapides (pas de pull d'image) et fonctionnent sur tous les runners. Les actions Docker sont plus lourdes mais garantissent un environnement isolé et reproductible, attention, elles ne fonctionnent que sur Linux.

Anatomie d'une référence d'action

Quand vous écrivez actions/checkout@v4 derrière uses:, voici ce que ça signifie :

uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
       └──────┬──────┘ └┬┘
          owner/repo   ref

• owner : L'organisation ou l'utilisateur GitHub (ici actions, l'org officielle GitHub)
• repo : Le nom du repository contenant l'action
• ref : La version à utiliser (tag, branche, ou SHA)

Les différentes façons de référencer une version

# ❌ Tag (le plus courant, mais MUTABLE)
- uses: actions/checkout@v7

# ❌ Branche (DANGEREUX - change à chaque commit)
- uses: actions/checkout@main

# ✅ SHA complet (RECOMMANDÉ - immuable), version en commentaire
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1

Les tags sont mutables

Un tag comme @v4 peut être déplacé par le mainteneur, ou par quiconque aurait pris le contrôle de son compte. Votre workflow exécuterait alors du code malveillant sans qu'une ligne de votre dépôt ait changé : c'est le scénario exact de l'attaque tj-actions/changed-files.

C'est pourquoi la bonne pratique est d'épingler par SHA. Voir la section sécurité plus bas.

Trouver des actions sur La Marketplace

La Marketplace est accessible sur github.com/marketplace?type=actions. Vous pouvez rechercher par catégorie ou par mot-clé.

Les catégories principales

Catégorie	Exemples d'actions
Continuous integration	Tests, linting, build
Deployment	AWS, Azure, GCP, Kubernetes
Code quality	SonarQube, CodeClimate
Security	Trivy, Snyk, CodeQL
Utilities	Cache, artifacts, notifications

Glissez pour voir

Actions officielles GitHub

L'organisation actions maintient des actions officielles, testées et sécurisées :

Action	Description
actions/checkout	Clone le repository
actions/setup-node	Configure Node.js
actions/setup-python	Configure Python
actions/cache	Cache des dépendances
actions/upload-artifact	Sauvegarde des fichiers entre jobs
actions/download-artifact	Récupère des artifacts

Glissez pour voir

Ces actions sont un bon point de départ. Elles sont maintenues activement, documentées, et suivent les bonnes pratiques de sécurité.

Évaluer une action avant de l'utiliser

Avant d'ajouter une action à votre workflow, posez-vous ces questions :

1. Qui est l'auteur ?

   Sur la Marketplace, cherchez le badge Verified creator, qui atteste que GitHub a vérifié l'identité de l'organisation. Les espaces de noms actions/* (GitHub), aws-actions/* ou docker/* offrent une garantie que n'a pas un compte personnel inconnu. Attention toutefois : ce badge dit qui publie, pas si le code est sûr.

2. Est-elle maintenue ?

   Vérifiez la date du dernier commit, les issues ouvertes, et la réactivité des mainteneurs. Une action abandonnée depuis 2 ans est un risque.

3. Combien de personnes l'utilisent ?

   Le nombre d'étoiles et de forks donne une indication utile, sans plus : une action très utilisée est davantage relue, donc ses failles ont plus de chances d'être vues. Mais la popularité attire aussi les attaquants, et tj-actions/changed-files comptait des dizaines de milliers d'utilisateurs.

4. Ai-je vraiment besoin d'une action ?

   Parfois, 3 lignes de shell suffisent. Une action ajoute une dépendance et un risque. Si la logique est simple, préférez run:.

5. Quelles permissions demande-t-elle ?

   Lisez la documentation. Si une action de notification Slack demande contents: write, c'est suspect.

Signaux d'alerte

Méfiez-vous si :

• ❌ Le repository n'a pas de fichier action.yml documenté
• ❌ Le code source n'est pas lisible (obfusqué)
• ❌ L'action demande des permissions excessives
• ❌ Peu d'étoiles et dernier commit il y a plus d'un an
• ❌ Pas de releases, juste une branche main
• ❌ Le nom ressemble à une action populaire (typosquatting)

Typosquatting

Le typosquatting consiste à créer une action avec un nom très proche d'un projet populaire. L'attaquant compte sur vos fautes de frappe :

• actions/checkout ✅ vs action/checkout ❌ (sans le "s")
• actions/setup-node ✅ vs actions/setup-nodejs ❌

Vérifiez toujours l'orthographe exacte. Une lettre de différence peut vous faire exécuter du code malveillant.

Sécurité : les bons réflexes

Utiliser une action tierce, c'est exécuter du code d'un inconnu avec accès à vos secrets. Adoptez ces réflexes dès maintenant :

1. Épingler par SHA

Au lieu des tags mutables, utilisez le SHA complet du commit :

# ❌ Tag mutable - peut changer sans prévenir
- uses: actions/checkout@v4

# ✅ SHA immuable - vous contrôlez exactement le code exécuté
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Le commentaire # v4.2.2 conserve la lisibilité tout en garantissant l'immutabilité.

Comment trouver le SHA ?

# Résoudre un tag EXACT, jamais un tag majeur
gh api repos/actions/checkout/commits/v4.2.2 --jq .sha

# Forme de référence, qui distingue un tag annoté de son commit
git ls-remote --tags https://github.com/actions/checkout v4.2.2 'v4.2.2^{}'

Résolvez toujours un tag exact, jamais v4. Le tag majeur est mobile : il désigne la dernière 4.x publiée à l'instant où vous interrogez l'API, et la réponse ne vous dit pas laquelle. Vous obtenez alors un SHA juste avec un commentaire faux, et c'est le défaut le plus sournois de l'épinglage : le workflow est sûr, mais Dependabot, les relecteurs et les audits raisonnent tous sur la version affichée.

Ce décalage ne se voit pas à l'œil, et les contrôles ne le voient pas tous. pinact run --check le laisse passer ; pinact run --verify --check le refuse en nommant la cause, et zizmor le signale par sa règle ref-version-mismatch, à condition de le lancer en ligne, puisqu'il doit interroger GitHub pour comparer.

2. Vérifier avec OpenSSF Scorecard

OpenSSF Scorecard analyse la maturité sécurité d'un projet open source. Entrez l'URL du repository de l'action pour voir son score.

Un score élevé indique que le projet suit les bonnes pratiques : branch protection, signed releases, dependency updates, etc.

3. Préférer les actions officielles

Quand le choix existe, préférez :

1. Les actions de l'organisation actions/* (GitHub officiel)
2. Les actions d'éditeurs connus (aws-actions/*, docker/*, azure/*)
3. Les actions de projets établis (anchore/*, aquasecurity/*)

4. Limiter les permissions

Même si une action est de confiance, appliquez le principe de moindre privilège :

permissions:
  contents: read  # Par défaut, lecture seule

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Si l'action est compromise, les dégâts sont limités.

5. Activer Dependabot pour les actions

Dependabot surveille les actions déclarées dans vos workflows, signale celles qui portent une vulnérabilité connue, et ouvre les pull requests de mise à jour. C'est ce qui rend l'épinglage par SHA tenable dans la durée : sans lui, un SHA figé finit par pointer du code non corrigé.

Ajoutez dans .github/dependabot.yml :

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7      # quarantaine avant de proposer une version

Dependabot ouvrira une pull request dès qu'une nouvelle version d'une action paraît, en conservant l'épinglage par SHA et en réécrivant le commentaire de version avec lui : le couple reste donc cohérent sans intervention.

Le bloc cooldown mérite une explication, car son absence est le défaut le plus courant de ces fichiers. Sans lui, Dependabot propose une version le jour de sa publication, c'est-à-dire pendant la fenêtre exacte où une version compromise fait le plus de dégâts : dans les incidents récents, le paquet malveillant a été retiré en quelques heures. Une quarantaine de sept jours ne coûte rien et laisse la communauté détecter l'anomalie à votre place. zizmor signale d'ailleurs son absence par la règle dependabot-cooldown.

Passer des paramètres à une action

La plupart des actions acceptent des paramètres via la propriété with: :

- uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
  with:
    python-version: '3.12'      # Version de Python
    cache: 'pip'                # Activer le cache pip
    cache-dependency-path: |    # Fichiers pour le cache
      requirements.txt
      requirements-dev.txt

Consultez la documentation de l'action avant de l'appeler : sa page sur la Marketplace, son README.md, et surtout son fichier action.yml, qui fait foi. C'est lui qui déclare les entrées acceptées et leurs valeurs par défaut, souvent plus à jour que la prose du dépôt.

Dépannage

L'action n'est pas trouvée

Error: Unable to resolve action `actions/checkout@v99`

Causes probables :

• Le tag/SHA n'existe pas
• Typo dans le nom de l'action
• Le repository est privé ou a été supprimé

Solution : Vérifiez l'URL exacte sur La Marketplace et le tag dans les releases du repository.

Erreur de permissions

Error: Resource not accessible by integration

Causes probables :

• L'action a besoin de permissions que vous n'avez pas déclarées
• Le token GITHUB_TOKEN n'a pas les droits nécessaires

Solution : Ajoutez les permissions requises dans votre workflow :

permissions:
  contents: read
  issues: write  # Si l'action doit créer des issues

L'action est lente

Causes probables :

• Action Docker qui télécharge une grosse image
• Pas de cache configuré
• Action mal optimisée

Solution : Cherchez une alternative JavaScript ou configurez le cache si l'action le supporte.

Créer ses propres actions : la meilleure façon d'apprendre

Avant de chercher une action sur La Marketplace, posez-vous la question : puis-je le faire moi-même ?

Créer vos propres actions présente plusieurs avantages :

• Maîtrise totale : vous savez exactement ce que fait le code
• Apprentissage : vous comprenez le fonctionnement interne de GitHub Actions
• Sécurité : pas de dépendance tierce = pas de risque supply chain
• Personnalisation : adapté exactement à vos besoins

Quand créer plutôt qu'utiliser ?

Situation	Recommandation
Logique simple (quelques commandes)	run: avec du shell
Logique réutilisée dans plusieurs workflows	Action composite
Besoin d'un environnement spécifique	Action Docker
Besoin de performances et compatibilité multi-OS	Action JavaScript
Tâche complexe et bien maintenue	Action du Marketplace

Glissez pour voir

Exemple : action composite simple

Créez .github/actions/setup-project/action.yml :

name: 'Setup Project'
description: 'Configure l''environnement du projet'

runs:
  using: 'composite'
  steps:
    - name: Setup Node.js
      uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
      with:
        node-version: '20'
        cache: 'npm'

    - name: Install dependencies
      shell: bash
      run: npm ci

    - name: Verify installation
      shell: bash
      run: npm --version && node --version

Utilisez-la dans vos workflows :

steps:
  - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
  - uses: ./.github/actions/setup-project  # Action locale

Commencez par le simple

Ne publiez pas vos premières actions sur la Marketplace. Gardez-les dans votre dépôt, sous forme d'actions locales, ou dans un dépôt privé de votre organisation. Publier engage une maintenance : les utilisateurs attendront des correctifs, et une action abandonnée devient à son tour un risque pour ceux qui l'ont adoptée.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Créez vos propres actions pour les cas simples, c'est la meilleure façon d'apprendre
• La Marketplace contient des milliers d'actions, mais toutes ne sont pas sûres
• Une action exécute du code tiers avec accès à vos secrets
• Épinglez toujours par SHA pour éviter les modifications surprises
• Évaluez l'auteur (badge Verified creator), la maintenance, et la popularité
• Le typosquatting est un risque réel, vérifiez l'orthographe exacte
• Préférez les actions officielles (actions/*, éditeurs vérifiés)
• Activez Dependabot pour être alerté des vulnérabilités

Références officielles

• GitHub Actions Marketplace, Catalogue officiel des actions
• About custom actions, Documentation officielle sur les types d'actions
• Creating a composite action, Tutoriel pour créer une action composite
• Sécurité GitHub Actions : les bases, Les 3 risques principaux dont les actions tierces
• OpenSSF Scorecard, Évaluer la maturité sécurité d'un projet

Pour aller plus loin

• Contexts et expressions : Lire les données que GitHub expose à un workflow, et les conditionner.
• Variables et secrets : Où placer une valeur selon qu'elle est publique, sensible, ou partagée.
• Déclencheurs : Choisir l'événement qui lance le workflow, et éviter ceux qui exposent le dépôt.

×

📖 Voir la documentation →