In this article

Pinning an action to a full commit SHA fixes the action revision you reference, but it does not prove the action is safe or that everything it downloads is immutable. Pair revision pinning with source verification, permission review and a tested update process.

GitHub's secure-use reference and SHA-pinning policy announcement, checked October 8, 2026, describe the control. This is a workflow-maintenance guide, not a claim that we audited a specific third-party action.

Inventory references before replacing them#

List direct uses entries, local/composite actions, reusable workflows and scripts that download tools. Record each owner, repository, human-readable release, resolved immutable reference, permissions and runtime downloads.

Do not stop at the visible setup action. It may invoke nested actions or download a mutable SDK, script or binary. Those inputs need their own provenance assessment.

Resolve the revision from the correct source#

Use the action's official repository and release information to identify the full commit corresponding to the version you intend. Verify the repository ownership and the code at that revision.

Keep a readable version comment beside a pin so maintainers understand the intended release. A schematic example is:

yaml
# Schematic only: replace with a verified full commit, not this placeholder.
uses: owner/action@VERIFIED_FULL_COMMIT_SHA

This placeholder is not runnable workflow configuration. Do not paste a random SHA from a search result or infer that any 40-character string is the intended release.

Review what the action can do#

Inspect required inputs, job permissions, secret handling and executable code. Compare the permission request with the job's real purpose. A pinned action with an unnecessarily powerful token can still perform an unnecessarily powerful action.

GitHub's security guidance treats immutable references as one part of secure use. Pinning prevents a reference from silently following a moved tag; it does not remove vulnerabilities already present in the pinned revision.

Maintain the pins rather than freezing them forever#

Choose an update owner and review trigger. Updates may be routine dependency maintenance or responses to an advisory. For each proposed change, record the old and new revision, release notes, relevant code change and tests run.

Use a controlled non-production workflow to verify the affected operations before allowing the new revision to perform a production release. A successful lint step does not validate a changed signing or upload action.

Do not claim an advisory is resolved solely because the tag label changed. Verify that the selected commit contains the intended corrective version.

Check policy scope separately#

GitHub announced organization and repository policy support for blocking actions and requiring full-SHA pins. The announcement distinguishes action enforcement from reusable-workflow references. Read the current settings and applicable documentation before claiming a policy covers every reference type.

Document exclusions and runtime downloads in the inventory rather than hiding them behind a “fully pinned” badge.

Leave an auditable maintenance record#

A useful record states which revisions are fixed, which downloaded tools remain mutable, who reviewed access and when updates are due. It should support a real incident investigation.

Our AI-generated code review checklist helps review automated pin updates: verify repository identity and behavior, not only a bot's confident description or a shorter diff.