Read the action's source, confirm it does not send secrets or repository content to unexpected hosts, pin it to a full length commit SHA taken from the original repository, and check who maintains it. GitHub's documentation says to audit the source code of any action you use, whatever the author's reputation.
Why this deserves 30 minutes
GitHub's secure use reference explains the exposure plainly. Jobs in a workflow can interact with each other, so a compromise of a single action can reach every secret configured on the repository, and may use the GITHUB_TOKEN to write to the repository. An action is code you run with your credentials.
The review, in order
1. Find out what kind of action it is
Open action.yml in the repository. A composite action is shell steps and other actions. A JavaScript action runs a bundled file. A Docker action runs an image. Each needs a different kind of reading.
2. Read where the data goes
Search the source for network calls, shell execution and anything touching environment variables or the workspace. GitHub's docs give the check to perform: secrets are not sent to unintended hosts and are not inadvertently logged.
For JavaScript actions, note that the file that runs is often a compiled bundle in a dist folder. Check that the bundle matches the source, or build it yourself and compare. A mismatch is a red flag.
3. Check the inputs it asks for
An action that wants a broad token or a cloud key for a job that should not need one deserves a question. Give it the narrowest permissions you can, using the job level permissions block.
4. Look at the people and the history
GitHub's docs call out the Verified creator badge on Marketplace as a useful signal, since it means GitHub verified the team's identity. They also warn that trusting the author is not enough, because a tag can be moved or deleted if an attacker gains access to the repository. Look at how many maintainers there are, how recently it was updated, and whether releases are signed or immutable.
5. Pin to a full commit SHA
GitHub says to pin to a full length commit SHA, which helps because an attacker would need a SHA-1 collision to substitute a backdoored version. Verify the SHA belongs to the action's repository and not to a fork. Add a comment with the version tag so reviewers can read it.
- uses: example-org/example-action@0123456789abcdef0123456789abcdef01234567 # v2.1.0
6. Plan updates
A pinned SHA never updates on its own. Let Dependabot propose updates, and review each one like a new action. See how to keep pinned actions up to date.
What an action's own dependencies add
An action is also a small supply chain. Its bundle may include dozens of packages. Check what it depends on before you adopt it, the same way you would review a library.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation show what a project pulls in, including packages inside code you build. It does not review action source for you, so keep the manual checks above.
Quick check
Is a popular action safe to use without review?
No. Popularity does not protect you from a compromised maintainer account or a moved tag. Pin and read it.
Is an action from the platform vendor exempt?
It is a lower risk, but still pin it and give it minimal permissions. Treat it like any dependency.
Sources
Last reviewed: 19 October 2026.
