Pipeline variables place secret material inside the CI platform, where it can be easier to expose through configuration access, logs, or job edits. Runtime retrieval from a central secrets manager keeps the sensitive value outside the pipeline until the job needs it, which improves rotation, revocation, and access scoping when runner controls are also in place.
Why This Matters for Security Teams
Where secrets live changes the blast radius. Pipeline variables are convenient, but convenience often means broader visibility across project settings, job definitions, logs, and administrative edits. A central secrets manager shifts the trust boundary outward: the CI/CD system requests a value only when it needs one, and access can be tied to a narrower policy, rotation schedule, and audit trail. That difference matters most when multiple teams share runners or when build configuration changes faster than secret governance.
Secrets sprawl is not hypothetical. In The 2024 State of Secrets Management Survey, 88% of security professionals said they were concerned about secrets sprawl, and the average time to mitigate a leaked secret was 36 hours. In practice, many teams discover exposure only after a leaked token has already been reused, rather than through deliberate control design.
How It Works in Practice
Pipeline variables embed secret material inside the CI platform’s configuration plane. That makes them easy to inject into jobs, but it also means the CI system itself becomes part of the secret trust boundary. If a user can edit pipeline definitions, inspect job output, or access the project configuration, they may be able to influence or reveal values that were meant to stay protected.
Runtime retrieval changes the workflow. The pipeline stores only a reference, while the job authenticates to a secrets manager and fetches the secret just before use. That supports shorter-lived access, finer-grained scoping, and revocation without editing every pipeline. It also reduces the chance that a copied job log, exported configuration, or stale branch setting contains reusable credentials.
- Use pipeline variables for non-sensitive parameters, not long-lived credentials.
- Keep the actual secret in the manager and rotate it there, not in the CI layer.
- Constrain runner identity and network path so the job can reach only the required secret.
- Return the secret late and hold it briefly, ideally in memory only for the job duration.
These controls tend to break down when runners are broadly trusted, shared across teams, or able to print environment values into logs, because the runtime fetch still leaves the secret exposed at execution time.
Common Variations and Edge Cases
Tighter runtime retrieval often adds setup overhead, so teams have to balance operational simplicity against reduced exposure. The right choice depends on how sensitive the secret is, how often it changes, and how much control exists around the runner. A low-risk build flag does not need the same handling as a production API key that can modify infrastructure.
Short-lived tokens are a common middle ground. They can be issued at runtime by the secrets manager or an identity provider, reducing persistence even further than a static secret stored in a vault. Current guidance suggests treating this as a lifecycle problem as much as a storage problem: if a secret can be revoked, rotated, or scoped more narrowly, those controls should exist outside the pipeline itself.
Edge cases appear when teams confuse masking with protection. Masked pipeline variables may still be copied, inherited, or reintroduced through templates, and redaction does not prevent abuse if the secret is valid. Runtime retrieval is stronger when the downstream system can also verify who or what is asking for access, not just whether the value is hidden from view.
Risk and Threat Considerations
The main risk with pipeline-stored secrets is exposure through configuration access, job edits, logs, forks, or inherited templates. Once a credential is reusable outside the pipeline, an attacker does not need to compromise the build system again to benefit from it. Central retrieval narrows that exposure, but only if the runner and its network path are controlled well enough to prevent secret theft at execution time.
Failure mechanism: The common failure path is secret overexposure, then reuse. A leaked pipeline variable, copied log line, or mis-scoped job can reveal a credential that remains valid long after the build has finished. With runtime retrieval, the weaker point shifts to runner compromise, token theft during execution, or overbroad access policy on the secrets manager.
Impact: Compromise can extend beyond one pipeline to source control, cloud accounts, deployment targets, or downstream services that trust the same credential. The practical consequence is not just disclosure, but loss of revocation speed, audit confidence, and blast-radius control.
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 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 | Covers CI/CD secret sprawl and runtime credential handling for non-human access. |
| Recommendation — Move secrets out of pipeline variables and enforce vault-backed runtime retrieval with rotation. | ||
| CIS Controls v8 | 6 — Access Control Management | Applies to limiting who and what can access sensitive CI/CD credentials. |
| Recommendation — Restrict secret access to the minimum required identities and review those permissions regularly. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Directly addresses controlling access paths to CI/CD secrets and runtime retrieval. |
| PR.DS — Data Security | Relevant because secrets are sensitive data that must be protected in storage and use. | |
| Recommendation — Apply access-control rules so pipelines can retrieve only the secrets they need at runtime. Protect secrets by keeping them out of pipeline storage and limiting exposure during execution. | ||
Practitioner Guidance
What to prioritise: Treat any secret that can modify production, access cloud APIs, or sign releases as a vault-managed credential, not a pipeline variable. If the value has real operational power, store only a reference in CI and assume the pipeline configuration itself is too widely inspectable to be the primary control boundary.
What to verify: Confirm the runner can fetch only the exact secret it needs, for the exact environment, at the exact time the job runs. Also verify that logs, artifact uploads, debug modes, and template inheritance cannot re-expose the value after retrieval.
Decision rule: If the secret must survive branch changes, shared runners, or multiple maintainers, move it out of pipeline variables. If it is short-lived, tightly scoped, and low impact, a pipeline variable may be acceptable only when exposure would not create meaningful downstream access.
Practitioner takeaway: The important distinction is not storage convenience, it is whether the secret remains governable after the CI system has been edited, copied, or compromised.
Related resources from NHI Mgmt Group
- What is the difference between syncing secrets into GitLab CI/CD variables and fetching them at runtime with OIDC?
- What is the difference between storing secrets in docker-compose files and injecting them at runtime from a secrets manager?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between storing secrets securely and governing them well?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
