Software Supply Chain

GitHub's New Workflow Default Begins in Evaluate Mode

By Kaleido Field Staff · September 18, 2026

Citation-ready: GitHub's default pull_request_target protection initially evaluates affected public-repository runs; evaluate mode must not be reported as active enforcement.

Evidence boundary: Official policy-tool announcement. No repository policy changed, exploit attempted or security outcome independently established.

What happened and why it matters

The new release gives maintainers more precise policy scope. The immediate review task is to distinguish the rule's existence, the workflows it targets and the mode in which it is currently operating.

Primary evidence

Primary reference: GitHub September 17 execution-protection changelog. Kaleido Field checked the event date and the article's attributed facts against this source.

The default has an explicit scope

GitHub describes the new default for public repositories without an applicable event policy, excluding private and internal repositories. It names November 2 enforcement for affected repositories using the default policy before general availability. The release also adds Insights and REST management.

That scope should be checked before applying the headline to an organization. A policy inherited from another level may change which rule applies to a particular workflow.

Review observed impact before the deadline

In evaluate mode, maintainers can inspect which runs would have been stopped. A review can pair each affected workflow with its intended actors and events, then decide whether the existing rule expresses the team's actual policy.

The decision should stay visible in the repository's change process. Quietly allowing every trigger would remove the distinction that the review was meant to examine. This article does not recommend weakening a protection or provide exploit steps.

Separate a policy block from a failing job

A run prevented from starting and a started job that fails tests require different diagnoses. Preserve the policy decision with the workflow record so the team does not spend time debugging code that never ran.

The Ubuntu migration report covers the later stage: a permitted run executing on a changed image.

Evidence boundary

Official policy-tool announcement. No repository policy changed, exploit attempted or security outcome independently established.