Environment variables become risky because they shift secrets out of source control but leave them reachable at runtime. If an attacker can modify build steps or inject commands, they can print those variables into logs without touching the vault. That creates a hidden exfiltration path that bypasses code scanning and can expose cloud credentials, tokens, and other sensitive data.
Why writable CI turns environment variables into a secrets problem
Environment variables are convenient because they keep secrets out of source files, but that only helps if the build environment itself is trusted. In a writable CI system, the attacker does not need to steal the secret from the vault. They can alter the pipeline, add a print step, or redirect output so the secret is disclosed at runtime, where the CI runner can already see it.
This is why the control failure is usually not “secrets in env vars” by itself, but “secrets in env vars plus attacker-controlled execution.” The variable is only as safe as the place it is expanded, and CI logs, test output, debug traces, child processes, and injected shell commands all become potential exfiltration paths.
When the secret is a cloud credential, API token, signing key, or deploy key, the impact extends beyond one pipeline run. A writable pipeline can turn a temporary build compromise into reusable access, and a long-lived environment variable can remain exploitable even after the immediate malicious change is removed.
How the leak happens in practice
In CI, secrets often enter the job as environment variables because that is easy for tooling and scripts. If an attacker can modify build definitions, environment overrides, job parameters, test fixtures, or shell commands, they can cause the runtime to reveal those values without touching the secret store itself.
The common failure pattern is command injection or pipeline tampering. A malicious build step can echo variables, dump process state, print inherited environments, or cause downstream tools to include sensitive values in logs and artifacts. Because the secret was consumed legitimately by the runner, normal secret scanning in git often misses the disclosure path.
For CI/CD defenders, the key distinction is that environment variables reduce exposure in the repository, but they do not provide confidentiality once execution is delegated to an untrusted or writable build context. That is why the same secret can be materially safer in a locked-down deployment job than in a broadly writable integration pipeline.
NHIMG’s Guide to the Secret Sprawl Challenge covers the broader pattern of secrets exposure across CI/CD, and the 230M AWS environment compromise shows how exposed environment files and cloud credentials can become a real-world access path.
What practitioners should do differently
Environment variables should be treated as a delivery mechanism, not as a protection boundary. If the job context is writable by an attacker, assume any secret available to that job can be disclosed, copied, replayed, or forwarded elsewhere unless additional controls reduce the blast radius.
What to verify: confirm which jobs can change pipeline code, job parameters, scripts, container images, or injected variables. If an attacker can influence the execution path, do not rely on environment-variable secrecy alone for anything that can authenticate to production systems or sign release artefacts.
Decision rule: if the secret is high-value or long-lived, prefer short-lived credentials, scoped access, and stronger isolation over broad runtime injection. If the secret must still be present in a writable job, treat log suppression, command sanitisation, and execution restrictions as mandatory, not optional.
What good looks like: the CI system should minimise who can alter execution, reduce the lifetime of exposed credentials, and make any secret use attributable and bounded. Where that cannot be achieved, the correct answer is usually to remove the secret from that job rather than hope the variable stays hidden.
Practitioner takeaway: environment variables are acceptable only when the build context is trusted enough that disclosure is already controlled; once attackers can write the CI path, the real control is not hiding the secret, but preventing the job from ever holding one with meaningful standing access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | CI environment variables expose non-human credentials and tokens at runtime. |
| NHI-03 — Privilege and Access Governance | Writable CI jobs magnify the impact of overprivileged environment-held credentials. | |
| NHI-05 — Visibility and Detection | Secret disclosure often occurs through logs and job output rather than repository scans. | |
| Recommendation — Use short-lived secrets and rotate any credentials exposed to writable CI jobs. Scope CI credentials to the minimum access needed and remove standing privilege. Monitor CI logs and job artifacts for secret leakage and unexpected environment access. | ||
| CIS Controls v8 | 6 — Access Control Management | Protects CI access paths so attackers cannot modify jobs that expose secrets. |
| 8 — Audit Log Management | Log review is essential because env-var secrets are often exfiltrated through build output. | |
| 16 — Application Software Security | Pipeline tampering and injection are software-delivery weaknesses that expose secrets. | |
| Recommendation — Restrict who can change CI pipelines and execution parameters. Centralise and review CI logs for secret-printing and suspicious command execution. Harden pipeline scripts and validate inputs that influence build execution. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Writable CI environments require least-privilege access to reduce secret exposure. |
| DE.CM — Continuous Monitoring | Secret exfiltration via logs or job output needs continuous monitoring signals. | |
| Recommendation — Limit pipeline write access and constrain credentials used by build jobs. Detect abnormal CI output, job changes, and credential use in your monitoring stack. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Attackers abuse exposed environment variables as readable credentials in CI. |
| T1059 — Command and Scripting Interpreter | Writable CI jobs let attackers inject commands that print or exfiltrate secrets. | |
| Recommendation — Hunt for secrets exposed through build output, logs, and job variables. Inspect build steps for injected shell commands that can access runtime secrets. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
