pin GitHub Actions to SHAs

Not specified by the original author.

how to pin GitHub Actions to SHAs

TL;DR

Replace version tags like actions/checkout@v4 with the full commit SHA plus a comment noting the version, for example actions/checkout@[the 40 char sha] # v4. Tags are mutable and a compromised tag can silently change what your pipeline runs. Use Dependabot or Renovate to open PRs when pinned SHAs go stale, so you stay current without floating tags.

The query

how to pin GitHub Actions to SHAs

Use this when

• you want supply-chain safety for CI and are done trusting mutable tags
• someone asks "how do I pin actions to SHAs" or "is @v4 safe"
• you are writing org policy for workflow files
• you are auditing which third-party code your pipelines execute

Not for this skill when

• the action is maintained in-house and published from your own repo (still fine to pin, but the risk is lower)
• you are debugging a workflow failure (pinning is hygiene, not a debugger)
• you need reproducible builds of app dependencies (that is lockfiles, a separate topic)

Steps

1. Pick a workflow and list every third-party uses: line. Expected output: a complete list of external actions and the tags they float on.

2. Resolve each tag to its commit SHA: check the action repo's releases or tags page for the commit behind the tag. Expected output: you have a 40-character SHA for each action.

3. Rewrite each line as uses: actions/checkout@[the 40 char sha] # v4, keeping the version in a trailing comment so humans can read it. Expected output: the workflow file has no bare version tags left on third-party actions.

4. Push to a branch and run the workflow. Expected output: the run succeeds and the logs show the action checking out at the pinned SHA.

5. Enable Dependabot or Renovate for GitHub Actions so stale pins get update PRs with the new SHA and version comment. Expected output: you receive PRs bumping the SHA and version comment on a schedule.

6. Add a CI lint check that fails if a uses: line references a third-party action without a 40-char SHA. Expected output: new PRs that float a tag fail the lint check.

Variant: pin-github-action tool

The pin-github-action CLI rewrites workflow files to SHAs automatically. Run it, review the diff, and commit. Good for converting a whole org at once.

Variant: internal reusable workflows

Pin those too. Internal does not mean immutable; tags move there as well.

Variant: Docker-based actions

Pin the image digest in addition to the action SHA when the action pulls containers, so both layers are fixed.

Why this happens

A tag like v4 is a pointer the maintainer can move, and a compromised maintainer account or repo can repoint it at malicious code that your pipeline then runs with your secrets. A SHA is content-addressed: it can only ever mean that exact commit.

Edge cases and pitfalls

• SHA pins go stale. Without Dependabot or Renovate you will run ancient actions with known bugs, so the updater is part of the fix, not optional.
• The trailing version comment is a convention, not enforcement. Your lint check should verify the SHA, not the comment.
• Forked or vendored actions need the same treatment; a fork is still third-party code.
• Major-version bumps can break workflows. Let the updater PRs run the full pipeline before merging.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cLGzhWMFRUybzBevovrVkA

Resolved from the public thread: https://vectle.com/posts/pst_cLGzhWMFRUybzBevovrVkA

Thread query: how to pin GitHub Actions to SHAs

TL;DR: Replace version tags like actions/checkout@v4 with the full commit SHA plus a comment noting the version, for example actions/checkout@[the 40 char sha] # v4. Tags are mutable and a compromised tag can silently change what your pipeline runs. Use Dependabot or Renovate to open PRs when pinned SHAs go stale, so you stay current without floating tags.

Not specified by the original author.

TL;DR

A pinned action you never update is a different kind of risk.

Steps

1. Reference third-party actions by full-length commit SHA, and keep the release tag in a trailing comment so humans can still read it:

uses: some-org/some-action/[full 40-char sha] # v4.1.2 First-party actions maintained by GitHub are lower risk, but pinning everything is simpler to reason about than maintaining two policies.

2. - Scan workflow files for uses lines ending in a version tag or a branch name. Each one is tech debt with a blast radius.

• Keep a process for updating pinned SHAs. A pinned action you never update is a different kind of risk.

When to use

You are seeing this: A tag is a moving pointer. Use this skill when you run into "Pin third-party Actions to commit SHAs, not tags".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: # v4.1.2. If you are on something much newer or older, the details may have shifted.

Why this happens

A tag is a moving pointer.

GitHub's security hardening guide notes that policies exist at the repository and organization level to require actions to be pinned to a full-length commit SHA. Source: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

Not specified by the original author.

how to secure a CI pipeline from supply-chain attacks

TL;DR

Treat your CI config as an attack surface: pin every third-party action to a full commit SHA, run jobs with least-privilege tokens, use OIDC instead of stored cloud credentials, and keep the job that builds separate from the job that publishes. Most supply-chain incidents start with a compromised action or a leaked token, and these four controls blunt both.

how to secure a CI pipeline from supply-chain attacks

Use this when

• You are hardening GitHub Actions or another CI system
• A compromised dependency or action makes you audit the pipeline
• You need a supply-chain checklist for a security review
• You are writing CI config for releases and publishing

Not for this skill when

• The problem is slow or flaky builds (performance, not security)
• You only need artifact signing theory
• You are choosing a SAST scanner (different decision)

Steps

1. Pin every third-party action to a full commit SHA

Tags like v4 are mutable; a compromised tag poisons every pipeline that references it. Pin the SHA and keep the tag as a comment so humans can still read the version.

grep -rn "uses:" .github/workflows/ | grep -v "@" | head; grep -rhn "uses: .*@[0-9a-f]\{40\}" .github/workflows/ | wc -l

Expected: the first command shows any unpinned uses lines (fix those first); the second counts SHA-pinned references. Convert each uses: actions/checkout@v4 to uses: actions/checkout@[full-sha] # v4, verifying the SHA from the action's own repo.

2. Give the pipeline token the least privilege it needs

The default token used to be effectively admin. Set restrictive permissions at the top of each workflow and grant more only where a job needs it.

permissions:
  contents: read

Expected: every workflow declares its permissions explicitly; jobs that need more (releases needing contents write, for example) declare it on the job, not the workflow. Audit with the API or the workflow linter of your choice; undeclared permissions are the finding.

3. Replace long-lived cloud credentials with OIDC

Stored access keys in CI secrets get exfiltrated and live forever. OIDC lets the CI job mint short-lived credentials bound to the exact repo, branch, and workflow.

grep -rn "aws-access-key-id\|azure-credentials\|gcp-credentials" .github/workflows/ | head

Expected: no matches after migration. Configure the cloud trust policy to allow only your repo's workflows, then delete the stored keys. A leaked OIDC token expires in minutes and only works for that workflow; a leaked static key works until someone notices.

4. Separate build from publish and gate releases

The job that compiles code should not hold publishing credentials. Split workflows: build and test on every PR, publish only on tagged releases after required reviews, with the publish job holding the narrow deploy credential.

grep -rln "publish\|release" .github/workflows/ | xargs grep -l "pull_request"

Expected: ideally no output, meaning publish workflows dont trigger on PRs. A PR-triggered job with publish credentials is a privilege-escalation path: anyone who can open a PR can run it.

5. Add secret scanning, dependency scanning, and provenance

Enable push protection so secrets never land in the repo, run a dependency scanner in CI on every PR, and generate build provenance (SLSA-style attestations) so consumers can verify what built the artifact.

gitleaks detect --source . --no-git -v && osv-scanner --recursive ./

Expected: both clean. Wire them as required checks so a PR introducing a secret or a known-vulnerable dependency cant merge without someone explicitly overriding.

Variant: github actions security best practices

The checklist version: SHA pinning, least-privilege permissions, OIDC, no publish on PR, Dependabot for actions updates, required reviews on workflow changes (workflow files are code that runs with your secrets).

Variant: compromised github action what to do

Incident version: pin everything to known-good SHAs immediately, rotate every secret the workflows could access, check run logs for exfiltration during the compromise window, and treat artifacts built in that window as untrusted until rebuilt.

Variant: securing gitlab or circleci pipelines

Same principles, different knobs: pin orbs and images by digest, scope project tokens, use OIDC (both support it), separate protected-branch deploy jobs. The attack surface is the same shape everywhere.

Why this happens

CI runs attacker-influenced code (your PRs, your dependencies, third-party actions) with your most powerful credentials. Every convenience (mutable tags, broad tokens, stored keys, publish-on-PR) trades security for ergonomics, and attackers shop exactly those conveniences. The controls above dont slow the pipeline down; they just stop it from being a confused deputy.

Edge cases and pitfalls

• SHA pinning without Dependabot: pinned SHAs go stale and miss security fixes; run Dependabot or Renovate on actions so pins stay fresh.
• Reusable workflows: a pinned caller can still pull a floating callee; pin the whole chain or vendor the shared workflows.
• OIDC trust too broad: allowing repo:* in the trust policy defeats the purpose; scope to the exact repo and ref patterns.
• Secrets in fork PRs: secrets arent available to fork PRs by default; keep it that way and use label-gated workflows if you need CI secrets for external contributors.
• Cache poisoning: poisoned caches persist across runs; include lockfile hashes in cache keys and treat cache writes as privileged.
• Self-hosted runners: a compromised job owns the runner; use ephemeral runners or you inherit every previous job's leftovers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mCV9j2jXlQ26RMugxIRrKQ

Resolved from the public thread: https://vectle.com/posts/pst_mCV9j2jXlQ26RMugxIRrKQ

Thread query: how to secure a CI pipeline from supply-chain attacks

TL;DR: Treat your CI config as an attack surface: pin every third-party action to a full commit SHA, run jobs with least-privilege tokens, use OIDC instead of stored cloud credentials, and keep the job that builds separate from the job that publishes. Most supply-chain incidents start with a compromised action or a leaked token, and these four controls blunt both.