Most fork pull request advice fails on a few repeated misunderstandings. Here are five, each checked against GitHub's own documentation. The short result: the default is safer than people fear, but a handful of settings and triggers remove that safety quickly.
Myth 1: Any pull request from a stranger can steal my secrets
Fact. For pull request workflows from forks, GitHub does not pass secrets to the runner, apart from GITHUB_TOKEN, which is read-only. The danger comes from privileged triggers that you add, such as pull_request_target or workflow_run combined with a checkout of untrusted code.
Myth 2: A green required check means the scan ran
Fact. On GitHub, skipped and neutral statuses count as successful, and a job skipped by a conditional reports success. A scan gated on "secrets are available" is skipped for forks and shows green. Use a summary job that fails on anything other than success.
Myth 3: If I use pull_request_target, I am safe because it runs my workflow
Fact. The workflow file comes from the base branch, which is helpful. But if it checks out and runs the pull request head, contributor code runs with secrets and possibly a write token. GitHub's guidance is to avoid that combination.
Myth 4: Self-hosted runners are fine because the repository is mine
Fact. For public repositories, GitHub says self-hosted runners should almost never be used. Anyone can open a pull request and run code on that machine. For private repositories, anyone who can fork it, generally someone with read access, can reach the runner.
Myth 5: Caches are harmless speed ups
Fact. Cache contents are not signed or verified. GitHub restricts which low-trust triggers can write to the default branch cache, but you can opt out per workflow. Do not restore untrusted caches into jobs that hold secrets.
Summary table
| Belief | Reality | Action |
|---|---|---|
| Strangers get my secrets | Not by default | Audit privileged triggers |
| Green means scanned | Skipped counts as success | Add a summary gate |
| pull_request_target is safe | Not with a PR code checkout | Search for head checkouts |
| Self-hosted is fine | Almost never for public repos | Use hosted runners |
| Caches are harmless | Not verified | Rebuild in release jobs |
What to do this week
- Grep for pull_request_target and workflow_run, and inspect each.
- Open a test pull request from a fork and see what the checks actually did.
- Review runner labels on public repositories.
- Set default token permissions to read-only.
- Add owner review for the workflows directory.
None of these needs a new tool. They need an hour and a willingness to read your own workflow files.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the gate decides and which inputs it uses.
Where Safeguard fits
Safeguard provides policies and gates for pull requests, plus dependency scanning and SBOMs. Run the free scan to see your baseline.
Quick check
Is it true that forks never run workflows?
Workflows do not run in a forked repository until its owner enables Actions, but a pull request to your repository does trigger your workflows, subject to approval settings.
Should I disable fork pull requests entirely?
Usually not. Keep the safe defaults and control the privileged triggers instead.
Sources
- Events that trigger workflows, GitHub Docs
- Secure use reference, GitHub Docs
- Troubleshooting required status checks, GitHub Docs
- Dependency caching reference, GitHub Docs
Last reviewed: 19 October 2026.
