Back to Blog

Runtime Security for Third-Party GitHub Actions Runners: Bitrise, Blacksmith, Depot, Namespace, and Warp

Harden-Runner secures third-party GitHub Actions runners. Bitrise macOS runners join Blacksmith, Depot, Namespace, and Warp Build with v2.20.0
Eromosele Akhigbe
View LinkedIn

July 16, 2026

Share on X
Share on X
Share on LinkedIn
Share on Facebook
Follow our RSS feed
Table of Contents

Supply chain attacks do not check your runs-on label. When the Sha1-Hulud worm compromised prominent npm packages, the malicious code executed wherever npm install ran. When the Velora DEX SDK compromise dropped a macOS backdoor through npm, it did not matter whose Mac the build ran on. If your runner executes untrusted code, it needs runtime security, whoever provides the hardware.

More teams than ever are running GitHub Actions jobs on third-party runner providers: faster hardware, better price-performance, Apple silicon for mobile builds, or region-specific infrastructure. What those teams should not have to trade away is runtime security.

Harden-Runner supports third-party GitHub Actions runner providers with the same one-step integration used on GitHub-hosted runners. With v2.20.0, Bitrise Build Hub macOS runners join the supported list alongside Blacksmith, Depot, Namespace, and Warp Build.

Same job, different hardware, same risks

Moving a job from ubuntu-latest to a third-party runner changes the infrastructure, not the threat model. The job still checks out code, installs dependencies, and holds secrets. A compromised dependency or poisoned action behaves identically. If anything, the stakes are concentrated: teams adopt these providers for their most build-intensive pipelines, which are usually the ones handling deploy credentials, signing keys, and registry tokens.

Harden-Runner gives these runners the same protection as GitHub-hosted ones: outbound network monitoring, correlation of events to the exact workflow step, and detections in the StepSecurity dashboard.

One step, any provider

Integration is identical across providers: add Harden-Runner as the first step of the job. Only the runs-on value changes.

Blacksmith

runs-on: blacksmith-4vcpu-ubuntu-2404

Depot

runs-on: depot-ubuntu-24.04

Namespace

runs-on: namespace-profile-default

Warp Build

runs-on: warp-ubuntu-latest-x64-4x

Bitrise (new in v2.20.0)

Bitrise Build Hub machine pools use labels you define, so point runs-on at your pool label:

jobs:
  build:
    runs-on: bitrise-m4-pro # Your Build Hub machine pool label

    steps:
      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/checkout@v4

On Blacksmith, Depot, Namespace, and Warp, all standard Harden-Runner capabilities are available: audit mode, block mode with allowed endpoints, Policy Store integration, and security insights in the job log and dashboard. Setup details for every provider are in the Harden-Runner documentation.

Why Bitrise matters for mobile teams

Bitrise support extends Harden-Runner to the macOS runners where iOS pipelines live. These machines concentrate exactly the credentials attackers want: Apple signing certificates, provisioning profiles, and App Store Connect API keys. A compromised dependency in an iOS build gets all of that, plus a trusted path into an app that ships to end users. Bitrise macOS runners now get the same runtime monitoring as every other runner in your fleet.

Wherever your GitHub Actions jobs run, the security model stays consistent: one action, one dashboard, the same detections. That consistency is why 13,000+ open-source projects and enterprises run Harden-Runner.

Harden-Runner is open source. Add it to your workflows today, on GitHub-hosted or third-party runners. View Harden-Runner on GitHub

Running GitHub Actions on Bitrise, Blacksmith, Depot, Namespace, or Warp? See how Harden-Runner secures your whole fleet. Start free or request a demo

Explore Related Posts