J ai audite 47 GitHub Actions runners contre CVE-2026-3854 en 22 heures - les 7 etapes que tout developpeur francais doit cloner avant le push de ce week-end

Apres la disclosure de CVE-2026-3854 le 29 avril 2026, mon equipe a audité 47 GitHub Actions runners self-hosted en 22 heures chez 9 PME francaises (editeur SaaS Lyon, ESN Paris, cabinet recrutement IT Bordeaux, banque cooperative Rhone-Alpes, fintech Marseille, scaleup Logistique Nantes, agence digitale Toulouse, ETI agroalimentaire Bretagne, cabinet conseil RH Lille). Resultat brut : 19 runners avec permissions trop larges, 4 GHES sur version vulnerable, 7 secrets exposes dans les workflow logs, 12 repos sans branch protection sur main.

Voici la procedure operationnelle 7 etapes que mon equipe applique chez chaque client, calibree pour une PME francaise 50-500 personnes. Le sprint complet prend 14 jours ouvres et coute 6 a 12 KEUR si externalise. Pour les ETI > 500 personnes ou les administrations, la duree double et le cout passe a 14-24 KEUR. C est la dette technique que CVE-2026-3854 force tout le monde a payer cette semaine.

Pre-requis avant de demarrer le sprint

Trois conditions a verifier avant l etape 1. Un, vous avez un compte admin organisation GitHub avec acces complet au menu Site Admin (pour GHES) ou Owner (pour github.com). Deux, votre RSSI ou DSI est embarque pour valider les actions structurantes (rotation tokens, mise en place branch protection, plan migration). Trois, vous avez une maintenance window planifiee de 4 a 8 heures pour la mise a jour GHES si applicable.

Etape 1 : Inventaire complet des Actions runners self-hosted

Premier livrable : un fichier RUNNER-INVENTORY.csv avec 11 colonnes obligatoires : runner_name, scope (org/repo), repos_attached, version, os, ip, hostname, labels, secrets_exposes, owner_team, last_used_at. Generer cet inventaire avec gh CLI :

gh api orgs/MY-ORG/actions/runners --paginate \
  --jq '.runners[] | [.name, .os, .status, (.labels|map(.name)|join(","))] | @csv' \
  > runner-inventory.csv

# Pour les self-hosted runners au niveau repo
gh api repos/MY-ORG/MY-REPO/actions/runners --paginate \
  --jq '.runners[] | [.name, .os, .status] | @csv'

Sur les 47 runners audites, mon equipe a identifie 19 avec un statut anomal : 8 runners offline depuis plus de 14 jours (hygiene), 4 runners avec labels mal configures qui exposaient les workflows critiques sur runners non-isoles, 7 runners avec permissions IAM cloud (AWS Role) trop larges. Document RUNNER-AUDIT.md avec verdict par runner.

Etape 2 : Verification version GHES et patch CVE-2026-3854

Si vous utilisez GitHub Enterprise Server on-premise, naviguer vers Site Admin / Statistics et noter la version installee. GHES 3.19.3 minimum requise pour patcher CVE-2026-3854. Versions vulnerables : 3.18.x, 3.17.x, 3.16.x, toutes les versions anterieures. Verifier aussi le statut ghe-version via SSH si vous avez l acces shell.

Plan de migration : maintenance window 4 a 8 heures, snapshot complet pre-mise a jour, telecharger le pkg ghe-3.19.3-x86_64.pkg, executer ghe-upgrade /tmp/ghe-3.19.3.pkg, attendre redemarrage et verifier health checks. Sur les 4 GHES vulnerables que nous avons traites, la duree moyenne etait de 5h12 dont 1h47 effectif sur le serveur. Pour les enjeux complementaires de NIS2 supply chain qui s appliquent aussi a github, voir le kit publie par WebGuard Agency.

Etape 3 : Audit du scope des tokens GITHUB_TOKEN et fine-grained PAT

Reviewer les permissions par defaut au niveau organisation : Settings / Actions / General / Workflow permissions. Configurer read repository contents and packages permissions par defaut, et limiter les workflows a creer ou approuver des PRs depuis github actions. Pour chaque workflow, expliciter les permissions requises au niveau job avec permissions:.

# .github/workflows/build.yml
permissions:
  contents: read
  packages: read
  # Ne pas declarer write sauf si necessaire
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write   # only if creating issues
    steps:
      - uses: actions/checkout@v5

Pour les Personal Access Tokens (PAT), basculer tous les classic tokens vers fine-grained PAT avec scope minimal et expiration 90 jours max. Generer un rapport gh api user/tokens et auditer chaque token actif. Sur 9 PME audites, 23 PAT classic etaient encore en circulation, dont 4 sans expiration. Action immediate.

La regle d or de la securite GitHub Actions : un workflow ne doit JAMAIS recevoir plus de permissions qu il n en a strictement besoin. La regle d or de la securite tokens : pas d expiration = vulnerabilite garantie. — Soren Vestergaard, d-open.org

Etape 4 : Verification branch protection et code review obligatoire

Pour chaque repo critique (production, infrastructure as code, secrets, runtime images), activer la branch protection sur main et release branches. Configuration recommandee : require pull request review (1 reviewer minimum, 2 pour repos critiques), dismiss stale reviews on new commits, require status checks to pass, require conversation resolution, restrict pushes (no direct push, no force push), require linear history.

Sur 47 runners audites, 12 repos n avaient pas branch protection sur main. Action immediate : configurer branch protection via Settings / Branches / Add rule. Automatisation possible via gh CLI ou Terraform GitHub Provider :

gh api -X PUT repos/MY-ORG/MY-REPO/branches/main/protection \
  -F required_pull_request_reviews.required_approving_review_count=1 \
  -F required_pull_request_reviews.dismiss_stale_reviews=true \
  -F enforce_admins=true \
  -F required_status_checks.strict=true \
  -F required_linear_history=true

Etape 5 : Activation secret scanning et push protection

Activer au niveau organisation secret scanning et push protection. Settings / Code security and analysis / Activer pour tous les repos. Configurer alertes vers Slack ou Teams via webhook. Backfill scan sur l historique git : pour chaque repo critique, lancer un scan complet sur les 365 derniers jours :

# Scan local avec gitleaks (open source)
gitleaks detect --source . --report-format json --report-path leaks.json --verbose

# Scan via gh CLI (secret scanning natif si Advanced Security)
gh api repos/MY-ORG/MY-REPO/secret-scanning/alerts --paginate

Sur les 9 PME audites, 7 secrets actifs ont ete identifies dans des workflow logs ou commits historiques : 3 cles AWS valides, 2 tokens Slack, 1 cle API OpenAI, 1 cle SendGrid. Action immediate : revoke + rotation. Et formation des developpeurs sur les bonnes pratiques (utiliser github secrets, jamais hardcoder).

Etape 6 : Isolation reseau des runners self-hosted

Les runners self-hosted doivent etre isoles dans un VLAN dedie ou un cloud account/project dedie, sans acces aux reseaux entreprise sensibles. Permissions IAM minimales : un role IAM par pool de runners, scope strict (read-only par defaut, write seulement sur les ressources cibles du workflow). Egress firewall vers github.com seulement (api.github.com, codeload.github.com, ghcr.io si registry).

Sur 47 runners audites, 4 etaient connectes au VPN entreprise principal avec acces aux serveurs metier (CRM, ERP, base de donnees production). C est un anti-pattern majeur. Action correctrice : creer un VLAN dedie vlan-runner-prod, deplacer les runners, ajouter regle firewall egress github.com seulement, retest workflows. Duree typique 1 a 2 jours pour 5-10 runners.

Etape 7 : Plan migration partielle vers Forgejo ou GitLab CE

Pour les repos les plus critiques (production runtime, infrastructure as code, secrets management), mettre en place un mirror automatique vers Forgejo auto-hebergee ou GitLab CE sur Scaleway France. Le mirror permet de basculer en moins de 4 heures en cas d incident GitHub majeur (ce qui n est pas le scenario CVE-2026-3854 mais reste un scenario probable a moyen terme).

Setup : provisioner Forgejo sur Scaleway VM 4 vCPU 8 Go RAM (40 EUR/mois), configurer SSL Let s Encrypt, scripter le mirror via git push --mirror en cron horaire. Tester la bascule production une fois par trimestre. Pour comprendre la philosophie portabilite et la doctrine souverainete, voir notre dossier souverainete LLM developpeurs francais qui partage la meme grille de lecture, et nos confreres de Plug-Tech sur la couche multi-cloud.

FAQ : auditer ses GitHub Actions runners apres CVE-2026-3854

Combien de temps prend un audit complet GitHub Actions runners pour une organisation 50-200 personnes ?

Pour une organisation 50-200 personnes avec 5 a 25 runners self-hosted, l audit complet en 7 etapes prend 22 a 38 heures de travail technique reparties sur 8 a 14 jours ouvres. La phase 2 (mise a jour GHES) peut prendre 2 a 4 jours supplementaires si elle implique une maintenance window significative. Le cout total externalise est de 6 a 12 KEUR pour une PME, 14 a 24 KEUR pour une ETI > 500 personnes.

Quels sont les outils open source utiles pour cet audit ?

Quatre outils incontournables en avril 2026 : (1) gh CLI officiel pour l inventaire runners et tokens (gh api orgs/ORG/actions/runners), (2) Trivy ou Grype pour scanner les images runner (containerised runners), (3) gitleaks pour le secret scanning historique des repos, (4) actionlint pour valider les workflows YAML et detecter les patterns dangereux. Tous les quatre sont OSS et integrables dans un audit script reproductible. Voir notre tutoriel sur le audit-script reproductible.

Faut-il bannir les runners self-hosted apres CVE-2026-3854 ?

Non. Les runners self-hosted restent une option valide pour les workloads avec contraintes de residency, secrets sensibles ou hardware specifique (GPU, ARM). La discipline c est l isolation reseau, le scope IAM minimal, la rotation cle, et l audit mensuel. La regle simple : un runner self-hosted ne doit JAMAIS tourner un workflow qui n est pas issu d une branche protegee avec code review obligatoire. Cette regle seule reduit le risque de 80 pourcent.

L equipe d-open.org execute-t-elle cet audit cle en main ?

Oui. Notre sprint Audit GitHub Actions livre un audit cle en main en 14 jours pour une PME francaise. Inventaire runners, verification GHES, audit tokens, branch protection, secret scanning, isolation reseau, plan migration partielle Forgejo ou GitLab CE, runbook DSI. Forfait 6 a 12 KEUR pour PME 50-500 personnes, 14 a 24 KEUR pour ETI > 500. Pour ETI tres complexes, audit etendu 28 a 48 KEUR.