Permissions GitHub Actions : GITHUB_TOKEN

Le GITHUB_TOKEN est généré automatiquement pour chaque workflow. Il permet d'interagir avec l'API GitHub : cloner le repo, créer des issues, publier des packages. Mal configuré, il devient un vecteur d'attaque majeur.

Ce que vous allez apprendre

• Appliquer le moindre privilège au GITHUB_TOKEN
• Déclarer les permissions explicitement dans chaque workflow
• Choisir entre permissions workflow-level et job-level
• Connaître chaque permission disponible et le risque associé
• Vérifier la conformité avec le check Token-Permissions de Scorecard

Principe de moindre privilège

Le principe de moindre privilège consiste à n'accorder que les permissions strictement nécessaires. Si un workflow est compromis, les dégâts restent limités à ce qu'il pouvait faire.

Permissions par défaut

Les permissions par défaut du GITHUB_TOKEN dépendent de l'âge du dépôt et de sa configuration. C'est un piège classique : un dépôt ancien accorde encore, par défaut, des droits d'écriture étendus.

Type de dépôt	Permissions par défaut
Créé après février 2023	contents: read uniquement
Créé avant février 2023	Lecture ET écriture sur tout

Glissez pour voir

Vérifier vos paramètres

Dans Settings > Actions > General > Workflow permissions, sélectionnez "Read repository contents and packages permissions" pour forcer des permissions minimales par défaut.

Déclarer les permissions explicitement

Même avec des paramètres de dépôt restrictifs, déclarez toujours les permissions dans vos workflows : la configuration du dépôt peut changer, le workflow, lui, reste explicite et auditable.

name: Build and Test

permissions:
  contents: read  # Lecture du code uniquement

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Installer et tester
        run: npm ci && npm test

Permissions workflow-level vs job-level

GitHub Actions permet de déclarer les permissions à deux niveaux. Le choix entre les deux détermine l'étendue des dégâts si un seul job est compromis.

Workflow-level

Les permissions déclarées au niveau workflow s'appliquent à tous les jobs, y compris ceux qui n'en ont pas besoin.

# ⚠️ Tous les jobs ont packages:write
permissions:
  contents: read
  packages: write

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - run: npm test  # N'a pas besoin de packages:write

  publish:
    runs-on: ubuntu-24.04
    steps:
      - run: npm publish

Job-level (recommandé)

Gardez le niveau workflow au minimum et déclarez les permissions write au niveau de chaque job qui en a réellement besoin.

permissions:
  contents: read  # Minimal pour le workflow

jobs:
  test:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - run: npm test

  publish:
    needs: test
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      packages: write  # Uniquement pour ce job
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - run: npm publish

Avantage : si le job test est compromis, l'attaquant ne peut pas publier de package.

Permissions disponibles

Voici les permissions que vous accorderez le plus souvent, classées par risque. La règle reste la même : n'activez write que sur le job qui en a strictement besoin.

Permission	Usage	Risque si abusée
contents: read	Cloner le repo	Faible
contents: write	Pousser, créer des releases	Injection de code
packages: write	Publier sur GitHub Packages	Distribution de malware
actions: write	Modifier les workflows	Persistance
id-token: write	OIDC pour cloud providers	Accès infrastructure
pull-requests: write	Commenter les PRs	Spam, phishing
issues: write	Créer/modifier les issues	Spam
security-events: write	Upload SARIF	Masquer des alertes

Glissez pour voir

Ne jamais utiliser

permissions: write-all

Un workflow avec toutes les permissions peut modifier son propre code, créer des releases malveillantes et persister dans le dépôt.

Scorecard Token-Permissions

OpenSSF Scorecard vérifie que vos workflows respectent le moindre privilège. Le check Token-Permissions exige que les permissions write soient au niveau job.

# Vérifier vos workflows
scorecard --local . --checks Token-Permissions --show-details

Score 0/10 : permissions write au niveau workflow.

# ❌ Scorecard : 0/10
permissions:
  contents: read
  packages: write  # Au niveau workflow

Score 10/10 : permissions write au niveau job uniquement.

# ✅ Scorecard : 10/10
permissions:
  contents: read

jobs:
  publish:
    permissions:
      packages: write  # Au niveau job

Cas pratique : CI/CD complet

Ce pipeline complet, test, build, publication, applique le moindre privilège job par job. C'est un modèle directement réutilisable : chaque job ne reçoit que ce dont il a besoin.

name: CI/CD Pipeline

permissions:
  contents: read

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Installer et tester
        run: npm ci && npm test

  build:
    needs: test
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Construire le projet
        run: npm run build
      - name: Publier l'artefact
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: dist
          path: dist/

  publish:
    if: github.ref == 'refs/heads/main'
    needs: build
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      packages: write
      id-token: write  # Pour OIDC
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Récupérer l'artefact
        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
        with:
          name: dist
          path: dist/
      - name: Publier le package
        run: npm publish

À retenir

• Le GITHUB_TOKEN est créé pour chaque exécution ; un dépôt ancien lui accorde par défaut des droits d'écriture étendus, à corriger.
• Déclarez permissions: explicitement dans chaque workflow, même si les paramètres du dépôt sont déjà restrictifs.
• Gardez le workflow-level au minimum (contents: read) et n'accordez write qu'au job qui en a réellement besoin.
• permissions: write-all est à proscrire : un workflow compromis pourrait modifier son propre code et persister.
• Le check Token-Permissions de Scorecard exige les permissions write au niveau job, c'est le signal de conformité.

Prochaines étapes

Sécuriser GitHub Actions Le guide complet : épinglage, secrets, déclencheurs, OIDC

Épingler les actions par SHA Bloquer les actions compromises par tags mutables

Attaques supply chain Comment des permissions trop larges sont exploitées

OpenSSF Scorecard Auditer le check Token-Permissions sur vos dépôts

Pour la liste exhaustive des permissions, consultez la documentation officielle sur le GITHUB_TOKEN.

×

📖 Voir la documentation →