Supply Chain

GitHub Actions workflows depend on third-party actions referenced by uses:. If these actions are not pinned to immutable references (full commit SHAs), attackers can compromise them via tag mutation, account takeover, or fork-and-replace attacks.

Policy: pin third-party actions and reusable workflows to a full 40-character commit SHA. Do not require SHA pins for first-party GitHub actions (actions/*, github/*) on version tags, or for same-repo / vendored actions.

What Counts As Third-Party

When org ownership is unclear, treat non-actions/* / non-github/* / non-local refs as third-party.

Pinning: Tags vs. SHAs

Reportable: Unpinned Third-Party Tags

Tags are mutable Git references. The maintainer (or attacker with write access) can delete and recreate a tag pointing to a different commit. When the tag is updated, every workflow using that tag runs the new code.

Safe: Third-Party SHA Pinning

SHAs are immutable — once a commit exists, its SHA cannot change. Pin third-party actions to the full 40-character SHA and add a comment with the version for readability.

Do Not Report: First-Party Version Tags

First-party actions/* and github/* on version tags are not findings by themselves. Same-repo or vendored actions are not third-party supply-chain findings (they can still be unsafe if loaded from a PR-controlled checkout — that is a pwn-request / trust-crossing issue, not pinning).

Attack Vectors

Tag Mutation Attack

1. Attacker compromises a popular third-party action’s repository (phishing, leaked credentials, insider)
2. Deletes the v1 tag
3. Creates a new v1 tag pointing to a malicious commit
4. Every workflow using @v1 now runs the attacker’s code

This is not theoretical — CVE-2025-30066 (tj-actions/changed-files) and related incidents showed tag rewrites can leak secrets at scale.

Account Takeover / Org Compromise

If a third-party action author’s GitHub account is compromised:

• All actions under that account can be backdoored
• Version tags can be silently updated
• Users won’t notice unless they’re pinned to SHAs

Fork-and-Replace

1. Original action author deletes their repository
2. Attacker creates a fork with the same owner/repo name
3. Existing workflows that reference owner/repo@tag now pull from the attacker’s fork

Actions That curl | bash at Runtime

Some actions download and execute external scripts at runtime:

Even if you pin the action to a SHA, the external URL can change. The action itself is immutable, but its runtime dependencies are not. Report this for third-party actions in privileged jobs; do not use it as a reason to demand SHA pins on first-party GitHub actions.

Detection Patterns

Do not treat every non-SHA uses: as a finding. Filter to third-party first, then assess job privilege.

When To Report

Report mutable third-party actions only when job privilege makes compromise security-relevant.

Risk Assessment by Third-Party Source

Use this only after the ref is classified third-party and the job is privileged enough to report:

The Fix: SHA Pin Third-Party Actions

Automated Pinning

Tools that can pin and update third-party action SHAs:

• Dependabot — GitHub native, updates action SHAs
• Renovate — Can pin and update actions
• StepSecurity Secure Workflows — Can pin actions to SHAs (configure to match third-party-only policy if you do not want first-party pins)

Vendoring Critical Actions

For high-security workflows, vendor the third-party action locally:

Severity Guidelines

Exploitation Scenario Template

References

• GitHub Docs: Security hardening — Using third-party actions (opens in a new tab)
• GitHub Blog: Four tips to keep your GitHub Actions workflows secure (opens in a new tab)