Is WarpBuild SOC 2 Compliant?

Answer

Yes. WarpBuild is SOC 2 Type 2 certified with three Trust Services Criteria, Security, Availability, and Confidentiality, as stated in the runner security documentation, and the report and its scope are requested through trust.warpbuild.com. That trust center is the evidence path a reviewer uses, so the report arrives through a documented request rather than through a sales thread.

Here is the attestation stated exactly, in the shape a vendor questionnaire asks for it.

Type 2 is the part reviewers care about, because a Type 2 report covers how controls operated across a period rather than how they were designed on a single day. The SOC 2 Type 2 definition covers the report structure and the criteria vocabulary if your questionnaire uses different wording.

Detail

What each criterion maps to in the documentation

The report is the audited evidence. The documentation states the control facts a reviewer usually wants before the report request clears, and the three criteria in scope line up with three published statements.

• Security. Each runner runs in its own virtual machine. The virtual machines are created on demand and destroyed after each build, and they are not reused, so no data is left behind for a later job.
• Confidentiality. Each runner has its own encrypted storage volume, created on demand and destroyed after each build. When caching is enabled, the cache is encrypted and stored in a location that is only accessible to your runner. WarpBuild does not access or store any build secrets; secrets stay in your source code repository and are only accessible to your runner environment.
• Availability. The report is the evidence for this criterion. This page publishes no uptime figure, so a reviewer who needs availability numbers should ask for them with the report request.

All three statements come from the same runner security documentation page, which is the single page to send a reviewer first.

The facts a reviewer asks for next

Attestation questions are usually followed by scope questions. Four answers cover most of them:

• Isolation unit. One virtual machine per job, with no reuse between builds, per the runner security documentation.
• Storage lifetime. One encrypted volume per runner, created on demand and destroyed when the build ends, per the runner security documentation.
• Catalog under review. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, per the runner catalog, and every label in that catalog resolves to the per-job machine described above.
• Regions. US and EU are the regions WarpBuild names publicly for hosted runners, per region-specific infrastructure.

Where your own account carries the evidence

Teams running BYOC keep the runner instance inside their cloud account, which moves part of the evidence from the vendor attestation to their own audit log. The BYOC security hardening documentation states the model: each job runs on a distinct, freshly provisioned EC2 instance that is terminated after the job completes, and the permissions available to runner instances are exactly what you provide through security groups and IAM instance profiles, with no additional permissions injected into runner workloads.

The same page publishes the hardening checklist a reviewer can verify in your console:

• Deploy the stack in a dedicated VPC or a dedicated AWS account.
• Remove all inbound rules from the runner security group. Outbound-only rules still let runners reach WarpBuild and the required AWS services, because runners initiate the connections.
• Deny traffic between runner instances with Network ACLs, so a compromised job cannot move sideways.
• Require IMDSv2 per runner, which closes the SSRF path to instance credentials.
• Set an S3 lifecycle policy on the stack bucket so cache and telemetry objects expire.

Under that split, the SOC 2 Type 2 report covers the WarpBuild service, and your CloudTrail, your IAM policies, and your VPC configuration cover the instances.

What is not claimed

The compliance statement on this site is SOC 2 Type 2 with Security, Availability, and Confidentiality. Processing Integrity and Privacy are the two remaining Trust Services Criteria categories, and neither appears in the scope stated above. No other framework is claimed on this page. If your questionnaire asks about a different standard, ask through trust.warpbuild.com and treat what comes back as the answer instead of anything inferred from this page.

Running the review against a real repository

A pilot is one label change on one job:

name: security-pilot
on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v5
      - name: Install dependencies
        run: npm ci
      - name: Test
        run: npm test

The security review checklist lists the five questions a runner vendor review covers and the documentation page behind each answer.

Related Questions

Which Trust Services Criteria does the WarpBuild SOC 2 Type 2 report cover?

Three: Security, Availability, and Confidentiality. The runner security documentation states the attestation and the criteria, and the report itself is requested through trust.warpbuild.com. The SOC 2 Type 2 definition covers what the criteria mean if your questionnaire words them differently.

How do we get a copy of the SOC 2 Type 2 report?

Request it in the WarpBuild trust center at trust.warpbuild.com, or email [email protected]. The same request covers the supporting security documentation a reviewer needs alongside the report, and the security review checklist shows where that request sits in the review sequence.

Does the attestation cover runners running inside our own cloud account?

A BYOC runner instance lives in your account, so your own cloud audit log and IAM configuration are the evidence for it. Each job runs on a freshly provisioned instance that is terminated when the job finishes, and the permissions it carries are the ones you attach through your security groups and instance profiles, per the BYOC security hardening documentation. The isolation model for hosted runners is covered in are GitHub Actions runners secure.