Reviewing Third Party Actions Before Using

uses: actions/checkout@... is easy to trust — it’s published by GitHub itself, in a repository GitHub controls. Most of the actions you’ll want in a real pipeline aren’t. They’re written by individual maintainers, small teams, or companies you’ve never heard of, and uses: will run their code inside your workflow with just as much access as anything GitHub wrote. Before you add a third-party action to a workflow, it’s worth spending few minutes actually looking at what you’re about to trust.

Star Count Tells You Almost Nothing

It’s tempting to treat a high star count as a proxy for safety — surely thousands of people wouldn’t use something dangerous. But stars measure popularity, not security. An action can accumulate stars for being useful and convenient while nobody who starred it ever read the source. Popularity also doesn’t protect you from an action that was safe when it was popular and got compromised later — a maintainer’s account taking over, a dependency getting poisoned, ownership quietly changing hands. None of that shows up as a drop in stars.

Use star count, if at all, as one weak signal among several — evidence that an action isn’t completely obscure, not evidence that it’s safe.

What Actually Tells You Something

Read the source, or at least skim it. Most actions fall into one of two implementation styles, and both are worth a quick look:

• Composite actions are just YAML wrapping a sequence of shell commands — genuinely quick to read end to end. Look for anything that reaches outside the repo it’s operating on: network calls to unfamiliar domains, anything piping a downloaded script straight into bash, or commands that read environment variables you wouldn’t expect an action to need.
• JavaScript or Docker actions package compiled or bundled code, which is slower to audit properly. At minimum, check the repository’s action.yml to see what inputs it takes and skim src/ if one exists, rather than trusting the dist bundle blindly.

Check for a verified-creator badge. On GitHub Marketplace, actions published by an organization GitHub has verified as a partner display a verified badge next to the listing. It doesn’t mean GitHub has audited the action’s code — GitHub explicitly does not inspect third-party action code — but it does confirm the publisher is who they claim to be, which rules out one entire category of risk: a convincing impersonation of a well-known org.

Look at maintenance activity, not just existence. A repository with commits from last week and issues getting responses is a different risk profile from one that hasn’t been touched in two years, even if both currently “work.” An abandoned action isn’t dangerous by itself, but it also isn’t getting security fixes if something is found — and its unused package name becomes a target if anyone ever deletes and re-registers it.

Check what permissions it’s actually asking for. This is the single most concrete thing to look at, and it connects directly back to the chapter where we talked about permission’s model. An action’s own documentation, or its action.yml, will usually tell you what it needs — a token, specific repo scopes, credentials for a third-party service. Compare that against what the action’s actual job is. A changelog-generator action that wants write access to your repository’s packages, or a linting action that wants access to secrets, is a mismatch worth stopping on. Sometimes it’s a legitimate need you hadn’t considered; sometimes it’s a sign the action does more than its README says.

A Quick Mental Checklist

Before adding a new third-party action to a workflow, it’s worth running through:

• Does the repo belong to who I think it belongs to, or does the verified-creator badge confirm it?
• Is it actively maintained — recent commits, responded-to issues?
• Does what it asks for (permissions, tokens, secrets) match what it does?
• If it’s a composite action, have I actually read the shell commands it runs?
• If it’s JS or Docker-based, have I at least looked at what inputs it consumes and where they go?

None of these checks are absolute proof of safety — a careful review can still miss something, and a popular, well-maintained action can still be compromised tomorrow. That’s exactly why SHA pinning matters as a complement to this, not a substitute for it: reviewing an action tells you it’s trustworthy right now; pinning it to a commit makes sure that trust doesn’t silently expire the next time your workflow runs.