GitHub Actions Approval Holds: A Maintainer Security Checklist

What changed

GitHub announced on July 28, 2026 that GitHub Actions now holds certain workflow runs it identifies as potentially malicious. A held workflow does not start until a repository collaborator with write access reviews and approves it through an authenticated web session. GitHub applies the protection automatically, but only to public repositories on github.com; GitHub Enterprise Server is not covered at this time. GitHub’s announcement

That is a useful additional barrier, not a verdict that every unblocked workflow is safe. GitHub has not published the detection criteria in the announcement, and maintainers should not infer that an automatically released run has passed a complete security review. Existing approval policies, workflow permissions, branch protection and careful review still matter.

Treat a hold as a request to inspect, not a prompt to click

When a run is held, begin with the pull request’s Files changed view. GitHub’s approval instructions specifically tell maintainers to inspect the proposed changes and pay particular attention to .github/workflows/. Runs from forks that remain unapproved for more than 30 days are automatically deleted. GitHub’s approval guide

Review more than the workflow YAML. A workflow can execute repository scripts, package-manager hooks, build tools, test fixtures and checked-in binaries. Trace each run: command and local action to the files it invokes. If the pull request changes any of those files, treat them as executable input even when the workflow file itself is untouched. Also inspect changes to dependency manifests and lockfiles because installation scripts may run before the visible test command.

Before approving, answer four questions:

1. What event triggered the workflow, and whose code or text can influence it?
2. What permissions, secrets, environments, caches and artifacts can the run reach?
3. Does it execute code from the pull-request branch on a self-hosted or otherwise privileged runner?
4. Are third-party actions pinned to reviewed, full-length commit SHAs?

If any answer is unclear, leave the run blocked while the contributor or another maintainer explains the data flow. Approval should mean “I understand what will execute with these privileges,” not merely “the pull request looks familiar.”

Check the trigger and trust boundary

GitHub distinguishes ordinary pull_request workflows from privileged triggers such as pull_request_target and workflow_run. Its security reference warns that privileged workflows must not check out untrusted pull-request code. It also recommends avoiding those triggers when they are unnecessary and treating artifacts from less-privileged workflows cautiously. GitHub’s secure-use reference

This distinction is especially important because GitHub’s configurable fork-approval policy does not gate pull_request_target: that event runs in the trusted base-branch context regardless of the approval setting. GitHub also warns that approving untrusted code for a self-hosted runner can expose infrastructure even when normal fork restrictions are enabled. GitHub’s organization settings documentation

A practical design is to keep untrusted compilation and tests in a read-only pull_request workflow with no secrets. If a later task must comment, label or publish a result, move that narrow operation to a separate privileged workflow that consumes only deliberately constrained data and never executes the contributor’s code. OpenSSF describes this separation as a way to keep write permission away from the workflow that processes untrusted code. OpenSSF’s workflow threat guide

Audit permissions before approving

Look for an explicit top-level permissions: {} or a minimal permission set, followed by narrowly scoped job permissions. A test job commonly needs contents: read; it usually does not need permission to modify repository content, packages, issues or pull requests. Deployment credentials should be isolated behind an environment with required reviewers rather than exposed to general CI.

Also search for direct interpolation of attacker-controlled values inside shell scripts. Pull-request titles, bodies, branch names, issue text and comments can contain shell syntax. GitHub recommends passing such values through action inputs or intermediate environment variables instead of inserting expressions directly into a generated script. This reduces the chance that data becomes executable shell text. GitHub’s secure-use reference

Third-party actions deserve their own pass. GitHub states that a full-length commit SHA is the only immutable way to reference an action and recommends verifying that the SHA belongs to the genuine action repository. A version tag is easier to read but can move if its repository is compromised. Record why each privileged dependency is needed and use automated updates so immutable pins do not become forgotten dependencies.

Choose a stronger fork policy where the project can support it

GitHub’s default policy requires approval from first-time contributors, while repository and organization settings can require approval from all external contributors. GitHub cautions that a malicious actor could first establish trust with an innocuous contribution and then submit a later workflow change, so “first-time only” is not a durable trust boundary. GitHub’s organization settings documentation

For a public project with sensitive build or release automation, requiring approval for all external contributors is the safer baseline if maintainers can handle the review load. OWASP likewise recommends that setting, read-only default GITHUB_TOKEN permissions, branch protection and required reviews or status checks. It advises extra caution with self-hosted runners because they may reach internal networks or retain sensitive state. OWASP’s GitHub Actions security checklist

The operational cost is real: frequent contributors may wait for a maintainer, and large projects need coverage across time zones. Reduce friction by documenting who can approve, setting a review rotation and providing a short checklist in the repository’s contributing guide. Do not weaken the policy merely to clear a queue; improve the approval process first.

Harden the repository around the new safeguard

Add .github/workflows/ to CODEOWNERS and require an appropriate reviewer for changes to that directory. Keep the default token read-only, then grant additional permissions per job. Protect release environments with required reviewers, avoid mixing public pull-request tests with deployment jobs, and scan workflow files with CodeQL or another maintained workflow analyzer. These controls address different failure modes and remain useful even when GitHub’s automatic hold does not activate.

For self-hosted runners, use ephemeral and isolated workers where feasible, prevent untrusted pull requests from reaching internal networks, and avoid reusing a workspace that may retain files from a previous job. If the project cannot establish those boundaries, route public pull-request tests to GitHub-hosted runners or do not execute them automatically.

A five-minute approval sequence

Start by confirming the contributor and trigger. Inspect workflow, script, manifest and lockfile changes. Identify the runner and effective token permissions. Search for secrets, privileged environments, untrusted interpolation and pull-request code checked out under pull_request_target or workflow_run. Verify every changed third-party action reference. Finally, write a brief approval note or link to the reviewed commit so another maintainer can understand the decision.

A clean review may still end with “do not run.” Ask the contributor to split workflow changes from unrelated code, reduce permissions or move privileged work into a separate workflow. GitHub’s new hold creates time for that decision. The security benefit comes from using the pause to examine the trust boundary rather than treating approval as another notification to dismiss.