Fork it when the action touches secrets, deploys, or signs releases and the upstream is small or slow to change. A fork freezes what you reviewed and removes the dependency on someone else's account. It also makes you the maintainer of a copy, so plan the sync work before you start.
What a fork buys you
A third-party action runs inside your job with access to whatever the job has. GitHub's guidance describes the risk as significant because a single compromised action can reach secrets and the repository token. If you point workflows at a copy in your own organization, three things improve.
- The code is under your access controls. Only people you choose can push to it or move its tags.
- Upstream changes arrive when you decide, not when the maintainer publishes.
- A rename or deletion upstream does not break your pipeline, because the action's address is yours. GitHub does not redirect calls to a renamed action repository, so this is a real reliability gain.
What a fork does not buy you
A fork is a copy of whatever was in the upstream when you made it. If that code was already unsafe, you now host unsafe code under your own name. Review before forking, not after.
A fork also does not stop the action from calling out to other places. If the action downloads a script or pulls a container image at run time, your copy does the same. Read the action's entry point and any nested references, and pin those too.
Finally, your fork needs the same hygiene as any repository: protected branches, protected tags, two-factor authentication for people with write access, and limited admin rights.
Fork or pin: a decision table
| Situation | Better choice |
|---|---|
| Action runs in jobs with deploy or signing credentials | Fork, or vendor the code into a repository you own |
| Action is a small helper in a job with read-only token | Pin to a full SHA and review updates |
| Upstream is unmaintained or has one maintainer | Fork |
| Upstream is active and well reviewed | Pin and update through pull requests |
| You need to change behavior | Fork, and keep the change small |
How to run a fork responsibly
- Review the upstream code at the commit you are forking, and write down what you checked.
- Fork into an organization, not a personal account, so access is managed centrally.
- Reference your fork from workflows by full commit SHA. GitHub's guidance is to confirm the SHA comes from the action's own repository and not an unrelated fork, so use your own fork's SHA and keep it in your organization's allow list.
- Turn on branch and tag protection so release tags on the fork cannot be moved without review.
- Sync on a schedule. When upstream publishes a release, read the diff, merge, and bump your SHA in a pull request.
- Track the fork in your inventory with its upstream source, so an advisory against the upstream can be matched to your copy.
Step 6 is the one teams skip. A fork does not receive upstream fixes automatically, and an advisory published against the original will not mention your copy.
The cost to be honest about
Each fork is a small ongoing job. Ten forks that no one syncs become ten stale copies of old code. If you cannot commit to syncing, a pinned reference to the upstream with reviewed updates is often a more honest arrangement.
For the related decision about references, see pin GitHub Actions to a SHA or a tag.
Quick check
Does forking protect me from a malicious upstream release?
Yes, as long as you do not sync without reading the diff. Your fork only changes when you merge.
Should I fork every action I use?
No. Prioritize actions in jobs that hold deploy, signing, or write credentials. Pinning plus reviewed updates is enough for low-risk helpers.
Sources
Last reviewed: 19 October 2026.
