How reusable-workflow permissions work
A job that calls a reusable workflow grants it a GITHUB_TOKEN: the caller job’s permissions, else the caller workflow’s, else the repository default. Inside the called workflow, workflow- or job-level permissions can only keep or reduce that grant. Asking for more—say contents: write when the caller granted read—makes GitHub fail the run before it starts. The auditor computes the grant at every level of every chain and reports each escalation with its file and line.
How secrets reach a called workflow
Secrets never flow automatically. The caller passes named secrets under secrets:, which must be declared in on.workflow_call.secrets, or passes everything with secrets: inherit, which must be repeated at each nesting level. The auditor flags required secrets that are not passed, secrets the callee does not declare, secrets the callee reads that will be empty, and inherit from triggers that outside contributors can start.
Risky triggers and script injection
pull_request_target, workflow_run and comment triggers run with the base repository’s secrets and a potentially writable token. Checking out the pull request’s code there, or interpolating github.event.pull_request.title, issue bodies or github.head_ref directly into run: scripts, lets an attacker execute commands. The auditor reports these patterns, plus unpinned remote workflows and actions that receive tokens.
Validation boundary
This is a static analysis aid, not GitHub. It does not read organization, enterprise or environment settings, fork-approval policies, branch protection, runner groups or OIDC trust, evaluate if: conditions or matrices, inspect composite actions, or fetch remote workflows. Fork pull requests always receive a read-only token regardless of the configuration shown here. Confirm changes in a test repository and review run logs.
Frequently asked questions
Can a reusable workflow raise GITHUB_TOKEN permissions?
No. A called workflow can keep or reduce the permissions its caller grants. Requesting more than the caller allows makes the run fail at startup.
Do secrets flow into reusable workflows automatically?
No. Secrets must be passed explicitly under secrets: or with secrets: inherit, and in nested chains inherit must be repeated at every level.
How deep can reusable workflows nest?
GitHub documents up to ten levels of connected workflows (the caller plus nine nested calls) and up to fifty unique reusable workflows per run.
Are my workflow files uploaded?
No. The YAML is parsed and analyzed in your browser; nothing is sent to GitHub or ToolQuill.
Authoritative references
GitHub’s documentation on reusing workflows, controlling GITHUB_TOKEN permissions and security hardening for GitHub Actions defines the rules modeled here.
Browse PKI & DevOps tools · Audit Docker Compose merges · Audit CODEOWNERS coverage