Environment Segregation for Build Runners
DEV and PROD builds ran on the same GitLab Runner, so a compromised development pipeline could pivot straight into production. I traced the shared runner path across both environments and identified the controls needed to isolate them.
Status: ASSESSED · VERIFIED
TOOLS
Objective
I set out to assess whether CI/CD runners were shared across DEV and PROD environments, and whether a compromise in the lower-trust DEV pipeline could provide a path into production infrastructure.
Scenario
An organisation maintained separate DEV and PROD environments for their application, each with its own deployment pipeline. I wanted to check whether the build infrastructure was equally separated, or whether a shared component could let an attacker cross from one environment to the other.
What I found
DEV pipeline runner: shared-runner-01
PROD pipeline runner: shared-runner-01
Runner isolation: NoneA single runner served both environments
Both the DEV and PROD pipelines were configured to use the same GitLab Runner. There was no runner-level separation between the two environments.
Runner access to DEV host: Confirmed (SSH)
Runner access to PROD host: Confirmed (SSH)
Environment separation: Not enforced at runner levelRunner had network access to both environments
The shared runner held SSH credentials and network access to both the DEV and PROD hosts. Compromising the runner through the DEV pipeline provided a direct pivot into the PROD environment.
A compromise in the lower-trust DEV environment could reach production without any additional barrier.
What I did
- Reviewed the pipeline configuration
I identified that both DEV and PROD builds used the same GitLab Runner.
- Assessed runner access
The shared runner had SSH access to both the DEV and PROD hosts.
- Traced the cross-environment path
From the DEV pipeline, I confirmed the runner could reach the PROD environment, completing the pivot path.
- Documented the exposure
The shared runner was the single point of failure connecting both environments.
EVIDENCE
# Cross-environment access from shared runner
Runner identity: gitlab-runner (shared across DEV and PROD)
DEV host access: Confirmed via SSH from runner
PROD host access: Confirmed via SSH from runnerValidation
The lab verification confirmed access to both environments through the shared runner. The cross-environment path was reproducible from the DEV pipeline alone.
Before and after
| CONTROL | BEFORE | AFTER |
|---|---|---|
| Runner assignment | Shared across DEV and PROD | Exposure documented |
| Environment separation | Not enforced at runner level | Recommended: dedicated runners per environment |
| SSH credentials | Available on shared runner | Recommended: scoped credentials per environment |
| PROD access from DEV | Possible via shared runner | Recommended: network segmentation |
| Runner isolation | None | Recommended: ephemeral or sandboxed runners |
What I recommend
- 01Assign dedicated runners to each environment so that DEV and PROD builds never share infrastructure.
- 02Scope runner credentials to a single environment; the DEV runner should have no way to reach PROD.
- 03Use ephemeral runners that are destroyed after each job to limit the window for lateral movement.
- 04Apply network segmentation so that build infrastructure for each environment can only reach its own hosts.
- 05Monitor runner activity for unexpected SSH connections or cross-environment access patterns.
“A shared CI/CD runner can become a bridge between environments, so DEV and PROD need separate runners, access controls, and security boundaries to prevent a lower-trust compromise from reaching production.”
SKILLS IT PROVES
- CI/CD Security
- GitLab Security
- Environment Segmentation
- Access Control
- Vulnerability Assessment
- Security Misconfiguration Analysis
- GitLab Runner Security
- Infrastructure Security
- Credential Management
- Production Security