The workflow sets permissions: contents: read at the top level, but one job must push a release tag. What is the least-privilege fix?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Job-level permissions can raise or reshape GITHUB_TOKEN scopes for just that job while the rest stay read-only. Do not widen everything, paste PATs into YAML, or invent admin-via-none.
Full explanation below image
Full Explanation
The permissions key can be set at workflow and job levels. A restrictive workflow default (contents: read) is a security best practice; individual jobs that must create tags, releases, or commits can set permissions: contents: write (plus packages or other scopes as required). That keeps unrelated jobs least-privilege. Removing top-level permissions may restore broader defaults depending on org/repo settings—usually worse for security. Hardcoding PATs in YAML is a critical secret leak. permissions: none reduces token scopes; it does not elevate to admin. For cross-repo or strong branch-protection cases you may need a GitHub App installation token or carefully scoped PAT as a secret, but the first lever for same-repo tag pushes is job-level GITHUB_TOKEN permissions.