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.
Why This Matters for Security Teams
secrets sprawl in Azure DevOps pipelines is not just a hygiene issue. It expands the blast radius of a single leaked token across variable groups, YAML, service connections, repository history, and task logs, which makes containment slow and attribution weak. NHIMG’s Guide to the Secret Sprawl Challenge frames this as a visibility problem first: teams cannot protect what they cannot inventory.
The practical risk is that pipeline secrets are often copied to satisfy build convenience, then forgotten after the original workflow changes. That is how long-lived credentials survive in branch templates, release definitions, and legacy variable groups long after the owning team has moved on. The OWASP Non-Human Identity Top 10 treats this as a non-human identity control problem, because each secret behaves like an identity with an owner, scope, and lifecycle.
In practice, many security teams encounter secret leakage only after a pipeline token has already been reused outside its intended deployment path.
How It Works in Practice
The strongest pattern is to stop treating pipeline secrets as static configuration and instead treat them as runtime dependencies. That means inventorying every location where Azure DevOps can store or expose a secret, then deciding which values should be retrieved just in time from a central manager and which legacy credentials must be rotated until they can be removed. For pipeline design, the goal is narrow scope, short TTL, and traceable ownership.
Start with discovery across variable groups, pipeline variables, YAML templates, classic release pipelines, service connections, library assets, and repository history. Then classify each secret by purpose, consumer, and expiry. Static credentials that remain in use should be the exception, not the default. Where possible, replace them with workload identity or federated access so the pipeline obtains a short-lived token only when the job starts, rather than carrying a reusable secret throughout the build. This approach aligns with guidance in NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- Use Azure Key Vault or an equivalent secret source as the system of record, not the pipeline variable store.
- Prefer ephemeral credentials issued per job, with automatic revocation when the task completes.
- Bind access to the specific pipeline identity and environment, not to a broad project role.
- Scan commit history and build logs so hidden persistence paths are not missed.
- Record an owner, purpose, and expiry date for every remaining secret.
This is also where detection and revocation must be paired. NHIMG’s CI/CD pipeline exploitation case study shows why exposed build credentials are often operationally reusable, not merely informational. A key insight from Akeyless research is that 88% of security professionals are concerned about secrets sprawl, which matches the operational reality that manual cleanup cannot keep pace with pipeline churn. These controls tend to break down when self-hosted runners are reused across many repositories because cached credentials and shared agent state can outlive the intended job boundary.
Common Variations and Edge Cases
Tighter secret governance often increases pipeline friction, requiring organisations to balance build reliability against credential minimisation. That tradeoff is real in Azure DevOps because not every legacy integration supports workload identity or short-lived tokens yet, and some release tasks still expect a password-like input. Current guidance suggests phasing the estate rather than waiting for a full platform redesign.
Edge cases usually appear in hybrid delivery models. Classic release pipelines may still depend on variable groups, while YAML-based builds can shift to runtime retrieval more easily. Service connections are another exception area: they can reduce secret exposure, but only if their underlying identity is tightly scoped and reviewed like any other NHI. When a team must keep a static secret temporarily, the best practice is to isolate it to one pipeline, one environment, one owner, and one expiry date.
Monitoring also needs nuance. A secret can be “removed” from current configuration yet remain live in historical logs, forked repositories, artifact metadata, or copied release definitions. That is why secret reduction is not a single cleanup event. It is a lifecycle program that combines discovery, rotation, runtime retrieval, and revocation. The Azure Key Vault privilege escalation exposure research is a reminder that even centralised storage fails if access paths are over-permissive.
One useful benchmark from NHIMG research is that only 44% of organisations report using a dedicated secrets management system, which helps explain why pipeline secrets often remain embedded in tooling rather than governed as identities.
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 NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle control for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control is central to reducing pipeline secret sprawl. |
| NIST AI RMF | Supports governance for automated systems that use credentials dynamically. |
Inventory pipeline secrets, rotate static values, and retire any credential without an owner or expiry.
