Durcir GitHub Actions avant la GA de septembre : secrets scopés, egress firewall et actions immuables
GitHub a annoncé pour 2026 une refonte des contrôles de sécurité d'Actions : verrouillage des dépendances de workflow, actions et releases immuables, secrets à portée fine, pare-feu egress natif et télémétrie d'exécution. Cet article détaille ce que ces briques changent, ce qu'on peut déjà appliquer sans attendre la disponibilité générale, et propose un plan de migration en quatre semaines assorti d'indicateurs de suivi.
2026, l’année où la CI devient une surface d’attaque de premier plan
Les incidents publics des dix-huit derniers mois partagent une anatomie remarquablement stable.
La compromission de tj-actions/changed-files en mars 2025 a exploité un tag mutable : l’attaquant a réécrit les tags de version pour pointer vers un commit malveillant, et des dizaines de milliers de workflows ont exécuté ce commit sans rien changer de leur côté. Le payload dumpait la mémoire du processus Runner.Worker et écrivait les secrets décodés dans les logs de build — publics sur les dépôts publics.
L’attaque sur trivy-action en avril 2026 rejoue la même mécanique d’extraction mémoire. La compromission de la chaîne d’approvisionnement AsyncAPI du 14 juillet 2026 y ajoute la brique classique du pwn request : un workflow déclenché sur pull_request_target exécutait du code contrôlé par l’auteur de la PR tout en disposant des secrets du dépôt ; l’attaquant a enchaîné 37 pull requests pour exfiltrer un PAT surprivilégié, puis publié des paquets npm malveillants sous l’organisation @asyncapi. La RCE découverte en juin 2026 dans les workflows de Claude Code montre la variante moderne : une simple issue malveillante suffisait à détourner l’exécution.
Trois primitives reviennent systématiquement :
- Une entrée non fiable évaluée dans un contexte privilégié. Titre de PR, corps d’issue, nom de branche interpolés dans un
run:— ou lus par un agent. - Une dépendance mutable. Un tag, une branche, une image
:latest. Le contrat « ce que j’ai audité est ce qui s’exécutera » n’existe pas. - Un secret trop puissant et trop accessible. Un PAT d’organisation avec droits d’écriture sur tout, disponible dans tous les jobs, lisible depuis la mémoire du runner par n’importe quelle étape du même job.
La roadmap 2026 attaque ces trois primitives. Mais la moitié des contre-mesures est déjà disponible.
Cartographier son exposition avant de durcir
Aucun durcissement n’a de sens sans inventaire. Quatre requêtes suffisent pour un premier état des lieux.
Les actions non épinglées par SHA :
# Toutes les références `uses:` qui ne pointent pas vers un commit de 40 caractères
rg --no-heading -g '.github/workflows/*.y*ml' -g '.github/actions/**' \
-o 'uses:\s*\K\S+' . \
| sort -u \
| grep -vE '@[0-9a-f]{40}$'
Les permissions par défaut du GITHUB_TOKEN, dépôt par dépôt :
gh api /orgs/$ORG/repos --paginate -q '.[].full_name' | while read -r repo; do
gh api "/repos/$repo/actions/permissions/workflow" \
-q "\"$repo\t\(.default_workflow_permissions)\t\(.can_approve_pull_request_reviews)\"" 2>/dev/null
done
Tout ce qui ressort en write est un token capable de pousser du code, de créer des releases et — si can_approve_pull_request_reviews est vrai — d’approuver ses propres PR.