Safeguard
Supply Chain•

How do you limit which GitHub Actions your organization can run?

Set an allowlist of actions and reusable workflows, block specific ones with a bang prefix, and require full commit SHA pinning. Steps and wildcard rules.

Safeguard Security Team
3 min read

In organization settings under Actions, General, choose a policy that allows only your own and selected actions, list the approved ones, and enable the option to require pinning to a full length commit SHA. Entries use owner, repository and tag or SHA, support wildcards, and a leading exclamation mark blocks an entry.

The policy choices

GitHub's documentation lists these options under Policies:

  • Disable Actions entirely, or allow it on selected repositories.
  • Allow your organization's actions plus selected others.
  • Allow only actions and reusable workflows within your organization, which also blocks GitHub authored ones such as checkout.

With the select option you can add actions created by GitHub, Marketplace actions from verified creators, and specified entries, up to 1,000 of them.

Writing the allowlist

Entries take the form owner slash repository at tag or SHA, and reusable workflows add a path and file name. A star is a wildcard and entries are comma separated. A leading exclamation mark blocks, so a star followed by a blocked entry allows everything except that action.

Only listed entries run unless you include a broad pattern. Workflows covered by a dependency lockfile are checked by locked commit SHA, so a tag based entry such as a version tag will not match. Use a wildcard or the full SHA.

Require SHA pinning

Tick the option to require actions to be pinned to a full length commit SHA. It applies to organization actions and GitHub authored actions. Reusable workflows can still be referenced by tag. Dependencies in a lockfile satisfy the requirement without editing workflow files.

Why bother: a tag is a movable label. A commit hash is a fixed address. If a maintainer account is compromised and a tag is repointed, pinned workflows keep running the code you reviewed.

Roll it out without breaking builds

  1. Inventory the actions used across your repositories.
  2. Decide which are approved and note an owner for each.
  3. Turn on the allowlist in a staging organization or a few repositories first.
  4. Pin to SHAs with a reviewable automated pull request, and let a dependency update tool keep them fresh.
  5. Enable the organization wide setting and watch the failed runs for a week.

Pair it with a restricted default token. New organizations start with read access for contents and packages only, and creating or approving pull requests from Actions is off by default.

Where Safeguard fits

Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Open the inventory demo and see how a list of what you depend on is built; your actions allowlist is the same list for pipelines.

Click through it at your own pace, or open it full screen.

Quick check

Does SHA pinning apply to reusable workflows?

GitHub says reusable workflows can still be referenced by tag.

How many entries can the allowlist hold?

Up to 1,000 specified actions and reusable workflows.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.