Restreindre les actions autorisées dans une organisation

Épingler une action par SHA garantit qu'elle ne changera pas. Cela ne dit rien de savoir si elle aurait dû être utilisée. La politique d'actions d'une organisation répond à cette seconde question, en amont de toute revue de workflow : elle décide quel code tiers a le droit de s'exécuter dans vos pipelines.

Ce que vous allez apprendre

• Choisir parmi les trois politiques proposées au niveau organisation
• Écrire une liste d'autorisation avec la syntaxe exacte de GitHub
• Évaluer ce que vaut réellement le label « créateur vérifié »
• Articuler cette politique avec l'épinglage par SHA, qui répond à une autre question

Les trois politiques disponibles

Le réglage se trouve au niveau de l'organisation, dans les paramètres Actions. Il n'a pas d'équivalent au niveau du dépôt : un compte personnel ne dispose donc pas de ce levier.

Politique	Effet
Tout autoriser	Les workflows peuvent utiliser toute action publique
Tout désactiver	Aucun workflow ne s'exécute
Autoriser l'organisation et une sélection	Le défaut recommandé, affiné par trois cases

Glissez pour voir

La troisième option ouvre trois cases à cocher, qui se cumulent :

• Autoriser les actions créées par GitHub, c'est-à-dire celles des organisations actions et github ;
• Autoriser les actions Marketplace de créateurs vérifiés, ceux que GitHub a validés comme partenaires ;
• Autoriser ou bloquer des actions spécifiées, qui active votre propre liste.

La syntaxe de la liste d'autorisation

La liste attend des motifs, séparés par des virgules. La forme de référence inclut le tag ou le SHA :

OWNER/REPOSITORY@TAG-OR-SHA

Pour un workflow réutilisable, le chemin du fichier fait partie du motif :

OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA

Les jokers élargissent le motif, et le préfixe ! retire du périmètre :

actions/*,
github/*,
mon-org/*,
docker/setup-buildx-action@*,
docker/login-action@*,
aquasecurity/trivy-action@*,
sigstore/cosign-installer@*,
step-security/harden-runner@*,
mon-org/*, !mon-org/action-experimentale@*

Le dernier motif illustre la combinaison utile : autoriser toute l'organisation sauf un dépôt nommément écarté.

Commencer par observer, pas par bloquer

Passer directement à une liste restrictive casse des pipelines dont personne ne connaît la composition exacte. Relevez d'abord l'inventaire réel des actions utilisées, puis construisez la liste à partir de ce qui tourne vraiment.

# Toutes les actions référencées dans un dépôt
grep -rhoE 'uses:\s*\S+' .github/workflows/ \
  | sed 's/uses:\s*//' | cut -d@ -f1 | sort -u

Étendu à tous vos dépôts, cet inventaire donne la liste de départ, et révèle souvent deux ou trois dépendances que personne n'assumait.

Ce que vaut le label « créateur vérifié »

La case « créateurs vérifiés » rassure, et c'est précisément ce qui la rend piégeuse. Elle atteste que GitHub a vérifié l'identité du partenaire. Elle n'atteste ni de la qualité du code, ni de la sécurité de la chaîne de publication, ni du fait que le compte n'a pas été compromis depuis.

Les compromissions marquantes de ces deux dernières années n'ont pas visé des inconnus. tj-actions/changed-files était utilisée par des dizaines de milliers de dépôts quand ses tags ont été réécrits vers du code d'exfiltration. La popularité, comme la vérification, décrit une réputation, pas une garantie.

Le label reste utile comme filtre grossier. Il ne remplace pas les trois contrôles qui comptent : épingler par SHA, tenir une liste d'autorisation explicite, et maintenir cette liste.

Trois questions, trois contrôles distincts

La confusion la plus fréquente consiste à croire que l'épinglage rend la liste d'autorisation superflue. Ce sont des réponses à des questions différentes, et aucune ne couvre les deux autres.

Question	Contrôle	Ce qu'il ne dit pas
Cette action va-t-elle changer sous mes pieds ?	Épinglage par SHA	Si l'auteur est digne de confiance
Ai-je le droit d'utiliser cette action ?	Politique d'organisation	Si la version épinglée est saine
Cette version porte-t-elle une faille connue ?	Scanner de posture	Si l'action est autorisée chez vous

Glissez pour voir

Un scanner de pipelines matérialise d'ailleurs le deuxième contrôle dans la CI : il signale une action dont le propriétaire n'est ni GitHub, ni votre organisation, ni sur votre liste, même lorsqu'elle est correctement épinglée par SHA. C'est le contrôle qui remonte le plus souvent sur un dépôt open source jamais audité, précisément parce que l'épinglage donne l'illusion d'avoir traité le sujet.

Le cas du compte personnel

Sans organisation, la politique d'actions n'existe pas. Le contrôle équivalent doit alors se déplacer dans la CI, ce qui est moins solide, puisqu'un workflow peut modifier le workflow qui contrôle, mais reste très supérieur à rien :

• faire échouer le pipeline sur toute action hors d'une liste déclarée, avec un scanner de pipelines configuré en ce sens ;
• protéger .github/workflows/ par CODEOWNERS et une revue obligatoire, pour que l'ajout d'une action passe par une relecture ;
• refuser en revue toute action inconnue tant que son intérêt n'est pas établi.

La différence de nature est à garder en tête : une politique d'organisation empêche l'exécution, un contrôle de CI la signale. La première est une porte, la seconde une alarme.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• La politique d'actions se règle au niveau organisation : elle n'existe ni sur un dépôt isolé, ni sur un compte personnel.
• Le réglage recommandé est « autoriser l'organisation et une sélection », affiné par les trois cases : actions GitHub, créateurs vérifiés, liste explicite.
• La liste attend des motifs OWNER/REPOSITORY@TAG-OR-SHA, accepte les jokers, et le préfixe ! pour retirer un dépôt du périmètre.
• Construisez la liste depuis l'inventaire réel de vos workflows avant de restreindre, sinon vous cassez des pipelines dont personne ne connaît la composition.
• Le label « créateur vérifié » atteste une identité, pas une sécurité : tj-actions/changed-files était populaire quand ses tags ont été réécrits.
• Épinglage, autorisation et détection de failles répondent à trois questions différentes ; aucun ne rend les autres inutiles.
• Sans organisation, le contrôle se déplace dans la CI : il signale au lieu d'empêcher, ce qui reste nettement préférable à l'absence de contrôle.

Pour aller plus loin

• GitHub CLI (gh) : L'outil qui permet d'inventorier en une commande les actions réellement utilisées sur un parc de dépôts.
• ACT : Rejouer un workflow en local pour vérifier qu'une action retirée de la liste n'était effectivement plus nécessaire.
• ActionLint : Le linter qui valide les références d'actions avant qu'une politique ne les refuse en exécution.

×

📖 Voir la documentation →