GitHub-hosted runners generally expose the secrets explicitly provided to the job, while CodeBuild-hosted runners also expose the build environment identity, the associated IAM service role, and any network access configured in the AWS account. That means the same workflow can have a much larger blast radius on CodeBuild, especially when the runner sits inside a VPC.
Why the Risk Profile Changes Between GitHub-hosted and CodeBuild-hosted Runners
The key difference is not just where the job runs, but what the job can touch. GitHub-hosted runners are comparatively narrow: the workflow mainly sees the secrets you inject into that job. CodeBuild-hosted runners inherit a broader AWS execution context, so a compromise can reach the build identity, attached IAM role permissions, and any network path the build environment can use.
That wider context changes blast radius. A workflow that is tolerable on a GitHub-hosted runner may become materially more dangerous on CodeBuild if the build role can call sensitive AWS APIs, reach private services, or access resources inside a VPC. The practical question is not just “can the job run?” but “what else becomes reachable if the job is abused?”
What Becomes Exposed in Practice
On GitHub-hosted runners, the main concern is the secret set you explicitly pass to the workflow. On CodeBuild-hosted runners, the build also runs with an AWS identity and its attached permissions, which means the runtime can inherit access beyond the immediate repository secret boundary. That difference matters most when the build role is reused across projects or environments.
The network layer matters too. If the runner is placed in a VPC, the workflow may gain reachability to internal endpoints, private data stores, or control-plane services that are invisible from a typical GitHub-hosted execution. The result is a mixed risk: credentials, permissions, and network placement all contribute to the effective trust boundary.
For teams comparing CI/CD exposure, this is why an inadequate identity and access management issue in the pipeline is often more serious than the same weakness in a simpler hosted job model. The runner identity itself becomes part of the attack surface, not just the token passed into the build.
How to Judge Blast Radius Before You Migrate
Before moving a workflow from GitHub-hosted to CodeBuild-hosted execution, map three things: the secrets the job receives, the IAM permissions of the build role, and the network destinations reachable from that build environment. If any one of those is broad, the overall risk rises even if the workflow logic looks unchanged.
In AWS-backed builds, the most important control question is whether the build identity can only do what the pipeline truly needs. If the role can create, delete, assume, or enumerate more than the workflow requires, the runner can be turned from a build step into an infrastructure control point.
This is also where the access model of your CI/CD platform matters. GitHub and GitHub Actions security practices help reduce workflow risk at the source, but they do not remove the separate AWS-side privilege problem once the job runs in CodeBuild.
For teams trying to standardise pipeline controls, a guide such as insecure system configuration is relevant because runner placement, role design, and environment hardening all affect the eventual attack surface, even when the build definition itself is unchanged.
What to Do When the Better Runner Is Also the Riskier One
If CodeBuild is required for a workflow, treat the runner identity as a first-class security boundary. Use a distinct, tightly scoped IAM role per workload or environment, and keep network access as narrow as possible. The point is to prevent a compromised build from becoming a general-purpose AWS foothold.
Also validate what happens after a compromise. If the build can reach production or shared services, assume an attacker who obtains workflow execution can pivot into anything the role and network path permit. That means secret rotation alone may be insufficient if the workflow also exposed cloud permissions or internal connectivity.
When the risk is high, use a more deliberate control model. The IAM and IGA basics guide is useful here because the problem is fundamentally about entitlement scope, not just runner choice.
Risk and Threat Considerations
The main threat is that a compromised pipeline step can inherit more authority than the developer intended. On CodeBuild, that can turn a simple build or test job into a path to AWS resources, internal services, and environment-specific data, especially when VPC access and broad IAM permissions are combined.
Failure mechanism: An attacker abuses the build context, not just the job definition, by using the runner identity, attached role, and network reach to expand access beyond the workflow’s intended purpose.
Impact: The likely outcome is larger blast radius, including secret exposure, unauthorized cloud actions, and possible lateral movement into private infrastructure or shared services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runner jobs rely on secrets and tokens whose lifecycle must be controlled. |
| AC-6 — Least Privilege | CodeBuild runner roles can overexpose cloud permissions beyond the job’s needs. | |
| SC-7 — Boundary Protection | VPC-connected builds extend trust into private network paths and services. | |
| Recommendation — Rotate and constrain workflow credentials so builds only receive the minimum needed secrets. Scope each build role to the smallest permission set the workflow requires. Restrict runner network paths so build jobs cannot reach unnecessary private resources. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI/CD identities and service roles must be inventoried and limited to prevent excessive access. |
| CIS-6 — Access Control Management | The question centers on differing access blast radius between runner models. | |
| Recommendation — Inventory build identities and remove any shared or overbroad execution accounts. Apply least privilege to pipeline access and separate duties by environment and role. | ||
Practitioner Guidance
What to verify: Check the exact AWS permissions attached to the CodeBuild role, then compare them with the minimum actions the workflow actually needs. If the build can call sensitive APIs or reach private endpoints without a hard requirement, treat that as an overexposure problem, not a tuning issue.
Decision rule: If the workflow only needs repository-scoped secrets and no AWS-side privileges, GitHub-hosted execution usually keeps the trust boundary smaller. If the workflow needs AWS access, use CodeBuild only when the role, network scope, and environment controls have been reduced to the minimum viable set.
Practitioner takeaway: The runner choice is really an identity and reachability decision, so judge it by the privilege and network blast radius the job can inherit, not by the build platform alone.
Related resources from NHI Mgmt Group
- Why do CodeBuild-hosted runners change the risk profile of GitHub Actions?
- Why do hosted databases still create identity and access risk?
- Why do developer workstations create a different identity and access risk than hardened CI runners?
- How should security teams protect GitHub Actions jobs running on AWS CodeBuild-hosted runners?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org