Cyber Security

GitHub Actions now pauses some suspicious public-repo workflows for human approval

GitHub Actions now automatically holds some suspicious public-repository workflow runs for collaborator approval before execution.

#supply chain security #open source #CI/CD #GitHub Actions

CyberOGZ Team • July 28, 2026 • 3 views • 2 min read

Format News Brief

Read Time 2 min

Category Cyber Security

Updated Jul 28, 2026

GitHub is adding a new automatic check to GitHub Actions that can hold certain workflow runs in public repositories before they execute, a targeted response to supply-chain attacks that abuse compromised developer accounts and continuous integration pipelines.

The company said on July 28 that recent attacks have used stolen GitHub credentials to push malicious Actions workflows designed to steal CI/CD secrets and enable follow-on compromises. Under the new protection, GitHub Actions can identify a workflow run as potentially malicious and stop it before jobs start running.

How the hold works

When a run is held, it does not execute until a repository collaborator with write access reviews and approves it. GitHub also requires that approval to come through an authenticated web session, adding friction against automated abuse or approval attempts from unauthenticated channels.

The change is designed to protect public repositories on github.com without requiring maintainers to turn on a setting or rewrite workflow files. GitHub says the protection is applied automatically. For now, the company is drawing a clear boundary around scope: the feature applies to public repositories hosted on github.com, while GitHub Enterprise Server does not receive the protection at this time.

Why it matters

CI/CD systems are high-value targets because they often touch signing keys, deployment credentials, package publishing tokens and cloud infrastructure. A malicious workflow introduced through a compromised account can run inside a trusted repository context, making it especially dangerous for open-source projects whose releases are consumed far downstream.

GitHub's move does not replace maintainer review, branch protection, secret hygiene or least-privilege tokens. It does, however, add a platform-level pause at a point where seconds can matter: before suspicious automation has a chance to execute. The approval requirement also gives maintainers a visible checkpoint when GitHub believes a workflow run deserves closer inspection.

The announcement is brief, so GitHub has not detailed the detection signals behind the hold or the expected rate of false positives. Maintainers should watch for held runs in public repositories and treat the prompt as a reason to inspect the workflow diff, actor, trigger and requested permissions before approval.

For open-source projects, the practical takeaway is straightforward: some risky GitHub Actions runs may now wait for a trusted collaborator instead of starting immediately. That small delay could prevent stolen credentials from becoming a broader software supply-chain incident.