← Actions self-hosted exposure check
Harden-Runner, from StepSecurity, is a GitHub Action you add as a step inside a job. While that job runs, it monitors the job's outbound network calls and file integrity, and can flag or block egress that was not expected -- a runtime control that watches one job for the duration it actually executes on the runner.
This checker does not run a job at all. It is a free, zero-dependency tool -- usable in the browser
or as a stdlib-only Python CLI -- that reads your .github/workflows/*.yml files as text
and flags every job whose runs-on includes the literal self-hosted label
and whose triggering event is pull_request, pull_request_target,
workflow_run, or issue_comment -- the exact combination GitHub's own
documentation names as a reason not to use self-hosted runners on a public repository -- and prints
which trigger matched. Nothing about it needs a job to run first.
| What you are trying to do | Where to do it |
|---|---|
| Monitor and constrain what a specific job actually does -- network calls, file writes -- while it runs on your infrastructure. | Harden-Runner -- that is precisely its job, as a step inside the workflow it is watching. |
| Find out, before any job has ever run, which workflow files pair a self-hosted runner with a trigger a fork can raise. | This checker -- a text scan of your workflow YAML, no job execution needed. |
| Audit a whole repository's workflow files in CI with a single exit code, no action installed into the workflows themselves. | This checker's CLI -- python3 check.py --fail-on-risk, stdlib only. |
| Get an allowlist of expected network endpoints and be alerted on anything outside it during a run. | Harden-Runner -- this checker makes no claim about runtime network behavior at all. |
| Decide whether a newly-opened workflow file is safe to merge before it ever executes on a self-hosted runner. | This checker -- it reads the file as committed; nothing has to run first. |
These sit at different points in the same job's life rather than competing for the same one. This
checker is a cheap, static gate on the workflow files themselves -- run it in CI on every pull
request that touches .github/workflows/ -- and Harden-Runner is a runtime control for
the jobs you have decided should run. A team that wants both exposure classes covered reasonably
runs this checker first and Harden-Runner on the jobs it lets through.
They act at different moments and most teams taking self-hosted-runner exposure seriously will want both. Harden-Runner, from StepSecurity, is a GitHub Action you add as a step inside a job; while that job runs, it monitors outbound network calls and file integrity and can block or flag unexpected egress -- a runtime control, watching one job as it actually executes. This checker never runs a job at all. It is a free, zero-dependency scanner (browser or CLI) that reads your .github/workflows/*.yml files as text and flags every job that combines a self-hosted runner label with pull_request, pull_request_target, workflow_run, or issue_comment -- GitHub's own documented risky combination -- before that job is ever scheduled. Reach for Harden-Runner to monitor and constrain what a job does while it runs. Reach for this to catch the exposed combination in your workflow files themselves, including ones that have not run yet.
Because a runtime monitor only sees a job once it starts, and by definition a self-hosted runner triggered by a forked pull_request has already let a stranger's workflow-file edits reach your machine by the time any step -- Harden-Runner included -- begins executing. Reading the workflow YAML directly catches the exposed trigger-plus-label combination itself, as a static fact about the file, whether or not the job has ever run. The two are complementary rather than redundant: this checker is about whether a job should be reachable by a fork at all; Harden-Runner is about constraining what that job can do once it is.
Being free is not the difference, and this page does not claim it is: StepSecurity offers Harden-Runner as a GitHub Action available to add to a workflow. The difference is shape and scope. Harden-Runner instruments a running job and needs to be added, per job, to the workflows you want it watching. This checker needs nothing added to your workflows at all -- point the CLI at a checkout, or paste YAML into the browser tool, and it reads the files as they already are, with no network call and nothing installed into your CI. It is built for the moment before a job runs, which a runtime action by definition cannot cover.
No. This site is not affiliated with, endorsed by, or sponsored by StepSecurity, Inc., and Harden-Runner and StepSecurity are named here only to describe what this checker is and is not. The description of Harden-Runner on this page is drawn from StepSecurity's own public documentation; check it there for what the action currently monitors and how.