What breaks when CI/CD secrets live in shared environment variables?

Why Shared Environment Variables Break CI/CD Secret Boundaries

Shared environment variables turn a pipeline secret into host-level state, which means the secret is no longer scoped to a single step, job, or workload identity. That breaks the core assumption behind ephemeral CI/CD execution: only the intended process should be able to use the credential, and only for the duration of the task. The result is standing privilege on runners, broader blast radius, and weaker auditability.

This is why current guidance in the OWASP Non-Human Identity Top 10 treats secret exposure and overbroad credential placement as a workload identity problem, not just a hygiene problem. NHI Management Group’s research on the Guide to the Secret Sprawl Challenge shows how quickly secrets stop being isolated once they are copied into shared operational surfaces.

In practice, many security teams discover this only after a runner compromise, an over-permissioned support account, or an unrelated build step has already accessed a credential that was supposed to be pipeline-local.

How to Replace Shared Env Vars with Pipeline-Scoped Access

The safer pattern is to make access contextual and short-lived. Instead of exporting one long-lived secret into the environment for every step, the pipeline should request a credential only when a job proves its identity and needs it. That usually means workload identity, a federated token exchange, or a secret broker that issues just-in-time credentials with a narrow TTL.

This aligns with emerging practice in agent and automation security: the secret should be bound to the workload, not the host. For CI/CD, that often means authenticating the runner with a cryptographic workload identity, then minting a short-lived token for a specific action such as package publish, container push, or deployment. The SPIFFE identity model is useful here because it emphasizes identity for workloads rather than static shared secrets.

Operationally, the pipeline should follow a few rules:

• Issue secrets per job or per step, not per runner.
• Store credentials in a broker or vault, not in exported environment variables.
• Use short TTLs and automatic revocation after task completion.
• Bind token use to the expected repository, branch, environment, or deployment stage.
• Log issuance and use separately so auditors can trace which workload requested access.

For teams mapping controls, CI/CD pipeline exploitation case study is a useful reminder that attackers rarely need to break encryption when the credential is already present in process memory or inherited by every child process. These controls tend to break down in self-hosted runners with shared shells, long-lived build hosts, or plugins that inherit environment state across unrelated jobs.

Common Failure Modes and Edge Cases in Real Pipelines

Tighter secret scoping often increases implementation overhead, requiring organisations to balance build simplicity against exposure reduction. That tradeoff is most visible in legacy pipelines, multi-tenant runners, and third-party build actions that were designed around ambient environment variables rather than explicit secret fetches.

One common edge case is toolchain inheritance. Many build tools automatically pass environment variables to subprocesses, which means a single secret can leak into test frameworks, package managers, or debug logs. Another is human access: operators who can inspect a runner, attach a shell, or read crash dumps may inadvertently inherit access to secrets that should have expired minutes earlier. Best practice is evolving, but current guidance suggests treating shared environment variables as a temporary compatibility mechanism, not a secure default.

This is also where audit and offboarding become fragile. If a secret lives in host state, revoking it requires confidence that no process cached it, no child process copied it, and no artifact captured it. That is why 230M AWS environment compromise remains relevant as a cautionary example of how broad environment exposure can amplify incident scope. The OWASP Non-Human Identity Top 10 and NIST Zero Trust Architecture both support the same practical conclusion: do not trust ambient presence, and do not let a runner’s environment become the authority for secret use.

Related resources from NHI Mgmt Group

• Should production secrets live in environment variables or a secrets manager?
• What breaks when secrets are stored in code and CI/CD tools?
• What breaks when CI/CD pipelines rely on static secrets?
• What breaks when secrets are stored in pods or build environments?