Find every use of the action, stop it running, rotate any secret it could reach, then replace it with a pinned safe version through bulk pull requests. If workflows call a shared template, you can cut exposure in one change. Speed depends on the inventory you built beforehand.
Hour 0 to 1: contain
- Confirm the advisory from the maintainer or a reputable source.
- Search all repos for the action name. A code search on
uses:and the action name works, and so does your own workflow inventory. - If an org setting restricts allowed actions, remove the action from the allow list. GitHub documents an allow and block list with wildcards, up to 1,000 entries, so this stops new runs quickly.
Blocking is blunt but fast. Expect some pipelines to fail, and tell teams why.
Hour 1 to 4: assess exposure
Check which workflows ran the affected version in the exposure window. Look at what each had access to: repository secrets, environment secrets, cloud credentials, the token and its permissions. A job with a read only token and no secrets has little to lose. A deploy job with cloud keys does not.
If you moved to OIDC, there are fewer stored keys to rotate, and tokens are short lived. The GitHub hardening guide recommends OIDC so you can stop storing long lived credentials.
Hour 4 to 8: rotate
Rotate any secret that was available to a run using the action. Start with deploy credentials and package publishing tokens. Review audit logs for unusual use. Record each rotation, because auditors and customers may ask.
Hour 8 to 16: replace
Write a script that edits workflows to remove the action or pin it to a verified safe SHA, and opens a pull request in each repo. If you use a shared workflow, fix it there and release a patch tag. A bot can bump callers.
Hour 16 to 24: verify and review
Confirm there are no remaining references. Re-enable the allow list entry only for the safe version if needed. Write a short review: how you found out, how long exposure lasted, what slowed you down.
Prepare before it happens
| Preparation | Benefit |
|---|---|
| Workflow and action inventory | Instant search |
| SHA pinning required | Moving tags cannot silently change code |
| Read only default token | Smaller blast radius |
| OIDC instead of stored keys | Less to rotate |
| Shared templates | One place to fix |
See also org level Actions defaults.
Quick check
Is pinning to a SHA enough to be safe?
It stops a tag being moved under you, but you still need to verify the SHA is the right code from the right repository, not a fork.
Should we block the action first or investigate first?
Block first if the advisory is credible, then investigate. You can unblock later.
Safeguard provides asset discovery, SBOM and dependency scanning that help you answer where a component is used, and supports a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Security hardening for GitHub Actions, fetched 19 October 2026
- GitHub Docs: Disabling or limiting GitHub Actions for your organization, fetched 19 October 2026
Last reviewed: 19 October 2026.
