Layer 1 — Pin Actions to SHAs

This is the runtime enforcement layer. Once enabled, any workflow run that references an action by tag (rather than a full-length commit SHA) fails before it executes.

No audit or evaluate mode

Unlike rulesets (Layer 3), the Actions policy is a single on/off checkbox. The moment you save, every unpinned workflow across every repo starts failing. There is no dry-run, no “would-have-blocked” insights view, and no gradual rollout knob.

Use static analysis as your audit proxy before enabling this: count unpinned-uses findings across all repos, fix them with auto-fix PRs, then flip the switch. The rollout plan sequences this correctly — Layer 1 comes last, after the bulk of repos are remediated.

Why SHA pinning

A tag like @v4 is a moving pointer. If an action’s maintainer account is compromised, an attacker can repoint that tag at malicious code and every workflow using @v4 picks it up on the next run. A full-length commit SHA is immutable — it pins the exact tree you reviewed.

Configuration

1. Navigate to Organization → Settings → Actions → General (or the enterprise-level equivalent under Policies → Actions).
2. Under Policies, choose Allow select actions and reusable workflows — the recommended posture.
3. Tick Require actions to be pinned to a full-length commit SHA.
4. In the allowlist, enable:
   • Allow actions created by GitHub
   • Allow Marketplace actions by verified creators
   • Explicit allowlist entries for trusted non-verified actions you depend on
5. Click Save.

Allowlist examples

The allowlist supports wildcards:

actions/*
github/*
docker/*
softprops/action-gh-release@*
hashicorp/setup-terraform@*
azure/login@*
your-org/*

To block a specific compromised version, prefix the entry with !:

!some-owner/some-action@v35

Caveats

• Reusable workflows are exempt — only uses: for actions is enforced, not reusable-workflow references. If you want those pinned too, cover them with a static-analysis rule.
• Local actions are exempt — ./path/to/action and ./.github/actions/x are not subject to the policy (but they are still audited by static analysis).
• The full dependency tree is validated — including sub-actions inside the actions you call. Expect a few surprise failures from popular actions that haven’t pinned their own dependencies. File upstream issues or temporarily allowlist by SHA.
• The policy overrides lower scopes — an enterprise-level setting cannot be relaxed by org or repo owners.

The error you’ll see

When an unpinned action is used after enablement:

Error: The action example/some-action@v1 is not allowed in your-org/your-repo
because all actions must be pinned to a full-length commit SHA.

Rollback

If enablement causes widespread breakage, this layer can be disabled instantly by un-ticking Require actions to be pinned to a full-length commit SHA. Workflows resume on the next run. Use this as an escape valve while you triage — but don’t leave it off; the protection only works when enabled.