Restricting the allowed actions in an organisation

Pinning an action by SHA guarantees it will not change. It says nothing about whether it should have been used in the first place. An organisation's actions policy answers that second question, upstream of any workflow review: it decides which third-party code may run in your pipelines.

What you will learn

Choose among the three policies offered at organisation level
Write an allow list with GitHub's exact syntax
Assess what the "verified creator" label is really worth
Combine that policy with SHA pinning, which answers a different question

The three available policies

The setting lives at organisation level, in the Actions settings. It has no repository-level equivalent: a personal account therefore has no access to this lever.

Policy	Effect
Allow everything	Workflows may use any public action
Disable everything	No workflow runs
Allow the organisation and a selection	The recommended default, refined by three checkboxes

The third option opens three checkboxes, which stack:

Allow actions created by GitHub, that is those of the actions and github organisations;
Allow Marketplace actions by verified creators, the ones GitHub has validated as partners;
Allow or block specified actions, which enables your own list.

The syntax of the allow list

The list expects patterns, separated by commas. The reference form includes the tag or the SHA:

OWNER/REPOSITORY@TAG-OR-SHA

For a reusable workflow, the file path is part of the pattern:

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

Wildcards widen the pattern, and the ! prefix removes something from the perimeter:

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

The last pattern illustrates the useful combination: allowing the whole organisation except one repository named explicitly.

Jumping straight to a restrictive list breaks pipelines whose exact composition nobody knows. First take a real inventory of the actions in use, then build the list from what actually runs.

# Every action referenced in a repository
grep -rhoE 'uses:\s*\S+' .github/workflows/ \
  | sed 's/uses:\s*//' | cut -d@ -f1 | sort -u

Extended to all your repositories, that inventory gives the starting list, and often reveals two or three dependencies nobody was owning.

What the "verified creator" label is worth

The "verified creators" checkbox is reassuring, and that is precisely what makes it a trap. It attests that GitHub has verified the partner's identity. It attests neither to the quality of the code, nor to the security of the publishing chain, nor to the fact that the account has not been compromised since.

The landmark compromises of the last two years did not target unknowns. tj-actions/changed-files was used by tens of thousands of repositories when its tags were rewritten to exfiltration code. Popularity, like verification, describes a reputation, not a guarantee.

The label stays useful as a coarse filter. It does not replace the three controls that matter: pinning by SHA, keeping an explicit allow list, and maintaining that list.

Three questions, three distinct controls

The most frequent confusion is believing that pinning makes the allow list redundant. They answer different questions, and none covers the other two.

Question	Control	What it does not say
Will this action change under my feet?	SHA pinning	Whether the author is trustworthy
Am I allowed to use this action?	Organisation policy	Whether the pinned version is sound
Does this version carry a known flaw?	Posture scanner	Whether the action is allowed at your place

A pipeline scanner materialises the second control in CI: it flags an action whose owner is neither GitHub, nor your organisation, nor on your list, even when it is correctly pinned by SHA. It is the finding that comes up most often on a never-audited open source repository, precisely because pinning gives the illusion the subject has been handled.

The case of a personal account

Without an organisation, the actions policy does not exist. The equivalent control then has to move into the CI, which is less solid, since a workflow can modify the workflow doing the checking, but stays far better than nothing:

fail the pipeline on any action outside a declared list, with a pipeline scanner configured that way;
protect .github/workflows/ with CODEOWNERS and a mandatory review, so adding an action goes through a human reading;
refuse in review any unknown action until its value is established.

The difference in nature is worth keeping in mind: an organisation policy prevents execution, a CI control reports it. The first is a door, the second an alarm.

Key points

The actions policy is configured at organisation level: it exists neither on an isolated repository nor on a personal account.
The recommended setting is "allow the organisation and a selection", refined by the three checkboxes: GitHub actions, verified creators, an explicit list.
The list expects OWNER/REPOSITORY@TAG-OR-SHA patterns, accepts wildcards, and the ! prefix to remove a repository from the perimeter.
Build the list from the real inventory of your workflows before restricting, otherwise you break pipelines whose composition nobody knows.
The "verified creator" label attests an identity, not a security posture: tj-actions/changed-files was popular when its tags were rewritten.
Pinning, authorisation and flaw detection answer three different questions; none makes the others useless.
Without an organisation, the control moves into the CI: it reports instead of preventing, which is still far preferable to no control at all.

Next steps

Runner groups and the network boundary: bounding what an allowed action can reach once it runs on your machines.
GitHub CLI (gh): the tool that inventories in one command the actions actually used across a set of repositories.
ACT: replaying a workflow locally to check that an action removed from the list was genuinely no longer needed.