Secrets management best practices are still failing at scale

At a glance

What this is: This is a practitioner guide to secrets management that argues secure storage, rotation, scanning, and CI/CD integration must work together across the full secret lifecycle.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat secrets as governed identities with lifecycle controls, not as isolated credentials hidden in a vault.

By the numbers:

• Organizations face significant risks from secrets sprawl, with 96% reporting secrets scattered across code, configuration files, and multiple environments.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Cycode's secrets management best practices guide

Context

Secrets management is the discipline of storing, distributing, rotating, and monitoring credentials such as API keys, tokens, passwords, and certificates. The core problem is not whether a vault exists, but whether secrets remain governed after they leave it and during the many places they are copied, injected, logged, or reused.

For IAM and NHI programmes, this is a lifecycle and governance issue, not a tooling checkbox. A secret is a non-human identity artefact with access value, so fragmentation across code, CI/CD, collaboration tools, and cloud environments creates the same class of risk as unmanaged service accounts or orphaned tokens.

Cycode frames the challenge as a broad application security and delivery problem, but the operational reality is stricter: secrets management fails when discovery, revocation, and policy enforcement are not connected end to end. That is typical in modern development environments, not an edge case.

Key questions

Q: How should security teams handle cloud secrets that are shared across applications and pipelines?

A: Treat shared secrets as a governance defect, not just an operational convenience. Assign ownership, reduce reuse, and move toward per-workflow credentials with automatic expiry. Shared secrets increase blast radius because one leak can affect multiple systems at once. A good control model limits where a secret can be used, how long it lives, and who can reissue it.

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 breaks when teams rely on long-lived secrets in modern delivery pipelines?

A: Long-lived credentials create standing access that persists across builds, deployments, and troubleshooting sessions. They are copied into logs, configs, and artifacts, which means one leak can survive multiple workflow stages and remain usable far longer than intended.

Q: How do IAM and NHI programmes reduce secrets sprawl without slowing delivery?

A: Use workload identity, runtime injection, and environment-based segmentation so credentials are issued only when needed and only where needed. That preserves developer velocity while shrinking the number of places a secret can leak or be reused.

Technical breakdown

Secrets sprawl across code, pipelines, and collaboration tools

Secrets sprawl occurs when credentials are duplicated across repositories, build systems, tickets, chat tools, and cloud configurations instead of being governed from a single control plane. Once that happens, discovery becomes harder because no single inventory reflects the real exposure surface. The issue is not just leakage in source code. It is the persistence of credential copies in every system that touches delivery, operations, and troubleshooting. In practice, this turns secrets into distributed access artefacts with unclear ownership and inconsistent retirement.

Practical implication: inventory all secret touchpoints, not just vaults, because unmanaged copies are where the breach path usually persists.

Dynamic secrets and short-lived credentials reduce persistence

Dynamic secrets are credentials generated on demand with a limited lifetime, often tied to a specific workload or session. They reduce the window in which a leaked secret remains usable, which is why they are better suited to CI/CD runners, serverless functions, and ephemeral jobs than long-lived static credentials. However, the security gain depends on whether expiration, renewal, and revocation are automated and enforced consistently. If expiry is optional or manually managed, the credential still behaves like a standing secret in practice.

Practical implication: replace long-lived pipeline secrets with short-lived workload credentials where the platform can enforce expiry automatically.

Secret scanning only works when validation and revocation follow detection

Secret scanning identifies exposed credentials, but detection alone does not reduce risk if the secret remains active. Mature workflows validate whether a discovered secret is live, then route it into revocation, rotation, or incident response based on exploitability rather than mere presence. This matters because leaked credentials can be discovered in code, logs, chat, or image layers long after publication. Without validation, security teams spend time triaging noise instead of removing usable access.

Practical implication: pair scanning with validation and automated revocation so exposed secrets cannot remain exploitable after discovery.

Threat narrative

Attacker objective: The attacker’s objective is to turn a leaked credential into persistent unauthorized access before defenders discover and revoke it.

1. Entry occurs when secrets are embedded in source code, CI/CD configs, or collaboration tools and are then discovered through repository scanning, logs, or public exposure.
2. Escalation occurs when the exposed credential is still active, allowing access to cloud services, deployment systems, or downstream applications without additional user interaction.
3. Impact occurs when the attacker uses the credential to move into systems, exfiltrate data, or alter delivery workflows before the secret is rotated or revoked.

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 sprawl is a governance failure, not a storage failure. Central vaults matter, but they do not solve the fact that secrets are copied into code, CI/CD, chat, tickets, and artifacts. That fragmentation breaks the assumption that a secret has one governed home and one revocation path. Practitioners should treat every copy of a secret as part of the identity lifecycle, not as a mere convenience artifact.

Secret lifecycle management is now an NHI discipline. API keys, tokens, certificates, and workload credentials behave like non-human identities because they confer access and require provisioning, monitoring, and offboarding. The control problem is not isolated to secrets teams. IAM, PAM, and application security all need the same accountability model for issuance, usage, and retirement.

Ephemeral credential trust debt: Short-lived credentials reduce exposure time, but only when the surrounding platform can validate, inject, and revoke them at runtime. If a secret can be copied into logs, cached in build outputs, or reused across environments, the organization still carries trust debt that outlives the intended session. The implication is that lifecycle design matters more than the label on the secret.

CI/CD is the highest-friction control point in secrets governance. Delivery pipelines aggregate the largest concentration of credentials, yet they are also the easiest place for secrets to leak into logs, environment variables, and build artifacts. That makes pipeline identity and access decisions a governance problem, not just a DevOps implementation detail. Practitioners should expect their most difficult revocation and audit questions to come from CI/CD.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 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.
• That scale makes the Guide to the Secret Sprawl Challenge the natural next step for teams trying to map exposure paths and reduction priorities.

What this signals

Secret sprawl is becoming a lifecycle control problem, not a detection problem. With 64% of leaked secrets still valid and exploitable today, the governance failure is the delay between discovery and revocation, not the absence of alerts. Teams that still treat scanning as the finish line will continue to carry exposed access into production.

Ephemeral credential design is now the practical boundary between safe automation and standing risk. The more CI/CD and cloud workflows depend on runtime-issued credentials, the less value long-lived secrets retain for attackers. That is why secret lifecycle architecture should sit alongside IAM, PAM, and workload identity planning, not underneath it.

Secret sprawl challenge: fragmented storage and duplicated credentials create a durable trust deficit across code, chat, and pipeline systems. Teams should align their remediation roadmap with the Guide to the Secret Sprawl Challenge and use OWASP Non-Human Identity Top 10 to frame control gaps in NHI terms.

For practitioners

• Map every secret touchpoint in the delivery chain Catalogue where credentials appear in code, repositories, build logs, collaboration tools, container images, and cloud configuration files. Use that inventory to define ownership, lifecycle state, and revocation paths for each secret class.
• Replace persistent pipeline secrets with short-lived workload credentials Use runtime injection, workload identity federation, and session-scoped tokens so CI/CD jobs do not depend on stored long-lived secrets. Restrict each pipeline stage to the minimum credential set required for that stage.
• Bind detection to validation and revocation Do not stop at discovery. Confirm whether a leaked secret is active, then trigger automatic rotation or revocation before the credential can be reused elsewhere.
• Separate production credentials from non-production workflows Prevent test and build stages from accessing production secrets, and use branch protections or approval workflows when elevated credentials are unavoidable.
• Treat secret misuse as an audit and response event Log who accessed which secret, when, and from where, then route unusual access patterns into incident response and forensic review.

Key takeaways

• Secrets management fails when organizations treat storage as the problem and ignore the lifecycle of every credential copy.
• Detection without revocation leaves real attack surface behind, because exposed secrets can remain active long after discovery.
• CI/CD, collaboration tools, and cloud configs need shared governance, or secrets sprawl will keep outrunning IAM controls.

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.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Secret Validation: Secret validation is the attacker practice of testing stolen credentials against the target provider to confirm that they still work. In supply chain attacks, this turns a stolen token from a possibility into an active access path, often within minutes or hours of theft.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.

What's in the full article

Cycode's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step implementation guidance for centralized vaulting, rotation, and monitoring across the SDLC
• Detailed tool selection criteria for secrets scanning, validation, and pipeline integration
• Expanded examples of CI/CD, cloud, and collaboration-tool exposure paths that this post only summarises
• Operational guidance on handling secret remediation, compliance evidence, and platform evaluation

👉 Cycode's full guide covers implementation detail on storage, rotation, scanning, and CI/CD controls.

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 building or maturing an IAM programme, it is worth exploring.