The GITHUB_TOKEN: default permissions, least privilege, and why read-all is a footgun

What the token is, and where its scope comes from

When you see a supply-chain incident in CI, the first question is always: what could that compromised code actually do? The answer lives entirely in the token scope — so it’s worth knowing exactly how that scope is determined before you write your first permissions: block.

At the start of every job, GitHub mints a fresh installation access token and exposes it as secrets.GITHUB_TOKEN (and github.token). It is scoped to the running repository, and it expires when the job finishes — at most after the job’s run, never persisted. That expiry is the good news. The bad news is its breadth. The token has a set of permission scopes — contents, pull-requests, issues, packages, actions, id-token, and more — each independently read, write, or none.

Where do those scopes default? Two layers. Historically, repositories were created with the permissive default: the token got read/write on most scopes (contents: write, issues: write, pull-requests: write, …). GitHub later let orgs flip the org/repo setting to the restricted default (contents: read, everything else none), and new orgs increasingly start there — but you cannot assume it. The only scope you control with certainty is the one you write yourself:

permissions:
  contents: read          # clone the repo, nothing more

Declare permissions: and every unlisted scope drops to none. That single block converts an ambient write-all token into a read-only one regardless of the repo’s default setting.

# Top-level: applies to all jobs as the floor
permissions:
  contents: read

jobs:
  release:
    permissions:          # job-level: overrides for this job only
      contents: write     # this one job may push a tag
      id-token: write     # and mint an OIDC token (next lesson)
    runs-on: ubuntu-latest
    steps: [...]

Least privilege, per job

The discipline is two-part. First, set a restrictive floor at the top of the workflow — permissions: contents: read (or even {} for no scopes) — so every job starts with nothing it does not need. Second, elevate narrowly: only the job that publishes a release gets contents: write; only the job that comments on a PR gets pull-requests: write; only the job that authenticates to a cloud gets id-token: write. A job-level permissions: block fully replaces the inherited set for that job — it is not additive, so listing one scope drops all the others to none.

This matters because of how the token reaches code. Every step in a job — every third-party Action, every run: script, every transitive npm or pip dependency those execute — runs with the same job token available in the environment and to the GitHub API. There is no per-step sandboxing of the token. So the token’s scope is the union of trust you extend to every line of code in that job. Pinning Actions to a full commit SHA (uses: owner/action@<40-char-sha>) closes the which code runs half; least-privilege permissions: closes the what that code can do half. You need both: pinning without scoping still hands a write-all token to pinned-but-later-compromised code, and scoping without pinning still runs arbitrary mutable code, just with less reach.