Besides repository allow lists on runner groups, which operational practice most reduces risk when self-hosted runners execute workflows that build untrusted pull requests?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Ephemeral per-job runners plus tight egress beat warm long-lived admin VMs for untrusted PR builds. Disabling HTTPS or baking root keys into AMIs massively increases risk.
Full explanation below image
Full Explanation
Untrusted PR code on self-hosted infrastructure is a high-risk pattern. Ephemeral (JIT) runners limit persistence of malware and stolen tokens. Combine with runner groups so only intended repos can schedule, and restrict egress so builds cannot freely exfiltrate to attacker servers. Long-lived shared admin VMs maximize blast radius and cache poisoning risk. TLS should remain enabled. Cloud root keys must never live on CI AMIs—prefer OIDC and short-lived roles. Many orgs simply forbid self-hosted execution for fork PRs and run those checks only on GitHub-hosted runners without secrets.