Harden-Runner puts egress control on the CI runner itself

The gap is that runners are not treated as endpoints

The premise is a gap in how security monitoring is deployed. Corporate laptops and production servers typically have robust security monitoring in place to reduce risk and meet compliance requirements, but CI/CD runners, which handle sensitive information like secrets for cloud environments and create production builds, often lack such security measures. The README connects this to real incidents, naming the SolarWinds and Codecov breaches as supply chain attacks that followed from the oversight. The reason ordinary EDR does not fill the gap is structural: traditional security monitoring and EDR solutions are ineffective for CI/CD runners because of their ephemeral nature, and they lack the necessary context to correlate events with specific workflow runs. A runner that lives for six minutes cannot be watched by a tool that expects a persistent host with a stable identity.

What it monitors inside the job

The description calls the tool a CI/CD security agent that works like an EDR for GitHub Actions runners, monitoring network egress, file integrity and process activity on those runners and detecting threats in real time. The three signals are the design. Egress monitoring catches the step that phones home to a command server, which is what a compromised npm package does. File integrity monitoring catches the step that overwrites a file in the workspace, which is what a poisoned build script does before the tests run. Process activity gives the context that a normal EDR lacks, because the events can be correlated with the specific workflow run that produced them. Support is for Linux, Windows and macOS runners, and the goal stated in the README is to bring CI/CD runners under the same level of security scrutiny as other critical systems.

The installation is one step at the top of each job

The integration is deliberately minimal, because a security control that has to be wired into twenty workflows will not be. You open the workflow file and add the action as the first step in each job:

steps:
  - name: Harden Runner
    uses: step-security/harden-runner@05e31511f85b41b11d1cf0ef85d0992719546e2c # v2.21.0
    with:
      egress-policy: audit

Two things in that snippet are deliberate. The action is pinned to a full commit SHA with the version in a trailing comment, which is the shape GitHub recommends for third party actions and is the practice the project's own topic tags include. And the egress policy is set to `audit` rather than to a blocking mode, so the first run observes rather than breaks the build. There is an online tool for pasting a workflow into to automate this step, and after the workflow runs you review the workflow logs and the job markdown summary and look for a link to security insights and recommendations.

The free tier is narrower than the product

The pricing note is worth reading before you plan a rollout. The Community tier is free for public repositories on GitHub-hosted runners and includes the core feature set, while advanced features, private repositories and self-hosted runners, including ARC, require the Enterprise tier. That boundary matters for most teams, because a company with private repositories is immediately in the paid category, and anyone running their own runners on their own hardware is in it too. The README also points at a set of StepSecurity maintained actions that are free for public repositories, and at an environment compatibility matrix, which is the document to check for the specific runner images you use, since the monitoring depends on what the image provides.

The detection history is the evidence

The list of detected incidents is the strongest argument in the README, because each entry names a real package and a real advisory. It includes the compromised axios npm package dropping a remote access trojan, the Trivy compromise with a malicious v0.69.4 release, and the tj-actions/changed-files compromise under CVE-2025-30066. It also covers the Sha1-Hulud supply chain attack in the CNCF Backstage repository, the NX build system compromise with data stealing malware, and a CI/CD supply chain attack in Google's open source Flank project and in Microsoft's Azure Karpenter Provider. Two of the entries are about behaviour rather than malware, one about anomalous traffic to an IP address lookup service across multiple customers and one about an unexpected endpoint security product installation on GitHub-hosted Ubuntu runners, and one about an anomalous outbound call that led to a documentation update upstream.

How the action is built

The package manifest shows the shape of the implementation, and it is a TypeScript project compiled with ncc into the `dist/` directory that the action runs from. The build produces three separate bundles: the main entry point, a pre step and a post step, which is the structure an action needs because the pre and post hooks run around the job rather than inside it. The runtime dependencies are the GitHub Actions toolkit packages, the cache and tool-cache helpers for the action cache and the tool cache, a `uuid` for identifiers and `node-fetch` for HTTP, with `is-docker` present to detect that the agent is running inside a container. The tests run on Jest with ts-jest and nock for HTTP mocking, and there is an `osv-scanner.toml` in the repository root, which suggests the project also tracks its own dependencies against the Open Source Vulnerabilities database. The licence is Apache 2.0 and the last push to the main branch was on 2026-10-08, with the v2.22.1 release the same day.

Editorial conclusion

Adopt Harden-Runner if you run GitHub Actions on GitHub-hosted runners and want to know what your build steps are doing at network level, since the egress policy is enforced inside the job rather than reviewed afterwards. Do not adopt it on the assumption that the free tier covers private repositories, because the Community tier is limited to public repositories on GitHub-hosted runners, and advanced features, private repositories and self-hosted runners need the Enterprise tier. Verify first which policy mode you start in, since the example uses audit rather than block, and check the known limitations document before you rely on the file integrity monitoring.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. step-security/harden-runner on GitHub