A CI runner can compile code, execute tests, access caches, publish packages and deploy production workloads. It may also execute a pull request containing code written by someone who has no permission to access any of those credentials.
That is the trust boundary: code that needs to be tested is not automatically code that can be trusted.
Cost and build speed matter, but runner architecture that reduces execution time while granting untrusted code access to production has optimized the wrong metric. Measure cost per completed build without treating utilization as more important than isolation.
Separate the jobs by trust level
Pull request tests, release builds and production deployments should not inherit identical permissions.
A pull request test might need a repository checkout and public dependencies. A release job needs a verified artifact and a tightly scoped package publishing identity. Production deployment needs authorization for one target environment and, preferably, only the reviewed artifact from the earlier stage.
Separate the underlying runner pools and credentials to match those boundaries. A private repository does not automatically imply every contributor and third-party dependency is equally trusted.
A clean container scan can be one of those job outputs, but it does not prove that the runner was isolated or that the deployed workload has safe permissions.
Why privileged pull-request workflows are dangerous
GitHub's secure-use reference warns that privileged workflow triggers can create serious risk when combined with untrusted source code.
A job using the pull_request_target or workflow_run event must not blindly check out and execute untrusted pull request code with a write-capable token or access to protected secrets. The vulnerability is the crossing of a trust boundary, not the name of the event in isolation.
If the workflow only needs to label a pull request or comment on it, keep the privileged job small and treat pull request content as untrusted data. Do not execute attacker-controlled scripts in that privileged context.
Artifacts passed from untrusted jobs to privileged workflows must also be verified. Uploading an artifact through GitHub Actions does not make its contents trustworthy.
The GitHub pull_request_target guidance describes additional platform protections and policy behavior. Recheck it before implementation because platform defaults change.
A self-hosted runner is not isolated by default
Self-hosted runners can deliver excellent value for CPU-heavy builds, local NVMe caching and private tools. But installing the runner binary on one VM does not reproduce the isolation normally provided by a disposable hosted VM.
A long-lived machine can retain credentials, modified binaries, cached build outputs or persistence introduced by a previous job. When multiple repositories or trust levels share its execution environment, a compromise can affect later jobs.
GitHub explicitly cautions against broad use of self-hosted runners for untrusted public pull requests. The same question applies to private repositories: who can submit executable workflow code, and what can that runner reach?
Using ephemeral or just-in-time runner registration is helpful, but registration lifecycle alone is not a guarantee that the disk, host or cache is clean after job execution.
What ephemeral actually needs to mean
For stronger isolation, an architecture should aim for a clean execution environment per job, short-lived credentials, access only to required dependencies, controlled access to private networks and verified cleanup after execution.
A container deleted after a job is not necessarily a strong security boundary if it held a privileged host mount or the host's Docker socket. Reusing hardware can be efficient, but the team must understand which state survives and whether one job can affect the next.
When CI runs Flutter, Android, Rust and container builds concurrently, the risk assessment must include toolchain integrity, writable shared caches and workspace separation. These become multi-tenant boundaries even when all workloads belong to the same company.
This is general architecture guidance, not a claim that a particular BBB runner system has these defects.
Treat cache sharing as a supply-chain decision
Persistent caches reduce setup time, but a shared cache may retain executable or generated material from a less-trusted job.
Use trust-aware cache separation, integrity checks and keys that represent the relevant toolchain and dependency inputs. Do not allow an untrusted job to publish artifacts into the location a privileged release later trusts without verification.
The goal is not to disable every cache. It is to ensure the build-performance optimization does not silently bypass code-review and artifact-integrity decisions.
Make build identities short-lived and narrow
Avoid handing static production cloud keys to ordinary build jobs. Where supported, use short-lived federated identities or OIDC-based credentials restricted by repository, environment and intended operation.
Limit the GitHub token permissions granted to each workflow. A test job normally should not need to create a release or change repository settings.
Secret masking in logs is not a permission boundary. A compromised process can use credentials without ever printing them. For Kubernetes workloads, apply the same ownership and access thinking used in shared secrets with External Secrets Operator.
A safe acceptance test for your build fleet
An architecture diagram cannot demonstrate that jobs are isolated. A bounded test can.
Create a disposable test pull request and use harmless canary resources to check that a low-trust job cannot assume a test-only deployment identity, modify a trusted cache or access an unrelated internal service. Confirm the unauthorized operations are denied while approved build workflows still function.
Then check cleanup and repeatability: can a later trusted job see state left by the untrusted run? Use synthetic credentials and isolated resources, never real secrets or destructive payloads.
Record the runner identity, privileges, expected denial and observed outcome. The result should be reproducible.
The decision for engineering leadership
A build farm is both a developer-productivity system and a privileged supply-chain component.
A runner that is cheap but shares production credentials with untrusted pull requests is not a bargain. A runner that is fully ephemeral but cannot be restored or patched reproducibly is not fully managed either.
For teams designing CI runner scale sets, private build fleets and safe deployment flows, Big Bad Byte DevSecOps engineering should review isolation and credential scope alongside utilization, caching and cost. Broader DevOps and Kubernetes consulting covers the pipeline and platform changes needed to put those boundaries into practice.