💡 Workflow Execution Protections Fleet Policy & pull_request_target Nov 2 Compliance Gate

[github-actions[bot]]

Summary

Adopt the now-GA workflow execution protections (Sep 17, 2026) across the org fleet, configure per-workflow-file actor and event policies, and audit all pull_request_target usage before GitHub's default block takes effect on November 2, 2026. The new per-workflow targeting capability enables scoping different policies to different .yml files within the same repo — a significant upgrade from repo-wide blanket rules.

Market Signal

GitHub shipped workflow execution protections GA on Sep 17, 2026 with a major new capability: per-workflow-file targeting — scope execution protection rules to specific workflow files rather than an entire repository. A default policy blocking pull_request_target in public repos enforces November 2, 2026 (38 days away). The MEGALODON_CI attack (May 2026, 5,500+ repos) demonstrated why execution policies are critical — attackers injected malicious workflows triggered on push and pull_request events across thousands of repos in 6 hours.

Sources: GitHub Changelog — Workflow execution protections GA (Sep 17, 2026), GitHub Actions 2026 Security Roadmap, MEGALODON_CI analysis (StepSecurity)

User Signal

Existing idea #484 tracked general execution protections adoption before GA. The org's workflows include agent-shield, pr-auto-review, dependabot-automerge, and feature-ideation that use various trigger events (push, pull_request, pull_request_target, workflow_dispatch, schedule). The compliance audit (standards/ci-standards.md) tracks workflow configurations but doesn't yet cover execution protection policies. Open issues show complex multi-workflow interactions that would benefit from per-workflow policy scoping.

Technical Opportunity

The org's compliance-audit.sh can be extended to verify execution protection policy configuration per-repo. The new per-workflow-file targeting maps naturally to the org's existing per-workflow security posture: strict policies on deploy.yml, pr-auto-review.yml, canary-rollout.yml (sensitive operations) while keeping CI workflows open to contributors. Actor rules can restrict sensitive workflows to specific GitHub Apps and bot accounts, complementing existing CODEOWNERS.

Assessment

Dimension	Score	Rationale
Feasibility	high	Configuration-only change, no code required. Existing compliance-audit infrastructure supports verification.
Impact	high	Defense-in-depth layer controlling WHO and WHAT triggers workflows — fills a gap branch protection doesn't cover.
Urgency	high	Nov 2, 2026 default enforcement deadline is 38 days away. GA just shipped — adoption window is now.

Adversarial Review

Strongest objection: The org's repos may all be private/internal, making the pull_request_target default policy inapplicable. The org already has branch protection and CODEOWNERS on .github/workflows/.

Rebuttal: Even for private repos, workflow execution protections add a defense-in-depth layer that branch protection and CODEOWNERS don't provide: controlling WHO can trigger a workflow (actor rules — restrict to specific users, apps, or roles) and WHAT events are permitted (event rules — explicitly allow or block trigger types). The per-workflow-file targeting is a genuinely new capability that enables the fine-grained security posture this org's standards philosophy demands. The Nov 2 deadline is a forcing function, but the value extends far beyond it.

Suggested Next Step

Audit all org repos for pull_request_target usage (grep -r pull_request_target .github/workflows/), then define per-workflow execution protection policies in standards/ and deploy via the standards-deploy sweep. Add a compliance-audit check for policy configuration.