Secrets management platforms still miss the lifecycle problem

At a glance

What this is: This is a comparison-driven analysis of secrets management platforms, with the key finding that lifecycle control and deployment fit matter more than vaulting alone.

Why it matters: It matters because IAM, PAM, and NHI teams need to govern secrets as living identities across pipelines, runtimes, and human workflows, not as static assets.

By the numbers:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Securden's analysis of secrets management for modern development workflows

Context

Secrets management is the discipline of storing, controlling, and delivering credentials such as API keys, database passwords, tokens, certificates, and private keys so they do not end up embedded in code, shared in spreadsheets, or left exposed in build systems. In practice, the hard part is not vaulting alone but governing the full credential lifecycle as secrets move through development, CI/CD, containers, and production.

That lifecycle challenge is why many teams compare cloud-native secret stores, file-based encryption approaches, and enterprise platforms. The article positions Securden as one option in that market, but the broader issue is the same across tools: if rotation, revocation, auditing, and runtime delivery are not tightly governed, secrets become durable attack paths rather than protected inputs.

For IAM and NHI programmes, this is not a tooling-only problem. Secrets are non-human credentials with access rights, blast radius, and lifecycle obligations, which means they need the same governance discipline applied to human access reviews and privileged access management.

Key questions

Q: How do security teams know whether secrets in CI/CD are actually controlled?

A: Look for three signals: how many secrets a workflow can reach, how long those secrets remain valid, and whether any of them can publish or sign artefacts. If a build job can touch long-lived credentials or production systems, the environment is not controlled. The objective is to reduce reachable secrets and shorten exposure windows.

Q: Why do leaked secrets remain dangerous after they are detected?

A: They remain dangerous because discovery does not automatically invalidate authentication. If the secret is still valid, an attacker can reuse it exactly as the legitimate system would, which turns a past mistake into present access.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: Should organisations choose a vault, a cloud secrets manager, or a unified identity platform?

A: Choose based on where your secrets live, how many environments they must reach, and how much lifecycle control you need. Cloud-native managers work well in simpler footprints, while broader identity platforms become more useful when you need policy, audit, privileged access, and secrets governance in one operating model.

Technical breakdown

Why secrets become identities in modern delivery pipelines

A secret is not just a string stored somewhere safe. Once a token, API key, or certificate is used by a build system, container, or service, it behaves like a non-human identity with permissions, lifetime, and operational context. That makes secrets management part of identity governance, not just storage. The technical risk increases when secrets are copied into multiple environments, passed through CI/CD jobs, or injected into runtime systems without clear ownership. In that model, the weakness is usually not the vault itself but the uncontrolled spread of the credential across execution surfaces.

Practical implication: Map every credential to an owner, a use case, and a revocation path before it enters a pipeline.

Why rotation and revocation must be lifecycle controls, not afterthoughts

Rotation reduces how long a stolen secret remains useful, but revocation is what closes the loop when a credential is no longer needed or has been exposed. A platform can centralize secrets and still leave organisations vulnerable if old credentials remain valid in downstream systems, cached agents, or forgotten integrations. This is why lifecycle governance matters across creation, distribution, rotation, expiry, and invalidation. Automated delivery is only safe when it is paired with reliable retirement of the old credential and auditability of every access event.

Practical implication: Tie every rotation policy to enforced revocation and verify that downstream systems stop accepting the old secret.

How CI/CD and multi-cloud deployments expand the attack surface

CI/CD pipelines, Kubernetes, serverless workloads, and multi-cloud environments all multiply the number of places a secret can be exposed or misused. The more systems that need access, the more pressure there is to weaken controls through shared credentials, broad access policies, or manual handling. That is why modern secrets management has to integrate with orchestration, identity policy, and logging, rather than sit alongside them as a separate vault. Without that integration, the organisation gets local protection but global sprawl.

Practical implication: Reduce secret reuse across environments and require pipeline-specific credentials with narrow scope and telemetry.

Threat narrative

Attacker objective: The attacker aims to turn a leaked credential into repeatable access across development and production systems.

1. Entry occurs when hardcoded credentials, misrouted tokens, or copied secrets are exposed in code, config files, or collaboration tools. Escalation follows when the leaked secret has standing access and can be reused across pipeline, cloud, or database environments without re-authentication. Impact lands when attackers move from one exposed credential to broader system access, data theft, or build compromise.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 management is really lifecycle governance for non-human identities. A token, certificate, or API key is only safe if its creation, use, rotation, and retirement are all governed as one process. The article correctly treats vaulting as necessary but not sufficient, because runtime delivery and revocation decide whether the secret remains an identity with active power. Practitioners should treat every secret as a governed credential, not a stored asset.

Secret sprawl is the real control failure, not vault absence. Most organisations already have some form of secret store, but they still leak because credentials proliferate into pipelines, chat tools, repositories, and downstream services. That creates a governance gap where the organisation believes the vault is the control, while the real problem is uncontrolled credential replication outside it. The practical conclusion is that discovery and lifecycle enforcement matter as much as storage.

Unified identity security only helps when access policy follows the credential everywhere. Bringing PAM, password management, and secrets under one platform can reduce fragmentation, but the architectural win comes from one policy model governing both human and non-human access paths. That matters because the same secret may be used interactively by an admin and programmatically by an application, and both paths need traceability. Security teams should evaluate whether their control model tracks the identity, not just the repository.

Static versus dynamic secrets is still the decisive design choice for many teams. Long-lived credentials create durable blast radius, while ephemeral delivery narrows exposure but raises integration demands. The article shows why many organisations still struggle: they want the security of short-lived credentials without redesigning their delivery workflows. The right question is not which vault is simpler, but which model actually reduces standing privilege in the environments they run.

Secret lifecycle governance must be measured by revocation success, not storage completeness. A platform can hold every credential centrally and still fail if old secrets remain valid, untracked, or recoverable after exposure. That is why lifecycle controls, access auditing, and downstream invalidation are the only meaningful proof of control. Practitioners should judge programmes by how quickly a leaked secret becomes useless.

From our research:

• 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, according to The State of Secrets Sprawl 2026.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, according to The State of Secrets Sprawl 2026.
• If you are building a remediation programme, the Guide to the Secret Sprawl Challenge explains how exposure moves beyond repositories into collaboration tools and CI/CD pipelines.

What this signals

Secret sprawl is now a lifecycle problem, not a repository problem. With hardcoded secrets appearing across code, collaboration tools, and CI/CD systems, teams need to stop treating leak detection as the end state and start treating invalidation as the real control objective. The operating model has to connect vault policy, pipeline identity, and downstream revocation. For teams mapping this to standards, the NIST Cybersecurity Framework 2.0 is a useful anchor for govern, protect, detect, and respond.

Static credentials create the kind of identity blast radius that modern pipelines amplify. Once one secret is reused across build, deploy, and runtime contexts, the compromise path becomes much wider than the original credential suggests. That is why short-lived access, scoped credentials, and telemetry need to be designed together rather than added piecemeal. The OWASP Non-Human Identity Top 10 remains the most useful external reference for framing that risk.

Secret lifecycle governance is becoming a board-level resilience issue. When organisations still find valid secrets long after exposure, the question is no longer whether they have a vault but whether they can prove retirement. Teams should align their internal reporting to measurable revocation outcomes and use NIST SP 800-53 Rev 5 Security and Privacy Controls as the control language for access, audit, and configuration management.

For practitioners

• Inventory every secret-bearing path Trace where API keys, tokens, passwords, certificates, and signing material appear across code, CI/CD, chat, ticketing, and production systems. Build the inventory around where the credential can be copied, not only where it is stored.
• Enforce rotation with verified revocation Do not treat rotation as complete until the previous credential is confirmed invalid in every downstream service. Test the invalidation path for databases, cloud APIs, and build systems so a retired secret cannot be reused.
• Use pipeline-specific credentials with narrow scope Issue separate credentials for build jobs, deployment jobs, and runtime services so one compromise does not expose the whole estate. Pair that with short-lived access and audit logs that identify the calling workload.
• Separate vaulting from detection Keep secret storage, runtime delivery, and leak detection as distinct controls. Repository scanning and collaboration-channel monitoring should feed the response process, while the vault enforces access and rotation policy.
• Measure control success by exposure window Track how long a leaked credential remains usable, not just how many secrets are stored centrally. If a stale secret can still authenticate after disclosure, the programme is not yet controlling lifecycle risk.

Key takeaways

• Secrets management is only effective when storage, delivery, rotation, and revocation are governed as one lifecycle.
• The biggest failure pattern is secret sprawl across pipelines, collaboration tools, and downstream services, where one leaked credential can remain valid long after discovery.
• Teams should measure success by how quickly a leaked secret becomes unusable, not by how many secrets sit inside a vault.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
• Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

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

• Step-by-step secrets lifecycle workflows across creation, rotation, and revocation.
• Integration detail for Jenkins, Ansible, Terraform, Chef, and Puppet.
• Deployment options for self-hosted and managed environments with different control trade-offs.
• Product-specific notes on just-in-time elevation, one-time access, and session recording.

👉 The full Securden article covers platform integration, lifecycle controls, and deployment trade-offs in more 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 identity security programme, it is worth exploring.