GitHub Actions security check

Why CI workflows are a target

A CI workflow runs with your repository's credentials, an access grant that can often write to the repository, and access to whatever your pipelines deploy to. That makes it one of the most valuable places to attack. Several real supply-chain incidents started with a compromised GitHub Action or a workflow that ran untrusted code, and the mistakes behind them are easy to spot once you know the patterns.

What this check looks for

• Actions not pinned to a commit SHA (GA001). A tag like @v4 can be moved to different code. Pin third-party actions to the full commit SHA.
• pull_request_target or workflow_run running pull request code (GA002). These triggers run with repository credentials and write access. Checking out and building the pull request's code in them lets anyone who opens a pull request run code with those credentials.
• Script injection (GA003). Putting an issue title, pull request body or branch name directly inside a run step lets an attacker inject shell commands through that text.
• Workflow permissions (GA004). Without a permissions block, the workflow's built-in credential may have write access. Start every workflow by granting read-only access to contents.
• Credentials passed to unpinned third-party actions (GA005), curl piped to a shell (GA006), self-hosted runners on pull requests (GA007), jobs without a timeout (GA008), checkout leaving its credential on disk (GA009), passing every credential to a reusable workflow (GA010) and unsafe workflow commands (GA011).

The safe pattern for untrusted input

Never put event data inside the script itself. Map it to an environment variable in the step's env block, then refer to that variable, quoted, in the shell. The shell then treats the text as data, not as commands.

Pinning without the pain

Pinning to SHAs sounds like a maintenance burden, but Dependabot and Renovate both update pinned SHAs and keep the version comment in sync. Keep first-party actions from actions/ and github/ pinned too if your policy requires it; this check reports them as low risk because GitHub controls them.

A hardening checklist

• Read-only contents permission at the top of every workflow, with more granted per job only where needed.
• Every third-party action pinned to a commit SHA.
• No event data inside run steps or github-script; pass it through env.
• pull_request for building contributions; pull_request_target only for labelling or commenting, never with a checkout of the pull request.
• timeout-minutes on every job.
• persist-credentials set to false on checkout unless a later step pushes.
• Credentials passed explicitly to reusable workflows, one by one.

This check reads one workflow at a time and doesn't see your repository settings, branch protections or organisation policies. It complements tools such as OpenSSF Scorecard and zizmor, which can scan a whole repository.