Securing GitHub Actions for SOC 2: CI/CD Pipeline Controls That Auditors Check

GitHub Actions and SOC 2 CC8

GitHub Actions is the CI/CD execution layer for most GitHub-based teams. SOC 2 CC8 (Change Management) requires that changes to production systems go through a controlled process: code review, testing, and deployment via a reproducible pipeline.

Auditors look at GitHub Actions for: how production deployments are triggered and by whom, whether secrets (cloud credentials) are properly protected, whether third-party actions in the pipeline could be compromised, and whether workflow changes themselves require review.

A compromised GitHub Actions workflow can exfiltrate secrets, deploy malicious code, or alter infrastructure. Supply chain attacks via malicious third-party actions are a growing threat. These controls mitigate the most common attack vectors.

OIDC authentication for cloud access

GitHub Actions supports OIDC (OpenID Connect) token exchange with AWS, GCP, and Azure. Instead of storing cloud credentials as GitHub secrets, the workflow requests a short-lived token from the cloud provider by presenting a GitHub JWT. The token is valid for the duration of the job only.

AWS OIDC setup: create an IAM OIDC provider for `token.actions.githubusercontent.com`, create an IAM role with a trust policy that allows assumption from your specific GitHub org/repo, and use the `aws-actions/configure-aws-credentials` action with `role-to-assume`. No AWS_ACCESS_KEY_ID secret needed.

Pin the aws-actions/configure-aws-credentials action to a commit SHA: `uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6542489bd537173696a1f884a`. This prevents a compromised version of the action from being substituted if the tag is moved.

Pinning action versions to commit SHAs

Mutable tags (@v3, @main) can be moved by the action author to point to different code. If a popular action is compromised (as happened with tj-actions/changed-files in 2025), any workflow using the mutable tag runs the malicious code on the next execution.

Pin every third-party action to a full 40-character commit SHA. Use Dependabot to keep pinned SHAs up to date: configure `.github/dependabot.yml` with `package-ecosystem: github-actions` to receive automated PRs when action maintainers publish new versions.

Use StepSecurity Harden-Runner or OpenSSF Scorecards to audit your workflows for unpinned actions. The Scorecard `Pinned-Dependencies` check will flag any mutable references and provide the correct pinned SHA.

Workflow permission restrictions

Set the default GITHUB_TOKEN permissions to read-only at the organisation level (Settings > Actions > Workflow permissions > Read repository contents). Then grant specific permissions at the workflow or job level as needed.

In each workflow file, set `permissions: {}` (no permissions) at the top level, then grant only what is needed per job: `permissions: contents: write` for a job that creates a release, `permissions: id-token: write` for a job that uses OIDC.

Audit permissions with the `gh workflow view` command or by reading workflow YAML. Any job with `permissions: write-all` is a red flag — it means the job can push to any branch, create releases, and modify repository settings using the GITHUB_TOKEN.

Required reviewers for workflow changes

Workflow files in `.github/workflows/` are code that runs in your CI/CD pipeline. A malicious change to a workflow file can exfiltrate secrets or modify production deployments. Require the same review rigour as application code.

Add `.github/workflows/` to a CODEOWNERS file: `/.github/workflows/ @your-org/security-team`. This requires approval from the security team on any PR that touches workflow files, in addition to normal code reviewers.

Use GitHub branch protection rules on the default branch: enable "Require a pull request before merging", set minimum approvals to 2, and enable "Dismiss stale pull request approvals when new commits are pushed". This prevents approval bypass via force push.

Secret scanning and push protection

Enable GitHub Advanced Security (GHAS) Secret Scanning on all repositories. Secret Scanning detects over 200 secret patterns (AWS keys, GitHub tokens, Stripe keys, etc.) in commits and alerts the repository admin. For private repositories, this requires a GHAS licence.

Enable Push Protection to block pushes that contain detected secrets before they reach the remote. Developers see a block message at push time and must either remove the secret or mark it as a false positive with a justification.

Configure secret scanning alerts to route to your security Slack channel or ticketing system via GitHub webhooks. Track mean-time-to-remediation for secret scanning alerts as a security metric. Include this metric in your quarterly security review.

GitHub Actions SOC 2 checklist

Before your audit: (1) OIDC federation configured for AWS/GCP/Azure — no long-lived cloud credentials in GitHub secrets. (2) All third-party actions pinned to commit SHAs. (3) Dependabot configured for github-actions ecosystem. (4) Default GITHUB_TOKEN permissions set to read-only. (5) Workflow-level permissions: {} with per-job grants. (6) CODEOWNERS requires security team review for .github/workflows/ changes. (7) Branch protection with minimum 2 approvals enabled. (8) Secret Scanning and Push Protection enabled on all in-scope repositories.

Evidence to collect: CODEOWNERS file, branch protection settings screenshot, Dependabot configuration, a sample workflow showing pinned SHA references, and GitHub Secret Scanning alerts dashboard (showing zero or resolved alerts).