In March 2025 a widely used GitHub Action had its tags repointed at code that wrote CI secrets into build logs. Every pipeline referencing it by tag picked up the new code on its next run, without anyone changing a workflow file. Pipelines referencing a commit SHA were unaffected. That is the whole argument for pinning, and it is why the advice to pin GitHub Actions to SHA is now close to universal.
What that advice almost never mentions is what to do on the other providers, where it is shaped differently and in one case cannot be followed at all. The wider frame for controls a pipeline enforces is in the guide to CI/CD security, and the wider supply-chain picture including provenance and SBOMs is in supply chain security in CI/CD. What follows is pinning specifically, on each provider.
A tag is a pointer somebody else owns
When a workflow says uses: owner/repo@v4, it is asking for whatever v4 currently points at. Tags and branches are movable labels, and the person who can move them is the maintainer of that repository, not you. A commit SHA is content-addressed, so it cannot be repointed by anyone.
The exposure is larger than it first appears because of what a CI job holds. The action runs inside your pipeline with your registry credentials, your deploy tokens, and whatever else the job has access to. Compromising one popular action reaches every repository that references it by tag, which is why this keeps being the attack of choice rather than a theoretical risk.
How common unpinned references actually are
A 2026 scan of 50,012 of the most-starred repositories on GitHub found that 19,005 of them, roughly two in five, referenced at least one third-party action by a mutable tag. Unpinned references made up 74.5% of every CI/CD finding in that sample, which makes this the single most common pipeline security gap those researchers found.
Read those two numbers carefully, because they answer different questions. The 74.5% is a share of findings, not of repositories: one repository with many unpinned references produces many findings. The number that describes how many teams are affected is the 38%. And the sample is most-starred public repositories, which skews towards large, actively maintained projects. Private estates are unmeasured.
Pin GitHub Actions to SHA, and what that means exactly
On GitHub Actions an immutable reference is a full 40-character commit SHA. Nothing shorter qualifies: not @v4, not @v4.1.2, not a branch. A release tag looks specific and is still a label the maintainer can move.
First-party actions under actions/ and github/ are usually treated as out of scope, on the reasoning that if GitHub is compromised then pinning its own actions is not your first problem. That is a defensible trade rather than a rule, and a team with a stricter threat model can pin those too.
GitHub added organisation policy in August 2025 that can require actions to be pinned, which moves this from a convention people forget to a setting that enforces itself. That is the single highest-leverage change available on this provider, and it is worth doing before any remediation sweep.
The same idea on GitLab CI
GitLab pulls in reusable pipeline units through its include mechanism rather than a uses key, so the surface is the include block. Components and cross-project includes both take a ref, and that ref can be a commit SHA in exactly the way a GitHub action reference can.
The translation is clean here. Different vocabulary, same control: find the third-party units the pipeline pulls in, check whether the ref is immutable, replace it if not. A team moving between the two providers can carry the habit across without changing how they think about it.
On CircleCI the advice cannot be followed
CircleCI reuse happens through orbs, and orbs are not git references. They are versioned packages published to a registry, so there is no commit to pin to. The strongest available reference is a full three-part version such as 5.1.2. Everything shorter is mutable: @5 and @5.0 resolve to the newest matching release, and volatile and dev references can be republished at will.
This matters more than a footnote. A team that takes the standard advice as a checklist item will record a permanent gap on CircleCI with no available fix, and either chase it or learn to ignore the check. Neither is useful. The correct target on CircleCI is the full version, understood as a weaker control than a SHA rather than an equivalent one: a published version is not supposed to change, but the guarantee is a registry policy rather than a property of the reference itself.
Bitbucket Pipelines, Azure DevOps and Jenkins do not have an equivalent third-party reuse mechanism in the same sense, so there is nothing for this particular control to check. That is worth stating plainly rather than implying coverage that does not exist. Those providers have supply-chain exposure through other paths, container base images most obviously, and those are different controls.
What pinning does not fix
Pinning fixes which code runs. It does not fix what that code fetches while running. An action pinned to a SHA can still pull a container image on a floating tag, call a nested action by version tag, or install packages without a lockfile. Palo Alto Networks found in 2023 that 32% of the top 1,000 Marketplace actions were unpinnable in this sense, meaning pinning them closes the outer door and leaves an inner one open.
That figure is from 2023 and may well have moved. The structural point does not age: a reference can only be as immutable as the things it pulls. Treat pinning as removing the largest and most easily exploited path rather than as closing the category, and prefer actions whose own dependencies are pinned when there is a choice between two that do the same job.
Keeping pinned references current
The objection to pinning is that a SHA is opaque and freezes you on an old version. Both halves are answered by the same thing: let a dependency bot manage it. Renovate and Dependabot both understand SHA-pinned action references, will raise the bump when the upstream releases, and can write the new SHA with the human-readable version alongside it as a comment.
That turns pinning from a one-off sweep that decays into a maintained state. Without it, pinning is worse than useless over a long enough window, because a frozen action stops receiving the security fixes that were the reason to trust it. The goal is immutable references that move deliberately, not references that never move.
Where CI/CD Watch fits
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, detects third-party units referenced by mutable refs and reports them per repository. The per-provider differences above are not a framing device: the detection has to encode them, because a rule that assumes GitHub semantics produces false findings on GitLab and meaningless ones on CircleCI.
The finding names what is unpinned and where. Whether to fix it, and whether a full orb version is an acceptable ceiling for a given repository, stays a judgement for the team that owns the pipeline. How each control is detected is covered in the security insights docs.
Where to start
On GitHub, turn on the organisation policy first so the problem stops growing, then sweep existing workflows. On GitLab, check the include blocks. On CircleCI, move every orb to a full three-part version and record that as the ceiling rather than as a partial failure. Then wire up a dependency bot, because a pinned reference nobody updates becomes its own risk.
To see which repositories are affected across a mixed estate, connect a provider and run an audit. The finding arrives per repository with the offending reference named, which is the form that makes a sweep tractable rather than a grep across every workflow file you own.
CI/CD Watch is built by 3CS Technologies Ltd, a UK consultancy that has run pipeline audits across regulated programmes and now runs the same engine inside the SaaS platform. The per-provider asymmetry in CI/CD security is the kind of thing you only hit once you are monitoring more than one provider.