Will It Vibe?Self-hosted runner
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
A job targets a self-hosted runner. Self-hosted runners persist between jobs and share the host, so untrusted code (for example from a fork pull request) can poison the runner, read other jobs data, or pivot into your network. This is a heuristic; self-hosted runners on private repositories with trusted contributors can be fine.
Why it matters
Self-hosted runners persist between jobs and share a real host and network, unlike ephemeral GitHub-hosted runners. Code that runs on them (especially from fork pull requests on a public repo) can leave behind tools, read other jobs data, or pivot into your internal network. This is a heuristic; self-hosted runners can be appropriate on private repos with trusted contributors.
How to fix it
Do not run untrusted code on self-hosted runners. Restrict which workflows and triggers use them, disable fork pull requests from reaching them, and prefer ephemeral, single-job runners (for example via the actions-runner-controller or an autoscaling setup that destroys the VM after each job). Keep production and CI runners network-isolated.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo