GitHub-hosted Ubuntu 24.04 runners: isolation guarantees and auditability / GitHub-hosted runners: pre-execution trust, isolation, and audit capabilities

[aifamily-founder]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

Hello GitHub Community,

We are evaluating standard GitHub-hosted Ubuntu 24.04 runners for an offline, security-sensitive validation workflow using synthetic data.

Before selecting a runner architecture, we would like to understand which security properties are enforced by GitHub's infrastructure, which must be implemented by the workflow owner, and which cannot be independently verified.

1. Pre-execution admission

Is there a GitHub-enforced mechanism to verify an approved repository revision, the resolved versions of third-party Actions, and executable dependencies before any untrusted workflow code runs?

Or must these checks be implemented within the job itself?

2. Continuous process and filesystem isolation

Within a standard GitHub-hosted runner job, what guarantees exist against interference from other processes running under the same OS user?

Specifically, can the platform enforce and demonstrate protection against writable filesystem paths, inherited write handles, process attachment, or modification of validation inputs during execution?

3. Trusted supervision and revocation

Does GitHub-hosted Actions provide a supervisor or policy enforcement mechanism outside the control of workflow code that can authorize or reject execution stages and enforce revocation?

Or would this require a separately managed external system?

4. Audit and attestation evidence

Which GitHub-controlled records can customers obtain to independently verify runner image identity, execution boundaries, enforcement decisions, and revocation behavior?

Are any of these guarantees documented but not exposed as per-run evidence?

We are not reporting a security vulnerability or requesting a review of private application code. We are trying to identify the documented security boundaries and limitations of standard GitHub-hosted runners.

Links to official documentation or guidance from GitHub engineers would be greatly appreciated.

Thank you!

[Sagargupta16]

Short version: GitHub enforces the boundary at the job (a fresh VM) and at the gates before a job starts; inside the job there is no isolation, and the per-run evidence you can get is the image identity, the OIDC claims and attestations on what the job produced.

1. Pre-execution admission. Nothing on GitHub's side verifies an "approved revision" before the job runs; the job runs whatever the triggering ref contains. What GitHub does enforce before any step executes is the Actions policy: an allow-list of actions and reusable workflows and the "Require actions to be pinned to a full-length commit SHA" setting (Managing GitHub Actions settings), plus workflow dependency lockfiles, which record the exact commit for every action (including transitive ones) and verify each source repository's identity at run time (Using third-party actions). A "Require lockfile" protection can make that mandatory (Control workflow execution). Executable dependencies you install with pip, npm or apt are entirely yours to pin and hash-check inside the job.

2. Isolation inside a job. "With the exception of single-CPU runners, each GitHub-hosted runner is a new virtual machine (VM) hosted by GitHub." Single-CPU runners are "hosted in a container on a shared VM" (docs). Inside that VM the runner user has passwordless sudo on Linux and macOS, and Windows runs as administrator with UAC disabled (Administrative privileges). Every step in a job runs in that VM as the same user, so nothing separates one step from another. The security docs go further: "The individual jobs in a workflow can interact with (and compromise) other jobs", through environment variables, a shared directory a later job reads, or the Docker socket, and a compromised action gets every repository secret and the GITHUB_TOKEN (Using third-party actions). GitHub documents no mechanism that protects validation inputs from other code in the same job. On hosted runners the strongest boundary is the job, because each one gets a fresh VM: put untrusted code and the validation step in separate jobs, pass data as artifacts, and check the artifact digest in the validation job, since the producing job controls what it uploads.

3. Supervision and revocation. The only GitHub-side gate that an external policy engine can drive is the environment protection rule: required reviewers (the job sits in "Waiting", fails after 30 days), wait timers, and custom protection rules implemented as a GitHub App that approves or rejects via the deployment_protection_rule webhook. Environment secrets are withheld until every rule passes (Control deployments). That gates stage starts, not behaviour mid-job; revocation during a job is limited to cancelling the run.

4. Evidence you can obtain.

• Runner image identity: the "Set up job" log, "Runner Image" section, names the image, its version and links the included-software manifest; an SBOM per image build is attached to each actions/runner-images release as sbom.IMAGE-NAME.json.zip.
• Execution context: the OIDC token carries runner_environment: github-hosted, repository, ref, sha, job_workflow_ref and more, signed by GitHub, so a relying party can verify where a job ran (OIDC).
• Outputs: artifact attestations bind an artifact to its source and build instructions via Sigstore. That is SLSA v1.0 Build Level 2; Level 3 needs the build in a reusable workflow. Private repositories use GitHub's own Sigstore instance, which has no transparency log (Artifact attestations).

Not exposed per run: the docs describe no VM or hypervisor attestation and no record of in-job enforcement decisions. If demonstrated in-job isolation or an out-of-band supervisor is a hard requirement, that is a self-hosted ephemeral runner design (one VM or pod per job, your own policy engine) rather than something the hosted runners provide.