Pin GitHub Actions to commit SHAs, in your browser
Paste a workflow. Get it back with every action pinned, every token grant audited and a receipt for each pin. The file never leaves this tab.
- Never uploaded
- No account
- Free
Your workflow · example
0 lines0 bytes
Certified copy
Checking your workflow…
The checker loads once, then runs on every edit. On a slow connection the first check can take a few seconds.
Nothing to install, nothing to grant
Other ways to pin and audit actions are good at what they do. Anchorflow is the one that needs no install, no account and no access to your repository, and shows its working for every pin.
Where your workflow is processedAnchorflow: In your browser tab
- CLI pinners
- On your machine
- Hosted hardening services
- On the service's servers
- Workflow linters
- On your machine or in CI
- Update bots
- In your repository
Before the first resultAnchorflow: Paste. No install, no account
- CLI pinners
- Install a binary
- Hosted hardening services
- Sign in or paste into their app
- Workflow linters
- Install and configure
- Update bots
- Install an app or add config
Pins tags to commit SHAsAnchorflow: Yes, on request
- CLI pinners
- Yes
- Hosted hardening services
- Yes
- Workflow linters
- Flag unpinned actions; most don't rewrite
- Update bots
- Keep existing pins up to date
Audits token permissions and injectionAnchorflow: Yes, offline
- CLI pinners
- No
- Hosted hardening services
- Usually permissions
- Workflow linters
- Yes
- Update bots
- No
Shows how each pin was resolvedAnchorflow: API hops and a git ls-remote line
- CLI pinners
- Not usually
- Hosted hardening services
- Not usually
- Workflow linters
- Not applicable
- Update bots
- In the pull request
Many repositories at onceAnchorflow: No, one file at a time
- CLI pinners
- Yes
- Hosted hardening services
- Yes
- Workflow linters
- Yes
- Update bots
- Yes
For every repository at once, or on a schedule, a CLI pinner in CI or an update bot is the better fit. Anchorflow is for the one workflow in front of you, when you want a reviewable change and the reasons behind it, without installing or granting anything.
Pin every action to an immutable commit
A tag is a pointer that can move; a commit SHA cannot. Anchorflow resolves owner/repo@ref to the commit the ref points at today and rewrites the uses value, appending the original ref as a trailing comment — the exact format GitHub and Dependabot read themselves.
# before — a tag that can move under you - uses: actions/checkout@v4 # after — the commit v4 points at today, with the honest label kept - uses: actions/checkout@11daba688012890e563df9f370a5fbd0c62c5f8 # v4 # ^ 40-hex commit ^ GitHub/Dependabot pin format
Questions engineers ask
Privacy, pinning, Dependabot, permissions, injection and rate limits.
Does my workflow leave my browser?
No. Parsing, the audits, the rewrite and the diff run in a Web Worker inside your tab, and there is no Anchorflow server that could receive the file. When you press Resolve & pin, your browser sends read-only, unauthenticated requests to api.github.com that name only the public owner/repo and ref of each action, never the workflow itself. Until you press it, nothing leaves the page.
Why pin actions to a commit SHA instead of a tag?
A tag is a pointer that anyone with push access to the action's repository can move. If @v4 is re-pointed at malicious code, your next run executes it without any change on your side. A full 40-character commit SHA cannot be moved, so the code that runs is the code you reviewed. Anchorflow keeps the original tag as a trailing comment (uses: owner/repo@<sha> # v4), the format Dependabot and Renovate read to keep proposing updates.
Will Dependabot still update pinned actions?
Yes. Dependabot's github-actions ecosystem updates SHA-pinned actions and reads the version comment after the SHA. Anchorflow writes exactly that shape, so a pinned workflow keeps receiving update pull requests.
What is a moving ref?
A ref that is expected to change: a branch (main, master, develop), HEAD, latest, or a bare major such as @v4 that maintainers move with every release. A dotted version such as @v4.2.0 is a fixed point by convention, but it is still a tag and can be re-pointed, so Anchorflow lists it as not pinned rather than as safe.
What does the permissions audit check?
It lists the GITHUB_TOKEN grant for every job, from the top-level permissions block and the job's own block, and flags write-all, permissions left unset (the token then gets the repository default), write scopes on jobs whose steps only read, and id-token: write with nothing that uses OIDC.
How does it find template injection?
GitHub expands ${{ }} expressions before a step runs, so a pull request title, branch name or issue body interpolated into run, with or if becomes code the attacker wrote. Anchorflow tokenises each expression and flags untrusted github.event fields wherever they appear. The fix is always the same: pass the value through env and read it as $VAR.
What happens when GitHub rate-limits me?
GitHub allows 60 unauthenticated API requests per hour per IP address; the limit belongs to your network, not to Anchorflow. Anchorflow keeps a small reserve, stops before spending it, marks the remaining refs as not looked up, and shows when the window resets. Everything already found stays on screen.
Is a pinned SHA proof that the action is safe?
No. Pinning guarantees the code will not change under you; it says nothing about whether that code was safe in the first place. Each pin carries a receipt with the API call that produced it and a git ls-remote command you can run to check it yourself, and you should still review the actions you depend on.