Setting the file. One moment.
Skill 189 · GitHub Actions Hardening
Subchapter 189.2
references/permissions-and-tokens.mdMarkdown3 KBView on GitHub
Every workflow run gets an automatic GITHUB_TOKEN. Its scope is the blast radius if a step is
compromised, so scope it to the minimum.
If a workflow has no permissions: block, it inherits the repository/organization default. On
older or permissive repos that default is . A single injected command
or malicious dependency then runs with the ability to push code, publish releases, or approve PRs.
Set a restrictive default at the top level, then elevate per job only where needed.
# Deny by default
permissions: {}
jobs:
build:
permissions:
contents: read # checkout only
runs-on: ubuntu-latest
steps: [...]
comment:
permissions:
contents: read
pull-requests: write # this job posts a comment; nothing else
runs-on: ubuntu-latest
steps: [...]Common scopes: contents, pull-requests, issues, actions, packages, id-token,
deployments, checks, statuses. Each is read, write, or none.
permissions: block anywhere → MEDIUM (inherits possibly-broad default).permissions: write-all → HIGH.write scope the job’s steps never use → HIGH (drop it).write that should live on one job → MEDIUM (move it down).Storing static cloud keys (AWS_ACCESS_KEY_ID, etc.) as repo secrets means a leak is permanent
until manually rotated. Prefer OpenID Connect: the workflow requests a short-lived token the cloud
provider trusts, scoped to that repo/branch, expiring in minutes.
permissions:
id-token: write # required to request the OIDC token
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: aws-actions/configure-aws-credentials@<sha>
with:
role-to-assume: arn:aws:iam::123456789012:role/my-ci-role
aws-region: us-east-1
# no AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY secrets neededThe same pattern exists for Azure (azure/login), GCP (google-github-actions/auth), HashiCorp
Vault, and others. On the cloud side, scope the trust policy to the specific repo and ideally a
specific branch/environment so a fork or another repo cannot assume the role.
echo a secret or enable shell tracing (set -x) in a step that handles one.pull_request runs get no secrets — don’t try to “fix” that by switching to
pull_request_target (see triggers-and-privilege.md).