When external actions are not pinned, the pipeline can silently consume changed code the next time it runs, even if the action name looks unchanged. That creates supply chain risk, because a compromised or modified action can execute inside a trusted workflow, access secrets, and influence builds or deployments before teams notice the change.
What actually changes when a third-party action is not pinned?
An unpinned action is a moving dependency, not a fixed artifact. If the upstream maintainer, repository, tag, or release target changes, your workflow may run different code on the next execution without any visible change in the pipeline definition. That breaks reproducibility and makes review, rollback, and incident investigation much harder.
In practice, the trust boundary shifts from “the code we reviewed” to “whatever that external reference resolves to today.” For CI/CD, that matters because the action often runs with access to build context, repository contents, deployment credentials, and other sensitive material.
Pinning to a commit SHA makes the dependency immutable for that workflow version, so teams can reason about exactly which code executed. It also creates a stable audit trail for change review and forensics when a build behaves unexpectedly.
Why unpinned actions create supply chain exposure
Third-party actions sit inside a trusted automation path, so a compromised action can turn normal pipeline execution into code execution inside your delivery system. That is why supply chain frameworks treat build integrity and provenance as first-class controls; for example, SLSA focuses on making artifact and build provenance verifiable, while NIST Cybersecurity Framework 2.0 supports governance over external dependencies and change control.
When an action changes silently, the immediate risk is not just build failure. The deeper problem is that the workflow may continue to succeed while executing altered logic, exfiltrating secrets, modifying build outputs, or weakening deployment integrity. In other words, the pipeline can remain green while the trust assumption has already been broken.
Pinning is therefore a control for both integrity and blast-radius reduction. If a release artifact or deployment step depends on a specific action version, a SHA pin prevents a tag rewrite or repository compromise from automatically propagating into every subsequent run.
What practitioners should verify before they trust a pipeline
Start by inventorying every third-party action in the workflow and checking whether each one is pinned to a commit SHA rather than a mutable tag. Then confirm whether the action is used in steps that can read secrets, publish artifacts, or deploy to production. Those are the places where an unpinned dependency becomes materially dangerous fastest.
For operational hardening, compare the workflow against the broader CI/CD security model in CI/CD Pipeline Identity Security Guide, and review the failure pattern shown in GitHub Action tj-actions Supply Chain Attack, where a compromised action exposed CI/CD secrets at scale. Those examples show why “trusted workflow” does not mean “trusted upstream dependency.”
If the action is unavoidable, treat the SHA pin as the baseline, not the final control. Review the action’s permissions, isolate high-trust jobs, and make secret exposure conditional on the minimum necessary job scope. If you cannot explain why a workflow step needs broad access, it probably has too much.
Risk and Threat Considerations
An unpinned action creates a moving attack surface because the referenced code can change outside your change-control process. A malicious maintainer action, tag hijack, or upstream compromise can turn routine pipeline execution into secret theft, build tampering, or unauthorized deployment activity.
Failure mechanism: The workflow resolves a mutable reference, such as a tag or branch, and later executes altered code with the same trusted name. That lets an attacker or compromised upstream project inherit the pipeline’s privileges without changing the workflow file.
Impact: Teams can lose repository secrets, produce poisoned builds, or ship manipulated artifacts before the change is noticed. The result is supply chain compromise with delayed detection and a much harder rollback path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity and provenance | Pinned actions support build provenance and reproducible pipeline inputs. |
| Recommendation — Pin dependencies and verify provenance for every build step. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | Mutable third-party actions are supply-chain dependencies that require governance and change control. |
| Recommendation — Inventory third-party actions and control upstream change risk. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | CI/CD workflow actions are application delivery components that need secure dependency handling. |
| Recommendation — Require pinned, reviewed build dependencies in delivery pipelines. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Pinned actions strengthen software supply-chain architecture and repeatable execution. |
| Recommendation — Design pipeline steps so external code execution is explicit and fixed. | ||
Practitioner Guidance
What to prioritise: Pin every third-party action to a commit SHA first, then review the jobs that touch secrets, signing, or deployment. Those are the highest-consequence steps if the action is replaced upstream.
What to verify: Confirm that the SHA actually corresponds to the reviewed action version, and that branch protection or release practices prevent silent ref updates from being treated as “the same” dependency.
Common mistake: Treating version tags as stable enough for security-sensitive workflows. Tags are convenient for maintainability, but they do not provide the immutability needed for trustworthy automation.
Practitioner takeaway: The goal is not to ban third-party actions, but to make every trusted automation dependency explicit, immutable, and reviewable so a pipeline cannot inherit surprise code changes.
Related resources from NHI Mgmt Group
- What is the difference between pinning CI/CD actions by commit SHA and trusting mutable tags in supply chains?
- What happens when CI/CD pipelines rely on untrusted third-party tools, actions, or libraries?
- Who is accountable for securing CI/CD workflows that depend on third-party actions?
- What happens when AI agents are built outside the SDLC and CI/CD pipeline without extra controls?
