Yes. A third party action runs inside your job with access to the job's secrets and token. GitHub's documentation says a compromised action can reach all secrets configured on the repository. Treat each action as a dependency: pick them carefully, pin them, limit token permissions and review changes.
What an action can touch
When a workflow uses an action, the code runs on the runner as part of your job. GitHub's secure use reference says a compromised action could access all secrets configured on your repository, and may be able to use the pipeline token to write to the repository. It also notes there is significant risk in sourcing actions from third party repositories.
That makes an action more privileged than most libraries. A library runs in your application. An action runs where your credentials are.
Four ways an action becomes an entry point
- The action's repository is taken over, or its maintainer account is compromised.
- A tag you reference is moved to a new commit.
- The action pulls in its own dependencies, which change.
- A lookalike action name is used by mistake.
What GitHub recommends
GitHub's documentation describes these controls.
- Pin to a full length commit SHA. It describes this as the way to use an action as an immutable release, and says that mitigating a backdoor then requires generating a SHA-1 collision for a valid Git object. Verify the SHA comes from the action's own repository and not a fork.
- Pin to a tag only if you trust the creator. The Verified creator badge on Marketplace is a useful signal, because it indicates the action was written by a team whose identity GitHub has verified.
- Use a lockfile for workflow dependencies where available. GitHub says a lockfile records the exact commit for every action, including transitive dependencies, and verifies source repository identity at run time, which it calls the strongest protection.
- Restrict token permissions, and set the default to read only for repository contents.
Our guide on pinning actions by SHA or tag covers the trade-offs.
A review habit
- List every action your workflows use, including those inside reusable workflows.
- Mark which ones run in jobs with secrets.
- Replace any action you could do with a short script in your own repository.
- Review updates to pinned actions as you would any dependency update.
- Remove actions you no longer use.
Quick triage
| Question | If yes |
|---|---|
| Does the job hold publish or deploy secrets? | Pin by SHA and review every update |
| Is the action from an unverified creator? | Prefer an alternative or fork and review it |
| Is the action unmaintained? | Replace it |
Where Safeguard fits
Safeguard's asset discovery and dependency scanning can help you see where pipelines and their dependencies live, and policies can enforce review rules before a workflow change merges.
Quick check
Is pinning to a tag enough?
Only if you trust the creator, because a tag can be moved. A full commit SHA is more stable.
Do official actions need the same care?
Apply the same permission limits. Review depth can scale with trust and with the secrets in the job.
Sources
Last reviewed: 19 October 2026.
