CI/CD Build Secret Segregation
A production API key was accessible from the development pipeline because the CI/CD variable was not scoped to its environment. I confirmed the cross-environment leak and identified the controls needed to properly isolate build secrets.
Status: ASSESSED · VERIFIED
TOOLS
Objective
I set out to assess whether CI/CD build secrets were properly scoped to their intended environments, or whether a development pipeline could access production secrets.
Scenario
A GitLab project used CI/CD variables to manage secrets for its DEV and PROD deployments. The PROD pipeline used an API_KEY variable, and the DEV pipeline used a separate API_KEY_DEV variable. I wanted to test whether the PROD secret could be reached from the DEV pipeline by changing the variable name in the CI configuration.
What I found
Variable: API_KEY (production)
Environment scope: All environments (not restricted)
Accessible from: DEV pipelineProduction secret not scoped to its environment
The PROD API_KEY variable was stored as a CI/CD variable but was not restricted to the production environment. Any pipeline in the project could request it by name.
Pipeline: DEV branch
Variable requested: API_KEY (production)
Result: Production API key exposed in job outputDEV pipeline exposed the production key
After modifying the DEV branch CI configuration to reference API_KEY instead of API_KEY_DEV, the DEV pipeline job output included the production API key value.
Environment variables alone were not enough to protect the secret. Without proper scoping, any pipeline in the project could access any variable.
What I did
- Reviewed the PROD deployment
I identified that it used an
API_KEYvariable for its deployment process. - Reviewed the DEV pipeline configuration
It used a separate
API_KEY_DEVvariable by convention, not by enforcement. - Tested cross-environment access
I modified the DEV CI configuration to request the PROD
API_KEYvariable and ran the pipeline. - Confirmed the leak
The DEV pipeline job output showed the production API key, confirming the variable was not scoped to its environment.
EVIDENCE
# Variable scoping test
DEV pipeline CI config: changed API_KEY_DEV to API_KEY
DEV pipeline output: PROD API key value exposed
Root cause: CI/CD variable not scoped to production environmentValidation
The DEV pipeline successfully accessed the PROD API_KEY variable, confirming that the secret was not restricted to its intended environment. The exposure was reproducible.
Before and after
| CONTROL | BEFORE | AFTER |
|---|---|---|
| PROD API_KEY scope | All environments | Weakness documented; scoping recommended |
| DEV access to PROD secrets | Possible | Risk confirmed and reported |
| Variable masking | Not configured | Recommended |
| Secret management | CI/CD variables only | Recommended: external secrets manager |
| Environment enforcement | Convention only | Recommended: platform-enforced scoping |
What I recommend
- 01Scope CI/CD variables to their intended environment so that production secrets are only available to production pipelines.
- 02Enable variable masking to prevent secrets from appearing in job logs.
- 03Use an external secrets manager for sensitive credentials instead of relying solely on CI/CD variables.
- 04Restrict who can modify CI/CD variable configurations and audit changes.
- 05Review all existing CI/CD variables for proper scoping and remove any that are accessible beyond their intended environment.
“Environment variables provide configuration management, not complete secret protection. CI/CD secrets must also be properly scoped, masked, access-controlled, and restricted to the environments that legitimately require them.”
SKILLS IT PROVES
- CI/CD Security
- Secrets Management
- GitLab Security
- Access Control
- Environment Segmentation
- Pipeline Security
- Vulnerability Assessment
- Secure Configuration Management
- Credential Protection
- DevSecOps
- Least Privilege