A GitHub Action Tag Can Move—Pin the Commit Before It Reads Your Secrets

Secure third-party GitHub Actions in this order: inventory every external action and reusable workflow, replace mutable references with verified full commit SHAs, enforce which dependencies may run, and reduce the credentials available to each job. GitHub’s secure-use reference says a full-length commit SHA is currently the only immutable way to consume an action and warns that a compromised action may access secrets or use the GITHUB_TOKEN.

Pinning prevents a moved tag from silently changing the code your workflow executes. It does not make that code trustworthy or harmless: you must verify the pinned commit, limit permitted actions, grant minimum token permissions, keep secrets away from jobs that do not need them, and route every update through review.

1. Inventory every executable dependency

Search .github/workflows for every uses: declaration. Include step-level actions, job-level reusable workflows and locally maintained composite actions; a local action can contain further external uses: references that are easy to miss.

For each dependency, record the workflow file, job, upstream owner and repository, current reference, and credentials available to the job. Classify the reference as a full SHA, tag such as @v4, branch such as @main, or local path beginning with ./.

Review the highest-impact jobs first: publishing, releases, deployments, signing and any job with write access, repository secrets or cloud credentials. This makes the audit about reachable authority, not simply the number of action references.

2. Resolve the release to an upstream commit

Open the intended release or tag in the action’s upstream repository, not a fork or a copied recommendation. Follow it to the associated commit in the same owner/repository namespace, inspect the changes and action definition, and copy the full commit identifier only after the revision matches the release you intended to approve.

Replace owner/action@v3 with owner/action@FULL_COMMIT_SHA. Keep the release label in a same-line comment such as # v3.2.1; the runner remains bound to the immutable object while reviewers retain readable version context. A Marketplace verification badge identifies a publisher, but it does not make the publisher’s tags immutable.

The consequence is not theoretical. The OpenSSF account of the reviewdog and tj-actions attacks describes redirected version tags, malicious code that scanned runner memory, and secrets written to workflow logs. It recommends full-SHA pins, restricted action usage and fine-grained permissions as complementary controls.

3. Enforce the boundary after converting workflows

Once existing references are pinned, open Settings → Actions → General and permit only the actions and reusable workflows the repository needs. Prefer specific owners and repositories—or exact revisions for especially sensitive dependencies—over a blanket allowance for Marketplace code.

Enable Require actions to be pinned to a full-length commit SHA where the applicable repository, organization or enterprise policy exposes it. GitHub’s repository settings documentation says the rule covers third-party, organization-owned and GitHub-authored actions, but reusable workflows may still be referenced by tags. Audit reusable-workflow references separately and pin them in workflow code even though this checkbox does not require it.

An organization-only policy also blocks GitHub-authored actions such as actions/checkout unless they are allowed. Test the completed policy on a representative repository before wider enforcement so missing dependencies surface during rollout rather than during a release.

4. Reduce what executed code can reach

Set a restrictive workflow baseline, commonly permissions: contents: read, and elevate individual scopes only in the job that needs them. Do not give test or metadata jobs package publication, pull-request write or repository-content write access because a later release job requires it.

Separate build, test and deployment when doing so keeps credentials away from third-party code. Pass narrowly defined artifacts between jobs instead of exposing publishing secrets across the workflow, and attach environment secrets only to the protected deployment job that consumes them.

For supported cloud providers, replace stored access keys with GitHub OIDC federation. Grant id-token: write only to the deployment job and constrain the provider-side trust policy to the expected repository and, as appropriate, its branch, tag, environment or reusable-workflow identity. OIDC removes a persistent cloud key from GitHub secrets, but an overly broad trust rule can still issue a powerful short-lived credential.

Review repository, organization and environment secrets after restructuring. Remove unused values, protect high-impact environments with required review, and rotate any credential that may have appeared in workflow logs.

5. Keep immutable references maintainable

Configure Dependabot version updates for the github-actions ecosystem at directory /. It can open pull requests that move a pinned reference to a newer commit and preserve a same-line version comment, so immutability does not require manual monitoring of every upstream release.

Treat those pull requests as proposals, not proof. Confirm that the new SHA resolves in the expected upstream repository and corresponds to the intended release; then inspect its release notes, commit diff and action definition. Require designated review for changes under .github/workflows and for the dependency-update configuration itself.

Finish with an auditable validation pass: no external action or reusable workflow remains on a branch or tag; every SHA resolves in the expected upstream repository; an unapproved action is rejected; and each job receives only its required token scopes and secrets. Confirm that cloud deployments use constrained OIDC trust and that automated update pull requests still arrive. The workflow can then change through visible review without letting an upstream tag move replace the code already approved.

Also read:

• EU Action Plan on AI and Cybersecurity: Objectives and Key Actions
• How to Back Up Google Authenticator Before You Lose or Replace Your Phone
• Four Blog CTAs That Move Readers Forward Without Blocking the Article