Harden the default-branch PR guard to use a trusted workflow definition #540

Summary

Review whether the default-branch PR guard should run from a trusted workflow definition.

Requested by @aramprice as a separate follow-up to PR #538. The PR preserves the existing workflow's pull_request event model while preparing the default-branch rename. This recommendation concerns inherited behavior, not a new security regression introduced by the rename.

Rationale

A workflow triggered by pull_request can use the workflow definition from the pull request's merge commit. A pull request could modify the guard condition or failure step. If the guard is intended to enforce merge policy, assess whether repository rules already prevent that bypass before selecting a mitigation.

Affected area

• .github/workflows/protect-default-branch.yml
• Repository branch rules and workflow ownership controls, if applicable

Recommended work

• Review the workflow trust model and existing repository rules.
• If repository policy permits, use pull_request_target for this metadata-only guard. Keep permissions empty and do not check out or execute pull request code.
• Otherwise, evaluate repository rules and CODEOWNERS-based review requirements to protect changes to the workflow definition.
• If the guard is required for merging, verify the required-check configuration and its protection against bypass.

Acceptance criteria

• Document the selected trust model and its rationale.
• Preserve rejection of PRs targeting the repository default branch and allow the normal develop contribution workflow.
• Validate the guard for relevant PR events, including base-branch edits.
• Verify that a PR cannot bypass the intended merge policy merely by changing its own guard definition.
• Keep the guard metadata-only and retain least-privilege permissions.

References

• PR: Prepare the default branch rename to main #538
• Review discussion: Prepare the default branch rename to main #538 (comment)