Contexte et motivation

Les workflows GitHub Actions sont récupérés depuis des dépôts Git. Historiquement, la recommandation était de épingler chaque action à son SHA complet plutôt qu’à un tag, car les tags peuvent être déplacés et exposer la chaîne d'approvisionnement à des attaques. L’article cite un workflow ancien où actions/checkout était référencé par le SHA 3d3c42e5aac5ba805825da76410c181273ba90b1 et j178/prek-action par 44924fe9ef4a6f88253c4b6b1bf11c689d3ce53d. Cette pratique, bien que sécurisée, reste lourde à maintenir.

Mise en œuvre du lockfile

GitHub propose désormais un format de lockfile dédié. L’extension gh-actions-lock s’installe via la CLI : 

gh extension install github/gh-actions-lock
Après exécution de gh actions-lock, le workflow est converti pour n’utiliser que des tags versionnés (actions/checkout@v7.0.1, j178/prek-action@v3.1.0) et un fichier .github/workflows/actions.lock est généré. Le lockfile, version v0.0.3, répertorie chaque action avec son ref, le commit correspondant, ainsi que les identifiants owner_id et repo_id. Ces métadonnées permettent de vérifier l’intégrité du code exécuté.

Intégration CI et vérification

Renovate et Dependabot comprennent déjà le format lockfile, de sorte que les mises à jour automatiques synchronisent également le fichier actions.lock. Le guide propose d’ajouter un job dédié à la validation : il utilise un runner ubuntu-slim, installe l’extension avec le flag --pin v0.4.1 et lance gh actions-lock --verify. En cas de désynchronisation entre le workflow et le lockfile, le job échoue, signalant une éventuelle altération.

Limites et bonnes pratiques

Le verrouillage ne supprime pas la nécessité de mettre à jour les versions majeures ; il faut régulièrement réexécuter gh actions-lock pour refléter les nouvelles releases. De plus, l’article rappelle l’usage de zizmor, un linter de sécurité qui, depuis la version v1.32.0, supporte les lockfiles. Intégrer zizmor via .pre-commit-config.yaml ajoute une couche de contrôle supplémentaire. Enfin, le processus exige de committer le lockfile et de le pousser, sinon les pipelines CI ne pourront pas le valider.