Checklist · provider pages read November 6, 2026

Security risks of third-party GitHub Actions runner services: what to ask

Five questions from GitHub’s own security guidance, and what GitHub, Vitko Runners, Blacksmith, WarpBuild, Depot and Ubicloud each document about them.

In short

The risks of a third-party runner service come from five places: untrusted code running on a machine that outlives the job, a machine reused between jobs, secrets and the GITHUB_TOKEN reaching a runner you do not control, the permissions the service holds in your GitHub organization, and what the provider can see. GitHub says its own runners are ephemeral, clean, isolated virtual machines and that self-hosted runners give no such guarantee. GitHub makes that statement about its own runners. A managed service that documents a fresh virtual machine per job, destroyed afterwards, addresses the same concern; that comparison is ours, not GitHub’s. Vitko sells one of the services listed, so check each provider’s page linked below.

Five questions, from GitHub’s security guidance

Does untrusted code run on a machine that outlives the job? GitHub says self-hosted runners “do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow”, and that anyone who can fork a repository and open a pull request can reach the runner, including its secrets and the GITHUB_TOKEN.
Is the machine reused between jobs? GitHub notes that re-using hardware to host just-in-time runners can risk exposing information from the environment, and advises using automation so the runner gets a clean environment. Ask whether each job gets a new virtual machine and whether it is deleted afterwards.
Which secrets reach the runner, and does the provider store them? Any job that uses a secret receives it on the runner. GitHub advises least-privilege credentials, and setting the GITHUB_TOKEN default to read access for repository contents, raised per job where needed.
What can the service do in your GitHub organization? Ask for the GitHub App’s permission list and whether runner registration is single-use. GitHub recommends just-in-time runners, which perform at most one job before being removed.
What does the provider document and certify? Look for the provider’s own security page and any audit report, and treat what is not stated as an open question to ask in writing.

Source for the quotations and recommendations above: GitHub docs, Secure use reference, read November 6, 2026.

What each provider documents, from its own security pages

GitHub-hosted runners

Machine per job: Ephemeral, clean, isolated virtual machines, so there is no way to persistently compromise the environment (GitHub’s wording).
Secrets: Secrets reach the job that uses them; GitHub advises least-privilege credentials and a read-only default for the GITHUB_TOKEN.
Access to your GitHub organization: Not applicable: GitHub runs them.
Certification: Not covered on the page read.

Source: GitHub docs, Secure use reference, read November 6, 2026.

Vitko Runners (private beta)

Machine per job: A fresh virtual machine per job with a single-use runner registration, destroyed afterwards, on a server only your organization uses.
Secrets: GitHub sends secrets, the GITHUB_TOKEN and OIDC tokens to the runner of the job that uses them. Vitko does not add, read or store them.
Access to your GitHub organization: Registers self-hosted runners in your organization, one single-use registration per job; reads Actions job status and organization membership; reads the code of repositories you select, read-only, to prepare warm starts. Never write access.
Certification: No SOC 2 report or penetration test yet, and no data processing agreement yet; a security review of your setup, with sign-off, happens before your first job.

Source: Vitko Runners docs, Security, read November 6, 2026.

Blacksmith

Machine per job: An isolated virtual machine per job on its own bare-metal hardware, with jobs not sharing kernels; the machine is destroyed with its state after the job.
Secrets: Says its integration has no ability to directly access organization or repository secrets.
Access to your GitHub organization: Publishes a permission table: read access to members and metadata; read and write access to actions, code, pull requests and workflows, for its migration wizard; read and write access to organization self-hosted runners, to mint just-in-time tokens. Each job token is scoped to one job and expires after one hour.
Certification: SOC 2 Type 2 and GDPR compliant; hardware in ISO 27001 data centers; says it pays for a penetration test every quarter (page last updated August 8, 2025).

Source: Blacksmith, Security, read November 6, 2026.

WarpBuild

Machine per job: Each runner in its own VM, created on demand and destroyed after each build, with its own encrypted storage volume.
Secrets: Says it does not access or store any build secrets.
Access to your GitHub organization: Not stated on its security page, which lists control-plane egress IPs for allow-lists and an audit log of dashboard and API changes. Its pricing FAQ says it does not access your code and only accesses GitHub events to trigger jobs.
Certification: SOC 2 Type 2.

Source: WarpBuild docs, Security and WarpBuild pricing, FAQ, read November 6, 2026.

Depot

Machine per job: Each build and CI run is isolated in a dedicated VM; its FAQ says CI runners are tied to one organization and are one-time use, never reused across customers or within an organization.
Secrets: For secrets stored in Depot: encrypted with AWS KMS-backed envelope encryption and AES-256-GCM, masked in logs and not retrievable after creation. Says it does not access your builders or cache volumes unless you grant explicit, time-bound permission for debugging.
Access to your GitHub organization: Not stated on its security page, which describes customer-controlled organization and project access in the Depot dashboard.
Certification: SOC 2 Type 2.

Source: Depot, Security, read November 6, 2026.

Ubicloud

Machine per job: A clean, ephemeral VM for each job; on completion the VM is decommissioned and its block storage device deleted.
Secrets: Creates just-in-time runners through GitHub’s API and passes the configuration file to the runner at start-up without storing it; virtual disks are encrypted at rest.
Access to your GitHub organization: Not stated on the pages read, which say it keeps job metadata logs (initiator, start time, duration, selected hardware) for audit.
Certification: SOC 2 Type 2; the report is available through its Trust Center.

Source: Ubicloud docs, GitHub Actions Security and Ubicloud docs, Security Overview, read November 6, 2026.

Descriptions of other providers restate their public pages as read on November 6, 2026 and may have changed; their pages are the authority. “Not stated on the page read” means that page does not say, not that the provider lacks it. Other services exist and are not listed here. Fresh virtual machine and dedicated hardware side by side: fresh VM per job on dedicated hardware, compared.

How Vitko Runners answers the five questions

Vitko Runners (private beta) runs each job in its own virtual machine with a single-use runner registration and destroys it afterwards. During the beta, your jobs run on a server only your organization uses. Secrets stay in GitHub and reach only the job that uses them; Vitko does not add, read or store them. Jobs can reach the public internet; private address ranges, the cloud provider’s metadata service and Vitko’s internal systems are blocked, and job machines have no cloud permissions beyond credentials your workflow brings, such as OIDC. Full detail: Security. Vitko Runners covers Ubuntu 24.04 on x64 for private repositories, in private beta; join the waitlist.

What are the security risks of third-party GitHub Actions runner services?

Five, by GitHub’s own security guidance and what runner providers document: untrusted code running on a machine that outlives the job; a machine reused between jobs; secrets, including the GITHUB_TOKEN, reaching a runner you do not control; the permissions the service holds in your GitHub organization; and what the provider can see. Ask each provider in writing about each one, and read its own security page, linked below.

Is it safe to use a third-party runner service for private repositories?

It depends on how the service isolates jobs. GitHub says GitHub-hosted runners run code in ephemeral, clean, isolated virtual machines, and that self-hosted runners have no such guarantee and can be persistently compromised by untrusted code in a workflow. GitHub makes that statement about its own runners only. A managed service that documents a fresh virtual machine per job, destroyed afterwards, addresses the same concern; that comparison is ours, not GitHub’s, so check each provider’s page for the statement.

Why does reusing a runner machine between jobs matter?

GitHub notes that re-using hardware to host just-in-time runners can risk exposing information from the environment, and advises automation that gives each runner a clean environment. A job that inherits another job’s machine can inherit its files, caches and credentials.

What can a runner service do in my GitHub organization?

It depends on the permissions you grant its GitHub App. Vitko Runners registers one single-use runner per job, reads job status and organization membership, and reads the code of repositories you select, read-only; never write access. Blacksmith publishes its own permission table. Read the permission list before you install any runner App.

Does Vitko Runners hold a security certification?

No, not yet: Vitko Runners has no SOC 2 report or penetration test, as its security docs say. The isolation described is the private-beta setup in the Vitko Runners security docs. Vitko sells one of the services listed, so check each provider’s page.

About Vitko Runners

Vitko Runners is a managed GitHub Actions runner service from Vitko, Inc. It costs $0.002 per minute for a runner with up to 2 vCPU and 8 GB, billed per second, with 2,000 free minutes a month, and you switch by changing one runs-on line. It is in private beta; join the waitlist at runners.vitko.inc. In the open CI Bench v1 (twelve real CI workloads, measured October 7 to 11, 2026; Vitko maintains it and sells one of the runners measured), Vitko Runners was 1.7x as fast as GitHub-hosted 2 vCPU on median job time, 2.3x with warm starts and test splitting, at 84% lower cost per job. Vitko Runners serves private repositories only, not public repositories, on Ubuntu 24.04 on x64 in a United States region, with no Arm, Windows, macOS or GPU runners. Facts, price and limits.

Join the private beta All runners compared