Azure DevOps secrets management is breaking at pipeline scale

At a glance

What this is: This analysis shows why Azure DevOps native secret handling breaks down at scale and what runtime, federated, and centralized patterns change for pipeline identity governance.

Why it matters: It matters because IAM, PAM, and NHI teams need a tighter model for pipeline credentials, rotation, and access scoping before secrets sprawl expands blast radius across delivery systems.

By the numbers:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Infisical's Azure DevOps secrets management guide

Context

Azure DevOps secrets management is a governance problem as much as an engineering one. When secrets are scattered across variable groups, YAML definitions, Key Vault instances, and repository history, teams lose the inventory and control discipline needed to know what exists, where it is used, and how it is rotated.

The article argues that native mechanisms can work for simple pipelines, but they do not scale cleanly across dozens or hundreds of delivery paths. For platform, IAM, and NHI teams, the real question is how to reduce standing credential exposure while preserving pipeline velocity.

Key questions

Q: How should security teams reduce secrets sprawl in Azure DevOps pipelines?

A: Start by inventorying every secret location, including variable groups, YAML, Key Vault references, and repository history. Then decide which values can move to runtime-only retrieval and which must be rotated on a fixed cadence. The goal is to eliminate unknown persistence paths and make every secret traceable to an owner and expiry point.

Q: Why do Azure DevOps pipeline secrets create governance risk at scale?

A: Because static secrets spread across multiple projects and environments become hard to inventory, hard to rotate consistently, and easy to overexpose. Once the same credential is reused across many delivery paths, compromise in one place can affect many. That turns secret handling into a blast-radius problem, not just a storage problem.

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

A: Secrets can leak into source control, logs, or multiple pipelines that were never meant to share the same value. Shared groups also tend to create coarse permissions, so a team often gets more access than it needs. The result is weak separation between services, environments, and ownership.

Q: How do teams decide between Key Vault, runtime injection, and federation?

A: Use persistent storage only when a secret truly must remain available between runs, use runtime injection when the value is needed only during execution, and prefer federation when the platform can issue short-lived identity assertions. The best choice is the one that reduces credential persistence without breaking deployment control.

Technical breakdown

Why Azure DevOps variable groups create secrets sprawl

Azure DevOps variable groups centralise storage only at a very narrow layer. They still leave secrets static, project-scoped, and manually maintained, which means a password or token must be updated everywhere it is referenced. Inline YAML can also leak values into source control or logs, so the control is masking, not lifecycle governance. At scale, that creates an inventory problem first and an exposure problem second.

Practical implication: treat variable groups as a weak storage layer and track every secret back to its owner, purpose, and rotation path.

How runtime secret injection changes pipeline identity

Runtime injection moves the secret from persistent pipeline storage into execution context only. In the pattern described, the pipeline authenticates with a short-lived token, fetches the needed value for one step, and discards it when the step ends. That reduces residual exposure in Azure DevOps itself, but the security model now depends on token scoping, environment isolation, and how strictly the pipeline identity is bounded.

Practical implication: prefer runtime-only access for deployment steps that do not need secrets to persist between jobs.

Why OIDC and machine identities matter for CI/CD secrets

OIDC-based federation replaces long-lived client secrets with ephemeral identity assertions issued per run. That matters because CI/CD systems are high-churn environments where static credentials are both hard to rotate and easy to copy into the wrong place. Machine identities then provide auditability and lifecycle control without relying on personal tokens, which are a poor fit for non-interactive automation. The mechanism shifts trust from stored secrets to provable, short-lived authentication.

Practical implication: use federated authentication for pipeline identity wherever the target system and tooling support it.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed pipeline secret into broader access across build, deploy, or cloud environments.

1. entry via secrets stored in pipeline variables, YAML, Key Vault sprawl, or repository history that can be read or copied by an attacker with insufficiently bounded access.
2. escalation through standing privilege and reused credentials that let the same secret reach multiple pipelines, environments, or cloud back ends.
3. impact through credential reuse, leaked tokens, or overexposed pipeline secrets that enable environment access, build compromise, or downstream cloud abuse.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets sprawl, not secret storage, is the real Azure DevOps governance failure. Azure DevOps can store secrets, but it cannot by itself answer the lifecycle questions that matter at scale: where a secret lives, who can use it, and how quickly it is rotated or revoked. That is why pipeline secret handling becomes an identity governance problem once organisations move beyond a handful of builds. Practitioners should judge their current model by inventory and lifecycle visibility, not by whether a field is marked secret.

Runtime-only secret injection is a better control boundary than persistent pipeline storage. The article’s CLI pattern shows the difference between a credential that lives in the platform and one that exists only inside execution memory. That distinction matters because blast radius is lower when secrets are never written back into variable groups or repo history. The field should treat runtime injection as a control design choice, not a convenience feature, because it changes the persistence model that attackers exploit.

OIDC federation is becoming the default trust pattern for CI/CD identity. Long-lived client secrets are increasingly mismatched to pipeline behaviour because the pipeline already has a run boundary and an attested workload boundary. When federation is available, the governance question shifts from storing credentials to verifying the workload that requested access. Practitioners should reframe CI/CD identity around ephemeral proof rather than reusable shared secrets.

Static secret management still creates identity blast radius even when the toolset is modern. Secrets that are duplicated across variable groups, Key Vaults, and environment-specific pipelines create hidden reuse paths that expand compromise impact. The important lesson is not that Azure DevOps is uniquely weak, but that any delivery system with persistent credentials inherits the same concentration risk. Teams should measure the size of that blast radius before deciding where to centralise or federate access.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, showing how lifecycle gaps turn secret exposure into durable access risk.
• For a broader control lens, see OWASP Non-Human Identity Top 10 for the NHI failures that commonly underlie secrets sprawl and overprivilege.

What this signals

Secret persistence is the main programme-level risk. As long as pipeline credentials survive in variable groups, YAML, or shared vault patterns, every identity review is incomplete because the hidden inventory keeps changing. That is why teams should track secret location, not just secret value, as a governance metric.

Static credentials create a widening identity blast radius. The more often a pipeline identity is reused across projects and environments, the more likely one leak can cross service boundaries. Teams should use NIST Cybersecurity Framework 2.0 language to connect identify, protect, and recover activities around secret lifecycle control.

Ephemeral authentication is the new baseline for delivery trust. Runtime credential boundary: a control model where secrets exist only for the duration of a pipeline step and never become a durable platform asset. Practitioners should treat that boundary as the target state for CI/CD access design.

For practitioners

• Map every pipeline secret to an owner and lifecycle state Build an inventory of variable groups, YAML secrets, Key Vault references, and repo-embedded values. Record where each secret is used, who can read it, and when it was last rotated so you can remove unknown standing access.
• Move deployment steps to runtime-only secret retrieval Use short-lived token exchange so secrets are fetched during execution and never persisted in Azure DevOps storage. Keep the scope narrow by limiting each job to the environment and path it actually needs.
• Replace personal tokens with machine identities or federation Authenticate non-interactive pipelines with machine identities or OIDC federation instead of employee-owned credentials. That keeps access bound to the workload and avoids dependency on accounts that change with staffing.
• Separate dev, staging, and production secret scopes Use distinct environments and permissions so one pipeline identity cannot read secrets from another tier. This limits cross-environment reuse and makes access reviews more meaningful.
• Add rotation and scanning gates to pipeline governance Automate rotation for static secrets that cannot be removed and scan repositories and logs for leaked credentials before they spread. Treat leaked secret remediation as a pipeline control, not an after-hours cleanup task.

Key takeaways

• Azure DevOps native secret handling becomes a governance weakness when teams lose inventory, rotation, and ownership visibility.
• Pipeline secret sprawl expands blast radius by duplicating credentials across variables, YAML, Key Vault, and repo history.
• Runtime injection and federation reduce persistence, but only if teams pair them with strict scoping, lifecycle control, and monitoring.

Key terms

• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across tools, files, environments, and teams. In CI/CD, it means the same token or key appears in variable groups, YAML, vaults, logs, and repository history, making inventory, rotation, and revocation inconsistent and error-prone.
• Machine Identity: A machine identity is the non-human identity assigned to a workload, pipeline, service, or automation process. It provides a controllable authentication and authorization boundary for non-interactive systems, with lifecycle management, scoping, and auditability separate from human user accounts.
• Runtime Secret Injection: Runtime secret injection is the pattern of fetching credentials only when a job or step executes, then discarding them when execution ends. It reduces durable storage of secrets in the platform and narrows exposure, but it still depends on correct scoping and trustworthy workload authentication.
• Workload Identity Federation: Workload identity federation is a method of exchanging a short-lived external identity assertion for access without storing a long-lived shared secret. In CI/CD, it replaces static client credentials with ephemeral proof from the workload, which is a stronger fit for automated, high-frequency delivery systems.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Azure DevOps sync configuration for App Connections, variable groups, and secret paths.
• Pipeline-ready CLI examples for runtime injection, including token exchange and environment scoping.
• Terraform and OpenTofu injection patterns for provider credentials, backend access, and TF_VAR mapping.
• Kubernetes operator deployment details for teams syncing secrets into cluster-native Secret resources.

👉 The full Infisical post covers runtime injection, OIDC federation, Terraform, and Kubernetes patterns in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.