Devops secrets vaults expose the governance gap in NHI control

At a glance

What this is: This is an analysis of why DevOps secrets vaults are becoming a core NHI control, with the key finding that scattered credentials and hard-coded secrets create avoidable exposure.

Why it matters: It matters because IAM, PAM, and cloud security teams need one way to govern machine credentials across pipelines, applications, and offboarding without breaking delivery speed.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 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 Securden's analysis of DevOps secrets vault governance for modern pipelines

Context

DevOps secrets vaults exist because automated delivery environments still rely on credentials that should never live in code, scripts, or shared files. The primary IAM problem is not storage alone, but how non-human identities retrieve, rotate, and retire those credentials across pipelines, microservices, and ephemeral runtime systems.

That is why secrets management belongs in the same governance conversation as PAM, workload identity, and NHI lifecycle control. When access is delivered to applications at runtime, the control model has to cover policy, auditability, offboarding, and privilege scope, not just encryption at rest.

Key questions

Q: What breaks when secrets are hardcoded into DevOps pipelines?

A: Hardcoded secrets break rotation, ownership, and offboarding at the same time. They become embedded in repositories, build systems, and configuration files, which means the credential can survive long after the workflow changes. That creates hidden persistence and makes remediation dependent on finding every copy first.

Q: Why do exposed secrets in applications matter to NHI governance?

A: Because the secret is often the identity. API keys, tokens, and certificates are the practical credentials that let software act, and once they are exposed in code or responses, the compromise path bypasses normal identity controls. NHI governance has to include detection of where those credentials surface, not only where they are stored.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.

Q: Who should own secret rotation and revocation?

A: Ownership should sit with the team that runs the workload, but policy should be set by identity security and enforced through the vault. That avoids orphaned credentials, inconsistent rotation, and offboarding gaps when pipelines or services are retired.

Technical breakdown

Why hard-coded secrets break DevOps identity control

Hard-coded secrets create a governance gap because they move credentials out of the identity system and into code artefacts that are copied, committed, logged, and reused. In NHI terms, the secret becomes a standing bearer credential with no reliable lifecycle boundary. That makes rotation slow, discovery incomplete, and revocation dependent on finding every place the value was copied. In cloud-native environments, that failure compounds because containers, serverless functions, and CI/CD jobs spin up and down faster than manual control processes can track.

Practical implication: treat hard-coded secrets as a lifecycle failure, not a storage problem, and map them to NHI discovery and revocation workflows.

How runtime secret delivery changes the access model

Runtime delivery means the application or pipeline requests a secret when it needs it, rather than embedding or caching the value in configuration. That changes the access pattern from persistent possession to controlled retrieval, which is much closer to how NHI governance should work. The vault becomes the policy decision point for who or what can fetch a credential, under what conditions, and with what audit trail. This is especially important for ephemeral workloads, where access duration and credential persistence should be separated.

Practical implication: design secrets retrieval as a governed transaction, with retrieval logging, short-lived access, and clear service ownership.

Why centralised vaulting matters for audit and offboarding

A central vault gives security teams one place to enforce access rules, log secret retrieval, and revoke credentials when a workload, pipeline, or service account changes. That matters because secrets that are dispersed across repositories, tickets, and environment variables cannot be reliably certified or offboarded. In practice, this is the NHI version of lifecycle governance: if the identity using the secret changes, the credential relationship has to change too. Without that linkage, access outlives accountability.

Practical implication: connect vault records to identity lifecycle events so offboarding, recertification, and rotation happen together.

Threat narrative

Attacker objective: The attacker wants durable machine access that can be reused to reach applications, data, and deployment paths without triggering human authentication.

1. Entry occurs when a secret is hard-coded into source code, a pipeline variable, or a shared file and then exposed through repositories, logs, or collaboration tools.
2. Escalation follows when the exposed credential is reused across multiple applications or systems, allowing an attacker to move from one compromised secret to broader environment access.
3. Impact is achieved when the attacker uses the credential to retrieve data, modify pipelines, or impersonate trusted automation at runtime.

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

DevOps secrets vaults are now an NHI governance layer, not just a convenience feature. Once applications, pipelines, and ephemeral workloads depend on programmatic secret delivery, the vault becomes the control point for identity scope, retrieval policy, and audit evidence. That shifts the discussion from storage hygiene to lifecycle governance for machine credentials. Practitioners should evaluate vaults as part of the NHI control plane, not as a standalone utility.

Standing secret exposure is the real control failure behind most DevOps credential risk. Hard-coded secrets, duplicated copies, and informal sharing create a persistence window that is invisible to normal IAM review cycles. The issue is not only that secrets leak, but that the same credential often survives across code, tickets, and runtime environments long enough to become reusable attack material. Teams need to treat exposure duration as a governance metric.

Runtime secrets delivery works only when identity and workload ownership stay linked. A secret without an associated workload, service account, or pipeline owner cannot be governed cleanly through access reviews or offboarding. That is why the strongest programmes tie secret issuance to a named non-human identity and its lifecycle events. The practitioner conclusion is simple: if the owner is unclear, the control is incomplete.

Secrets sprawl creates an identity blast radius that traditional PAM boundaries do not contain. The more places a credential is copied, the more systems inherit the failure of a single secret. That makes blast-radius reduction a more useful design goal than blanket centralisation language. Teams should measure how far one leaked secret can travel across pipelines, services, and cloud accounts before they can claim effective control.

Centralised vaulting sharpens accountability, but only if governance spans offboarding and recertification. A vault can log retrievals, yet the compliance value is limited if stale credentials remain active after the associated identity changes. This is where NHI lifecycle discipline matters as much as encryption or access policy. The practitioner takeaway is to make secret retirement part of identity governance, not a separate cleanup task.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• The 2025 State of NHIs and Secrets in Cybersecurity also shows that 44% of NHI tokens are exposed in the wild, reinforcing why lifecycle control must extend beyond storage.
• For a broader baseline, the Top 10 NHI Issues resource helps teams map secret sprawl to the wider NHI risk surface.

What this signals

Secret governance is becoming a lifecycle problem before it is a vault problem. Teams that focus only on central storage will miss the operational reality that credentials are copied, shared, and retired across multiple systems. The next maturity step is to connect retrieval policy to identity ownership so the vault can support offboarding, recertification, and runtime access together.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the scale of exposed credentials is now large enough to overwhelm manual cleanup. That makes secret discovery and revocation a programme issue, not a point-in-time remediation exercise.

Identity blast radius: one leaked secret now reaches farther when the same credential is reused across pipelines, services, and cloud accounts. Practitioners should watch for duplicate storage, shared values, and orphaned secrets as leading indicators that their NHI programme is drifting out of control.

For practitioners

• Inventory every secret source Map secrets in repositories, CI/CD variables, ticketing systems, shared documents, and runtime environments, then classify which ones are still active and which identities use them.
• Bind each secret to one accountable identity Tie every credential to a named service account, workload, or pipeline owner so access reviews and offboarding can target a real identity instead of an orphaned value.
• Enforce runtime-only retrieval Move pipelines and applications to fetch secrets at execution time through approved interfaces, and block persistent copies in config files, environment variables, and build artefacts.
• Automate rotation around lifecycle events Rotate secrets when applications are rebuilt, services are decommissioned, or owners change, and revoke any credential that cannot be traced to a current operational need.
• Unify audit trails across identity systems Correlate secret access with PAM, privileged session, and pipeline logs so investigations can show who or what retrieved a credential and when it was used.

Key takeaways

• DevOps secrets vaults are really about governing machine identity access at runtime, not just storing credentials safely.
• The main risk is lifecycle failure, because hard-coded and duplicated secrets survive long enough to be reused across pipelines and services.
• Teams need linked controls for retrieval, audit, rotation, and offboarding or the vault will only hide sprawl instead of reducing it.

Key terms

• DevOps secrets vault: A DevOps secrets vault is a centralized control point for machine credentials used by pipelines, applications, and automated services. It stores secrets securely and delivers them on demand, with policy, audit, and rotation controls that reduce hard-coded exposure and improve governance across non-human identities.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Runtime Secret Delivery: Runtime secret delivery is the practice of supplying credentials only when a workflow actually needs them, rather than storing them permanently in a file or environment. Used well, it reduces exposure, but it still depends on strong ownership, logging, and revocation discipline across the full lifecycle.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Securden's full article covers the operational detail this post intentionally leaves for the source:

• Detailed comparison of platform coverage across PAM, CIEM, endpoint privilege management, and secrets management.
• Feature-by-feature discussion of deployment flexibility, including on-premise and SaaS options.
• Operational examples of REST API, CLI, and SDK-based secret retrieval in DevOps workflows.
• Commercial and operational claims around deployment time and total cost of ownership.

👉 The full Securden article covers secrets delivery, platform scope, and deployment considerations in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.