
Runtime Security for AWS CodeBuild-Hosted GitHub Actions Runners
StepSecurity announces Harden-Runner support (v2.20.1+/v2.21.0) for GitHub Actions jobs executed on AWS CodeBuild-hosted just-in-time runners, including custom container images. The post frames the feature around CVE-2025-8217, where a threat actor exfiltrated GitHub tokens by dumping CodeBuild build-environment memory via a malicious pull request to compromise the AWS Toolkit for Visual Studio Code and AWS SDK for .NET repos, and notes that CodeBuild runners additionally expose an assumed IAM service role and VPC network reachability that GitHub-hosted runners don't have. Harden-Runner correlates outbound network calls, file writes, and process executions to the workflow step that triggered them and unifies detection across GitHub-hosted, self-hosted, ARC, and CodeBuild-hosted runner fleets.
What it is
StepSecurity's Harden-Runner now supports GitHub Actions jobs running on AWS CodeBuild-hosted runners. EC2 compute support starts at Harden-Runner GitHub Action v2.20.1; v2.21.0 adds Linux-container-on-EC2 support, which covers the custom-image scenario (images from Amazon ECR and external Docker registries both work).
How it works
CodeBuild registers itself as a just-in-time GitHub Actions runner, so a job that would run on ubuntu-latest instead runs in your AWS account, in your VPC, under your IAM service role. Harden-Runner captures outbound network calls, file writes, and process executions on the runner and correlates each to the workflow step that caused it. It raises the memory-read technique behind CVE-2025-8217 (the same technique used in the tj-actions/changed-files compromise) as a runtime detection with an attached triage runbook.
Preconditions
Two settings are configured on the CodeBuild project, not in the workflow:
- Host kernel must be
kernel-6— the agent needs kernel-level features it provides. The post flags this as the setting most likely to trip you up. - Privileged mode is required for the same reason.
The project's webhook must be configured for WORKFLOW_JOB_QUEUED events. No buildspec or webhook changes beyond that are needed.
What to do
Add the action as the first step of the job:
jobs:
build:
runs-on: codebuild-my-project-${{ github.run_id }}-${{ github.run_attempt }}
steps:
- uses: step-security/harden-runner@v2.21.0
with:
egress-policy: audit
- uses: actions/checkout@v4
# ... rest of your jobThe runs-on label follows the standard CodeBuild pattern codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}, where the project name matches the CodeBuild project whose webhook fires. For custom images, either set the project's Environment type to Linux Container, or use the label override image:custom-<environment-type>-<custom-image-identifier>. Custom images require v2.21.0 or later.
Why the blast radius differs
flowchart TD
A[Compromised job] --> B{Runner type}
B -->|GitHub-hosted| C[Only passed-in secrets]
B -->|CodeBuild-hosted| D[Secrets + IAM service role]
D --> E[VPC network reachability:<br/>internal registries, APIs,<br/>databases, metadata endpoints]On a GitHub-hosted runner a compromised job holds only the secrets you passed in. On CodeBuild it also inherits the project's IAM service role and, if the project runs in a VPC, network reachability into those subnets. None of this is visible in GitHub's job log, which only shows what the build printed — not that a step opened a connection to an internal host or read the runner worker's memory.
Organisations named here
- CloudSEK
CVEs named here
- CVE-2025-8217
Technologies named here
- Harden-Runner
- AWS CodeBuild
- GitHub Actions Audit
- AWS Toolkit for Visual Studio Code
- AWS SDK for .NET
- GitHub Actions
- AWS IAM
- tj-actions/changed-files
- StepSecurity
Techniques named here
- Process memory dumping to steal tokens
- Malicious pull request triggering CI job
- Credential/secret theft from CI pipelines
Threat actors named here
- Team PCP campaign
- tj-actions/changed-files compromise
- Unnamed threat actor
- TeamPCP
Related in DevSecOps
JFrog: The Governance Gap Between Your Policy and Your Pipeline

Dev Machine Guard Now Supports Windows - StepSecurity

Socket: TanStack npm Packages Compromised
