A Security Review Checklist for GitHub Actions Runners

A GitHub Actions runner vendor clears a security review when five questions have documented answers: how jobs are isolated from each other, how long build storage lives, whether the vendor can read your secrets, what compliance attestation backs the claims, and where runner traffic goes. WarpBuild publishes all five answers in its documentation, and this page collects them in the order reviewers usually ask.

Below is the question list with the documented answer next to each item, the isolation and storage model in detail, the compliance attestation and how to request it, and the BYOC configuration for teams whose policy requires runners inside their own cloud account.

Answer

Security reviews stall when the answers live in a sales thread rather than in documentation a reviewer can open without asking anyone. Every answer in the table below points at a page you can send to a reviewer directly.

Two deployment shapes sit behind those answers, and a reviewer should know which one is under review before reading further.

Hosted runners. WarpBuild operates the fleet. You change one runs-on label per job and the runner comes up on WarpBuild infrastructure. The isolation, storage, and secret-handling answers in the table apply here, and the compliance evidence is the SOC 2 Type 2 report.

BYOC runners. WarpBuild creates and manages runner instances inside your AWS, GCP, or Azure account. The instances, the network they sit in, and the object storage bucket used for caches and telemetry belong to you. The evidence a reviewer wants comes out of your own cloud console and audit log rather than from a vendor attestation.

US and EU are the regions WarpBuild names for hosted runners. Placement detail for teams with a written residency clause is covered on the US data residency page.

Isolation and Data Handling

The isolation model is a per-job virtual machine with a lifetime equal to the job.

Each runner runs in its own virtual machine. The virtual machines are created on demand and destroyed after each build, so builds are isolated from one another and no data is left behind. The virtual machines are ephemeral and are not reused. That single fact answers most of the multi-tenancy section of a review: there is no long-lived host that runs your job today and someone else's job tomorrow, and no warm pool of machines carrying state from a previous run.

Storage follows the same lifetime. Each runner has its own encrypted storage volume, created on demand and destroyed after each build. The source checkout, downloaded dependencies, compiled output, and test artifacts all live on that volume and go away when the virtual machine goes away. When caching is enabled to speed up builds, the cache is encrypted and stored in a location that is only accessible to your runner.

Secrets never enter the WarpBuild side of the boundary. WarpBuild does not access or store any build secrets. Secrets are stored in your source code repository and are only accessible to your runner environment, which means the secret-handling row on a vendor questionnaire is answered by GitHub's secret storage plus the ephemeral runner, with no additional vault or credential broker introduced by the runner vendor.

Reviewers usually want the runner inventory too, since the labels a workflow can reference define what the review covers. The table below lists representative labels with the shape and the published per-minute rate from the pricing page, checked on 2026-08-13.

Every runner in that table gets the same treatment: its own virtual machine, its own encrypted volume, both destroyed when the job ends. The storage column is the size of the ephemeral disk, not a persistent volume that survives the run.

A reviewer who wants to see the change under review is usually satisfied by the diff itself, because adopting these runners is a label swap inside the workflow file that is already in your repository and already goes through code review:

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}

  arm-tests:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/test-arm64.sh

  windows-integration:
    runs-on: warp-windows-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration.ps1

The secrets.API_TOKEN reference in that job behaves exactly as it does on GitHub-hosted runners. GitHub injects the value into the job environment, the runner uses it, and the virtual machine holding it is destroyed at the end of the job.

Compliance

WarpBuild is SOC 2 Type 2 certified with three Trust Services Criteria: Security, Availability, and Confidentiality. The controls required for that certification are implemented, and the report plus the supporting security documentation are requested through trust.warpbuild.com. Questionnaires, data processing agreements, and follow-up questions from a review go to [email protected].

Two practical notes for the person assembling the evidence package.

First, an attestation covers the vendor's control environment. It does not describe your workflows, your repository permissions, or the third-party actions your jobs run. A complete review pairs the SOC 2 Type 2 report with your own controls on the GitHub side: who can edit workflow files, which actions are allowed, and how repository secrets are scoped.

Second, obligations that arrive from a customer contract or from a GDPR commitment usually turn into three narrow questions for the runner layer: where the machine runs, where the storage sits, and what evidence proves both. Hosted runners answer those through the SOC 2 Type 2 report and the region the fleet runs in. BYOC answers them from artifacts your own account already produces, because the instances and the bucket show up in your inventory, your audit log, and your tagging and cost reports.

The rest of the procurement surface is short. SSO is available for a flat $250 per month, whatever the user count, and the current rates are on the pricing page.

BYOC and Network Controls

For reviewers whose policy requires runners inside the company's own account, BYOC is the configuration to evaluate. BYOC runs on AWS, GCP, and Azure. Setup is three steps: connect the cloud account, which creates the IAM role or service account WarpBuild uses; create a stack, which fixes the region, network, and object storage bucket; and create a custom runner, which fixes instance types, disks, and IP configuration.

The security model documented for AWS has two properties a reviewer cares about.

Ephemeral instances. Each GitHub Actions job runs on a distinct, freshly provisioned EC2 instance that is terminated after the job completes. There is no shared state and no cross-contamination between jobs.

User-controlled permissions. The permissions available to runner instances are exactly what you choose to provide through security groups and IAM roles or instance profiles. WarpBuild does not inject additional permissions into runner workloads. The stack provisions networking infrastructure and an S3 bucket used for cache data, and all IAM permissions for runner workloads are managed independently by you through instance profiles.

Outbound access is the other half of the network question. The documented destinations a BYOC runner needs are short, which makes an egress allowlist practical:

Inbound access is simpler still. GitHub Actions runners do not need to accept inbound connections at all, so the hardening guidance is to remove every inbound rule from the runner security group and to avoid attaching any group that allows inbound traffic from 0.0.0.0/0 or from the whole VPC range. Lateral movement between runners is handled with Network ACLs on the subnets, since runners have no reason to talk to each other.

On the control plane side, calls that WarpBuild makes to GitHub leave from three static egress IPs: 3.13.16.127, 3.141.157.169, and 3.151.226.250. Add them to your GitHub IP allow list, or to the inbound rules of a GitHub Enterprise Server instance, when your organization restricts that traffic.

Least-privilege IAM is where most of the remaining review effort goes. An instance profile is configured per runner in the WarpBuild dashboard, so permissions can be scoped per workload type rather than granted to the whole fleet. A job that only needs to push images gets a policy shaped like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecr:GetAuthorizationToken"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<your-repo>"
    }
  ]
}

The remaining hardening steps from the BYOC security hardening guide are worth copying into a review checklist as they are: deploy the stack in a dedicated VPC or a dedicated AWS account so the blast radius and the audit boundary are both small; require IMDSv2 on every runner to protect instance credentials against SSRF; scope S3 bucket lifecycle policies so cache data expires; and tag stack resources for cost attribution and access control.

Terraform support exists for BYOC on AWS, which turns the placement and the permissions into reviewable code rather than a console click, and it gives a reviewer a diff to sign off on when the configuration changes later.

A short evaluation path usually beats a long questionnaire. Sign up, use the $10 free credits to run one real pipeline on hosted runners, and confirm the labels and images fit your builds while the security review runs in parallel. If the review lands on runners inside your own account, move the same workflow to a BYOC runner in AWS and let the evidence come from your own console. The narrower questions about source code handling are answered on do GitHub Actions runners store my source code, and the general version of this topic is on are GitHub Actions runners secure.

FAQ

Does WarpBuild have access to our build secrets?

No. WarpBuild does not access or store any build secrets. Secrets stay in your source code repository and are reachable only from your runner environment while the job runs.

How long does build storage live on a WarpBuild runner?

For the length of the build. Each runner has its own encrypted storage volume, created on demand and destroyed after each build, and the virtual machine around it is destroyed at the same time.

What compliance attestation can WarpBuild provide to a reviewer?

SOC 2 Type 2 with three Trust Services Criteria: Security, Availability, and Confidentiality. Request the report and the supporting security documentation at trust.warpbuild.com.

Can runners stay inside our own cloud account?

Yes. BYOC runs on AWS, GCP, and Azure. Each job runs on a freshly provisioned instance in your account that is terminated when the job finishes, and the permissions it carries are the ones you attach through your own IAM roles and security groups.