Triaging Action Uses Imposter Commit

You received an Action Uses Imposter Commit detection. The workflow references a GitHub Action by a commit SHA that does not exist on the action repository's default branch or on any other branch. This is a known supply-chain attack pattern, but a small number of legitimate release workflows produce the same signal. Use this runbook to decide which case you have.

How it's detected

For each third-party action pinned by SHA, StepSecurity queries the GitHub API to check whether the pinned commit is reachable from the default branch, then paginates every other branch in the action's repository. Annotated tags are resolved to their target commit before the check. If the SHA is not reachable from any branch, the action's commit is flagged.

Triage

Likely a compromise (true positive)

The workflow uses some-org/some-action@<sha> where <sha> exists only as a dangling commit, not on the default branch and not on any other branch in the action's repository. This is the pattern used in the March 2025 tj-actions/changed-files compromise: the v1 through v45 tags were silently repointed to an attacker-pushed commit that lived on a fork of the action repo and was never merged into the upstream repository.

If you see this pattern:

• Treat any workflow run that used the action as a potential compromise.

• Rotate every secret the affected workflows had access to, including GITHUB_TOKEN.

• Audit recent commits, branches, issues, and releases for unauthorized changes made during the affected runs.

• Pin the action to a verified commit on the action's default branch, or remove it.

• Check the Threat Center for related advisories.

Likely benign (false positive)

Some maintainers ship releases by creating a short-lived branch at the release commit, pointing the tag at that commit, then deleting the branch. The release commit is no longer reachable from any branch, so the detection fires even though the release was legitimate.

Before treating the detection as benign, verify all of the following:

• The action is from a maintainer you trust and the repository looks healthy.

• The tag and commit were published through the maintainer's normal release process.

• The commit's contents match what you would expect for that release (compare against the previous release diff).

• No advisories exist for the action or its maintainer.

If all checks pass, suppress the detection with the reason "Legitimate release on deleted branch." Where possible, repin to a commit that is reachable from the action's default branch.

Next steps

• If confirmed compromise: rotate secrets, audit downstream activity, and follow your incident response process. Resolve the detection once remediation is complete.

• If false positive: suppress per How to Suppress a Detection.

• If uncertain: escalate to your security team with the action reference, pinned SHA, and workflow run URL.