GitHub Actions freezes suspected-malicious workflow runs until a human signs off

A stolen credential and one push. That is all it takes to run whatever you want inside somebody else's CI, with their secrets, from their identity. It has been the shape of an unlovely pile of supply-chain incidents this year, and the platform response has mostly been advisory. On July 28 GitHub shifted the Actions default: workflow runs the platform judges potentially malicious no longer run. They wait.

What actually changed

The Changelog entry, filed under "Improvement," is short. GitHub says Actions will now hold workflow runs it identifies as potentially malicious until a repository collaborator with write access reviews and approves them, and that the approval must come through an authenticated web session. The protection is applied automatically. There is nothing to configure. It currently ships on public repositories on github.com; GitHub Enterprise Server does not carry it at this time.

That really is the whole announcement. GitHub does not publish the criteria that trip the hold, and I would not extrapolate them here: any specific classifier or heuristic you read into this is your speculation, not GitHub's guidance. What the entry does name is the class of attack it is aimed at: recent supply-chain campaigns that use compromised GitHub credentials to push malicious Actions workflows that steal CI/CD credentials and stage the next hop.

Why a pause is the whole point

Think about the sequence GitHub is interrupting. A credential leaks, however it leaks. The attacker pushes a workflow file to a repository they now speak for. On the next event the workflow runs inside that repository's trust boundary, which means it runs on a runner holding the repository's secrets. It exfiltrates them. Now the compromised repository is a launchpad, and its downstream consumers become the next targets.

Every mitigation on the market up to this point has been shift-left: rotate the token, harden the identity, require signed commits, scan for exposed secrets. All useful. But once the push lands, the workflow has historically executed on the next event with no human in the loop. The hold rearranges that. It inserts a review step between push and run, but only for runs the platform considers unproven. From "execute and hope somebody notices" to "wait for someone with write access to look".

Is a pause a strong control by itself? No. It is a floor. It buys minutes of dwell time in which somebody who can log in with write access can catch a strange-looking workflow before it holds anybody's secrets. If your review culture is "click Approve" or your write-access list is scattered across former contributors, the control will fire and you will authorize the attack yourself. Great feature. Rehearse it.

How the loop looks for a maintainer

GitHub has not published the review UI in this entry, so treat the operational picture as generic until you meet it in your own repository. What the Changelog does specify is worth reading closely.

• The gate is who. A repository collaborator with write access. Not a bot. Not a GitHub App token running from inside the very workflow being reviewed.
• The gate is how. An authenticated web session. Automation cannot bypass it by hitting an API endpoint from the same runner that is trying to run.
• The gate is when. For workflow runs the platform identifies as potentially malicious. Ordinary runs are unaffected.

The practical shift for a maintainer of a busy public repository is a new failure mode to plan for. A legitimate workflow run that the platform's classifier is uncertain about will occasionally block on human sign-off, and the person who has to sign off cannot be your CI service account.

What to watch out for

A short list, in the spirit of assuming the mitigation works and worrying about the edges.

• False positives on legitimate contributor pushes. GitHub has not stated a rate; run your own tally over the first weeks. A well-known contributor whose PR gets held on their first workflow change is a support ticket you should be ready to answer.
• Approval fatigue. The value of the pause is the review. If approving becomes a reflex the control is theater; if the reviewer is the same person whose credential got stolen, the control is worse than theater.
• Uneven coverage. Public repositories on github.com only. Private repositories on github.com and self-hosted GitHub Enterprise Server do not get this today, per the Changelog. Those are exactly the surfaces where a stolen internal credential does the most damage. Treat this as a partial fix, not a solved problem.
• Compromised collaborators. The write-access population is your trust boundary. If it is loose, or stale, or shared with somebody who left three quarters ago, the hold protects nobody.

How other CI platforms sit next to this

Every major CI provider has a version of "gate the run." None of them, as far as I have seen shipped, run an automatic classifier-driven hold as the default response to a suspicious workflow file.

• GitLab CI/CD exposes manual approval jobs and merge-request pipelines that can require an approver. The trigger is you configuring the job, not the platform judging the pipeline.
• CircleCI has approval steps inside workflows and restricted contexts that hold secrets behind manual gates. Same shape: opt-in, author-defined.
• Jenkins treats this as a plugin-and-policy problem. Multibranch pipeline strategies and script approval exist, but "the platform decides this run looks off" is not a Jenkins primitive.
• Bitbucket Pipelines supports manual step gates and deployment approvals. The classifier is your team.

The GitHub move is a shift from provider-as-substrate to provider-as-gatekeeper. Whether you like that trade depends on how much you trust GitHub's classifier and how much you trust the reviewers on your side of the fence. Both matter. Only one of them is under your control.

Approve nothing you would not merge.