Developer-first secrets management still leaves trust gaps

At a glance

What this is: Akeyless argues that secrets management must fit developer workflows, and the core finding is that runtime injection and policy control matter more than hardcoded or manual handling.

Why it matters: IAM, PAM, and NHI teams need to see developer secrets as governed identities, because scattered credentials in pipelines and containers create the same lifecycle and exposure problems as any other non-human access.

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.

👉 Read Akeyless's article on developer-first secrets management for modern toolchains

Context

Secrets management is the discipline of controlling how credentials, tokens, API keys, and certificates are created, distributed, used, and revoked. In developer-heavy environments, the problem is not just storage, but the way secrets move through local machines, CI/CD pipelines, containers, and infrastructure-as-code workflows, where visibility is often fragmented and lifecycle ownership is unclear.

For NHI programmes, that matters because developer-facing secrets are still non-human identities in practice, even when teams treat them as convenience artefacts. The governance gap is familiar: if access can be copied into code, logs, env files, or pipeline variables, then least privilege and revocation are already weaker than the architecture assumes.

Akeyless is used here as a source on developer-first secrets handling, not as the subject of endorsement. The broader lesson is that modern delivery speed only remains safe when secret injection, access policy, and auditability are built to survive the pace of engineering change.

Key questions

Q: How should security teams handle exposed secrets in modern software pipelines?

A: Treat exposed secrets as identity incidents, not just code defects. Identify the owning service, revoke the credential everywhere it may be used, and verify that downstream automation still functions. The goal is to shorten the secret’s usable life while preserving legitimate operations through a controlled rotation process.

Q: Why do hardcoded secrets remain such a serious risk in modern DevOps?

A: Because one exposed credential can be copied into multiple systems and reused long after the original leak. Hardcoding creates invisible persistence, weakens auditability, and bypasses lifecycle controls that would otherwise let teams rotate or revoke access quickly. Git-based workflows make the problem scale faster than manual review can contain.

Q: What breaks when secrets management is separated from identity governance?

A: When secrets management is separated from identity governance, credentials can outlive approvals, regions, or vendor relationships. That creates a mismatch between who is supposed to control access and who actually can. The result is weak revocation, poor auditability, and higher risk in distributed estates.

Q: How do organisations know if secrets management is actually working?

A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration. If secret scanners still find high-value tokens in routine developer paths, the control is not operating as designed, regardless of policy statements or vault adoption.

Technical breakdown

Secrets sprawl in developer toolchains

Secrets sprawl happens when the same credential appears in source code, local files, pipeline variables, deployment configs, and runtime environments. Each copy increases exposure because control moves from a single governed system to multiple execution contexts with different logging, caching, and retention behaviour. In CI/CD, the risk is amplified by automation that handles secrets at build time, deploy time, and runtime, often without a shared lifecycle model. The result is not just leakage, but loss of authoritative control over where the secret exists and who can still use it.

Practical implication: map every secret-bearing workflow to a single owner and force an explicit source of truth for issuance, rotation, and revocation.

Runtime injection versus hardcoded credentials

Runtime injection replaces static storage with ephemeral delivery at execution time, which reduces long-lived exposure but does not eliminate trust assumptions. The secret still exists inside the session, container, or job environment, so the security model depends on the integrity of the runtime boundary, logging controls, and downstream access scope. For workloads that spin up and disappear quickly, the goal is to keep credentials out of code and off disk while preserving deterministic access for the exact job that needs them. That shifts the control point from the repository to the execution layer.

Practical implication: prefer runtime injection for ephemeral workloads, but pair it with strict log suppression, short TTLs, and post-execution revocation.

RBAC and dynamic access policies for secrets

RBAC gives role-based permission boundaries, while dynamic access policies add context such as environment, workload, or identity provider state. Used well, that combination limits who can retrieve which secret and when, but only if policy is applied consistently across development, testing, and production. The practical weakness in many environments is not the absence of roles, but the mismatch between identity lifecycle and secret lifecycle, especially when onboarding and offboarding are handled separately from access policy. That creates lingering entitlement even when the credential itself is rotated.

Practical implication: align secret access policy with joiner-mover-leaver workflows so that entitlement removal happens at the same pace as identity change.

Threat narrative

Attacker objective: The attacker wants persistent, reusable access that can be used to tamper with builds, move between systems, or extract data without triggering immediate detection.

1. Entry occurs when hardcoded secrets, pipeline variables, or exposed configuration files make credentials available to an attacker or unauthorized insider.
2. Escalation follows when the stolen secret is reused across environments, giving access to CI/CD jobs, runtime containers, or cloud services beyond the original intended scope.
3. Impact occurs when the credential enables source code theft, build tampering, environment compromise, or broader lateral movement through connected systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Developer-first secrets management is really lifecycle governance for non-human identities. Once a credential enters a pipeline, container, or local development workflow, it behaves like any other NHI and needs issuance, access, rotation, and revocation rules that survive engineering speed. The mistake is treating developer convenience as separate from identity governance. Practitioners should manage these secrets as governed identities, not as disposable implementation details.

Secrets sprawl creates identity blast radius, not just exposure risk. Every extra copy of a credential expands the number of places where trust can be abused, logged, cached, or exfiltrated. That is why centralisation alone is not enough if the workflow still emits credentials into multiple execution layers. The practical conclusion is that blast-radius control must be measured across the full delivery chain, not inside the vault alone.

Runtime injection narrows the exposure window but does not remove the trust debt. A secret delivered into a build or container is still a credential with an identity lifecycle, and short-lived delivery only helps if the downstream environment is tightly constrained. This is where the ephemeral credential trust debt concept matters: the industry keeps reducing storage duration while leaving reuse, propagation, and revocation assumptions largely intact. Practitioners should treat short-lived access as a control layer, not a complete governance model.

Developer secrets handling increasingly intersects with AI-assisted code creation and machine-generated leaks. The article is framed around developer workflows, but the same distribution paths now carry secrets from copilots, agents, and automated code generation into repositories and pipelines. That widens the identity problem from human error to machine-assisted propagation. Security teams should expect secrets governance to become a shared control plane across human, NHI, and emerging autonomous workflows.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• That is why the Guide to the Secret Sprawl Challenge matters for teams trying to govern secrets across the whole delivery chain.

What this signals

Ephemeral credential trust debt: reducing secret lifetime is only half the problem if teams still allow the same credential to propagate across pipelines, logs, and runtime layers. The programme risk is that revocation looks complete while usable copies continue to exist in adjacent systems, so security teams need to measure propagation paths as well as rotation cadence.

The next governance step is to treat developer secrets as part of the broader NHI estate, with policies that connect code, CI/CD, container, and workforce identity controls. That aligns with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, especially where access, auditability, and recovery depend on the same credential lifecycle.

For practitioners

• Inventory every secret-bearing workflow Trace credentials from local development through Git, CI/CD, containers, and IaC so each path has an owner, rotation rule, and revocation trigger. Use this to eliminate shadow copies in env files, logs, and pipeline variables.
• Replace hardcoded credentials with runtime delivery Move secrets out of source code and disk, then inject them only at execution time with short TTLs and strict runtime boundaries. Prioritise ephemeral jobs, build runners, and container workloads first.
• Align secrets policy with identity lifecycle Tie secret issuance and revocation to joiner-mover-leaver processes so onboarding, role changes, and offboarding remove access from the same control plane. Review vendor, contractor, and service-account paths together.
• Audit developer access for overexposure Check whether developers and automation accounts can retrieve more secrets than their jobs require, especially across shared environments. Use RBAC and dynamic policy to narrow retrieval rights by workload and stage.

Key takeaways

• Developer-first secrets management only works when secret handling is governed like any other non-human identity lifecycle.
• Hardcoded and overdistributed credentials create blast radius that runtime injection can reduce but not eliminate.
• The decisive control is not storage convenience, but enforceable issuance, rotation, and revocation across the full delivery chain.

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.
• Runtime injection: Runtime injection is the practice of supplying credentials or tokens directly into an application or agent at execution time instead of storing them locally. It keeps secrets out of files and shared environment variables, but only works well when the runtime boundary is tightly controlled and observable.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• 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

Akeyless's full article covers the implementation detail this post intentionally leaves for the source:

• CLI, SDK, and REST API workflow details for pulling secrets during builds and runtime jobs
• GitOps and IaC configuration patterns for Terraform, Helm, ArgoCD, and Kubernetes
• CI/CD integration steps for GitHub Actions, GitLab CI, Jenkins, and CircleCI
• Local development handling for .env files, environment variables, and identity provider authentication

👉 The full Akeyless post covers CLI workflows, GitOps patterns, and CI/CD runtime injection details.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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.