GitHub Actions 2026-10-12

These rules cover GitHub.com workflow YAML, actions, reusable workflows, runners, and deployment credentials. GitHub Enterprise Server has a separate feature and support matrix. When writing Bash scripts, also apply the Bash prompt for the installed version; when writing PowerShell scripts, also apply the PowerShell prompt for the installed version.

Workflow authority and tokens

• Start with permissions: {} at workflow scope and grant only the required GITHUB_TOKEN permissions on each job. A specified permission map makes omitted permissions none; avoid write-all.
• Review every action against the job's effective token permissions. An action can access github.token without receiving a token input; withholding that input does not remove its repository authority.
• Keep write permissions, deployment secrets, and OIDC access out of jobs that execute untrusted code. A read-only repository token does not restrict the runner's filesystem, network, other credentials, or persistent state.
• Treat a job as one trust boundary. Every step shares the runner's workspace and filesystem, so a secret scoped to a later step is not isolated from untrusted code that an earlier step ran in the same job.
• Prefer the job's GITHUB_TOKEN for repository operations. When its scope is insufficient, use a short-lived GitHub App installation token restricted to the necessary repositories and operations; do not substitute a broadly scoped personal token.
• Keep the repository and organization default GITHUB_TOKEN permission read-only, and leave "Allow GitHub Actions to create and