What breaks when secrets are stored in YAML or shared variable groups?

Why This Matters for Security Teams

Storing secrets in YAML or shared variable groups turns a credential into configuration, and that changes the blast radius immediately. YAML is easy to copy, review, and reuse, which makes it easy to accidentally commit secrets into source control or propagate them across environments. Shared variable groups solve convenience, but often at the cost of separation of duties and environment isolation. That is why NHIMG continues to treat secret sprawl as an operational control problem, not just a developer hygiene issue, as shown in the Guide to the Secret Sprawl Challenge.

The practical failure is not just exposure. Once a value is embedded in a pipeline definition or shared group, it becomes harder to prove who can read it, where it is replicated, and how quickly it can be revoked. The OWASP Non-Human Identity Top 10 treats credential handling as an identity risk because pipeline secrets often outlive the workload that uses them. NHIMG research on the State of Secrets in AppSec found that the average time to remediate a leaked secret is 27 days, which is long enough for a compromised token to be reused across build systems, test environments, and downstream services.

In practice, many security teams discover this only after a pipeline has already copied the same secret into places it was never meant to reach.

How It Works in Practice

YAML and shared variable groups fail because they centralize convenience instead of context. A secret in YAML is usually treated like any other parameter, so it can be versioned, templated, reused, and accidentally echoed. A shared variable group reduces duplication, but it also creates a coarse trust boundary: if one pipeline or project needs the value, multiple others often inherit it. That breaks least privilege and makes it difficult to map a secret to a single service, owner, or environment.

Better practice is to keep secrets out of source-controlled definitions entirely and inject them at runtime from a dedicated secrets manager, preferably with short TTLs and automatic revocation. For pipelines, that usually means a workload identity or federated identity flow that obtains a credential only when the job starts, rather than storing a reusable static secret in the pipeline file. This aligns with current guidance from the OWASP Non-Human Identity Top 10 and with the operational lessons in NHIMG’s CI/CD pipeline exploitation case study.

• Use per-environment secret scopes instead of a shared global group.
• Rotate values on change events, not on a calendar alone.
• Prefer ephemeral credentials over long-lived tokens in build jobs.
• Prevent secret values from appearing in logs, artifacts, and test output.
• Use policy checks to block plaintext secrets in YAML before merge.

Where this works best, the secret is issued just in time, used by one pipeline run, and revoked or expires automatically after completion. These controls tend to break down in legacy CI/CD systems that cannot federate identity or in monolithic variable groups that are reused across many repos because ownership and scope are too coarse to separate safely.

Common Variations and Edge Cases

Tighter secret isolation often increases pipeline complexity, so organisations have to balance reduced blast radius against developer friction and operational overhead. That tradeoff is real, especially when legacy tooling expects a single shared variable group or when release engineering teams manage dozens of repositories with inconsistent credential patterns.

One common edge case is a low-risk internal test secret that still becomes dangerous because it is copied into templates and reused in production-like pipelines. Another is a “temporary” variable group that quietly becomes permanent because no one owns its lifecycle. Guidance is evolving here, but current best practice is to treat any shared secret as a production-grade asset with an owner, expiry, and revocation path, regardless of whether it appears harmless.

Another failure mode is believing masking alone is enough. Masking can reduce accidental disclosure, but it does not fix overbroad access, secret duplication, or the fact that many CI systems expand variables before redaction occurs. NHIMG has repeatedly shown how quickly secrets spread once they are placed in build workflows, including in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack. Shared storage becomes especially risky when multiple teams inherit the same value for convenience, because one compromised pipeline can expose every downstream environment that depends on it.

Related resources from NHI Mgmt Group

• How should teams design Kubernetes secrets operators for shared machine identities?
• What breaks when agents can read secrets in prompts or chat history?
• Why do AWS secrets still create risk when they are centrally stored?
• What breaks when production secrets are readable inside a hosting control plane?