GitHub Actions Security Best Practices

GitHub Actions Security Is About Workflow Trust, Not Just YAML Style

GitHub Actions is powerful because it can build, test, sign, deploy, label, comment, publish, and assume cloud roles. That same power is what makes it dangerous when workflows are written casually.

The tj-actions/changed-files compromise and a long history of pull_request_target misuse both showed that pipeline trust assumptions can fail quietly and then fail everywhere at once.

1. Treat Pull Requests From Forks as Untrusted Input

This should be the default mental model.

Do not:

• run privileged deploy logic on forked code
• expose secrets to workflows that execute untrusted repository content
• use pull_request_target carelessly with checked-out head code

If a workflow needs repository write access, environment secrets, or cloud roles, it should be tightly scoped to trusted events.

2. Never Interpolate Untrusted Values Directly Into Shell Commands

PR titles, branch names, issue bodies, and comments are user-controlled input.

Safer pattern:

- name: Safe use of PR title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "$PR_TITLE"

Unsafe pattern:

- run: echo "${{ github.event.pull_request.title }}"

That difference matters.

3. Minimize Permissions at Workflow and Job Level

Use the least GitHub token privilege needed.

permissions:
  contents: read

Then add narrower permissions only where justified. The workflow should not begin with broad write access out of habit.

4. Use OIDC Instead of Stored Cloud Keys

Prefer:

• GitHub OIDC to AWS, Azure, or GCP
• branch and environment conditions in cloud trust policy
• short-lived credentials scoped to specific workflows

This removes one of the most common failure modes: long-lived deployment keys sitting in repository or organization secrets.

5. Pin Third-Party Actions to Immutable References

Do not trust floating tags for security-sensitive workflows.

Use commit SHAs for third-party actions and review dependency updates on a schedule.

6. Separate Build, Test, and Deploy Authority

The same workflow job should not casually do everything.

Better pattern:

• build and test jobs run with minimal permissions
• deployment jobs require branch conditions and environment approvals
• production secrets only appear in the final stage that actually needs them

7. Isolate Runners and Artifacts

If you use self-hosted runners, isolate by trust level and clean aggressively. Persistent runners are comfortable until they are not.

Also verify:

• artifact retention settings
• who can download artifacts
• whether deployment consumes only signed or expected artifacts

8. Monitor Workflow and Permission Changes

High-value events to watch:

• workflow file creation or modification
• permission increases
• environment approval bypass attempts
• new third-party actions introduced in sensitive workflows

GitHub Actions Hardening Checklist

• forked PRs treated as untrusted
• no direct interpolation of user-controlled input into shell commands
• permissions minimized by default
• OIDC used for cloud auth
• third-party actions pinned to commit SHA
• privileged deploy steps separated from test steps
• self-hosted runners isolated or ephemeral
• workflow changes monitored

Further Reading

• GitHub Security Hardening for GitHub Actions
• GitHub OpenID Connect Documentation
• GitHub Events That Trigger Workflows
• CISA Defending CI/CD Environments

Related SecureCodeReviews guides:

• GitHub Actions Security: Script Injection and Secret Leaks
• How to Secure a CI/CD Pipeline Step-by-Step
• How to Prevent Supply Chain Attacks in CI/CD

Well-hardened GitHub Actions workflows do not assume good intent from untrusted input, and they do not hand out deployment power just because a job technically could use it.