Review and harden high-risk pull_request_target workflows identified in Ticket 40

User Need
As a DevX platform engineer
I want the 11 high-risk pull_request_target workflows identified in Ticket ministryofjustice/ministry-of-justice-developer-portal#40 to be reviewed and hardened
so that external contributors cannot exploit these triggers to exfiltrate secrets or run untrusted code with write access to our repositories.

Value / Purpose
• pull_request_target is the single most dangerous workflow trigger because it runs with full write permissions and secret access in the context of the base repository, even when the pull request originates from an untrusted fork
• Ticket ministryofjustice/ministry-of-justice-developer-portal#40 identified 11 workflows across the MoJ estate using this trigger, and without review we don’t know whether each one has appropriate guards (e.g. not checking out PR head code, gating on committer identity, limiting permissions)
• Hardening or replacing these workflows closes a high-impact attack vector and aligns with GitHub’s own security guidance on pull_request_target usage

Description / Context
Ticket ministryofjustice/ministry-of-justice-developer-portal#40 added Stage 9 to github_workflow.py which classifies workflow triggers by risk level. The scan identified 11 workflows using pull_request_target as the primary risky trigger. These workflows are listed in github_workflow_trigger_risk.csv (filter risk_level = high) and github_workflow_trigger_risk_per_repo.csv on the DevX Team SharePoint under Spreadsheets & Data.
For each flagged workflow, we need to determine whether the current usage is safe (i.e. the workflow does not check out or execute code from the PR head, or has explicit guards) or unsafe, and then either document an acceptable pattern or raise a remediation with the owning team.

Steps:

1. Pull the list of 11 high-risk workflows from github_workflow_trigger_risk.csv and identify the owning team for each repo
2. For each workflow, inspect the YAML to classify as:
   • Safe: uses pull_request_target only to access labels/metadata, does not check out PR head
   • Guarded: checks out PR head but has explicit permission or identity guards in place
   • Unsafe: checks out PR head without guards and has access to secrets
3. For unsafe workflows, raise individual issues against the owning repos recommending either migration to pull_request or the addition of appropriate guards
4. Document the acceptable patterns in the developer portal so teams have a reference for safe pull_request_target usage

Definition of Done
• All 11 high-risk workflows classified (safe / guarded / unsafe)
• Unsafe workflows have remediation issues raised against their owning repos
• Developer portal guidance on safe pull_request_target usage published
• Findings summary shared in #developer-experience-team

Testing steps
• Re-run Stage 9 of github_workflow.py after remediation to confirm reduction in high-risk count
• Spot-check at least 3 of the remediated workflows to verify guards are functioning as intended

Start with Stage 9 in github_workflow.py, then obtain the high-risk entries from github_workflow_trigger_risk.csv and github_workflow_trigger_risk_per_repo.csv on the DevX Team SharePoint. Review each workflow’s YAML and record whether it is safe, guarded, or unsafe. Done means all 11 are classified, unsafe cases have remediation issues, guidance is published, and the scan plus spot-checks confirm the changes.