How to Harden GitHub Actions: Proven Security Practices for Safer CI/CD

Why Secure GitHub Actions

GitHub Actions is now a core part of CI/CD pipelines, but recent supply‑chain attacks (e.g., hijacked rss actions) show that insecure workflows expose repositories to unauthorized access, privilege escalation, and malicious code injection.

Fundamental Concepts

Actions : reusable automation units (build, test, deploy, etc.)

Workflows : YAML files that define which actions run and when

Events : triggers such as push, pull_request, or scheduled runs

Jobs : individual tasks within a workflow, runnable in parallel or sequentially

Runners : machines that execute jobs

Hardening these components reduces the overall attack surface.

Priority Hardening Steps

1. Set Default Token Permissions to Read‑Only

If a repository was created before 2023, GITHUB_TOKEN may still have write access. Change the default to read‑only unless write access is explicitly required.

2. Restrict Action Sources to Trusted Channels

Use only official GitHub‑maintained actions (e.g., actions/checkout)

Select verified Marketplace publishers

Maintain a whitelist of custom trusted actions

Limiting sources prevents malicious third‑party actions from being introduced.

3. Disable Workflow Creation or PR Approval

Turn off the “Allow GitHub Actions to create and approve pull requests” option to stop automated processes from bypassing code review.

4. Strengthen Branch‑Protection Rules

Automatically revoke old approvals after a new push

Require independent review by someone other than the committer

These rules help prevent PR hijacking and post‑commit malicious code insertion.

5. Proper Secret Management

GitHub supports three secret scopes:

Repository‑level (most common)

Organization‑level (shared CI keys)

Environment‑level (fine‑grained, requires approval)

Best practices:

Pass secrets only within a single step to avoid global exposure

Never bundle all secrets into a JSON object (e.g., toJson(secrets))

Avoid using secrets: inherit in reusable workflows

Prefer OIDC (OpenID Connect) over long‑lived static tokens

6. Write Secure Workflows

At the top of each workflow file declare explicit permissions: permissions: {} Then grant the minimal required permissions per job.

Pin actions to a specific commit SHA instead of a tag:

uses: actions/checkout@3d7e7fa6d5f6b1e14e9a4c97f3e829f8a92c6a3d

Avoid third‑party actions unless they are thoroughly vetted. Evaluate code complexity, contributor count, community activity, and whether the action provides a version‑locking mechanism.

Never inject user‑controlled variables directly into shell commands. Example of a vulnerable step:

run: curl https://example.com/${{ github.event.issue.title }}

Instead, sanitize inputs or avoid dynamic concatenation.

Limit the use of GITHUB_ENV and GITHUB_PATH to trusted jobs only, and always validate inputs before setting environment variables.

7. Guard Against Poisoned Pipeline Execution (PPE)

High‑risk triggers such as pull_request_target and workflow_run execute with repository permissions and can expose secrets. Never allow code from forked repositories to run in a high‑privilege context.

8. Self‑Hosted Runner Security

Enable self‑hosted runners only when necessary and never for public repositories. Recommended practices:

Prefer ephemeral runners

Isolate runners based on trust level (public vs internal projects)

Log and continuously monitor runner activity

Restrict outbound network access to trusted destinations

If possible, use GitHub‑hosted runners, which have stronger default security.

9. Consolidated Recommendations

Pin all actions to a SHA hash; avoid tags or latest versions

Set GITHUB_TOKEN to read‑only and declare minimal permissions per job

Replace long‑lived credentials with OIDC for zero‑trust secret handling

Avoid high‑risk triggers like pull_request_target Sanitize or isolate all user‑provided inputs

Regularly audit security policy reports and branch‑protection settings

Treat the CI system as critical production infrastructure

10. Recommended Security Tools

zizmor : scans workflow files for security risks

gato / gato‑x : simulates attacker behavior to test workflow resilience

Allstar : official GitHub app that enforces organization‑level security policies