GitHub has added a new protection for public repositories: some GitHub Actions workflow runs can now be held for approval when GitHub identifies them as potentially malicious. The change is aimed at supply-chain attacks in which compromised GitHub credentials are used to push workflows that steal CI/CD credentials or launch further attacks. For repository maintainers, the important question is not whether an approval screen exists. It is whether your review process treats a held run as a security signal rather than a routine click.
What GitHub changed
In its July 28, 2026 GitHub Changelog entry, GitHub says that certain workflow runs in public repositories on github.com may be held before they start. A repository collaborator with write access must review and approve the run through an authenticated web session. After approval, the workflow continues normally.
GitHub describes this as an automatic protection. The changelog does not present it as a replacement for least-privilege permissions, review of workflow diffs, pinned action references, or protected branches. It also states that GitHub Enterprise Server does not add this protection at this time. Those scope limits matter: a held run is not evidence that every workflow is safe, and an unheld run is not evidence that a workflow is trustworthy.
Why an approval hold deserves investigation
A workflow file is executable CI configuration. It can access repository contents, tokens, artifacts, package registries, cloud credentials, and third-party actions depending on its permissions and the event that triggered it. If an attacker changes a workflow after compromising a maintainer account, the visible pull request or commit may look small while the runtime consequences are large.
The approval event adds a useful control point, but it does not answer the core review questions. A reviewer still needs to identify who changed the workflow, which lines changed, what event started the run, which permissions are granted, whether an action reference moved to a mutable tag, and whether the job can reach secrets or trusted deployment environments. Treat the hold as a trigger for a bounded review.
Five-minute review workflow
- Confirm the scope. Check that the repository is public and hosted on github.com. Record whether the run is held, which workflow file is involved, and the triggering event. Do not assume this control applies to GitHub Enterprise Server or every private-repository deployment.
- Identify the change. Compare the workflow file with its last reviewed commit. Look for new shell commands, downloaded scripts, changed action references, altered environment variables, permissions changes, and jobs that now run on pull requests or other untrusted inputs.
- Inspect trust boundaries. Pay special attention to
pull_request_target, write-enabledGITHUB_TOKEN, repository or organization secrets, cloud federation, deployment environments, artifact upload/download, caches, and commands that interpolate issue, branch, or pull-request text. - Validate action provenance. Prefer full commit-SHA pinning for third-party actions where your maintenance process can support it. Verify that a changed owner, repository, tag, or SHA is intentional and that the referenced action is the one the workflow expects.
- Approve only with evidence. If the diff, actor, event, permissions, or external action cannot be explained, do not approve the run. Escalate through your incident or repository-owner process and preserve the commit, run URL, and review notes.
Controls to keep even when the hold works
| Control | Review question |
|---|---|
| Workflow permissions | Does each job receive only the scopes it needs? |
| Action references | Are external actions pinned and changes reviewed? |
| Untrusted input | Can attacker-controlled text reach a shell command or script? |
| Secrets and OIDC | Can this event or job access deployment credentials? |
| Branch and environment rules | Are merges and deployments protected independently of CI approval? |
For a broader review, compare this workflow with the earlier self-repository Actions checklist, the workflow-trigger allowlist checklist, and the guidance on pull_request_target checkout defaults. Each addresses a different failure mode; none should be presented as a complete security assessment.
How to document the decision
Write down the workflow path, commit SHA, triggering event, actor, approval decision, permissions, secret exposure assessment, external action references, and any follow-up work. If the run was approved, record why the change was expected and what evidence supported that decision. If it was rejected or escalated, preserve the reason without copying secrets or raw credential values into tickets.
This evidence is useful during incident response and release review because it distinguishes a GitHub platform control from your organization’s own decision. GitHub’s documented behavior is the platform fact; the quality of your repository review is an operational fact that must be demonstrated separately.
FAQ
Does a held workflow mean GitHub found malware?
No. The changelog says the run was identified as potentially malicious. That is a signal for human review, not a confirmed malware verdict.
Can I approve the run from an API or an unattended bot?
GitHub’s changelog says approval must be submitted through an authenticated web session. Follow the current GitHub interface and repository permissions rather than assuming an automation path exists.
Does this replace a local change review?
No. A local review can inspect the exact diff, policy, permissions, and evidence before a run starts. If you want a local gate for intent-bound changes, see the AI Change Firewall. It is a review aid, not a guarantee that a repository or workflow is secure.
Where can I compare workflow and code-security workflows?
Use the single CodeRiskTools comparison page for a bounded overview, and use the free AI code review checklist when you need a lightweight starting point.
Source boundary: The GitHub Changelog page is the official source for the platform behavior and stated scope. The review workflow and control recommendations above are CodeRiskTools editorial guidance. They are not a claim that GitHub’s hold mechanism detects every malicious workflow or that following this checklist establishes that a repository is secure.
